Why IBGP traffic cannot be balanced between two circuits?

cn.wangxuejun · ‎08-01-2008

Router A connects to Router B and C with a 2.5 POS circuit respectively. Router A is the router reflector of B and C while B and C have advertised the same ip address blocks to the router reflector A. The feature of maximum path has been enabled on IBGP and IS-IS and I have verified the per-destination sharing works fine when the command "show ip cef x.x.x.x" is issued. But what's curious is that the traffic from A to B and C is only carried on the circuit of A->B, the circuit of A->C has little output traffic. When I increase the isis metric of A->B, all traffic will transit to the circuit A->C soon. Except that the linecard of A-B is a 4-port 2.5G POS Engine 4 card while the linecard of A->C is a SIP 601 Engine 5 card, all physical parameters and configuration of these two circuits are same.

Is there anything else I might have not noticed? Any reply will be appreciated, thanks in advance.

lee.reade · ‎08-01-2008

Hi,

Are the BGP routes advertised from B and C equal in all respects for BGP attributes? weight, local pref, as path, origin,med, next hop metric?

Can you give us a show ip bgp x.x.x.x where x.x.x.x is an external prefix.

HTH

LR

tdrais · ‎08-01-2008

This sounds like a isis issue. BGP has should not care what interface metric you put in.

First make sure the route you want is being learned via BGP rather than ISIS. ISIS has a better administrative distance than IBGP so it will be preferred.

If the prefix you are interested in is using ibgp learned then you need to ensure that the ISIS metric is the same for both the nexthop addresses. There is a option to override this restriction but I forget at the moment.

milan.kulik · ‎08-01-2008

Hi,

do you mean maximum-paths ibgp number unequal-cost number ?

See

http://www.cisco.com/en/US/docs/ios/12_3/iproute/command/reference/ip2_k1g.html#wp1058680

but I never used that...

BR,

Milan

Giuseppe Larosa · ‎08-02-2008

Hello Tiger,

Based on the usual long hierarchy of criterias BGP uses to choice best path a last tie is the lowest BGP router-id.

So a choice is done via Router B

When you change the IS-IS metric you get traffic via router C (lowest IGP metric to iBGP nexthop comes before then BGP router-id).

maximum-paths applies only to eBGP sessions.

Try to use:

router bgp XXX

maximum-paths ibgp 2

You may achieve load balancing on RA.

Be aware that however, RA as route reflector will propagate only the best path (via RB) to the rest of your network.

This is a known limitation in implementation of BGP Route Reflector.

Hope to help

Giuseppe

cn.wangxuejun · ‎08-03-2008

Hi Giuseppe and other guys, thanks for your reply.

I've tried to implement maximum-paths ibgp 2 but failed to solve the problem. Also, I'm 100% sure that all BGP criterias are same for the routes advertised by these two IBGP neighbors. Someone told me it might be resulted from the second hash algorithm of Cisco's router.

The router platform which performs as router reflector is Cisco 12410 with IOS Version 12.0(32)SY4.

I think I have to open a case to ask Cisco why. If any progress, I'll post here. Thanks!

Giuseppe Larosa · ‎08-03-2008

Hello Tiger,

if you can try to make RB and RC normal iBGP clients of RA (not clients) in this case you should see both paths installed in the routing table.

Behaviour is different in Route-Reflector as I told you in the previous post.

However, have you checked the IP routing table ?

do a sh ip route prefix_behind_RB&RC if you can see both installed it is fine.

Because in the sh ip bgp prefix_behind_RB&RC it can still show only one best path.

hash algorythm : if your traffic is made of only one flow with a specific source and specific destination it will go through one path only

You would need to use load-sharing per packet on RA to have the packets of a single flow balanced on the two links.

I you have multiple flows with different SA and DA, once you get two entries in the routing table for the destination prefix, you should get some load distribution.

As a workaround you could have the IP prefixes behind RB and RC advertised on IS-IS

Hope to help

Giuseppe