BGP - Load sharing - q

[dpugalendi.d]

My server LAN is – 172.30.1.0/24 , and using BGP for primary and secondary Links on a single HUB Router,

I need to Load share the secondary Link by specific ip address ,

172.30.1.5 and 172.30.1.6 server traffic only via the Secondary Link using BGP on Router.

Note : When secondary is down it should use primary Link for all my spoke sites

Need help what to change on HUB and spoke Router BGP configs

[Richard Burts]

If we had more information about your environment we would be able to give you better advice. In particular you are asking about what to do with BGP on hub and on spoke routers. How do you have BGP configured on these routers. Please provide some clarification.

HTH

Rick

[dpugalendi.d]

The below is the BGP neighbour config with Vendors primary and secondary and the same at Spoke site also

router bgp 64577

bgp log-neighbor-changes

neighbor 101.1.222.22 remote-as 4752

neighbor 101.1.222.22 description

neighbor 172.16.0.11 remote-as 9732

neighbor 172.16.0.11 description

[Jon Marshall]

I agree with Rick, some more details would be helpful.  However from your description it sounds as though you have a hub with multiple spokes and you are exchanging routes between them using BGP. You want traffic between the spokes and hub for the specific server IPs you provided to use the secondary link ?

If so the problem you have trying it with BGP is the return traffic. ie. you could advertise the server IPs as host addresses from the hub site down both links and use AS prepending so the secondary link was preferred at all spoke sites. All spokes would then use the secondary link to send traffic to these servers.

The issue with that though is when the servers reply the destination IP is one of the spokes site addresses. How are you going to make sure that the secondary link is used for this traffic. You cannot tell the hub router to use the secondary for all spoke addresses because then all return traffic would go via the secondary link ie. all return traffic being for any device sending traffic back to the spokes.

So i don't think BGP is the solution to this or it could only be a partial solution. PBR could solve the problem of the return traffic though so you could either -

1) use PBR on the hub router and PBR for all the spoke routers. This would be quite a lot of config as you would need to update all routers.

or

2) use BGP to make sure the spokes use the secondary link for traffic to the specific servers and then use PBR on the hub to make sure traffic from these specific servers uses the secondary link. The advantage of this would be all the configuration would only be on the hub router.

If you do use PBR you may also need to track the availability of the link so that if it failed it would failover to the other link.

Having said that, Rick may know of a better way to do this though, so some more specifics would be helpful.

Jon

[dpugalendi.d]

Thanks ; can share some sample config also

[Jon Marshall]

Which option do you want to use ?

Jon

[dpugalendi.d]

Thanks , i need option 2 pls

[Jon Marshall · Accepted solution]

BGP config

========

You need host specific routes in your routing table ie.

ip route 172.30.1.5 255.255.255.255

ip route 172.30.1.6 255.255.255.255

router bgp 64577

network 172.30.1.5 mask 255.255.255.255

network 172.30.1.6 mask 255.255.255.255

neighbor x.x.x.x  route-map PREPEND out  <--- x.x.x.x is the neighbor for the primary link. Note the primary link neighbor not the secondary.

ip prefix-list servers seq 5 permit 172.30.1.5/32

ip prefix-list servers seq 10 permit 172.30.1.6/32

route-map PREPEND permit 10

match ip address prefix-list servers

set as-path prepend 64577

to check the above is working log on to the remote router and do a "sh ip bgp 172.30.1.5 255.255.255.255". You should see two entries and one should have two occurences of the AS 64577. The other route should be the one marked as the best path. "sh ip route" should also show the route to be via the secondary link.

PBR

====

access-list 101 permit ip host 172.30.1.5 any

access-list 101 permit ip host 172.30.1.6 any

route-map PBR permit 10

match ip address 101

set ip next-hop x.x.x.x    <--- where x.x.x.x is the next hop of the BGP neighbor  on the secondary link

int fa0/0  <-- this connects to the LAN where the servers are situated

ip policy route-map PBR

Note i have not included tracking on PBR. You may not need it and if you do there are docs on the Cisco site you can use.

Jon

[dpugalendi.d]

thanks i will check and get back to you on the same

[dpugalendi.d]

The BGP config is working fantastic.

; but instead of PBR  can i use  same BGP kind of config at my spoke site also using ACL and Route map...

[Jon Marshall]

; but instead of PBR  can i use  same BGP kind of config at my spoke site also using ACL and Route map...

No you can't. The problem is the return traffic from the hub site eg.

PC1 = 172.30.2.10 (this PC is at the spoke site)

S1 = 172.30.1.5  (this is one of the servers to be routed down the secondary link)

PC1 sends a packet to S1. The spoke router sends it via the secondary link because of your BGP changes. When the packet gets to S1 it then sends the return packet to the hub BGP router and it looks up the destination IP (172.30.2.10) and sees it should send it via the primary link and not the secondary link.

You cannot change that so that the return traffic is sent down the secondary link because then all traffic to 172.30.2.10 would go down the secondary link ie. traffic from the 172.30.1.5/6 servers but also traffic from any other server at the hub site.

This is why you need PBR because you are routing traffic based not just on destination IP but also source IP.

There is no way, as i said in my original post, to use BGP, or any routing protocol to achieve this because routing protocols are only concerned with the destination IP.

Glad to hear the BGP is working well.

Jon

[dpugalendi.d]

Thanks ; Note i have not included tracking on PBR. You may not need it and if you do there are docs on the Cisco site you can use. On Above PBR Statement ; changing next hop to secondary will give fall back to primary also ( when secondary is down ) or i need to use tracking the PBR for achive this feature ... pls clarify

[Jon Marshall · Accepted solution]

Re the BGP config. I diidn't include a second permit statement on the route map config which i should have done. The second statement is just an empty statement but it allows all other routes to be advertised ie. those you do not want to prepend. It sounds like your BGP is working though but i think it would be a good idea to modify the route map to add the second line ie.

route-map PBR permit 10

match ip address 101

set ip next-hop x.x.x.x    <--- where x.x.x.x is the next hop of the BGP neighbor  on the secondary link

route-map PBR permit 20

apoologies for missing it out of the original config.

As for PBR whether you need to track the next hop depends on how it is connected. If you have a point to point link to the BGP peer you may not need to. Bear in mind also that if the next hop is not available then PBR should fall back to the routing table.

If however there is a L2 switch for example between you and the BGP peer device then you would need to track the next hop because if the BGP peer goes down your end of the link would still think it was up as it is connected to the switch.

Jon

[dpugalendi.d]

"If however there is a L2 switch for example between you and the BGP peer device then you would need to track the next hop because if the BGP peer goes down your end of the link would still think it was up as it is connected to the switch.

YES , the above is happening in MPLS network also ...

When my MPLS HUB down and next hop not down , i am getting a PBR routing issue , still the packets going to next hop and returing ...

is it any way to avoid the same in PBR ?

Thanks in advance

[dpugalendi.d]

Can you Pls share option 1 configuration also to verify the suitable model