[c-nsp] 7513 multilink interface issue

[Rodney Dunn]

sh contr cbus | incl 1/0:14|1/0:15

Todd wrote:
> Currently running Version 12.4(23).  I may upgrade to (25) to see if that
> helps at all.
> 
> VIP Console:
> VIP-Slot5>sh ppp multilink
> dmlp_ipc_config_count 210
> dmlp_bundle_count 4
> 
> Bundle Multilink75, 2 members
>   bundle 0x61B1C3A0, frag_mode 0
>   tag vectors 0x6053A4A0 0x60514CBC
>   Bundle hwidb vector 0x605AA624
>   idb Multilink75, vc 14, RSP vc 15
>   QoS disabled, fastsend (qos_fastsend 0x605AA624), visible_bandwidth 1540
>   board_encap 0x605A61A4, hw_if_index 0, pak_to_host 0x0
>   max_particles 400, mrru 1500, seq_window_size 0x8000
>   working_pak 0x0, working_pak_cache 0x0
>   una_frag_list 0x0, una_frag_end 0x0, null_link 0
>   rcved_end_bit 1, is_lost_frag 0, resync_count 0
>   timeout 0, timer_start 0, timer_running 0, timer_count 0
>   next_xmit_link Serial1/0:15, member 0x3, congestion 0x3
> dmlp_orig_pak_to_host 0x60425D00
> dmlp_orig_fastsend 0x60397B18
> bundle_idb->lc_ip_turbo_fs 0x60503E70
> bundle_idb->lc_ip_mdfs 0x604251B4
>   0 lost fragments, 0 reordered, 0 unassigned
>   0 discarded, 0 lost received
>   0x2AE received sequence, 0x319 sent sequence
>   Member Link: 2 active
> Pascb for Bundle 0x61A8CD20, tx_polling_high_default 0, tx_polling_high 143
>     Serial1/0:14, id 0x2, fastsend 0x605A88B4, lc_turbo 0x605A97BC, PTH
> 0x605A8FF4, OOF 0
>                 Pascb 0x61A8CD20, tx_polling_high_default 0, tx_polling_high
> 143, poll_default_addr 0x61A8CD7C, poll_addr 0x61A8CD68
>     Serial1/0:15, id 0x1, fastsend 0x605A88B4, lc_turbo 0x605A97BC, PTH
> 0x605A8FF4, OOF 0
>                 Pascb 0x61A8CE60, tx_polling_high_default 0, tx_polling_high
> 143, poll_default_addr 0x61A8CEBC, poll_addr 0x61A8CEA8
> 
> 
> RSP:
> Multilink75, bundle name is group75
>   Endpoint discriminator is group75
>   Bundle up for 00:19:29, total bandwidth 3080, load 1/255
>   Receive buffer limit 24000 bytes, frag timeout 1000 ms
>   Bundle is Distributed
>     0/0 fragments/bytes in reassembly list
>     0 lost fragments, 0 reordered
>     0/0 discarded fragments/bytes, 0 lost received
>     0x2B3 received sequence, 0x319 sent sequence
>   Member links: 2 active, 0 inactive (max not set, min not set)
>     Se5/1/0/15:0, since 00:12:53
>     Se5/1/0/16:0, since 00:02:15
> 
> 
> 
> -----Original Message-----
> From: Rodney Dunn [mailto:rodunn at cisco.com] 
> Sent: Tuesday, August 04, 2009 1:43 PM
> To: Todd
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] 7513 multilink interface issue
> 
> It does. I've seen it before years ago.
> 
> get 'sh ppp multilink' from the RSP and VIP console (if-con slot)
> and sh contr cbus.
> 
> Make sure you are in dCEF mode, all links are on the same PA, and on 
> later(est) 12.4 mainline (12.4(25) or 12.0(32)S(latest)) on Cisco.com.
> 
> We had bugs in how we manage the member links of the bundle.
> 
> Rodney
> 
> 
> 
> Todd wrote:
>> When it happens, I can ping the remote end from the 7513, but nothing
>> outside of the 7513.  
>>
>> For Example....
>>
>> SERVER --ethernet--- 7513 ---multilink (2 T1's)--- END USER
>>
>> 1 multilink T1 bounces.
>>
>> After the T1 comes up, the multilink interface and both T1's show as up/up
>> and 7513 can ping END USER, but END USER can't ping 7513 and no connection
>> to/from SERVER to END USER.
>>
>> Hope that makes sense.
>>
>> -----Original Message-----
>> From: Rodney Dunn [mailto:rodunn at cisco.com] 
>> Sent: Tuesday, August 04, 2009 1:24 PM
>> To: Todd Shipway
>> Cc: cisco-nsp at puck.nether.net
>> Subject: Re: [c-nsp] 7513 multilink interface issue
>>
>> That should never happen and is possibly a bug.
>>
>> Can you ping directly over the bundle to the ip address on the other 
>> side when it's broke? If not, go to the latest code and see if it's 
>> fixed...or do some debugging: 'sh ip cef for other side of bundle, debug 
>> ip packet, etc...
>>
>> Rodney
>>
>>
>>
>> Todd Shipway wrote:
>>> We have several customers setup with T1's multilinked.  We are running
>> into
>>> a problem with a single multilink member bouncing causing routing issues.
>>> When a single T1 member of a multilink group bounces, traffic to the
>> overall
>>> multilink interface stops and we have to manually shut and no shut the
>>> multilink interface to get traffic flowing again.
>>>
>>> Has anyone seen this before and if so, know what the issue may be?
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/