SBC trunks 'have changed status to Up' multiple times

[Leo_B]

Hello everyone,

This Wednesday's evening several customers' SBC instances literally burst up with multiple notifications reporting SBC trunk is back online. Between 5:46 PM and 7:14 PM EST we received 30+ messages reporting another trunk to have 'changed status to Up'. As we checked the SBC devices remotely, ones uptime is being measured in days, so recurring unexpected reboot is not an answer. Some SBC instances are Linux-powered PCs and some are Raspberry Pi devices, yet all appear to run build 18.1.36. So the question is, what could be a reason for such a messages outburst?

 

[SweetAction]

Could be a network drop to the SBCs or PBXs that lasts less then 30 seconds (won't trigger the trunk down notifications in this case).

SBC uptime is not a good measure because you can lose network and not power.

 

[Leo_B]

Appreciate your response! Year, but I'm talking about customers' sites located some 30+ miles away one from other and having different internet providers (some are AT&T-powered and some are Comcast customers).

 

[SteveITS]

Could be at the server end then? The up alert triggers at every successful (re)connection, and the down alert takes longer as mentioned. So it was some sort of connection drop, packet loss, etc.

 

[Leo_B]

Could be at the server end then? The up alert triggers at every successful (re)connection, and the down alert takes longer as mentioned. So it was some sort of connection drop, packet loss, etc.

All our 3CX-powered servers are being hosted in Vultr Atlanta data center, totalling some 10 instances. Of which only half experienced last week's 'back online' notifications. Other 50% clearly ignored that blast.

 

[SteveITS]

Could be a temporary ISP routing issue or packet loss then. Are those clients on the same ISP?

Overall it's some sort of short repeated connection loss.

 

[Leo_B]

Could be a temporary ISP routing issue or packet loss then. Are those clients on the same ISP?

Overall it's some sort of short repeated connection loss.

Actually, two different ISPs - a fact that causes extra complications.

 

[SteveITS]

Still could be a backbone provider in between those ISPs and the servers.

No real way to tell after the fact. During, ping/traceroute for packet loss…sometimes one can narrow it down and ask one of the two ends to investigate. Once every year or two our data center adjusts how our IP block is routed because one provider had a full pipe and we detect it in our monitoring.