cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3809
Views
0
Helpful
8
Replies

Serial Interface in Multilink

ALIAOF_
Level 6
Level 6

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

8 Replies 8

Ashish Arora
Level 1
Level 1

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

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

export@cisco.com.

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

Richard Burts
Hall of Fame
Hall of Fame

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

HTH

Rick

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

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

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:

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.

Its already resolved.  Like I mentioned issue was on the providers end.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: