BGP Loadsharing, What am I missing?

Discussion in 'Cisco' started by JVK, Apr 17, 2007.

  1. JVK

    JVK Guest

    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
     
    JVK, Apr 17, 2007
    #1
    1. Advertisements

  2. JVK

    Trendkill Guest

    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.
     
    Trendkill, Apr 18, 2007
    #2
    1. Advertisements

  3. JVK

    chris Guest

    BGP relies on underlying protocols,

    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
     
    chris, Apr 18, 2007
    #3
  4. JVK

    Trendkill Guest

    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.
     
    Trendkill, Apr 18, 2007
    #4
  5. JVK

    JVK Guest

    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!
     
    JVK, Apr 19, 2007
    #5
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.