Unequal load split with static routes

Unequal load-sharing with static routes is almost impossible as there is no configuration command to assign non-default traffic share count to a static route. For example, if you configure two default routes, one pointing to a low-speed interface and another one pointing to a high-speed interface, there is no mechanism to force majority of the traffic onto the high-speed link (IOS ignores interface bandwidth when calculating load sharing ratios).

You can, howerer, use a workaround: if you configure multiple routes for the same prefix pointing to the same interface, that interface will attract proportionally more outbound traffic.

For example, let's assume you have two point-to-point serial subinterfaces, one three times as fast as the other:

interface Serial0/0/0.100 point-to-point
bandwidth 1000
ip address 172.16.1.1 255.255.255.252
!
interface Serial0/0/0.200 point-to-point
ip address 172.16.1.5 255.255.255.252
bandwidth 3000

To shift more traffic onto Serial0/0/0.200, you can create two default routes pointing to the second interface, one pointing to the interface itself, the other one to the next-hop router:

ip route 0.0.0.0 0.0.0.0 Serial0/0/0.100
ip route 0.0.0.0 0.0.0.0 Serial0/0/0.200
ip route 0.0.0.0 0.0.0.0 172.16.1.6

This setup will give you a 1:2 sharing ratio. To shift even more traffic to the higher-speed interface, one has to get more creative

  • Create a bogus host route for a bogus next-hop pointing to the actual next-hop router (and make sure you don't advertise the bogus route into your routing protocols).
  • Configure yet another static route pointing to the bogus next-hop. Due to recursive lookup done by Cisco IOS, the bogus next-hop will be resolved into the actual next-hop IP address.

In our example, you could use:

ip route 10.255.255.1 255.255.255.255 172.16.1.6
ip route 0.0.0.0 0.0.0.0 10.255.255.1

The results are as expected: the traffic split is the desired 1:3 ratio

a1#show ip route 0.0.0.0 0.0.0.0
Routing entry for 0.0.0.0 0.0.0.0, supernet
Known via "static", distance 1, metric 0 (connected), candidate default path
Routing Descriptor Blocks:
172.16.1.6
Route metric is 0, traffic share count is 1
10.255.255.1
Route metric is 0, traffic share count is 1
* directly connected, via Serial0/0/0.100
Route metric is 0, traffic share count is 1
directly connected, via Serial0/0/0.200
Route metric is 0, traffic share count is 1

a1#show ip cef 0.0.0.0 0.0.0.0 internal
0.0.0.0/0, version 43, epoch 0, attached, per-destination sharing
0 packets, 0 bytes
via 172.16.1.6, 0 dependencies, recursive
traffic share 1
valid adjacency
via 10.255.255.1, 0 dependencies, recursive
traffic share 1
valid adjacency
via Serial0/0/0.100, 0 dependencies
traffic share 1
valid adjacency
via Serial0/0/0.200, 0 dependencies
traffic share 1
valid adjacency

0 packets, 0 bytes switched through the prefix
tmstats: external 0 packets, 0 bytes
internal 0 packets, 0 bytes
Load distribution: 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 (refcount 1)

Hash OK Interface Address Packets
1 Y Serial0/0/0.200 point2point 0
2 Y Serial0/0/0.200 point2point 0
3 Y Serial0/0/0.100 point2point 0
4 Y Serial0/0/0.200 point2point 0
5 Y Serial0/0/0.200 point2point 0
6 Y Serial0/0/0.200 point2point 0
7 Y Serial0/0/0.100 point2point 0
8 Y Serial0/0/0.200 point2point 0
9 Y Serial0/0/0.200 point2point 0
10 Y Serial0/0/0.200 point2point 0
11 Y Serial0/0/0.100 point2point 0
12 Y Serial0/0/0.200 point2point 0
13 Y Serial0/0/0.200 point2point 0
14 Y Serial0/0/0.200 point2point 0
15 Y Serial0/0/0.100 point2point 0
16 Y Serial0/0/0.200 point2point 0

Note: this article is part of You've asked for it series.

12 comments:

  1. I did ask for this! It is exactly the solution I was looking for. You are great! tnx

    ReplyDelete
  2. Hi Ivan, nice web site! I have a question a little off topic but sort of related; many books and web sites state that the Administrative Distance of a static route pointing to an outgoing interface is 0, however IOS shows that the AD is 1. For example, this excerpt from Routing TCP/IP Vol 1 Second Edition, Jeff Doyle, Pg. 99; "For example, IPv4 static routes pointing to a next-hop address have an administrative distance of 1, and static routes referencing an exit interface have an administrative distance of 0". At some point in the past was this true? Do you know the history behind this? Thanks.

    ReplyDelete
  3. All static routes are treated equally since (at least) IOS release 12.2. Here are the details.

    ReplyDelete
  4. I have two link's: 1024kbps e 512kbps, ppp. In teh 512k there's no traffic!! Then, when i make this configuration the traffic coming! But only in one direction of the 512k link. What's wrong? Thank's

    ReplyDelete
  5. You need to have similar configuration on both ends of the link (static routes affect only outgoing traffic). Also make sure that you have CEF switching enabled on both ends, otherwise the fast-switching code will use only a single path.

    ReplyDelete
  6. Hello Ivan, I am going to attempt to apply your fancy static route method to my problem, but I wanted to throw a problem at you to see if I have missed some things. I have a router which has two unequal paths being provided by the Satellite provider. I connect to their network via GIG0/0 and GIG0/1. The rates are 9mb and 3 mb respectively. They allow me to use my own IP addresses due to the use of MPLS on their part. I traverse their network to my remote router. Right now I am only using the 9mb link with the 3mb as a failover. I want to load balance across these two links but I have VOIP traffic. I believe that if I allow this traffic along with the data to go through the load balancing, I will end up with to much jitter on the call because it will split routes. Is there a way to force the VOIP to use one link while still running the load sharing protocol such as EIGRP with a variance. As a side problem, I would also still want failover if I was to lose one link. So the VOIP would have to be able to move. Basically everyone needs to get out regaurdless of whether both links are up or just one with VOIP always having priority. I have setup GRE tunnels on my one link to make the router see the ethernet connection for what it really is (9mb), but we really want to use the full 12mb or pretty close.

    ReplyDelete
  7. @Michael: if you use CEF, packets belonging to a single source-destination address pair (or a single TCP/UDP session, if you configure it so) will always go over the same path, so there will be no extra jitter within a single VoIP call.

    ReplyDelete
  8. nikolay popgeorgiev25 August, 2010 19:13

    Hello Ivan, nice site thank you.

    a question related to the topic, i saw the person before me is having it similar so I want to conclude on it:

    I have a GRE tunnel accros two devices with two paths in between. because the src/dst are always the same I cannot make the traffic flow over both lines on one of the devices. The router on which this works is 2821 with 12.4(15)T7 with "ip load-sharing per-packet" on the interfaces, and the other side is CISCO7613 with 12.2(33r)SRB4 with only option of "ip load-sharing per-destination" on its ATM subinterfaces . Both have CEF enabled. the 7600 is sending out only on a single line

    thanks
    Nick

    ReplyDelete
  9. awesome ..

    I was hunting for this solution.. :)
    But how dod U know the bogus routing part? I dont think it is somewhere written or posted..

    Thank You
    Chetan

    ReplyDelete
  10. Recursive routing table lookup. Present in IOS since (at least) 9.0 SW.

    ReplyDelete
  11. hello, thanks for the information

    I have a cisco 2801 router and I want to connect two ADSL links on it and balance the load but not that kind of IOS that team would need or if I would be useful?

    ReplyDelete
  12. Zdravo Ivane, interesuje me postoji li mogucnost da moju ADSL konekciju koja dolazi na ruter, i odatle se racva na nekoliko djelova (1 kabal i vise wireless uredjaja) mogu podesiti tako da konekcija koju ja koristim ima fiksnu velicinu, recimo pola konekcije. Dok bi ostali korisnici dijelili drugi dio. Nadam se da sam bio jasan, Blagodarim.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.