RE: ppp reliable link vs. ppp quality link

From: Gustavo Novais (gustavo.novais@novabase.pt)
Date: Fri Jul 15 2005 - 14:58:28 GMT-3


Hi all, sorry to pick up a old issue, but I was faced with it on a exercise lab...

The documentation on DOC CD says that we do not need compression in order to make ppp reliable link work, but that was the only way that I was able to put it to work. The negotiation took a while to complete, about 15 icmp packets, but it did work!

My config looked like this on both sides...

R5#sh run int bri 0/0
Building configuration...

Current configuration : 331 bytes
!
interface BRI0/0
 description AB - 214189541
 ip address 216.30.25.5 255.255.255.224
 encapsulation ppp
 dialer map ip 216.30.25.2 name R2 broadcast 214189540
 dialer hold-queue 50
 dialer-group 1
 isdn switch-type basic-net3
 compress stac
 ppp reliable-link
 ppp authentication pap
 ppp pap sent-username R5 password 0 R5
end

R5#

And my result was

R5#
R5#ping 216.30.25.2 repeat 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 216.30.25.2, timeout is 2 seconds:
.
*Mar 1 05:52:31.589: %LINK-3-UPDOWN: Interface BRI0/0:2, changed state to up...
*Mar 1 05:52:37.595: %ISDN-6-CONNECT: Interface BRI0/0:2 is now connected to 214189540 ..!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 94 percent (94/100), round-trip min/avg/max = 20/22/93 ms
R5#
*Mar 1 05:52:42.667: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0/0:2, changed state to up
R5#

Without compress it simply didn't work

R5#ping 216.30.25.2 repeat 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 216.30.25.2, timeout is 2 seconds:
.
*Mar 1 05:58:29.047: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to up...
*Mar 1 05:58:35.048: %ISDN-6-CONNECT: Interface BRI0/0:1 is now connected to 214189540 ...
*Mar 1 05:58:40.105: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0/0:1, changed state to up............................
Success rate is 0 percent (0/35)
R5#

Any thoughts? The docs states that it doesn't support multilink ppp, but is the extra header introduced by LAPB so large that the packets do not go by a 64k B channel?

TIA

Gustavo

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Scott Morris
Sent: sabado, 18 de Junho de 2005 6:02
To: 'ccie2be'; 'John Matus'; 'lab'
Subject: RE: ppp reliable link vs. ppp quality link

No, actually, I wasn't...

I labbed it up here at home, and at least I didn't have BRI interfaces commit suicide this time (they did come back on the other router, but it was about 30 minutes later than the reload (go figure))....

But still nothing. Reliable link DOES get negotiated, and when doing "debug ppp packet" I see the IP packets coming in on the received side. When doing "debug lapb" I see what looks like the correct interaction....

When looking at the IP packets, when reliable-link is active, the received ping IP/ICMP frames are 102 bytes in length. When reliable-link is NOT active, the received IP/ICMP frames (from debug ppp packet) are 104 bytes in length. If any size change, I would have expected it to be bigger with reliable-links extra fields. Go figure.

So, I'm not sure what to say other than "it don't work right" on BRI interfaces even though according to all docs it is supposed to! On a serial link back-to-back it works fine. I haven't tested it on a point-to-point ISDN PRI yet, but it's supposed to work there as well.

So, it is unlikely to be a code problem within PPP itself since it works some places. Perhaps it's an ISDN-related but. But definitely interesting!

With that being said (and tested by many here!) I would leave it by saying this will NOT be part of your test... Anything on an actual lab scenario has been tested and reviewed by folks. So I would feel safe to say that you won't be given this tidbit on a dial-up line.

Just my opinion there...

Scott

PS. On a command with absolutely no options or useful related commands, one would reasonably expect that it just works! Or at least when IT works (which it does) that it wouldn't kill anything else in the process! No errors show up either (debug ppp error) :)

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of ccie2be
Sent: Friday, June 17, 2005 3:45 PM
To: swm@emanon.com; 'John Matus'; 'lab'
Subject: RE: ppp reliable link vs. ppp quality link

Scott,

Were you ever able to get reliable-link to work over isdn?

I was never able to.

Tim

-----Original Message-----
From: Scott Morris [mailto:swm@emanon.com]
Sent: Friday, June 17, 2005 3:41 PM
To: 'John Matus'; 'ccie2be'; 'lab'
Subject: RE: ppp reliable link vs. ppp quality link

The whole point of RFC 1663 (reliable stuff) was to give retransmission ability at Layer 2 here instead of waiting until L4 to realize something had gone bad.

As you may remember from trivia, or from earlier versions of the written exam, X.25 was the only L2 protocol that gives retransmission of errored frames.

Scott

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of John Matus
Sent: Friday, June 17, 2005 12:37 AM
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
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:00:30 GMT-3