cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
356
Views
0
Helpful
3
Replies

load-sharing over serial and dialer

a.tillmann
Level 1
Level 1

Hi all,

I am looking for a solution for the following secenario:

2 routers (C1600 or also different platforms up to a C3660) are connected via a serial link with 128k (in other loacations up to 2 Mbit). At each side are ethernets. For redundancy there are dialer-interfaces with a BRI-interface configured as backup interfacees for the serials. Additionally the ISDN-Interfaces (dialers) are configured to be kicked in when the serials have a load of 80% which happens at night when there is a file-copy for backup between servers.

So far so good, the ISDN-interfaces come up as expected, but the copy-connection between the servers (which uses a single session!) could not use the additional path. For that we updated to 12.2(15)T2 to provide ip cep for dialers. We also tuned EIGRP to have the same metric via Serial- and Dialer-Interface. Now we can see that both Serial- and Dialer-interfaces with each B-Channel have a load of about 98%. The Problem is, that the session between the servers creates too much 'ack too long' and 'retransmissions' so that the effective bandwidth is worse than the single serial line.

I would prefer something like a Multilink-Interface for the serial and the dialer to use 'PPP multilink' but the dialer-interface is not supported for that. Is there any other solution possible?

thanks for reply,

Alexander

3 Replies 3

j.vanrooyen
Level 1
Level 1

Your scenario is certainly strange so first a check for understanding :

You have two routers with 1 or more serial links as well as a BRI interface as load-backup for each serial. You have upgraded the router 's IOS to support CEF and still the copy procedure fails and reports the failure due to ack's being to long.

If this is correct than it certainly is strange. The way I understand cef is that it's default load sharing method is per session which means that if your destination is reachable via two different interfaces cef will transports a single TCP session per interface (I might be wrong) , this however does not seem to happen in your case as both the dialer and the serial shows a high util. Is it possible that you have some other traffic and the copy procedure still only uses the single link (Either serial or BRI ) and fails due to not having enough bandwidth which causes the delayed acks and due to this load the other traffic causes the bri to activate (Due to load backup).

Try enabling ip cef per-packet load balancing on the interfaces , this overides the default per session and see what happens.

Combining a serial and multiple BRI's into a single multilink interface does not seem to be possible. You could try tying your BRI 's into a sinlge interface with a rotary group and then use this dialer interface for backup to supply additional bandwidth though but if you are not dropping packets I dont really see the point , but try the per-packet load balancing or check that you have no other traffic at the time.

To simplify a bit:

2 routers connected via serial (X.21 with 128k) and one basic-rate-interface (2 B-channels, together also 128k) for backup and load-backup. At night there is a filecopy between 2 servers at each side which needs more bandwidth.

It is correct that I upgraded the IOS to the newest version that provides load-sharing with dialer-interfaces. The interfaces are configured with the command 'ip load-sharing per-packet'.

The filecopy uses a single session. There is definitively no other traffic on the line, we also tested it in our lab.

We see a lot of retransmissions and the performance is sometimes worse, sometimes better than with only the X.21-line, overall it is about the same than only the serial, even if we have a summary of 256k via serial and ISDN and both lines have almost a max load. By the way the ethernet-interfaces also show a load of almost 256k. The problem is that about half of the traffic seems to be retransmissions.

You are probably getting the packets out of sync because of the different latency of the different paths. You should never attempt to do this kind of loadsharing with unequal latency links.