BGP and static route 1

[pepe123]

I have a Cisco router running BGP for the main (primary) link. If my main link goes down there is a back up circuit. I have created a static route with a metric of 250. When the main link goes down the traffic goes via my backup with no problem. The problem is when the main link(primary) comes backup the router does not change the traffic back to the primary. On the bgp status I do not get an update about the location being backup until I remove the static route. If any one can help me on this issue I would appreciated.

Thanks,
Jose'

 

[sbonete]

One point, please jneiberger correct me if it is wrong:

As far as I have been able to see, lets follow the route 197.98.3.0. All works ok when learning about that route via BGP over the mpls link. Great.

Now, the circuit fails. The router add a new static at its routing table. The router now routes over the backup path. Perfect.

The primary link is recovered and... as we have configured under bgp 'redistribute statics' our box now tries to pass the info about our the backup route to its peer. Also the bgp peer updates the router with a different path to reach that network.

Honestly, I think that there could be a little mess in that point. I am not totally sure about what is going to do the router in that situation but another peer is triying to inform it about a route that it is redistributing... I think that it will not believe the peer.

Can the following be tried, just for test, remove the redistribute static command under bgp and try. If it works, a tunning under bgp redistribution should be done.

I am going to check under cisco and over lab the sugested config.

pepe123, please update us with any action as it is becoming interesting.

regards all.

Sam Bonete.

 

[jneiberger]

That's an interesting theory and you might be right. However, I'm not sure that it explains why the BGP peer doesn't come back up at all when the primary comes back up.

You do suggest an interesting routing problem, and one worth investigating once we figure out why the BGP peer won't come back up. Something must be failing during peer negotiation but I have no idea what it might be.

Can you do some debugging on this router? I'd suggest debugging the BGP neighbor negotiation to see if you can spot an error message indicating why the peer won't connect.

 

[sbonete]

Checked on lab, I think that the asumption is ok.

1. Configured BGP without redistributing statics, but with a a backup route. All worked ok, after the main link came up, the router deleted the backup route to 10.20.2.1 and used again the BGP one.

*Mar 1 00:25:45.871: BGP(0): 192.168.1.5 update run completed, afi 0, ran for 40ms, neighbor version 0, start version 28,8*Mar 1 00:25:45.875: BGP(0): 192.168.1.5 initial update completed
*Mar 1 00:25:45.939: BGP(0): 192.168.1.5 rcvd UPDATE w/ attr: nexthop 192.168.1.5, origin ?, path 65000 1
*Mar 1 00:25:45.943: BGP!
router bgp 2
no synchronization
bgp log-neighbor-changes
redistribute connected
redistribute static route-map NEEDED_STATICS
neighbor 192.168.1.5 remote-as 65000
no auto-summary
!
(0): 192.168.1.5 rcvd 10.20.1.0/24
*Mar 1 00:25:45.947: BGP(0): 192.168.1.5 rcvd 10.20.2.0/24
*Mar 1 00:25:45.955: BGP(0): 192.168.1.5 rcvd 10.20.3.0/24
*Mar 1 00:25:45.959: BGP(0): 192.168.1.5 rcvd 192.168.1.0/30
*Mar 1 00:25:45.967: BGP(0): 192.168.1.5 rcvd 192.168.1.8/30
*Mar 1 00:25:45.983: BGP(0): Revise route installing 1 of 1 route for 10.20.1.0/24 -> 192.168.1.5 to main IP table
*Mar 1 00:25:45.987: BGP(0): Revise route installing 1 of 1 route for 10.20.2.0/24 -> 192.168.1.5 to main IP table
*Mar 1 00:25:45.995: BGP(0): Revise route installing 1 of 1 route for 10.20.3.0/24 -> 192.168.1.5 to main IP table
*Mar 1 00:25:46.003: BGP(0): Revise route installing 1 of 1 route for 192.168.1.0/30 -> 192.168.1.5 to main IP table


2. Configured also a redistribute static command, therefore after a failure and recovery of the main link, the router is redistributing the backup route to its peer 192.168.1.5 and also learning that router from the same peer. And... NO GETTING IT INSIDE THE ROUTING TABLE![/color red]

*Mar 1 00:27:43.543: BGP(0): 192.168.1.5 rcvd UPDATE w/ attr: nexthop 192.168.1.5, origin ?, path 65000 1
*Mar 1 00:27:43.547: BGP(0): 192.168.1.5 rcvd 10.20.1.0/24
*Mar 1 00:27:43.555: BGP(0): 192.168.1.5 rcvd 10.20.2.0/24
*Mar 1 00:27:43.559: BGP(0): 192.168.1.5 rcvd 10.20.3.0/24
*Mar 1 00:27:43.567: BGP(0): 192.168.1.5 rcvd 192.168.1.0/30
*Mar 1 00:27:43.575: BGP(0): 192.168.1.5 rcvd 192.168.1.8/30
*Mar 1 00:27:43.587: BGP(0): Revise route installing 1 of 1 route for 10.20.1.0/24 -> 192.168.1.5 to main IP table
*Mar 1 00:27:43.595: BGP(0): Revise route installing 1 of 1 route for 10.20.3.0/24 -> 192.168.1.5 to main IP table
*Mar 1 00:27:43.603: BGP(0): Revise route installing 1 of 1 route for 192.168.1.0/30 -> 192.168.1.5 to main IP table

