uplinkStatusChanged - trap contents and Up / Down state determination

[DonL]

Hello, 

I am working with another customer that has a very large Meraki deployment and we are putting support for trap processing in place. 
I have noticed that the uplinkStatusChanged trap still does not seem to include anything about the "direction" of the state change e.g.: Down / Up - only that it changed ?
That means that any Alarm / Tickets created related to this state change will never Auto Clear / Resolve, meaning that it will require Human / manual intervention to determine the current state and clear the Alarm and Resolve and Close the ticket... not very Automation Friendly.

I can only imagine that if its been this way since the beginning of Meraki time : 
a: Not many people are using traps 

b: there have not been any requests to include an Down / Up state with the trap

The environment is So large that the throttling implemented to restrict the number of call made against the Dashboard, precludes us from making REST calls to get this state information.
 
Would using WebHooks to track the uplinkStatus help us out here - would the Down / Up state be available ? 

Thank , 
Don

[JonP]

We are using Webhooks into Teams, and whilst we haven't had a WAN uplink status change recently, we have had Sharepoint Degradation which does clear via another webhook message.

[DonL]

Hello JonP, 

Would you be willing to share anything about what the WebHook " registration" looks like ? 
Do you have the option to specify each of the elements / fields / data you want as part of the notification - or you just get what you Get ?
Sorry - I have no familiarity with using WebHooks 😞  

Thank you for the reply,
Don

[JonP]

PM'd you

[DonL]

Perfect - thank you very much !
( I am also looking at the Doc pages now 🙂 ) 

[DonL]

Geeezzzz  - the trap for usage is relatively Useless  !!!

# usageAlert                                                    organizationName
1.3.6.1.4.1.29671.1.1.7.6.33   1.3.6.1.4.1.29671.1.1.1(1,0)\
# networkName
1.3.6.1.4.1.29671.1.1.2.1.2(2,3)\
# period
1.3.6.1.4.1.29671.3.6(4,0)\
# endOfHighUsageWindow
1.3.6.1.4.1.29671.3.7(5,0)\
# threshold
1.3.6.1.4.1.29671.3.8(6,0)\
# usage
1.3.6.1.4.1.29671.3.9(7,0)

Nothing about the Device or Interface triggering the "out of Usage Window threshold" !
Just something in the Network 🙈 - networks are not only one device 🙄

( this of course is not directed at anyone *here* , just a disappointing observation ! )

[JonP]

We ended up using a product called Highlight to monitor our bandwidth and up/down status. It costs, but it's infinitely better than the stock Meraki dashboard which doesn't do as good a job.

[mlefebvre]

"The environment is So large that the throttling implemented to restrict the number of call made against the Dashboard, precludes us from making REST calls to get this state information."  There is no way this is possible unless you are not being efficient in the way you are calling the API. 

"Would using WebHooks to track the uplinkStatus help us out here - would the Down / Up state be available ? "

If you have Meraki Insight or the SD-WAN+ MX license, yes it would. Here is an example pair of emails I received from Insight for a WAN status change, the webhook data should be similar.

"

The primary security appliance in the [REDACTED] network failed over to using uplink Internet 2 because the primary link has become unavailable.
It will return to using the primary uplink when it becomes available.

There has been 1 failover event detected:

At 01:21 AM MST on Jan 18, the security appliance switched to using Internet 2 as its uplink.

- Cisco Meraki"

and then

"

The primary security appliance in the [REDACTED] network switched to using its primary uplink, configured to be uplink Internet 1, after a period in which the link was unavailable.

There has been 1 failover event detected:

At 01:24 AM MST on Jan 18, the security appliance switched to using Internet 1 as its uplink.

- Cisco Meraki"

[DonL]

Cisco Meraki, 

Thank you for the WebHook examples. 

One has to wonder why would the Uplink status not have been included as part of the original trap ? 
The trap is all but Useless with it's current payload ?
Something happened: Good / Bad / informational 

# uplinkStatusChanged networkName
1.3.6.1.4.1.29671.1.1.7.6.9  1.3.6.1.4.1.29671.1.1.2.1.2(1,2)\
# organizationName
1.3.6.1.4.1.29671.1.1.1(3,0)\
# devMac
1.3.6.1.4.1.29671.1.1.4.1.1(4,0)\
# devInterfaceName
1.3.6.1.4.1.29671.1.1.5.1.3(5,6)


We try to poll for inventory - It times out. ( we hit the throttling limit ) 
We try to poll for basic performance data - it times out. ( we hit the throttling limit ) 
We try to poll for Alarm data - It times out ( we hit the throttling limit ) 

We are at work re-engineering the solution to make smaller requests  and sequence those requests to stay under the throttling threshold(s). 

Too Big seem to be somewhere over 4000 " Clients / Organizations ) with nearly 40,000 devices.

Don

[DonL]

Hello Meraki World 🙂 

When we started coding to use these Uplink Status Change traps - we were naively under them impression that the # devInterfaceName would be  "Internet Uplink 1" for the Primary and  "Internet Uplink 2" for the secondary. 
No sooner was logic to support this put into place we get a trap with "Cellular Uplink 3" as the # devInterfaceName. 

Is anyone intimately familiar with the ranges of possible values we could receive for # devInterfaceName ? 

Thank you, 

Don

[DonL]

So for MX devices we can see the ifTable and a handfull of ports 
Are the Uplink ports part of that table or are they * Other* ports ? 
I was of the understanding ( maybe misguided ) That they  were not listed as part of the ifTable
True / False?  

Thank you, 

PS: We enabled WebHooks for some conditions to see what they contained and the UplikStatus change Notification contains No more Usefull information than the trap ?