cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
429
Views
10
Helpful
8
Replies

EEM - Verifying multiple BGP peering statuses

cwkronk1982
Beginner
Beginner

I'm new to working with the EEM and SLAs and I'm trying to get something together to fit a condition. Below is what I have currently

event manager applet BGP_DOWN_IPV4_edge-int_DOWN
event tag 1.0 syslog pattern ".*%BGP-5-ADJCHANGE: neighbor 172.16.200.1 Down"
event tag 2.0 syslog pattern ".*%BGP-5-ADJCHANGE: neighbor 172.16.250.1 Down"
trigger
correlate event 1.0 and event 2.0
action 1.0 cli command "enable"
action 2.0 cli command "conf t"
action 3.0 cli command "router bgp 65510"
action 4.0 cli command "neighbor 192.168.0.2 shutdown"
action 5.0 cli command "neighbor 192.168.0.3 shutdown"
action 6.0 cli command "end"
action 7.0 cli command "wr mem"

event manager applet BGP_DOWN_IPV4_edge-int_UP
event tag 1.0 syslog pattern ".*%BGP-5-ADJCHANGE: neighbor 172.16.200.1 Up"
event tag 2.0 syslog pattern ".*%BGP-5-ADJCHANGE: neighbor 172.16.250.1 Up"
trigger
correlate event 1.0 and event 2.0
action 1.0 cli command "enable"
action 2.0 cli command "conf t"
action 3.0 cli command "router bgp 65510"
action 4.0 cli command "no neighbor 192.168.0.2 shutdown"
action 5.0 cli command "no neighbor 192.168.0.3 shutdown"
action 6.0 cli command "end"
action 7.0 cli command "wr mem"

What I need to do now is to work on single up connections to the 200.1 and 250.1. I can easily write the above up statement as an OR, so that the 0.2 and 0.3 peers are brought up when either of the 200.1 and 250.1 come up. That's what I'm aiming for. I'm just not sure if I need to rewrite the top statement or create a new one and how to go about doing it to track if one of the 200.1 or 250.1 is up and goes down while the other is already down to shut down both the 0.2 and 0.3 peers. Hopefully this will make what I'm looking for a little clearer:

If 172.16.200.1 and 172.16.250.1 adjacency goes down, shut down 192.168.0.2 and 192.168.0.3.
If 172.16.200.1 and 172.16.250.1 adjacency comes up, bring up 192.168.0.2 and 192.168.0.3.
If 172.16.200.1 or 172.16.250.1 adjacency comes up, bring up 192.168.0.2 and 192.168.0.3.
If 172.16.200.1 or 172.16.250.1 adjacency is down and the adjacency for the other peer goes down, shut down 192.168.0.2 and 192.168.0.3.

I'm using the adjacency statement to test if a peer is up or down right now. If one of my EEM policies brings up the 192.168 peers because only one of the 172.16 peers comes up, I would need to verify that the other peer is already down if adjacency for the up peer changes. I don't won't to bring down the 192.168.0.2 and 192.168.0.3 peers if one of the two 172.16 peers remains up.

1 Accepted Solution

Accepted Solutions

Dan Frey
Cisco Employee
Cisco Employee

One way to do this is to perform conditional checks on all the BGP peers and then take the appropriate actions.  A single policy to trigger BGP actions when either 172.X peer goes up and/or down.   Actions 4.4 and 4.5 are true if both 172.x peers are down.  This would meet your first requirement "If 172.16.200.1 and 172.16.250.1 adjacency goes down, shut down 192.168.0.2 and 192.168.0.3."
Action 6.0 looks for a single "Up" and would meet the next two requirements. Only one needs to be up in order to do a "no shutdown" on the neighbor so not necessary to check the other peer.

Your forth requirement "If 172.16.200.1 or 172.16.250.1 adjacency is down and the adjacency for the other peer goes down, shut down 192.168.0.2 and 192.168.0.3."  Looks exactly the same as the first requirement.

Need additional data for your last paragraph as I am not sure what the requirement is being stated.   

Example EEM policy below should meet the four requirements.

 

event manager applet BGP_UpDown
event syslog pattern "BGP-5-ADJCHANGE: neighbor 172.16.2[05]0.1 Down|Up"
action 1.0 cli command "enable"
action 3.1 regexp "BGP-5-ADJCHANGE: neighbor ([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+) ([A-Za-z]+)" $_syslog_msg match ip state
action 3.2 if $state eq "Down"
action 3.3 set reverse "Up"
action 3.4 else
action 3.5 set reverse "Down"
action 3.6 end
action 3.7 if $ip eq "172.16.200.1"
action 3.8 set reverseip "172.16.250.1"
action 3.9 else
action 4.0 set reverseip "172.16.200.1"
action 4.1 end
action 4.2 cli command "show ip bgp neighbor $reverseip | inc BGP state"
action 4.3 regexp "BGP state = (Established)" $_cli_result match reverseipstate
action 4.4 cli command "config t"
action 4.5 cli command "router bgp 65510"
action 4.4 if $_regexp_result eq "0"
action 4.5 if $state eq "Down"
action 4.6 cli command "neighbor 192.168.0.2 shutdown"
action 4.7 cli command "neighbor 192.168.0.3 shutdown
action 4.8 end
action 4.9 end
action 6.0 if $state eq "Up"        
action 6.1 cli command "no neighbor 192.168.0.2 shutdown"
action 6.2 cli command "no neighbor 192.168.0.3 shutdown"
action 6.3 end
action 6.4 cli command "end"
action 7.0 cli command "wr mem"

   

View solution in original post

8 Replies 8

Georg Pauwen
VIP Master VIP Master
VIP Master

Hello,

this one is difficult to answer without lab testing. Can you post a topology map including IP addressing that shows how many routers you have, and how these routers are connected to each other ?

EEM_Question.png

So the peers are 4 to 6 and 7 and 5 to 6 and 7. 4 and 5 use an HSRP address and that's what 6 and 7 peer with. 4 and 5 peer with a loop back on 3. 1 and 2 peer with a loop back on 3.

What's I have working is that if the peer from 4 to 3 or 5 to 3 goes down, the EEM policy shuts down the peer to 6 and 7. If the peer to 3 comes back up, a policy makes the peering to 6 and 7 come back up. Because of the one peer to 3 and the HSRP peering with 6 and 7, this works. 1 and 2 are separate routers that we can't setup any type of redundant routing protocol. I have an EEM policy on 3 that shuts down the peers to 4 and 5 when the peers to 1 and 2 go down. That in turn causes the peers to 6 and 7 to go down. There's a different policy on 3 that brings up the peers to 4 and 5 when both the peers to 1 and 2 comes back up.

What I'm trying to wrap my head around right now is this - if the peer to 1 or 2 comes back up, I'd like the peering to 4 and 5 to be brought up. So far everything is being down with EEM policies and I can easily make a policy that says if the peering to 1 or 2 comes up, bring up the peering to 4 and 5. What I'm getting stuck on is how to track something like this - what if the peer from 3 to 1 comes up, but then goes down? The current EEM policy requires the peer from 3 to 1 AND 2 to go down to shut down the peers to 4 and 5. I need a way to have it so that it only shuts down the peering to 4 and 5 when both peers to 1 and 2 are down, but it can bring the peers to 4 and 5 up if only one peer to 1 or two comes up. After that, if that one peer that came up to 1 or 2 fails, I need the peers to 4 and 5 to be shut back down.

1 & 2 to 3 = up
 then 3 to 4&5 = up
1 & 2 to 3 = down
 then 3 to 4&5 = down
1 or 2 to 3 = up
 then 3 to 4&5 = up

But with that last statement, I need something to track if 1 & 2 are down if it sees 1 or 2 go down and with the current EEM policy below, it's tracking that it sees two neighbor adjacency statements for down, which it wouldn't see if one of the two are already down. If I change it to "correlate event 1.0 or event 2.0" it will shut down the peers to 4 and 5 if just one of the peers to 1 and 2 go down and the other one is still up.

event manager applet BGP_DOWN_IPV4_edge-int_UP
event tag 1.0 syslog pattern ".*%BGP-5-ADJCHANGE: neighbor 172.16.200.1 Up"
event tag 2.0 syslog pattern ".*%BGP-5-ADJCHANGE: neighbor 172.16.250.1 Up"
trigger
correlate event 1.0 and event 2.0

Sorry if I made this confusing.

 

Dan Frey
Cisco Employee
Cisco Employee

One way to do this is to perform conditional checks on all the BGP peers and then take the appropriate actions.  A single policy to trigger BGP actions when either 172.X peer goes up and/or down.   Actions 4.4 and 4.5 are true if both 172.x peers are down.  This would meet your first requirement "If 172.16.200.1 and 172.16.250.1 adjacency goes down, shut down 192.168.0.2 and 192.168.0.3."
Action 6.0 looks for a single "Up" and would meet the next two requirements. Only one needs to be up in order to do a "no shutdown" on the neighbor so not necessary to check the other peer.

