Date: Fri, 29 Mar 2024 14:01:15 +0000 (UTC) Message-ID: <195497028.4155.1711720875107@skald.opmantek.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_4154_1879625219.1711720875107" ------=_Part_4154_1879625219.1711720875107 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This article will provide an example of opConfig collecting specific com= mand output based on event characteristics. The command output become= s embedded into the event allowing network operators to more quickly identi= fy root cause and affect resolution.
For this example we'll take actions if an event's stateful element is a = BGP Peer. opEvents will fire scripts that result in useful informatio= n for engineers to follow up on.
In this case the necessary configuration for opEvents is contained in /u= sr/local/omk/conf/EventActions.nmis. There are two sections we will b= e concerned with; script and policy.
Let's have a look at the script section first. For this example we= want to ping the node that reported the problem, the BGP peer it's having = an issue with, and leverage opConfig to gather related command output. = ; Notice the arguments passed to opconfig-cli.pl, there is a command set na= me; IOS_TS_BGP. In the opConfig step we'll define what these specific= router commands are.
=09'script'= =3D> { 'ping_node' =3D> { arguments =3D> '-c 5 node.host', exec =3D> '/bin/ping', =20 output =3D> 'save' }, 'ping_neighbor' =3D> { arguments =3D> '-c 5 event.element', exec =3D> '/bin/ping', output =3D> 'save' }, 'troubleshoot_bgp' =3D> { arguments =3D> 'act=3Drun_command_sets names=3DI= OS_TS_BGP nodes=3Dnode.name print_command_output=3Dtrue mthread=3Dfalse deb= ug=3D0 quiet=3D1', =20 exec =3D> '/usr/local/omk/bin/opconfig-cli.pl', output =3D> 'save' }, =09}
In the policy section we define a rule that matches stateful properties = that contain 'BGP Peer'. If there's a match it will fire the scripts = defined above.
'po= licy' =3D> { '10' =3D> { IF =3D> 'event.any', THEN =3D> { '10' =3D> { IF =3D> 'event.stateful =3D~ "BG= P Peer"', THEN =3D> 'priority(8) AND scrip= t.ping_node() AND script.ping_neighbor() AND script.troubleshoot_bgp()', BREAK =3D> 'false' }, }, }
The /usr/local/omk/conf/command_sets.d directory is where we have files = detailing exec commands to be executed on nodes. For this example we = are concerned with ios.nmis. Our IOS_TS_BGP command set will be runni= ng the following commands.
If you have a large number of BGP routes we do not recommended 'show ip = bgp'.
'IOS_TS_B= GP' =3D> { =20 'os_info' =3D> { 'version' =3D> '/12.2|12.4|15.\d+/', 'os' =3D> 'IOS', }, 'scheduling_info' =3D> { 'run_commands_on_separate_connection' =3D> 'false', 'attempt_timeout_recovery' =3D> 1, }, =20 'purging_policy' =3D> { 'keep_last' =3D> 1000, 'purge_older_than' =3D> 2592000, # 30 days 'autoprotect_first_revision' =3D> 'true',=20 }, =20 'commands' =3D> [ { 'multipage' =3D> 'true', 'privileged' =3D> 'true', 'command' =3D> 'show ip bgp', 'tags' =3D> [ 'troubleshooting', 'routing', 'detect-change' ], }, =20 { 'multipage' =3D> 'true', 'privileged' =3D> 'true', 'command' =3D> 'show ip bgp summary', 'tags' =3D> [ 'troubleshooting', 'routing', 'detect-change' ], }, =20 { 'multipage' =3D> 'true', 'privileged' =3D> 'true', 'command' =3D> 'show ip route summary', 'tags' =3D> [ 'troubleshooting', 'routing', 'detect-change' ], }, ], },
The easiest way to test this configuration is to administratively shutdo= wn a BGP peer. After the next NMIS collect cycle a BGP Peer Down aler= t will be processed by opEvents. Here's an example from our lab.
Notice the Actions section is notifying us that our scripts fired. = Scrolling down we can view the script output; it's now embedded into the e= vent.