From: John Matus (jmatus@pacbell.net)
Date: Fri Jun 17 2005 - 01:36:33 GMT-3
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