At the IP routing table:

10.0.0.0/24 is subnetted, 6 subnets
C 10.1.3.0 is directly connected, Loopback3
C 10.1.2.0 is directly connected, Loopback1
C 10.1.1.0 is directly connected, Loopback0
S 10.20.2.0 [250/0] via 192.168.1.10
B 10.20.3.0 [20/0] via 192.168.1.5, 00:07:09
B 10.20.1.0 [20/0] via 192.168.1.5, 00:07:09
192.168.1.0/30 is subnetted, 3 subnets
C 192.168.1.8 is directly connected, Serial0
B 192.168.1.0 [20/0] via 192.168.1.5, 00:07:09
C 192.168.1.4 is directly connected, Serial1


At the BGP table the situation is as follows:

RA#sh ip bgp
BGP table version is 42, local router ID is 10.1.3.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 0.0.0.0 0 32768 ?
*> 10.1.2.0/24 0.0.0.0 0 32768 ?
*> 10.1.3.0/24 0.0.0.0 0 32768 ?
*> 10.20.1.0/24 192.168.1.5 0 65000 1 ?
* 10.20.2.0/24 192.168.1.5 0 65000 1 ?
*> 192.168.1.10 0 32768 ?
*> 10.20.3.0/24 192.168.1.5 0 65000 1 ?
*> 192.168.1.0/30 192.168.1.5 0 65000 1 ?
*> 192.168.1.4/30 0.0.0.0 0 32768 ?
* 192.168.1.8/30 192.168.1.5 0 65000 1 ?
*> 0.0.0.0 0 32768 ?


Conclusion:
As we can see at the bgp table for RA, once the backup router has been used and, after the failure, the main link has been recovered, the bgp table has two paths for the studied router 10.20.2.0. One via its BGP neighbour (ASPATH 65000 1 ) and another generated by itself because of the redistribute static:

* 10.20.2.0/24 192.168.1.5 0 65000 1 ?
*> 192.168.1.10 0 32768 ?

Also, the prefered or elected one is the one generated by itself with a nexhop equal to the next hop of the static route.


Explanation:
Following the logic of bgp election process, the router preffers to elect a route with the highest weight. As the redistribute route has a default weight of 32768 it is prefered over the one learned by its peer.


Solution:
As stated above, the solution passes for tunning the redistribution of the static over BGP. Is really needed redistribute those statics? If so, filter that redistribution with a route map, i.e:

a) Tag the backup static routes with some tag (this example I am using 40, looks line NO).

ip route 10.20.2.0 255.255.255.0 192.168.1.10 250 tag 40[/color blue]

Take care don't forget the AD (250). It happened to me I was getting mad about what where was the failure!

b) Create a route a route map that blocks the redistribution of the statics that have been taged with the 40 tag.Redistribute the statics over bgp with a route map. In this case I have called it NEEDED_STATICS.

!
route-map NEEDED_STATICS deny 10
match tag 40
!
route-map NEEDED_STATICS permit 20
!
[/color blue]

c) Redistribute the statics over bgp with that route map.

!
router bgp 2
no synchronization
bgp log-neighbor-changes
redistribute connected
redistribute static route-map NEEDED_STATICS
neighbor 192.168.1.5 remote-as 65000
no auto-summary
!
[/color blue]


pepe123, I think it will fix your problem
jneiberger, thanks for pointing this issue to the correct path!

Regards.

Samuel Bonete.

 

[jneiberger]

Excellent work, sbonete! Your hypothesis made sense and this certainly proves it. I'm still wondering why the BGP peer doesn't even come up in pepe123's environment.

Pepe123, are you absolutely certain that the BGP peer doesn't establish at all?

 

[pepe123]

Thanks sbonete. I will try this this week and let you know.

Jneiberger the peer never establish until I delete the static route. BGP nevers gets an update.

 

[onlinecorp]

Can someone clarify this? I have 2 T1s with one carrier and 1t1 with another. After implimenting BGP I now have all my traffic routing through one carrier and none on the other. I am being told that with BGP this is way it is supposed to work. That the other carrier is just a fail over. I thought that I could config during regular operations that I can use all my T1 bandwidth and only during a failure does it switch to the other carrier?
Does anyone know for sure how this is supposed to work???
Can I use all my bandwidth and only BGP on failure???

 

[jneiberger]

Onlinecorp, I have some questions I'd like to ask you but we should really start another thread about it. This would take us too far off-topic for this thread.

Thanks,
John

 

[onlinecorp]

OK I started a tread called BGP please join

 

[pepe123]

sbonete, I appreciate the help. That work with no problems. You are the man.

Thanks,
pepe

 

[sbonete]

It has been a pleasure.
Regards.
Sam.

 

[baddos]

Can someone clarify this? I have 2 T1s with one carrier and 1t1 with another. After implimenting BGP I now have all my traffic routing through one carrier and none on the other. I am being told that with BGP this is way it is supposed to work. That the other carrier is just a fail over. I thought that I could config during regular operations that I can use all my T1 bandwidth and only during a failure does it switch to the other carrier?
Does anyone know for sure how this is supposed to work???
Can I use all my bandwidth and only BGP on failure???

BGP does work this way by default. The only way to load balance, is if you have two equal cost routes to the same subnet and your maximum-paths > 1.

Now, you should try after hours unplugging your primary router to test your failover as a test. You need to be sure that backup ISP is doing it's job.