CUBE dial peer failover

[mclean.danny]

Hello fellow IT pros,

We have two ITSP SIP servers being learned via BGP. they designed the failover to use the internet when BGP routes are lost. The problem is the routing path is one direction to the ITSP via the cube and another direction via the internet. So in my dial-peer bind commands I have to chose the correct interface depending on if the ITSP primary path is available. But since the ITSP IP's will be available either via BGP or internet then the bind command will not work since it is applied to the primary call path interface. Do I have to use one SIP server for primary and one for backup via the internet each bound to their respective interfaces? I will need to setup a prefix list to filter the backup SIP server from the provider.  Another option is to land the carrier router and learn BGP directly to the core. I would like to try to the first option because the site is on the other side of the country.

[Ayodeji Okanlawon]

I am not sure I totally understand you but cant you just use options ping on each dial-peer. When the BGP neighbour is down, then options ping to that ITSP will fail and the call will be routed via the back up dial-peer. you can configure the correct bind statements based on each dial-peer

[mclean.danny]

Hi Ayodeji,

The ITSP mentioned PING options causes issues with for them for some reason. The issue with PING is that the IP will always be available either via BGP or via the internet so PING would not fail to the next dial peer. My issue is when I use the bind command on the dial-peer they exit interface for the SIP servers will be different depending on if they are available over the private or public network.

[Ayodeji Okanlawon]

In this case then your best bet will be to use EEM. Embedded event manager. You can use EEM

Examples

Embedded Event Manager - Interface - No Shut

EEM being used to monitor an interface and perform a "no shut" if the interface state changes to down

event manager applet F0/1

event syslog pattern "Interface FastEthernet0/1, changed state to down"

action 1.0 cli command "enable"

action 1.1 cli command "config terminal"

action 1.2 cli command "interface fas 0/1"

action 1.3 cli command "no shut"

action 9.5 syslog msg "FastEthernet0/1 is UP leveraging EEM"

Embedded Event Manager - Default Route

Here is a EEM Scenario Question:

Provide a solution that provides failover capabilities from the primary link to the backup link and failback capabilities from the backup link to the primary link. You must send a syslog message stating "Failed over to the Backup Link" during failover and a syslog message "Failed Back to the Primary Link" when failing back.

Requirements:

• You cannot use IP SLA
• You cannot use dynamic routing on R1
• You cannot modify the current routing configuration on R2 and R4
• You cannot use static floating routes on R1

R1

interface FastEthernet0/0

ip address 192.168.1.1 255.255.255.0

interface Serial1/0

ip address 10.0.1.1 255.255.255.0

interface Serial1/1

ip address 10.0.0.1 255.255.255.0

R2

interface FastEthernet0/0

ip address 192.168.0.2 255.255.255.0

interface Serial1/0

ip address 10.0.1.2 255.255.255.0

router rip

version 2

passive-interface default

no passive-interface FastEthernet0/0

network 10.0.0.0

network 192.168.0.0

no auto-summary

ip route 192.168.1.0 255.255.255.0 Serial1/0

R4

interface FastEthernet0/0

ip address 192.168.0.4 255.255.255.0

interface Serial1/0

ip address 10.0.0.4 255.255.255.0

router rip

version 2

passive-interface default

no passive-interface FastEthernet0/0

network 10.0.0.0

network 192.168.0.0

no auto-summary

ip route 192.168.1.0 255.255.255.0 Serial1/0

Give it a try --- Solution Below

Solution

There are many ways to tackle an issue and in this case I choose to leverage object tracking and EEM (Embedded Event Manager provides real-time network event detection and automation)

track 1 interface Serial1/0 line-protocol

ip route 0.0.0.0 0.0.0.0 Serial1/0

event manager applet Primary-Backup

event syslog pattern "1 interface Se1/0 line-protocol Up->Down"

action 1.0 cli command "enable"

action 2.0 cli command "configure terminal"

action 3.0 cli command "no ip route 0.0.0.0 0.0.0.0 serial 1/0"

action 4.0 cli command "ip route 0.0.0.0 0.0.0.0 serial 1/1"

action 50.0 cli command "end"

action 99.0 syslog msg "Failed over to the Backup Link"

event manager applet Backup-Primary

