From: Scott Morris (swm@emanon.com)
Date: Sat Jun 18 2005 - 02:01:43 GMT-3
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 : Wed Jul 06 2005 - 14:43:41 GMT-3