BGP load sharing using dmzlink-bw

luke.johnson · ‎08-08-2012

Hi,

I'm having some difficulty getting the following to work as I need it to. I have a 20Mb WAN link to a customer and a 16Mb ADSL 2+ also to the same customer. The idea is to have the DSL service provide additional bandwidth in times of high load (they would manually turn it on) or perhaps it would be left on all the time and just share load all the time.

I have setup in the lab configs for both the CPE and the core, and I'm seeing the customer's network from both BGP sessions, but when I perform a download from either the same PC on the clients side or another PC, I seem to be only getting data over the 20Mb service. A traceroute from the core indicates that traffic is going via both paths, but I'm just not seeing it on the graphs and it's also not reflected in the download rate.

I've included some config and also some output from various show commands.

Any advise would be much appreciated.

CORE

router bgp 100

neighbor 10.1.1.1 remote-as 65100

neighbor 10.1.1.1 description BGP testing via DSL

neighbor 10.1.1.1 update-source Loopback0

neighbor 10.1.1.1 send-community both

neighbor 10.1.1.1 default-originate

neighbor 10.1.1.1 prefix-list customer in

neighbor 10.1.1.1 distribute-list 1 out

neighbor 10.1.1.1 dmzlink-bw

neighbor 172.16.0.1 remote-as 65100

neighbor 172.16.0.1 description BGP tesing - ethernet

neighbor 172.16.0.1 send-community both

neighbor 172.16.0.1 default-originate

neighbor 172.16.0.1 prefix-list customer_ in

neighbor 172.16.0.1 distribute-list 1 out

neighbor 172.16.0.1 dmzlink-bw

sh ip route 10.99.99.0 (192.168.1.1 is the IP assigned to the DSL session (Vi16) )

Routing entry for 10.99.99.0/29

Known via "bgp 100", distance 20, metric 0

Tag 100, type external

Last update from 192.168.1.1 00:24:15 ago

Routing Descriptor Blocks:

* 192.168.1.1, from 192.168.1.1, 00:24:15 ago

Route metric is 0, traffic share count is 5

AS Hops 1

Route tag 65100

172.16.0.2, from 172.16.0.2, 01:24:25 ago

Route metric is 0, traffic share count is 8

AS Hops 1

Route tag 65100

sh ip cef 10.99.99.0

10.99.99.0/29

nexthop 192.168.1.1 Virtual-Access16

nexthop 172.16.0.2 GigabitEthernet0/1.557

sh ip bgp 10.99.99.0

BGP routing table entry for 10.99.99.0/29, version 4757446

Paths: (2 available, best #2, table Default-IP-Routing-Table)

Multipath: eBGP iBGP

Advertised to update-groups:

5

65100

192.168.1.1 from 192.168.1.1 (10.99.99.2)

Origin IGP, metric 0, localpref 100, valid, external, multipath

DMZ-Link Bw 1500 kbytes

65100

172.16.0.2 from 172.16.0.2 (10.99.99.2)

Origin IGP, metric 0, localpref 100, valid, external, multipath, best

DMZ-Link Bw 2500 kbytes

CPE

router bgp 65100

bgp router-id 10.99.99.2

bgp log-neighbor-changes

neighbor 172.16.0.1 remote-as 100

neighbor 172.16.0.1 description BGP via ethernet

neighbor 10.1.1.2 remote-as 100

neighbor 10.1.1.2 description BGP via xDSL

maximum-paths 4

!

address-family ipv4

neighbor 172.16.0.1 activate

neighbor 172.16.0.1 send-community both

neighbor 172.16.0.1 dmzlink-bw

neighbor 10.1.1.2 activate

neighbor 10.1.1.2 send-community both

neighbor 10.1.1.2 next-hop-self

neighbor 10.1.1.2 dmzlink-bw

maximum-paths 4

no auto-summary

no synchronization

bgp dmzlink-bw

network 10.99.99.0 mask 255.255.255.248

exit-address-family

luke.johnson · ‎08-10-2012

Any ideas? anyone?

Peter Paluch · ‎08-12-2012

Hello Luke,

Your output suggests that the CORE router should see the client's network 10.99.99.0/29 via both paths. I guess what you are experiencing is not a problem but rather a symptom of how CEF performs destination-based load balancing.

CEF appears to use some kind of hashing both source and destination IP address when determining the exact route of a packet. You can test the CEF decision using the command

show ip cef exact-route source-address destination-address

Here, the source-address would be the IP address of the server that the clients downloaded data from, and destination-address would be the client's IP address (i.e. the addressing of the return traffic back to the client). Try to find out if both client IP addresses may have resulted in CEF choosing the same path.

What platform is your CORE router, anyway?

Best regards,

Peter

luke.johnson · ‎08-12-2012

Thanks for the reply Peter.

I was starting to suspect it was CEF related and from the output I've been getting it does appear to be the case - as you say, not a problem with CEF but more in which the way it handles the load balancing.

My testing from a single and multiple hosts to various destinations wasn't enough to see the load balancing appear on the graphs - perhaps more traffic with a greater spread of hosts and destinations would better demonstrate the load balancing.

From the various show commands, I agree that it does look to be doing what it is configured to do.

Thanks again for your response.

luke.johnson · ‎08-12-2012

I forgot to add that I'm doing this testing on a 7200 G1