event syslog pattern "1 interface Se1/0 line-protocol Down->Up"

action 1.0 cli command "enable"

action 2.0 cli command "configure terminal"

action 3.0 cli command "no ip route 0.0.0.0 0.0.0.0 serial 1/1"

action 4.0 cli command "ip route 0.0.0.0 0.0.0.0 serial 1/0"

action 50.0 cli command "end"

action 99.0 syslog msg "Failed Back to the Primary Link"

Explanation

track 1 interface Serial1/0 line-protocol - (this tracks the line protocol of the interface, we could have used IP SLA but the requirements prohibited us from doing so)

ip route 0.0.0.0 0.0.0.0 Serial1/0 - (Default route using the primary link)

event manager applet Primary-Backup - (Name of the EEM Applet)

event syslog pattern "1 interface Se1/0 line-protocol Up->Down" - (Syslog message generated from object tracking 1 configuration")

action 1.0 cli command "enable" - (command to put the applet into enable mode)

action 2.0 cli command "configure terminal" - (command to put the applet into global configuration mode)

action 3.0 cli command "no ip route 0.0.0.0 0.0.0.0 serial 1/0" - (command to remove the default route pointing to the primary link)

action 4.0 cli command "ip route 0.0.0.0 0.0.0.0 serial 1/1" - (command to add the default route pointing to the backup link)

action 50.0 cli command "end"

action 99.0 syslog msg "Failed over to Backup Link" - (Create syslog message based on the requirements)

event manager applet Backup-Primary - (Name of the EEM Applet)

event syslog pattern "1 interface Se1/0 line-protocol Down->Up" - (Syslog message generated from object tracking 1 configuration")

action 1.0 cli command "enable" - (command to put the applet into enable mode)

action 2.0 cli command "configure terminal" - (command to put the applet into global configuration mode)

action 3.0 cli command "no ip route 0.0.0.0 0.0.0.0 serial 1/1"   - (command to remove the default route pointing to the backup link)

action 4.0 cli command "ip route 0.0.0.0 0.0.0.0 serial 1/0" - (command to add the default route pointing to the primary link)

action 50.0 cli command "end"

action 99.0 syslog msg "Failed Back to the Primary Link" - (Create syslog message based on the requirements)

Assorted notes / external links

Notes

• Before modifying an EEM applet, be aware that the existing applet is not replaced until you exit applet configuration mode. While you are in applet configuration mode modifying the applet, the existing applet may be executing. It is safe to modify the applet without unregistering it. When you exit applet configuration mode, the old applet is unregistered and the new version is registered.
• Environment variables can be set using "action set" and retrieved by using the variable name with a $ in front of it. For example, the action cli command returns the output generated by the IOS CLI command in the $_cli_result variable

 So in your case you can create EEM event such that when BGP goes down, you tell EEM to shutdown the dial-peer to the private network and then calls will be forced to go via the backup dial-peer and you also configure to bring it up when BGP is backup

[mclean.danny]

Thanks for the recommendation. I am going to ask the provider to work me on redesigning the setup.

[mclean.danny]

Thanks for everyone's input. I ended up just changing the CUBE to use a single interface for all SIP traffic. I used the KISS method to keep it easy with the one interface. I moved the carrier router to the core switch instead of landing on the CUBE router. So the core switch is now making the routing decisions.

[Carl Ratcliffe]

Hi Danny

Just to be clear, what you are saying is that if you go via BGP the ITSP are expecting you to come from 1 IP address but if you go via the Internet they are expecting you to come from another IP address ? Therefore that's why you need to change your bind commands to change the IP address you are coming from ?

I may be getting the wrong end of the stick here but im assuming the firewall is in the path of the Internet therefore can you not just use the same dial-peers and let the firewall NAT ?

If traffic goes out of the BGP route it uses a dial peer with a bind statement, this same dial peer can be used in failover for the internet route seen as the destination address is the same. The bind statement could also be the same because the firewall will NAT.

Thanks, Carl Ratcliffe

Preston Lancashire England

[mclean.danny]

Hi Carl,

Yes that is correct in the way it is setup. The current dial peer setup is bound to each exit interface. The CUBE router has a handoff to the ITSP and the other interface lands on our core switch toward the internet. I'm thinking of redesigning this to have one exit point.