From: Tom Lijnse (Tom.Lijnse@globalknowledge.nl)
Date: Fri Jun 17 2005 - 05:17:08 GMT-3
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