From: Piotr Jelonek (piotr@jelonek.info)
Date: Thu Jun 16 2005 - 15:29:44 GMT-3
Hi.
On czw, cze 16, 2005 at 09:51:58 -0400, ccie2be wrote:
> So, anyway, from this debug, does this mean that reliable-link should be
> config'd on both sides of the link and if it's not, then during ppp
> negotiation, neither side will use this feature?
If you configure reliable-link on one side:
*Apr 20 02:47:20.837: BR0/0:1 LCP: O CONFREQ [Closed] id 20 len 19
*Apr 20 02:47:20.837: BR0/0:1 LCP: AuthProto CHAP (0x0305C22305)
*Apr 20 02:47:20.837: BR0/0:1 LCP: MagicNumber 0x09CA8EA7
*Apr 20 02:47:20.837: BR0/0:1 LCP: ReliableLink window 7 addr 1
*Apr 20 02:47:20.849: BR0/0:1 LCP: I CONFREQ [REQsent] id 2 len 15
*Apr 20 02:47:20.849: BR0/0:1 LCP: AuthProto CHAP (0x0305C22305)
*Apr 20 02:47:20.849: BR0/0:1 LCP: MagicNumber 0x0F7BD400
*Apr 20 02:47:20.849: BR0/0:1 LCP: O CONFACK [REQsent] id 2 len 15
*Apr 20 02:47:20.849: BR0/0:1 LCP: AuthProto CHAP (0x0305C22305)
*Apr 20 02:47:20.849: BR0/0:1 LCP: MagicNumber 0x0F7BD400 (0x.!!!!
*Apr 20 02:47:20.849: BR0/0:1 LCP: I CONFREJ [ACKsent] id 20 len 8
*Apr 20 02:47:20.849: BR0/0:1 LCP: ReliableLink window 7 addr 1
Rejected.
> When I tried it on a bri interface, reliable-link only worked when it was
> configured on one side.
No. It didn't work.
I have the same problem as you all on BRI. When configured on both sides
it gets negotiatied successfully. But IP/PPP doesn't work:
--- Pinging the other side.
deb lapb
deb lapb-ta
deb ppp pac
*Mar 2 09:50:28.095: BR0/0:1 PPP: O pkt type 0x0021, datagramsize 102
*Mar 2 09:50:28.095: BRI0/0:1: LAPB O CONNECT (104) IFRAME 3 1
*Mar 2 09:50:28.115: BRI0/0:1: LAPB I CONNECT (2) RR (R) 4.
*Mar 2 09:50:30.095: BR0/0:1 PPP: O pkt type 0x0021, datagramsize 102
*Mar 2 09:50:30.095: BRI0/0:1: LAPB O CONNECT (104) IFRAME 4 1
*Mar 2 09:50:30.111: BRI0/0:1: LAPB I CONNECT (2) RR (R) 5.
*Mar 2 09:50:32.095: BR0/0:1 PPP: O pkt type 0x0021, datagramsize 102
*Mar 2 09:50:32.095: BRI0/0:1: LAPB O CONNECT (104) IFRAME 5 1
*Mar 2 09:50:32.111: BRI0/0:1: LAPB I CONNECT (2) RR (R) 6.
--- On the other side:
deb ip pac
deb ppp pac
fast-switching turned off on BRI0/0
And I get _only_ this one repeating:
*Mar 1 07:20:03.297: BR0/0:1 PPP: I pkt type 0x0021, datagramsize 102 link[ip]
It looks like PPP has some problems. LAPB works fine as we are
receiving Receiver Ready (RR) frames with appropriate sequence numbers
and the PPP frames on the other side are successfully unpacked from LAPB.
I can't get any further with this problem. Your turn. ;)
Cheers,
Piotr
> -----Original Message-----
> From: Scott Morris [mailto:swm@emanon.com]
> Sent: Thursday, June 16, 2005 9:25 AM
> To: 'ccie2be'; 'John Matus'; 'lab'
> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
-- piotr@jelonek.info
This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:41 GMT-3