Daniel left a very relevant comment to my convoluted BGP session shutdown solution:

What I am currently doing is using EEM to watch my tracked objects and then issuing a neighbor shutdown command. Is there a functional reason I would not want to do it that way, and use the method you prescribe?

As always, the answer is “it depends.” In this case, the question to ask yourself is: “do I track configuration changes and react to them?”

Changing the router configuration with an EEM applet is no different from changing it through a terminal session. Let’s solve the BGP session shutdown challenge with a simple EEM applet:

event manager applet shutdown_BGP_Session
 event track 10 state down
 action 1.0 cli command "enable"
 action 1.1 cli command "configure terminal"
 action 1.2 cli command "router bgp 65100"
 action 1.3 cli command "neighbor 10.0.7.10 shutdown"

Every time the applet is run, the router configuration is changed, triggering all sorts of events:

• The running configuration change time (that you can see with show running) is updated.
• Configuration commands executed by the EEM applet are written in the configuration log (use the event manager session cli username global configuration command to change the username displayed in the printouts).

A1#show archive log config all
 idx   sess           user@line      Logged command
    1     0            EEM@vty0     |!exec: enable
    2     5            EEM@vty0     |router bgp 65100
    3     5            EEM@vty0     | neighbor 10.0.7.10 shutdown

• Syslog messages are generated if you’ve configured configuration change logging with notify syslog:

%TRACKING-5-STATE: 10 stub   Up->Down
%PARSER-5-CFGLOG_LOGGEDCMD: User:EEM  logged command:!exec: enable
%PARSER-5-CFGLOG_LOGGEDCMD: User:EEM  logged command:router bgp 65100
%PARSER-5-CFGLOG_LOGGEDCMD: User:EEM  logged command:neighbor 10.0.7.10
  Shutdown

• SNMP traps are generated if you’ve enabled configuration-related traps with the snmp-server enable traps command.

On top of that, the configuration-tracking network management tools (RANCID, SolarWinds ...) might generate configuration changed alerts and you’ll be prompted whether you want to save the changed running configuration the next time you’ll try to reload the router.

Last but definitely not least, if you do save the changed configuration (when the BGP neighbor is disabled), the change made by the EEM applet will be stored in the startup configuration. Not a good idea.

To avoid the problems caused by saves of EEM-changed configurations, always create a third EEM applet that applies the desired configuration after the router reload (in our case, no neighbor shutdown).

Summary: As always, consider all side effects of your solution. On one hand, configuration changes done within an EEM applet trigger all sorts of alerts (if you track configuration changes); on the other hand, the static route-based solution might be too convoluted for your support team (and impossible to troubleshoot at 1AM on Sunday, January 2nd).