From: Tom Lijnse (Tom.Lijnse@globalknowledge.nl)
Date: Fri Jun 17 2005 - 10:22:18 GMT-3
Hi Tim,
Just to see it for myself I quickly labbed it up. I included the config
and some show output and debugs below.
I basically had to draw the same conclusion: It just doesn't work. The
reliable link is negotiated correctly, the packets are routed to the
BRI, they get encapsulated and even arrive at the other end (as can be
seen from debug ppp packet), but they don't seem to get decapsulated
correctly.
On both sides I have a 'debug ip packet' matching only ICMP and a 'debug
ppp packet'. On the PPP layer all seems to be well. The packets are sent
on R5 and received on R4, but on the IP level I only see the packets
being sent on R5, not received on R4.
The only conclusion I can draw is that this is a bug.
As to the 'why?': I honestly don't know why Cisco keeps adding bugs to
their software ;-)
Basically, I think nobody in the real world ever uses PPP reliable link
on ISDN, so nobody ever bothered to open a TAC case for this and that's
why this bug is still in there.
I have successfully configured ppp reliable link on serials in the past,
so it does not seem to be a problem with the feature itself, but the
combination with ISDN seems to be problematic.
Hope this helps,
Tom Lijnse
CCIE #11031
Global Knowledge
------------------------------------------------------------------------
----R5#sh run int bri 1/0 Building configuration...
Current configuration : 227 bytes ! interface BRI1/0 ip address 10.4.5.5 255.255.255.0 encapsulation ppp dialer idle-timeout 300 dialer map ip 10.4.5.4 name R4 66 dialer-group 1 isdn switch-type basic-net3 ppp reliable-link ppp authentication chap end
R5# R5#sh int bri 1/0:1 BRI1/0:1 is up, line protocol is up Hardware is BRI MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, LCP Open Open: CDPCP, IPCP LAPB DTE, state CONNECT, modulo 8, k 7, N1 12048, N2 3 T1 3000, T2 0, interface outage (partial T3) 0, T4 0, PPP over LAPB VS 7, VR 2, tx NR 2, Remote VR 7, Retransmissions 0 Queues: U/S frames 0, I frames 0, unack. 0, reTx 0 IFRAMEs 79/74 RNRs 0/0 REJs 0/0 SABM/Es 1/1 FRMRs 0/0 DISCs 0/0, loopback not set idle 00:04:24 <sniP>
R5#deb ppp pack PPP packet display debugging is on R5#deb ip pack 101 det IP packet debugging is on (detailed) for access list 101 R5# R5#ping 10.4.5.4 rep 3 time 1
Type escape sequence to abort. Sending 3, 100-byte ICMP Echos to 10.4.5.4, timeout is 1 seconds:
*Mar 2 18:29:02.805: IP: tableid=0, s=10.4.5.5 (local), d=10.4.5.4 (BRI1/0), routed via RIB *Mar 2 18:29:02.805: IP: s=10.4.5.5 (local), d=10.4.5.4 (BRI1/0), len 100, sending *Mar 2 18:29:02.805: ICMP type=8, code=0 *Mar 2 18:29:02.805: BR1/0:1 PPP: O pkt type 0x0021, datagramsize 102 *Mar 2 18:29:03.805: IP: tableid=0, s=10.4.5.5 (local), d=10.4.5.4 (BRI1/0), routed via RIB *Mar 2 18:29:03.805: IP: s=10.4.5.5 (local), d=10.4.5.4 (BRI1/0), len 100, sending *Mar 2 18:29:03.805: ICMP type=8, code=0 *Mar 2 18:29:03.805: BR1/0:1 PPP: O pkt type 0x0021, datagramsize 102.. Success rate is 0 percent (0/3) R5# *Mar 2 18:29:04.805: IP: tableid=0, s=10.4.5.5 (local), d=10.4.5.4 (BRI1/0), routed via RIB *Mar 2 18:29:04.805: IP: s=10.4.5.5 (local), d=10.4.5.4 (BRI1/0), len 100, sending *Mar 2 18:29:04.805: ICMP type=8, code=0 *Mar 2 18:29:04.805: BR1/0:1 PPP: O pkt type 0x0021, datagramsize 102 R5# R5#sh access-l Extended IP access list 101 10 permit icmp any any (3 matches)
------------------------------------------------------------------------ ----
R4#sh run int bri 1/0 Building configuration...
Current configuration : 227 bytes ! interface BRI1/0 ip address 10.4.5.4 255.255.255.0 encapsulation ppp dialer idle-timeout 300 dialer map ip 10.4.5.5 name R5 65 dialer-group 1 isdn switch-type basic-net3 ppp reliable-link ppp authentication chap end
R4# R4#sh int bri 1/0:1 BRI1/0:1 is up, line protocol is up Hardware is BRI MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, LCP Open Open: CDPCP, IPCP LAPB DCE, state CONNECT, modulo 8, k 7, N1 12048, N2 3 T1 3000, T2 0, interface outage (partial T3) 0, T4 0, PPP over LAPB VS 0, VR 5, tx NR 5, Remote VR 0, Retransmissions 0 Queues: U/S frames 0, I frames 0, unack. 0, reTx 0 IFRAMEs 88/93 RNRs 0/0 REJs 0/0 SABM/Es 1/1 FRMRs 0/0 DISCs 0/0, loopback not set idle 00:01:27 <snip> R4#deb ppp pack PPP packet display debugging is on R4#deb ip pack 101 det IP packet debugging is on (detailed) for access list 101 *Mar 2 18:28:59.757: BR1/0:1 PPP: I pkt type 0x0021, datagramsize 102 link[ip] *Mar 2 18:29:00.757: BR1/0:1 PPP: I pkt type 0x0021, datagramsize 102 link[ip] *Mar 2 18:29:01.757: BR1/0:1 PPP: I pkt type 0x0021, datagramsize 102 link[ip] R4# R4#sh access-l Extended IP access list 101 10 permit icmp any any
-----Original Message----- From: ccie2be [mailto:ccie2be@nyc.rr.com] Sent: vrijdag 17 juni 2005 13:13 To: Tom Lijnse; 'John Matus'; swm@emanon.com; 'lab' Subject: RE: ppp reliable link vs. ppp quality link
Hi Tom,
Thanks again for your explanation.
By any chance, do you know why using ppp reliable-link seems not to work over bri interfaces.
I've tried using this feature a number of times with different config's and it never worked.
(I thought, mistakenly it turned out, that the problem was I was configuring this command on both sides because pings would only work when this was configured on just one side. In reality, what was occurring was that during negotiation, ppp wasn't using it because it wasn't supported by both sides.)
TIA, Tim
-----Original Message----- From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Tom Lijnse Sent: Friday, June 17, 2005 4:17 AM To: John Matus; swm@emanon.com; ccie2be; lab Subject: RE: ppp reliable link vs. ppp quality link
Hi John,
Okay, let me try to answer your original question.
I'd say that when an exercise calls for a reliable link and the link is already running PPP you should configure 'ppp reliable-link'. This will force PPP to use LAPB to add sequence numbers to the packets, use windowing, acknowledgments, etc. in order to make sure that any packet that is sent across the link will eventually arrive. If it would get lost in transit the LAPB mechanism will just retransmit the packet until the other side acknowledges it.
PPP Quality on the other hand just measures the error rate of the circuit and if that drops below a certain threshold it will disable the link. The idea here is that if the quality of a link is too low you'd rather not use it at all and hopefully reroute your traffic onto another link. In itself this mechanism does not prevent packet loss, so I would not call this a reliable link.
Hope this helps,
Tom Lijnse
CCIE #11031 Global Knowledge
-----Original Message----- From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of John Matus Sent: vrijdag 17 juni 2005 5:37 To: swm@emanon.com; 'ccie2be'; 'lab' Subject: Re: ppp reliable link vs. ppp quality link
ok, while all of this debugging is really interesting , i think you missed the gist of my question. my question was, if i can remember it correctly, "what constitutes a 'reliable' link?". if you consider ppp quality-link as an example, it decided what the quality is by a ration between the number of packets sent/dropped on the interface. but what constitutes "reliability"?? if this were a lab task, would they say, "make sure the link is reliable", or would they say "use lapb's to provide a reliable connection" or would they say something completely different? i'm still
unsure what the mechanism behind 'Reliable'.
Regards,
John D. Matus MCSE, CCNP Office: 818-782-2061 Cell: 818-430-8372 jmatus@pacbell.net ----- Original Message ----- From: "Scott Morris" <swm@emanon.com> To: "'ccie2be'" <ccie2be@nyc.rr.com>; "'John Matus'" <jmatus@pacbell.net>; "'lab'" <ccielab@groupstudy.com> Sent: Thursday, June 16, 2005 6:24 AM Subject: RE: ppp reliable link vs. ppp quality link
> Well, there's no reason it shouldn't work on both ends. It's a negotiated > parameter. > > Here's some debugs from running this on a serial link (more in a > minute)... > > Emanon-R3# > 14w3d: %LINK-3-UPDOWN: Interface Serial1/1, changed state to up > Jun 17 07:56:37.898: Se1/1 PPP: Using default call direction > Jun 17 07:56:37.898: Se1/1 PPP: Treating connection as a dedicated line > Jun 17 07:56:37.902: Se1/1 PPP: Phase is ESTABLISHING, Active Open > Jun 17 07:56:37.902: Se1/1 LCP: O CONFREQ [Closed] id 1 len 14 > Jun 17 07:56:37.902: Se1/1 LCP: MagicNumber 0x0DF2172F (0x05060DF2172F) > Jun 17 07:56:37.902: Se1/1 LCP: ReliableLink window 7 addr 0 > (0x0B040700) > Jun 17 07:56:37.926: Se1/1 LCP: I CONFREQ [REQsent] id 1 len 14 > Jun 17 07:56:37.930: Se1/1 LCP: MagicNumber 0xEF11847D (0x0506EF11847D) > Jun 17 07:56:37.930: Se1/1 LCP: ReliableLink window 7 addr 0 > (0x0B040700) > Jun 17 07:56:37.930: Se1/1 LCP: O CONFNAK [REQsent] id 1 len 8 > Jun 17 07:56:37.930: Se1/1 LCP: ReliableLink window 7 addr 3 > (0x0B040703) > Jun 17 07:56:37.930: Se1/1 LCP: I CONFNAK [REQsent] id 1 len 8 > Jun 17 07:56:37.934: Se1/1 LCP: ReliableLink window 7 addr 1 > (0x0B040701) > Jun 17 07:56:37.934: Se1/1 LCP: O CONFREQ [REQsent] id 2 len 14 > Jun 17 07:56:37.934: Se1/1 LCP: MagicNumber 0x0DF2172F (0x05060DF2172F) > Jun 17 07:56:37.934: Se1/1 LCP: ReliableLink window 7 addr 1 > (0x0B040701) > Jun 17 07:56:37.934: Se1/1 LCP: I CONFREQ [REQsent] id 2 len 14 > Jun 17 07:56:37.938: Se1/1 LCP: MagicNumber 0xEF11847D (0x0506EF11847D) > Jun 17 07:56:37.938: Se1/1 LCP: ReliableLink window 7 addr 3 > (0x0B040703) > Jun 17 07:56:37.938: Se1/1 LCP: O CONFACK [REQsent] id 2 len 14 > Jun 17 07:56:37.938: Se1/1 LCP: MagicNumber 0xEF11847D (0x0506EF11847D) > Jun 17 07:56:37.938: Se1/1 LCP: ReliableLink window 7 addr 3 > (0x0B040703) > Jun 17 07:56:37.938: Se1/1 LCP: I CONFACK [ACKsent] id 2 len 14 > Jun 17 07:56:37.942: Se1/1 LCP: MagicNumber 0x0DF2172F (0x05060DF2172F) > Jun 17 07:56:37.942: Se1/1 LCP: ReliableLink window 7 addr 1 > (0x0B040701) > Jun 17 07:56:37.942: Se1/1 LCP: State is Open > Jun 17 07:56:37.954: Se1/1 PPP: Phase is FORWARDING, Attempting Forward > Jun 17 07:56:38.002: Se1/1 PPP: Queue CDPCP code[1] id[1] > Jun 17 07:56:38.002: Se1/1 PPP: Queue IPCP code[1] id[1] > Jun 17 07:56:38.006: Se1/1 PPP: Phase is ESTABLISHING, Finish LCP > Jun 17 07:56:38.010: Se1/1 PPP: Phase is UP > Jun 17 07:56:38.010: Se1/1 IPCP: O CONFREQ [Closed] id 1 len 10 > Jun 17 07:56:38.010: Se1/1 IPCP: Address 172.17.1.3 (0x0306AC110103) > Jun 17 07:56:38.010: Se1/1 CDPCP: O CONFREQ [Closed] id 1 len 4 > Jun 17 07:56:38.010: Se1/1 PPP: Process pending packets > Jun 17 07:56:38.014: Se1/1 IPCP: Redirect packet to Se1/1 > Jun 17 07:56:38.014: Se1/1 IPCP: I CONFREQ [REQsent] id 1 len 10 > Jun 17 07:56:38.014: Se1/1 IPCP: Address 172.17.1.4 (0x0306AC110104) > Jun 17 07:56:38.014: Se1/1 IPCP: O CONFACK [REQsent] id 1 len 10 > Jun 17 07:56:38.014: Se1/1 IPCP: Address 172.17.1.4 (0x0306AC110104) > Jun 17 07:56:38.018: Se1/1 CDPCP: Redirect packet to Se1/1 > Jun 17 07:56:38.018: Se1/1 CDPCP: I CONFREQ [REQsent] id 1 len 4 > Jun 17 07:56:38.018: Se1/1 CDPCP: O CONFACK [REQsent] id 1 len 4 > Jun 17 07:56:38.018: Se1/1 CDPCP: I CONFACK [ACKsent] id 1 len 4 > Jun 17 07:56:38.018: Se1/1 CDPCP: State is Open > Jun 17 07:56:38.022: Se1/1 IPCP: I CONFACK [ACKsent] id 1 len 10 > Jun 17 07:56:38.022: Se1/1 IPCP: Address 172.17.1.3 (0x0306AC110103) > Jun 17 07:56:38.022: Se1/1 IPCP: State is Open > Jun 17 07:56:38.026: Se1/1 IPCP: Install route to 172.17.1.4 > Jun 17 07:56:38.026: Se1/1 IPCP: Add link info for cef entry 172.17.1.4 > 14w3d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/1, changed > state to up > Emanon-R3# > > You'll see on that that the reliable link is actually a negotiated piece > along with the changes in the magic number part... > You should be able to verify its operation afterwards on "show interface" > > Emanon-R3#sh int s1/1 > Serial1/1 is up, line protocol is up > Hardware is QUICC with integrated T1 CSU/DSU > Internet address is 172.17.1.3/24 > MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, > reliability 255/255, txload 1/255, rxload 1/255 > Encapsulation PPP, LCP Open > Open: CDPCP, IPCP > LAPB DCE, state CONNECT, modulo 8, k 7, N1 12048, N2 3 > T1 3000, T2 0, interface outage (partial T3) 0, T4 0, PPP over LAPB > VS 0, VR 7, tx NR 7, Remote VR 0, Retransmissions 0 > Queues: U/S frames 0, I frames 0, unack. 0, reTx 0 > IFRAMEs 32/23 RNRs 0/0 REJs 0/0 SABM/Es 1/1 FRMRs 0/0 DISCs 0/0, > loopback not set > Last input 00:00:04, output 00:00:00, output hang never > Last clearing of "show interface" counters 00:01:26 > Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 > Queueing strategy: weighted fair > Output queue: 0/1000/64/0 (size/max total/threshold/drops) > Conversations 0/2/256 (active/max active/max total) > Reserved Conversations 0/0 (allocated/max allocated) > Available Bandwidth 1158 kilobits/sec > 5 minute input rate 0 bits/sec, 0 packets/sec > 5 minute output rate 0 bits/sec, 0 packets/sec > 48 packets input, 1632 bytes, 0 no buffer > Received 0 broadcasts, 0 runts, 0 giants, 0 throttles > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort > 50 packets output, 4269 bytes, 0 underruns > 0 output errors, 0 collisions, 1 interface resets > 0 output buffer failures, 0 output buffers swapped out > 1 carrier transitions > DCD=up DSR=up DTR=up RTS=up CTS=up > > Emanon-R3# > > Notice all the LAP-B stuff. This, by the way, is all part of RFC 1663. > > Now, the side note... I tried to lab it up real quick on ISDN using one > of > the vedor's pods, and something really interesting happened... As soon as > I > initiated the line and it negotiated stuff (correctly, by the way) one of > the routers committed suicide. It reloaded, lost its config and more > importantly lost the BRI interface! Kinda cool to say the least, and I'm > sure it's not related to this configuration (that would be the WAY > opposite > of "reliable"). But I have no other explanation or debugs at this time... > More later when I get to the end of my BRI disappearance! > > Scott > > -----Original Message----- > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of > ccie2be > Sent: Thursday, June 16, 2005 7:41 AM > To: 'John Matus'; 'lab' > Subject: RE: ppp reliable link vs. ppp quality link > > John, > > I can't answer your question but I came across an interesting situation > with > ppp reliable-link very recently. > > I had enabled reliable-link on both sides of the link and that brought the > link down. > > When reliable-link was only enabled on one side (it didn't which side), it > worked fine. > > I couldn't figure out why that was and I'm still annoyed about that. > > So, I'm with you - I'd like to get to bottom of these questions. > > Unfortunately, the Doc-CD falls far short of providing complete and useful > info on these issues. > > Tim > > -----Original Message----- > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of > John > Matus > Sent: Thursday, June 16, 2005 2:18 AM > To: lab > Subject: ppp reliable link vs. ppp quality link > > ok, ppp quality link looks at the number of packets dropped as a > percentage > in order to calculate the "quality" of the link. > ppp reliable link uses lapb's in order to negotiate a "reliable" > link......does that mean the lapb's provide an error checking mechanism? > i > was under the impression that ppp had an error checking mechanism built > into > it as well.... > so, does it make sense to use "reliable-link" and "quality-link" at the > same > time?? hmm...... > > > Regards, > > John D. Matus > MCSE, CCNP > Office: 818-782-2061 > Cell: 818-430-8372 > jmatus@pacbell.net > >
This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:41 GMT-3