Your forth requirement "If 172.16.200.1 or 172.16.250.1 adjacency is down and the adjacency for the other peer goes down, shut down 192.168.0.2 and 192.168.0.3."  Looks exactly the same as the first requirement.

Need additional data for your last paragraph as I am not sure what the requirement is being stated.   

Example EEM policy below should meet the four requirements.

 

event manager applet BGP_UpDown
event syslog pattern "BGP-5-ADJCHANGE: neighbor 172.16.2[05]0.1 Down|Up"
action 1.0 cli command "enable"
action 3.1 regexp "BGP-5-ADJCHANGE: neighbor ([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+) ([A-Za-z]+)" $_syslog_msg match ip state
action 3.2 if $state eq "Down"
action 3.3 set reverse "Up"
action 3.4 else
action 3.5 set reverse "Down"
action 3.6 end
action 3.7 if $ip eq "172.16.200.1"
action 3.8 set reverseip "172.16.250.1"
action 3.9 else
action 4.0 set reverseip "172.16.200.1"
action 4.1 end
action 4.2 cli command "show ip bgp neighbor $reverseip | inc BGP state"
action 4.3 regexp "BGP state = (Established)" $_cli_result match reverseipstate
action 4.4 cli command "config t"
action 4.5 cli command "router bgp 65510"
action 4.4 if $_regexp_result eq "0"
action 4.5 if $state eq "Down"
action 4.6 cli command "neighbor 192.168.0.2 shutdown"
action 4.7 cli command "neighbor 192.168.0.3 shutdown
action 4.8 end
action 4.9 end
action 6.0 if $state eq "Up"        
action 6.1 cli command "no neighbor 192.168.0.2 shutdown"
action 6.2 cli command "no neighbor 192.168.0.3 shutdown"
action 6.3 end
action 6.4 cli command "end"
action 7.0 cli command "wr mem"

   

 


@Dan Frey wrote:

Your forth requirement "If 172.16.200.1 or 172.16.250.1 adjacency is down and the adjacency for the other peer goes down, shut down 192.168.0.2 and 192.168.0.3."  Looks exactly the same as the first requirement.

With the way I wrote the EEM policy, it needed to see the syslog statements for the adjacency change to down before taking effect. So I should have tested this, but I'm assuming if one of the two peers were to go back up my policy would have removed the shutdown statements from the 4 and 5 peers, that the EEM policy:

vent manager applet BGP_DOWN_IPV4_edge-int_UP
event tag 1.0 syslog pattern ".*%BGP-5-ADJCHANGE: neighbor 172.16.200.1 Up"
event tag 2.0 syslog pattern ".*%BGP-5-ADJCHANGE: neighbor 172.16.250.1 Up"
trigger
correlate event 1.0 and event 2.0

would not shut down the peers to 4 and 5 if the only link to 2 and 3 that is us goes down, because only one syslog message would be generated for the one adjacency change that would happen. I'm unfamiliar with the regexp commands and most of the EEM stuff as well. I need to find and read some EEM material on the syntax and what can be done with it. I found the Cisco configuration guide and command references. I'll start with those.

Disregard.

The action numbering in your policy is out of order.   The second line (event syslog) and actions 1.0 to 7.0 should be removed.  Correct the numbering and  Turn on "debug event manager all" and run the policy.   

EEM runs like a normal user and consumes a vty line each time it gets triggered. EEM will never take the last vty line and generates this error when vty is not available: 

*Nov 14 13:10:23.647: %HA_EM-3-FMPD_CLI_CONNECT: Unable to establish CLI session: 'Embedded Event Manager' detected the 'fatal' condition 'no tty lines available, minimum of 2 required by EEM'

 

 

@Dan Frey @cwkronk1982 

I have idea here
you can use Boolean tracking instead of using two BGP down neighbor.
https://howtorouteswitch.com/dual-isp-redundancy-ip-sla-boolean-object-tracking-longest-match-routing/

sorry but I have little Ack in EEM so I can not help  you in EEM lines.

Object tracking can be used and boolean logic to figure out when to trigger the EEM policy as you have pointed out here.   Using this method can lead to creating an EEM policy for each permutation of the boolean logic.   If you consolidate the EEM policies into one you are left with adding conditional statements (if true, run cli) which is what I am suggesting in my previous post.   The boolean logic is only to trigger the EEM policy.   I have found it easier to use regexp for the syslog pattern rather than listing each boolean permutation that can exist.    So it would be up to the user to select one method or the other but I believe your suggestion has merit and can be implemented.   

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers