BGP Loadsharing, What am I missing?

Loadsharing and redundancy are broke. What am I missing? Here are the BGP configs (IP's are changed to protect the innocent :) )

R1 & R2 in the same ASN, R1 connects to Provider1 ASN and R2 connects to Provider2 ASN:

R1 Config

interface Loopback0 ip address 4.4.66.253 255.255.255.255

router bgp 22105 bgp log-neighbor-changes neighbor 4.4.66.254 remote-as 22105 neighbor 4.4.66.254 update-source Loopback0 neighbor 10.200.200.3 remote-as 105 neighbor 10.200.200.3 description -=-=- ebgp peer with Provider1-=-=- neighbor 10.200.200.3 version 4 ! address-family ipv4 neighbor 4.4.66.254 activate neighbor 4.4.66.254 send-community neighbor 4.4.66.254 soft-reconfiguration inbound neighbor 10.200.200.3 activate neighbor 10.200.200.3 send-community neighbor 10.200.200.3 prefix-list provider1-out out no auto-summary no synchronization network 4.4.66.0 mask 255.255.255.0 network 192.168.10.0 mask 255.255.254.0 exit-address-family ! ip route 4.4.66.0 255.255.255.0 Null0 ip route 4.4.66.254 255.255.255.255 FastEthernet4/0 ip route 192.168.10.0 255.255.254.0 Null0

ip prefix-list provider1-out description advertised prefixes to provider1 ip prefix-list provider1-out seq 5 permit 192.168.10.0/23 ip prefix-list provider1-out seq 10 permit 4.4.66.0/24 logging alarm informational

access-list 2 permit 4.4.66.0 0.0.0.255 access-list 3 permit 192.168.10.0 0.0.1.255

route-map comm permit 10 match ip address 2 set community 105:70 ! route-map comm permit 20 match ip address 3 set community 105:100 ! route-map comm permit 30

R2 Config

interface Loopback0 ip address 4.4.66.254 255.255.255.255

router bgp 22105 bgp log-neighbor-changes neighbor 10.10.10.3 remote-as 1234 neighbor 10.10.10.3 description -=-=- eBGP peer with Provider2 -=-=- neighbor 10.10.10.3 version 4 neighbor 4.4.66.253 remote-as 22105 neighbor 4.4.66.253 update-source Loopback0 maximum-paths 4 ! address-family ipv4 neighbor 10.10.10.3 activate neighbor 10.10.10.3 send-community neighbor 10.10.10.3 prefix-list lvlt-out out neighbor 10.10.10.3 route-map comm out neighbor 4.4.66.253 activate neighbor 4.4.66.253 send-community neighbor 4.4.66.253 soft-reconfiguration inbound maximum-paths 4 no auto-summary no synchronization network 4.4.66.0 mask 255.255.255.0 network 192.168.10.0 mask 255.255.254.0 exit-address-family ! ip route 4.4.66.0 255.255.255.0 Null0 ip route 4.4.66.253 255.255.255.255 FastEthernet4/0 ip route 192.168.10.0 255.255.254.0 Null0

ip bgp-community new-format ! ! ! ip prefix-list Provider2-out description advertised prefixes to Provider2 ip prefix-list Provider2-out seq 5 permit 192.168.10.0/23 ip prefix-list Provider2-out seq 10 permit 4.4.66.0/24 logging alarm informational ! access-list 2 permit 192.168.10.0 0.0.1.255 access-list 3 permit 4.4.66.0 0.0.0.255

route-map comm permit 10 match ip address 2 set community 1234:70 ! route-map comm permit 20 match ip address 3 set community 1234:100 ! route-map comm permit 30

Reply to
JVK
Loading thread data ...

BGP relies on underlying protocols, therefore I'm fairly certain you need to bring BGP back one hop in your network to your core. The reason is, the traffic is reaching R1 or R2 through an underlying protocol (OSPF, EIGRP), and by the time it is to one or the other (probably the one with the better route to 0.0.0.0), it will only go out that directly connected pipe. You need to bring bgp back so that it can load balance R1 and R2, and then subsequently load balance your internet pipes. Without that, BGP will not load balance as R1 does not have two paths..it only has one. Hope this makes sense, but we had to do this when load balancing DS3s between datacenters on separate routers.

Reply to
Trendkill

For iBGP, not EBGP

therefore I'm fairly certain you

R1 has two 'pipes'. One to an ISP and one iBGP toR2 so as far as BGP is concerned it will see BGP routes via both internet pipes. Traffic will not simply go out via one router because there is a directly connected internet circuit. It will be making a BGP routing decision based on the BGP policy, AS hops etc...

Hope this makes sense, but we

Reply to
chris

If traffic destined for the internet is routed to R1 based on 0.0.0.0 from an IGP, then it will route out R1s internet connection. The same goes if it routes to R2. So unless he is load sharing within his IGP, then all traffic most likely routes to R1 or R2 and goes out that single pipe. BGP has to know about two equal cost routes to load balance, and in this case I'm don't see anything that would ensure that the costs are equal on both routers given the 2nd ISP connection is a hop away. I still think he needs to back BGP up one hop so that his core will know that he has two equal cost internet routes through directly connected networks....both one hop away.

Reply to
Trendkill

Yes, you are correct. After some more research and work in the lab, I found my error. Both routers are sending updates with the same local preference (100). What I failed to due was create a route-map statement to create the correct local preference for each AS and add the next hop self command. Once this was done, each AS had the correct local preference and the default route (we receive full updates and default routes) is taking the correct path out (our 100MB link) because the IP address of the carrier with the faster link is lower than the other carrier. I also did some AS prepending to allow for the redundant route advertisements. So all is well back in BGP land. Thanks to all who contributed, between the comments and some other digging I was able to get this resolved. Cheers!

Reply to
JVK

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.