Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Community Member

Reordered packet problems with Multilink PPP over ISDN

We are setting up a Cisco 3640 using IOS 12.2.7c and a BRI card

for an ISDN multilink connection to an ISP. The connection works

fine with one channel. When multilink is activated, most data

transfers periodically produce errors. Some data on the HTTP

transactions appears to be lost and web pages do not display

properly.

There are a high number of reorders on "sho ppp multi" (several

hundred per minute). Activating the "debug ppp multi events" produces

errors of the form:

Aug 14 14:23:15.538 AST: Di1 MLP: Lost fragment 132A in '00c0.7b8a.df2a' (all links have rcvd higher seq#)

Aug 14 14:23:15.726 AST: Di1 MLP: Lost fragment 132C in '00c0.7b8a.df2a' (all links have rcvd higher seq#)

Aug 14 14:23:15.738 AST: Di1 MLP: Lost fragment 1331 in '00c0.7b8a.df2a' (all links have rcvd higher seq#)

Aug 14 14:23:20.666 AST: Di1 MLP: Load (67) above threshold in bundle 00c0.7b8a.df2a

Aug 14 14:23:21.070 AST: Di1 MLP: Lost fragment 13D1 in '00c0.7b8a.df2a' (all links have rcvd higher seq#)

Aug 14 14:23:21.338 AST: Di1 MLP: Lost fragment 13D3 in '00c0.7b8a.df2a' (all links have rcvd higher seq#)

Tried "no ppp multilink fragmentation" but it seems to have no

effect. The interfaces show no transmission (CRC, etc.) errors.

Would anyone have a suggestion ?

Thanks.

3 REPLIES
Bronze

Re: Reordered packet problems with Multilink PPP over ISDN

The "sh ppp mult" output reflects that status of packets received; therefore, reordered packets means that either the remote sent them out of order (not very likely), or the B-channels have a different latency between them. In general, this is not a big problem and MPPP should be able to handle it without loss.

The debug message means that we were waiting to get fragment #132A (for example), and are now declaring that it must be lost, because we have now received fragments with sequence numbers > 132A on every link. Since sequence numbers always increase, that means there is no legitimate way we could now receive #132A on any of those links. If your interfaces are clean, then it could be a telco issue or a problem with the ISP.

I'll assume that you don't have any fancy queueing or other features (compression) on the ISDN interface; regardless, you may want to ensure that you are running relatively recent code.

Community Member

Re: Reordered packet problems with Multilink PPP over ISDN

Thanks for your prompt response.

The telco already checked the BRI and they claim it is

OK. It does work fine with a single channel.

IOS is version 12.2.7c, IP only. The router originally had

12.2.5a with the same issue.

This is the BRI/Dialer config (IPs, phones, SPIDs and

username/password are examples):

interface BRI0/0

no ip address

encapsulation ppp

no ip route-cache

no ip mroute-cache

load-interval 30

dialer pool-member 1

isdn switch-type basic-ni

isdn spid1 866555121200 8665551212

isdn spid2 866555121300 8665551213

no cdp enable

ppp multilink

no ppp multilink fragmentation

!

interface Dialer1

description ISP

bandwidth 128

ip address 200.200.200.145 255.255.255.248

no ip proxy-arp

ip nat outside

encapsulation ppp

no ip route-cache

no ip mroute-cache

dialer pool 1

dialer remote-name prw.net

dialer idle-timeout 0

dialer string 8665551211

dialer hold-queue 10

dialer load-threshold 1 either

dialer-group 1

no peer default ip address

pulse-time 0

no cdp enable

ppp authentication pap callin

ppp pap sent-username myuser password mypassword

ppp multilink

no ppp multilink fragmentation

Bronze

Re: Reordered packet problems with Multilink PPP over ISDN

Config looks fine, although you should enable fast switching (ip route-cache) and again disabling fragmentation is not likely going to make a difference. You could try without dialer profiles, but that should not make a difference either. If the telco can do some more testing, what you want them to focus on is loss and latency between the 2 B-channels.

185
Views
0
Helpful
3
Replies
CreatePlease to create content