From: Scott Morris (swm@emanon.com)
Date: Thu Jun 16 2005 - 10:24:44 GMT-3
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