BGP primary route

[Liam Dwyer]

Good morning, 

I am trying to find out if there is way to fail back to my primary ISP circuit without unplugging the secondary circuit?

Is there a command for this on the primary or secondary router?

Two circuits, two ISP's.  3945 routers for both. 

Many thanks in advance!

[Julio E. Moisa]

Hi Liam,

You could use IP SLA + EEM script or just an EEM script to create an automatic failover trigerred by any event on the primary, it could be detecting connectivity between the primary router and ISP. 

Please let me provide you and example.

[Julio E. Moisa]

This is an example to make an automatic failover if the primary ISP is down, but you could make something similar in order to trigger the script once the primary ISP is Up again. Take in consideration if you are using BGP attributes like Local Preference it will prefer the highest value so if the ISP1 is down all the traffic will go through ISP2, once ISP1 is up again all the traffic will be moved to the primary path again. No the script could be used to avoid flappings. 

event manager applet SCRIPT01
event syslog pattern "Line protocol on Interface GigabitEthernet0/0, changed state to down"
action 1 cli command "enable"
action 10 cli command "conf t"
action 11 cli command "router bgp 100"
action 12 cli command "neigh 1.1.1.2 shut"
action 13 cli command "end"
action 14 cli command "wr memory"

event manager applet SCRIPT02
event syslog pattern "%BGP-5-ADJCHANGE: neighbor 1.1.1.2 active Down BGP Notification sent"
action 1 cli command "enable"
action 10 cli command "conf t"
action 11 cli command "router bgp 100"
action 12 cli command "neigh 1.1.1.2 shut"
action 13 cli command "end"
action 14 cli command "wr memory"

event manager applet SCRIPT03
event syslog pattern "%BGP-5-ADJCHANGE: neighbor 1.1.1.2 active Down BGP Notification received"
action 1 cli command "enable"
action 10 cli command "conf t"
action 11 cli command "router bgp 100"
action 12 cli command "neigh 1.1.1.2 shut"
action 13 cli command "end"
action 14 cli command "wr memory"

event manager applet SCRIPT04
event syslog pattern "%BGP-5-ADJCHANGE: neighbor 1.1.1.2 Down BGP Notification Received"
action 1 cli command "enable"
action 10 cli command "conf t"
action 11 cli command "router bgp 100"
action 12 cli command "neigh 1.1.1.2 shut"
action 13 cli command "end"
action 14 cli command "wr memory"

event manager applet SCRIPT05
event syslog pattern "%BGP-3-NOTIFICATION: sent to neighbor 1.1.1.2 4/0 (hold time expired)"
action 1 cli command "enable"
action 10 cli command "conf t"
action 11 cli command "router bgp 100"
action 12 cli command "neigh 1.1.1.2 shut"
action 13 cli command "end"
action 14 cli command "wr memory"

event manager applet SCRIPT06
event syslog pattern "%BGP-5-NBR_RESET: Neighbor 1.1.1.2 reset"
action 1 cli command "enable"
action 10 cli command "conf t"
action 11 cli command "router bgp 100"
action 12 cli command "neigh 1.1.1.2 shut"
action 13 cli command "end"
action 14 cli command "wr memory"

event manager applet SCRIPT07
event syslog pattern "%BGP-5-ADJCHANGE: neighbor 1.1.1.2 Down BGP Notification sent"
action 1 cli command "enable"
action 10 cli command "conf t"
action 11 cli command "router bgp 100"
action 12 cli command "neigh 1.1.1.2 shut"
action 13 cli command "end"
action 14 cli command "wr memory"

Hope it is useful

:-)

[milan.kulik]

Hi,

why any EEM script would be necessary?

Isn't it easier to simply apply better Local Preference to prefixes advertised from the primary router to the LAN and worse BGP attributes (prepending your AS number several times, e.g.) to your prefixes advertised to the secondary ISP?

BR,

Milan

[Julio E. Moisa]

Hi

Yes, that is correct it was included on the post below, if the primary devices has a highest local preference it will be always preferred while the peering is up, if the main peering is down the traffic will go through the backup router and once the main peering is up again the traffic will be reestablished.

The EEM could be used to avoid flapping and if voice or other sensitive traffic are passing through it will be affect, so you can use EEM to create a an automatic failover and reestablish it manually during a maintenance window to avoid any downtime on production. Also BGP dampening could be evaluated. 

:-)

[milan.kulik]

Hi,

IMHO, it's not a good practice to shutdown the primary BGP neighbor at the moment the peering goes down.

And definitely not to save the config!

What if the primary connection is fixed by the ISP but the secondary goes down in the meantime?

You would need another script to detect it and let the primary neighbor unshut immediately!

What about the situations when BGP peering remains up but no prefixes are received effectively?

I'm afraid all script-based solutions are just bringing complexity.

I believe  voice or other sensitive traffic affecting by flapping back to primary is not so dramatic - I usually see cca 1 Ping lost during such situations.

What about just adding some IP SLA (tracking some important prefix received via BGP primary connection, e.g.) to influence the preference of the default route (if used) advertised by the primary router to the LAN and BGP attributes of prefixes advertised out by the primary router to the ISP possibly?

BR,

Milan

[Giuseppe Larosa]

Hello Milan,

I totally agree with your concerns about the proposed EEM scripts approach.

BGP protocol gives to us the local preference tool to handle this scenario.

And checking the effective reachability of some host over the border router connected to the primary ISP using IP SLA should be enough as you have suggested.

Best Regards

Giuseppe

[cofee]

We came across this strange issue where bgp peering wouldn't be affected and remote Ebgp neighbor would still be pingable, but Users couldn't connect to Vpn due to massive CRC errors on primary circuit. Since Ebgp peering wasn't dropped ip sla or hsrp tracking wouldn't help and traffic won't failover to secondary circuit.

we ended up using eem script to monitor CRC errors and shut down the interface if the policy is triggered. This helped us big time to fail over to secondary circuit when there was an issue. There can definitely be situations where eem script makes more sense, but you will just need to decide what solituon works best for your network.

[Julio E. Moisa]

Hi

I have seen this situation on contact centers and believe me it could affect the voice a lot hehe. But if it is just data it could be handled just with local-preference. 

:-)

[paul driver]

Hello

depending on your setup regards prefixes advertisement into your network -( assuming default route from each isp) and unless something drastic inside the isp failed  to route then as long as ibgp peering is the established between each of your  sites rtrs  and igp between bgp rtr and your L3 core then all would be good.

Advertising a two default routes into your igp with a preference to the primary isp default will only install the preferred one into the route table thus is the primary isp does go down then the other default will then advertised 

You can also as suggested incorporate EEM to actively monitor reachabilty inside the isp and if for some reason th peering was up but reachabity was lost then failover would occur

res

paul