DX NetOps

  • 1.  Monitor number of established BGP connections

    Posted Nov 06, 2018 02:50 AM

    Hello community!

     

    Has anyone ever had to (or has an idea on how to) configure Spectrum to monitor the number of established BGP connections in a given router? I have searched the community for ways to make SpetroWatch sum the state for each instance but wasn't able to make that happen.

    Through CLI script it would be fairly easy, but the crontab is not enabled for the Spectrum user and I would prefer not requesting that. 

    Maybe there is an OID out there that shows this data, but so far I was not able to find it.

    Any help is welcome!

     

    Best regards,

    Marcelo



  • 2.  Re: Monitor number of established BGP connections
    Best Answer

    Posted Nov 06, 2018 09:33 AM

    Marcelo,

     

    The only OID I am aware of is the bgpPeerState at 1.3.6.1.2.1.15.3.1.2 but it does not give the total. Just the state of each connection. I do not see how this can be done in a watch. 

     

    One possibility is to create a threshold watch to evaluate once a day (or how often you need it run). Configure the watch so it will exceed the threshold every time it run. Then, on exceeding the threshold, run a CLI script to gather the information. The last thing to do int he script is to deactivate and the reactivate the watch for the model so it is evaluated at the next poll.

     

    Joe



  • 3.  Re: Monitor number of established BGP connections

    Posted Nov 07, 2018 02:54 AM

    Hi Joe,

     

    Thanks for your reply.

    I have tried doing what you suggested, but the problem is that, apparently, the watch remembers its last status before it was deactivated. So, it works great the first time it runs, but then the status is frozen on "Violated" and the script is no longer executed, even after the Watch is deactivated and activated. Code below:

    update action=0x480004 watch=0xffff0019 mh=$dev_mh
    update action=activate watch=0xffff0019 mh=$dev_mh

    I have looked for ways for forcefully change the Watch Status but couldn't find one. The other option would be to change the control attribute, wait (sleep) for the watch to poll and change to Active, then set the attribute back to the alarming value. But the problem is that if the poll is set to happen each 30 mins, the script will be hanging for all this time.

     

    Are you aware of any action code that could reset the status and force the watch to poll?

     

    Best regards,

    Marcelo



  • 4.  Re: Monitor number of established BGP connections

    Posted Nov 07, 2018 09:15 AM

    Marcelo,

     

    Are you generating an alarm as well? I did a quick test where I also generated an alarm and it worked.

     

    You may also want to pause a few seconds between deactivating and activating the watch to give the system time to reset everything.

     

    Joe



  • 5.  Re: Monitor number of established BGP connections

    Posted Nov 07, 2018 10:05 AM

    Joe.

     

    Now it worked! I guess the Watch interval was shorter than the time the script took to run.

    I increased the first to 5 minutes and the interval between the deactivating and activating the Watch in the script to 10 seconds and now it is running smoothly.

     

    Thanks for the tips.

     

    Best regards,

    Marcelo



  • 6.  Re: Monitor number of established BGP connections

    Posted Nov 07, 2018 10:16 AM

    Glad I could help!

     

    Joe



  • 7.  Re: Monitor number of established BGP connections

    Posted Nov 09, 2018 03:47 AM

    Hi ackjo04, Zacchi, all,

     

    from my perspective the only solution would be to have a "count rows" operator within SpectroWATCH functionality.

    Once such thing is available, there would be a lot of additional practical cases that could be solved, e.g. number of wireless accesspoints, number of cdp neighbours, ...

     

    We requested that years ago, but CA did not agree on the necessity.

     

    regards,

    Raphael



  • 8.  Re: Monitor number of established BGP connections

    Posted Nov 09, 2018 06:16 AM

    Hi Raphael,

     

    I fully agree. Also, some conditional operators wouldn't hurt.

     

    Best regards,

    Marcelo