01-14-2014 01:29 PM - edited 03-04-2019 10:04 PM
Got two interfaces in a multilink. Both are showing up/up. But when I do "show ppp multilink". One of them shows "inactive". I'm thinking that the provider probably did not bundle them on their end? Thoughts?
Multilink1, bundle name is xxxxxxxxxxxxxxxxx
Endpoint discriminator is xxxxxxxxxxxxxxxxxx
Bundle up for 02:08:21, total bandwidth 1536, load 32/255
Receive buffer limit 12000 bytes, frag timeout 1000 ms
0/0 fragments/bytes in reassembly list
0 lost fragments, 0 reordered
0/0 discarded fragments/bytes, 0 lost received
0x19F35E received sequence, 0x0 sent sequence
Member links: 1 active, 2 inactive (max not set, min not set)
Se0/3/1:0, since 02:08:21
Se0/2/0:0 (inactive)
Here is the debug:
Jan 14 15:15:30.673: Se0/2/0:0 PPP: Outbound cdp packet dropped
Jan 14 15:15:31.569: Se0/2/0:0 CDPCP: State is Closed
Jan 14 15:15:31.573: Se0/2/0:0 PPP: Phase is ESTABLISHING, renegotiate LCP
Jan 14 15:15:31.573: Se0/2/0:0 LCP: O CONFREQ [Closed] id 58 len 28
Jan 14 15:15:31.573: Se0/2/0:0 LCP: MagicNumber 0x193FDD4E (0x0506193FDD4E)
Jan 14 15:15:31.573: Se0/2/0:0 LCP: MRRU 1524 (0x110405F4)
Jan 14 15:15:31.573: Se0/2/0:0 LCP: EndpointDisc 1 -RTR-01 (0x130E014F4E54312D5254522D3031)
Jan 14 15:15:31.585: Se0/2/0:0 LCP: I CONFREQ [REQsent] id 13 len 14
Jan 14 15:15:31.585: Se0/2/0:0 LCP: MRU 1500 (0x010405DC)
Jan 14 15:15:31.585: Se0/2/0:0 LCP: MagicNumber 0x0B84E462 (0x05060B84E462)
Jan 14 15:15:31.585: Se0/2/0:0 LCP: O CONFACK [REQsent] id 13 len 14
Jan 14 15:15:31.585: Se0/2/0:0 LCP: MRU 1500 (0x010405DC)
Jan 14 15:15:31.585: Se0/2/0:0 LCP: MagicNumber 0x0B84E462 (0x05060B84E462)
Jan 14 15:15:31.589: Se0/2/0:0 LCP: I CONFREJ [ACKsent] id 58 len 22
Jan 14 15:15:31.589: Se0/2/0:0 LCP: MRRU 1524 (0x110405F4)
Jan 14 15:15:31.589: Se0/2/0:0 LCP: EndpointDisc 1 -RTR-01 (0x130E014F4E54312D5254522D3031)
Jan 14 15:15:31.589: Se0/2/0:0 LCP: O CONFREQ [ACKsent] id 59 len 10
Jan 14 15:15:31.589: Se0/2/0:0 LCP: MagicNumber 0x193FDD4E (0x0506193FDD4E)
Jan 14 15:15:31.597: Se0/2/0:0 LCP: I CONFACK [ACKsent] id 59 len 10
Jan 14 15:15:31.597: Se0/2/0:0 LCP: MagicNumber 0x193FDD4E (0x0506193FDD4E)
Jan 14 15:15:31.597: Se0/2/0:0 LCP: State is Open
Jan 14 15:15:31.597: Se0/2/0:0 PPP: Phase is FORWARDING, Attempting Forward
Jan 14 15:15:31.601: Se0/2/0:0 PPP: Phase is ESTABLISHING, Finish LCP
Jan 14 15:15:31.601: Se0/2/0:0 PPP: Phase is UP
Jan 14 15:15:31.601: Se0/2/0:0 CDPCP: O CONFREQ [Closed] id 1 len 4
Jan 14 15:15:31.601: Se0/2/0:0 PPP: Process pending ncp packets
Jan 14 15:15:31.609: Se0/2/0:0 LCP: I PROTREJ [Open] id 247 len 10 protocol CDPCP (0x820701010004)
Jan 14 15:15:31.609: Se0/2/0:0 CDPCP: State is Closed
Jan 14 15:15:31.609: Se0/2/0:0 CDPCP: State is Listen
01-14-2014 03:30 PM
Hello Mohammad ,
As per the output you posted , it seems like Second interface is not part of Multilink on the far end(in our case Telco).
Just to check more things , can you please share the output of following:-
1. Show version.
2. Show ppp multilink internal
3. SHow ip interface brief.
ALso, can you please let me know of if you can see activity on the serial interface Se0/2/0:0 , THis can be checked by show interface Se0/2/0:0, Please share the outputs.
Thank you
Ashish Arora
01-15-2014 04:42 AM
Cisco IOS Software, 2800 Software (C2800NM-SPSERVICESK9-M), Version 12.4(25c), RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Thu 11-Feb-10 23:55 by prod_rel_team
ROM: System Bootstrap, Version 12.4(13r)T11, RELEASE SOFTWARE (fc1)
RTR-01 uptime is 17 hours, 51 minutes
System returned to ROM by reload at 12:47:21 CST Tue Jan 14 2014
System restarted at 12:48:33 CST Tue Jan 14 2014
System image file is "flash:c2800nm-spservicesk9-mz.124-25c.bin"
This product contains ............................................................................
A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
If you require further assistance please contact us by sending email to
Cisco 2811 (revision 53.50) with 249856K/12288K bytes of memory.
Processor board ID FTX1032A57F
2 FastEthernet interfaces
27 Serial interfaces
4 Channelized T1/PRI ports
4 Voice FXO interfaces
DRAM configuration is 64 bits wide with parity enabled.
239K bytes of non-volatile configuration memory.
62720K bytes of ATA CompactFlash (Read/Write)
Configuration register is 0x2102
------------------------------------------------------------------------------
Multilink1, bundle name is xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Endpoint discriminator is xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Bundle up for 17:19:06, total bandwidth 1536, load 19/255
Receive buffer limit 12000 bytes, frag timeout 1000 ms
LinkMask: 00000001
MLP process input queue: 0 current, 0 peak, 0 drops
0/0 fragments/bytes in reassembly list
3 lost fragments, 3 reordered
0/0 discarded fragments/bytes, 0 lost received
0x7B228A received sequence, 0x0 sent sequence
EqCost: Yes, MLP Encaps: No, FragDisabled: No, UseLLQ: No
Max frag size: 1496
InOrder: 00000001
InSync: 00000001
Xmit link: 0x45AEE4DC (Se0/3/1:0)
Oqueue: 0x403017A8
Oqueue_dQ: 0x40301EE8
Oqueue_int_dQ: 0x41158748
QoS_classify: 0x0
Soutput: 0x41AC3D58
Fastsend: 0x400D4AA4
Sub encap: 0x0
Board encap: 0x0
Member links: 1 active, 1 inactive (max not set, min not set)
Se0/3/1:0, since 17:19:06, 5760 weight, 1496 frag size, 0 bytes
0 fragments in reassembly list
Link index: 0, Qdepth: 0, Qlimit: 8, TxQLen: 0, TxQ checked: Yes
Oqueue: 0x4136CB08
Oqueue_dQ: 0x41AC3DA0
Soutput: 0x4001CFF0
Fastsend: 0x4001A304
Sub encap: 0x0
Board encap: 0x0
PPP Header: FF03003D
Se0/2/0:0 (inactive)
No inactive multilink interfaces
-------------------------------------------------------------------------------------------
Serial0/2/0:0 unassigned YES manual up up
Serial0/3/0:0 unassigned YES NVRAM down down
Serial0/3/1:0 unassigned YES NVRAM up up
NVI0 unassigned NO unset up up
Multilink1 10.136.104.129 YES manual up up
Loopback0 172.16.4.209 YES NVRAM up up
01-14-2014 03:56 PM
There is certainly some problem. Perhaps not done no shut. Or perhaps not configured for multilingual. Or perhaps not configured for PPP.
HTH
Rick
Sent from Cisco Technical Support iPhone App
01-15-2014 04:43 AM
Hi Richard interface is configured for multlink definitely and it is up/up
interface Serial0/2/0:0
description AT&T MPLS
bandwidth 1544
no ip address
encapsulation ppp
ip route-cache flow
no cdp enable
ppp multilink
ppp multilink group 1
max-reserved-bandwidth 100
01-15-2014 06:40 AM
Rihard,
As per the configuration it seems to be ok and i am not seeing any issues with the configuration at all.
just for the next action we should try as follow:-
1. Create another multilink(multilink 2) , bundled both interfaces and see the outputs.
2. Run debug ppp negotation and share the outputs. In order to get the outputs , you need to clear the multilink interface by using CLI(clear interface multilnk).
3. Try to shut/no shut all the interface ( multilink and serial).
4.Ask Telco and see if everything is fine at their end.
5. In case if still problem persist , it might be due to the software issues defined under(CSCtr79608).Since this Bug doesn't affect the current IOS version you are usinfg ;however we can try upgrading(fixedin version) IOS and see the behaviour( just in case).
-Ashish
01-16-2014 05:40 AM
Thank you all for your replies. As I suspected issue was on the providers end. It was not bundled properly on their end and the case had to be escalated to T3 to resolve. So after looking at the working vs non working packets I think this makes sense.
If you look at the log above, there is an incoming "I CONFREJ" packet and looks like it is rejecting the end point discriminator.
Also towards the end there is an in coming "I PROTREJ" with is rejecting the protocol "CDPCP".
With the working version it is clearly passing:
01-17-2014 01:45 AM
Ali,
correct , but we should always look at the ppp Debugs which were initiated by multilink interface in our case , because multilink is the one which in the question.
Since we bound our interface in the mulilink and other end is still indepenedent , then it creates issues while reaching to the upplar layers of the ppp and leads to the rejection.
We should wait till provider provisioned it and lets see what happen.
Thank you
-Ashish
Please don't forget to rate the posts.
01-20-2014 11:01 AM
Its already resolved. Like I mentioned issue was on the providers end.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide