EIGRP - Unequal load balancing problem with CEF

[johnross400]

If I adjust EIGRP metrics to use only Delay, will this prevent unequal cost load balancing from working ????

I?m trying to configure R2 to load-share per-packet across two serial interfaces directly connected to R3.

A ping from R1 through R2 in order to reach an interface on R3 is successful. However, when I view the interfaces used to forward these packets at R2 (debug ip packets) I see the S0/1 & S0/0 interfaces are not forwarding these packets according to the variance setting. Almost all packets use the lower cost of S0/1.

On R2 I configured the inbound interface S1/1 (directly connected to R1) for Process Switching & the outbound configurations on S0/0, S0/1 for Process Switching.

Why doesn?t it work????????????

sh ip route....

D 192.168.17.0/24 [90/25856] via 172.20.15.10, 00:15:37, Serial0/1

[90/155136] via 172.20.15.6, 00:15:37, Serial0/0

So I set the variance to 7 ? right?

*********************************************************************

sh run...

interface Serial0/0

ip address 172.20.15.5 255.255.255.252

ip load-sharing per-packet

no ip route-cache cef

no ip route-cache

delay 506

interface Serial0/1

ip address 172.20.15.9 255.255.255.252

ip load-sharing per-packet

no ip route-cache cef

no ip route-cache

delay 1

interface Serial1/1

ip address 172.20.15.1 255.255.255.252

no ip route-cache cef

no ip route-cache

router eigrp 15

variance 7

network 172.20.0.0

metric weights 0 0 0 1 0 0

auto-summary

****************************************************************************

From the sh cef int command I know CEF is no being used on the inbound or outbound interfaces.

The EIGRP metric is delay only and the two serial links have been manipulated and are in the routing table.

I?m using 2620 12.3.

I can't understand why the router doesn't use both outgoing interfaces when the in/out bound interfaces don't use CEF!!!! Please help me.

[Kevin Dorrell]

Have you tried with CEF on? I have seen explanations of how the load-sharing works, but all the documents I have seen ahve involved CEF. The document also has a lot of goodstuff about debugging the load-sharing, and hidden commands for verifyig it. It's all about buckets. Here it is:

http://www.cisco.com/en/US/tech/tk827/tk831/technologies_tech_note09186a0080094806.shtml

http://www.cisco.com/en/US/products/hw/modules/ps2033/prod_technical_reference09186a00800afeb7.html

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009437d.shtml#cef

In any case, maybe ping is not the fairest way to test this functionality; it would be better to try real mixed traffic.

Kevin Dorrell

Luxembourg

[Richard Burts]

John

First of all - if you adjust EIGRP metric weights to use just delay it should not prevent unequal cost load balancing from working. No matter how the metric is calculated, EIGRP will do unequal cost load sharing when variance is configured. And the proof of that is that where you have made the change in your example there are two routes with unequal cost in the routing table. So variance is working.

Another point is that with variance the load sharing is proportional to the metrics. So with the metrics here there should be about 7 packets on serial 0/1 for every packet on serial 0/0. From your description I get the feeling that this is happening. What did you expect to happen? What makes you thing that it is not working?

There are several things in your config that I do not understand.

- the serial interfaces include this command:

ip load-sharing per-packet

but the load-share per-packet is a feature of CEF and you have disabled CEF.

- is there a reason to take bandwidth out of the calculation of the EIGRP metric?

- is there a reason for configuring delay of 506 on serial 0/0 and a delay of 1 on serial 0/1?

I get the feeling that when you force process switching you expect equal traffic on both interfaces. And if you were doing equal cost load share then that is what you would get. But when you introduce unequal cost load share you also get the concept of traffic-share. When you do EIGRP unequal cost load sharing the traffic will be distributed in proportion to the metrics of the interfaces. When you need variance 7 to get the second interface into the routing table you are going to get pretty unequal sharing on the interfaces.

HTH

Rick

[johnross400]

Hi Rick

I only have T1 connections so I adjusted the metrics to give me 2 routes with unequal metrics. Anyway, Im trying to do exactly as you say - seven packets should pass on one intf to every one on the secod intf. But I cant get this to work - even though there are two routes in the routing table and the variance is correct.

I think I should have Fast process switching on the inbounf interface & on the two outbound interfaces (s0/0 & s0/1) I should have process switching enabled.

So should S1/1 now look like...???

interface Serial1/1

ip address 172.20.15.1 255.255.255.252

no ip route-cache

and the serial links...

interface Serial0/1

ip address 172.20.15.9 255.255.255.252

no ip route-cache cef

no ip route-cache

Thanks for you help!!

[Kevin Dorrell]

I think there is a misunderstanding here. The traffic is distributed in proportion to the relative composite metrics of two routes, not according to the variance setting. The variance setting specifies the maximum tolerable ratio of metrics before the weaker route is ignored altogether.

It looks from your config that your routes should have a ratio of 1:506, and so the weaker one would be ignored altogether given that the maximum variance is 7. However, it will also depend on the upstream delays as well. I cannot remember whether it is the delay at the advertising end of a link that gets added to the metric, or the delay at the receiving end. (Can you help me out there Rick?)

Could you please post the show ip route so that we can see the actual ratio of the composite metric.

Just a word of warning: if you adjust the metric weightings, you should do it consistently on all the routers in the EIGRP AS, otherwise you can easily end up with routing loops.

Kevin Dorrell

Luxembourg

[Richard Burts]

Kevin

In fact the original post did include the show ip route for the destination address. And if you look at the metrics they are about 1:7 ratio (25856:155136).

Perhaps I was not entirely clear in my post how I got the 7 to 1 packet distribution. But it was from the ratio of the calculated metric which coincidently is the same as the variance.

Perhaps John can do a clear counters on the router, do an extended ping with maybe 800 pings, and post the output of show interface, so we can see what the packet distribution is.

HTH

Rick

[johnross400]

Guys

Here is what I see when I ping through this router...see attachment. Perhaps someone can show me how to configure the interfaces - maybe i made a mistake??

[Kevin Dorrell]

John,

Have you tried it with CEF enabled? According to the document I posted earlier, it should work. Try enabling CEF, then do a show ip cef ip-addr internal.

I wonder whether ping is really a fair way of testing this feature. There are some platforms (e.g. the 7500) on which mechanisms like QoS, fancy queueing, load balancing, etc. do not operate on single packets. That is if the transmitter is idle, then the packet gets switched directly onto the tx-ring of the egress interface regardless of any packet scheduling. It is only if the transmitter is currently in use that the packets gets queued/distributed etc. So a ping might not be sufficient traffic to bring the scheduling mechanisms into play.

Kevin Dorrell

Luxembourg

[Richard Burts]

I have looked at the file that John posted and the contents did surprise me a bit as they do show that all the ping packets are being forwarded through a single interface. I believe that there is an explanation which we have not yet found.

I would like to see fresh output of the show ip route command for the subnet as posted before and also the output of show ip route for the exact destination address. I would also like to see the output of show ip interface for the 3 serial interfaces. The output of show ip protocol might also be helpful.

HTH

Rick

[Kevin Dorrell]

John, the more I think about it, the more I am convinced that per-packet load distribution only works like that if CEF is running.

Try it! Have a look at the docs I gave you in my first post for some ideas how to verify it.

If you are process switching, the load is distributed differently, probably to the first outbound interface that has nothing in the queue, which would explain why all your pings came out on one line.

Kevin Dorrell

Luxembourg

[Richard Burts]

Kevin

With process switching it should use both paths - and use them according to their traffic share which should reflect the ratio of their metrics. With equal metric paths that should become per packet load share. With unequal metric paths it should use the better path more but it should still use the other path some.

I am not sure what is going on here. I had wondered whether with the large difference in metric if there was an issue with the EIGRP feasibility test. But if there were an issue with the EIGRP feasibility test it should prevent the second path from appearing in the routing table - and apparently it is in the routing table.

I hope that we can get some more information and be able to solve this puzzle.

HTH

Rick

[Kevin Dorrell]

Rick,

OK, I understand what you are saying about process switching using both paths. You may well be right, and it would be interesting to lab it to verify.

However, pursuing a (maybe false) hypothesis for a moment that it only works correctly on CEF, the ping from (or to) the box would not be a fair test because internally generated packets are always process switched. To test its behavior under CEF you would have to attach yet another router to another interface and ping from there. Indeed, it may be that the load balancing simply does not apply to internally generated traffic for architectural reasons.

But this CEF/PS is only a hypothsis, and it may well be wrong. Load balancing may work correctly under process switching, and there is something else going on. We really need those diagnostics to solve the problem. Perhaps if Harold Ritter or Russ White are monitoring, they could explain what is happening here?

I understand the platform is 2620 + IOS 12.3.

Kevin Dorrell

Luxembourg

[Richard Burts]

Kevin

The original post described three routers: R1 generating the ping, R2 is the router of interest which is forwarding the ping, and R3 which is the destination. This is a pretty well thought out test and it anticipates your thought about internally generated packets are always process switched.

The file that John posted with debug output confirms that this is the case:

*Mar 1 00:26:48.011: IP: s=172.20.15.2 (Serial1/1), d=192.168.17.1 (Serial0/1), g=172.20.15.10, len 100, forward

The source address of 172.20.15.2 is an address connected to R2 not the address of the interface on R2.

HTH

Rick