TCL script to monitor BGP Neighbor or 0.0.0.0 to call EEM event

Unanswered Question
Oct 23rd, 2009

We were trying to use EEM 2.2 to monitor 4 BGP neighbors and if they all went down to remove eigrp from the configuration. Apparently this type of monitor is not available using EEM so it was suggested that TCL would be able to do this. Currently this would be for a 7200VXR running 12.4.24T1 but may need to be able to be ported to the ASR 1000 series if this makes any difference. Any assistance with this would be greatly appreciated.

Regards,

-Adam

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Joe Clarke Fri, 10/23/2009 - 13:27

First, IOS 12.4(24)T has EEM 3.0, so you have a lot more flexibility here. However, if you will need the same policy to run on IOS-XE, that limits things as the best you will have there is EEM 2.3.

When the BGP neighbors go down, what syslog messages do you get? It would be much easier to trigger off of these then having EEM periodically run show commands. Additionally, what needs to happen when one of them comes back up? that is, assuming all are down, when do you recover from the loss of EIGRP (or will that be a manual recovery)?

alesyshyn Mon, 10/26/2009 - 05:41

When the BGP neighbor goes down the following is seen in the log:

%BGP-5-ADJCHANGE: neighbor x.x.x.x Down Neighbor deleted

Oct 21 16:27:26.706: %BGP-5-ADJCHANGE: neighbor x.x.x.x Up

ideal when one of the neighbors come back up would be when EEM would be trigger the reconfiguration of EIGRP.

Thank you very much for your response.

Let me know if there is any other information that I can provide.

Regards,

-A

Joe Clarke Mon, 10/26/2009 - 12:23

I think this policy should do what you want. It requires three environment variables to be set before you can register it, though:

bgp_watch_neighbors : Comma-separated list of BGP neighbors to watch (as they appear in the syslog messages)

bgp_watch_eigrp_as : AS number of the EIGRP processes to unconfigure.

bgp_watch_eigrp_cfg : EIGRP configuration which will be reconfigured when one of the BGP neighbors comes back up (each line must be separated by commas).

For example:

event manager environment bgp_watch_neighbors 10.1.1.1,192.168.1.1,172.16.1.1

event manager environment bgp_watch_eigrp_as 29

event manager environment bgp_watch_eigrp_cfg router eigrp 29,network 20.0.0.0,auto-summary

alesyshyn Tue, 10/27/2009 - 11:38

Thank you very much. It sounds like this will do what we need however, I have registered the script and we am getting the errors shown on the attached file. I have provided the sh event policy registered, appropriate config and log errors.

Any further assistance you can offer with this would be greatly appreciated.

-Adam

sh event manager policy registered

No. Class Type Event Type Trap Time Registered Name

1 script user syslog Off Tue Oct 27 13:57:51 2009 sl_bgp_neighbor_watch.tcl

pattern {BGP-5-ADJCHANGE: neighbor.*(Down|Up)}

nice 0 queue-priority normal maxrun 20.000 scheduler rp_primary

event manager environment bgp_watch_eigrp_as 10

event manager environment bgp_watch_eigrp_cfg router eigrp 10,network x.x.x.x,no autosummary,distribution list 10 in,distribution list 10 out

event manager environment bgp_watch_neighbors x.x.x.x,x.x.x.x,x.x.x.x,x.x.x.x

event manager directory user policy "disk2:/"

event manager policy sl_bgp_neighbor_watch.tcl type user

Joe Clarke Tue, 10/27/2009 - 12:03

You didn't re-register the policy. Simply copying into the policy directory is not enough. You have to do:

no event manager policy sl_bgp_neighbor_watch.tcl

event manager policy sl_bgp_neighbor_watch.tcl

Joe Clarke Tue, 10/27/2009 - 12:18

You must have copied the old script. Check line 96 of your script. It should say:

array set arr_einfo [event_reqinfo]

alesyshyn Tue, 10/27/2009 - 12:46

You are absolutely correct about the old script being copied up. I copied the new one up and however it looks like we now get a new error.

Thanks for your patience in this matter.

Attachment: 
alesyshyn Tue, 10/27/2009 - 13:48

We are unfortunately still see an issue. I am attaching the complete log file as well as a more of the file on flash for you to confirm that I have put up the right one (try not to make the same mistake twice, if possible). Also I am making sure to register the policy after each revision.

Sorry that I have to keep coming back to you on this, but your assistance has been greatly appreciated.

Attachment: 
alesyshyn Tue, 10/27/2009 - 14:15

We are not seeing any errors however the EIGRP removal doesn't appear to be called. I am attaching the term mon as I remove the peers as well as a more of the current file on flash.

unfortunately this is at a remote site and due to security I have to have the flash swapped to an inside router and I have no one available for tonight.

Please let me know if there is any other information or if there is something that we are doing wrong.

Again thanks!

Attachment: 
alesyshyn Wed, 10/28/2009 - 21:13

Great thank you. I was out of the office today so I have not been able to test. I will test the new file in the morning and post the results.

Thanks again.

alesyshyn Thu, 10/29/2009 - 09:12

I think that works! I had couple of environment issues that I had to find on the rewriting of EIGRP. Let me do a little more test and I will let you know shortly.

Thank you so much for all the time you have put into this!

alesyshyn Mon, 11/02/2009 - 05:33

Success!I can't thank you enough for your time and patience, they are greatly appreciated.

Actions

This Discussion