UDP session corrupt meraki

donavon89
Comes here often

UDP session corrupt meraki

Good Morning! 

I have a problem im trying to understand. 

I have Polycom VVX500 Phones the phone server is cloud based (as far as i know its owned and managed by a 3rd party company) 

recently my phones stopped being able to call our or receive calls. They could do an over head page and they could receive a page on the phone it self just no calls. I contacted support and they said....

Attempted to reach out to hosted core via this connection and was unable to.
Circuit traffic is routing this path to what appears to be a firewall or device that is preventing outside connections to hosted core
Attempted to locate an alternate route to use for phone to test connection to boot server 
Updated Boot URL from HTTP to HTTPS and rebooted one of the phones, Phone did not register. 
CURRENT STATUS: In order for phones to register an outside connection will need to be provided or connections to our hosted core allowed through firewall. 

my response 

 

James that does not make much sense. I have 30+ other phones on the same network that are working just fine. The firewall has all the phones at the Chevy store plugged into it and they are working just fine and i hace no problems with he phones at the other stores. We need to relook at this network. There is something else wrong.

There reply

Assisted James with this. 

The phones appear to be having issues with reaching as1 for registration. They can reach the boot server just fine. 
As we do not have eyes on the ISP hand off ultimately I ended up changing the transport from UDP to TCP for one of the phones and it reached our server fine. 
This tells me that the FW or ISP modem/router has corrupted UDP sessions. Those sessions most likely are not timing out as the phones continue to attempt registration , keeping the sessions alive. 
With the three phones moved to TCP, they were able to register. I am going to keep the case open and next week will move one of the phones back to UDP to see if it was just a corrupt session on the fw/ ISP gear.

Update

 We have been looking into this issue to investigate what is preventing these phones from registering with our hosted core. I have been working with Teir 2 and we were able to locate what was causing this issue. It appears there is a session for each of these phones that has either timed out or become corrupted for the UDP transport. We have temporarly adjusted these phones to use TCP instead. We are showing these phones are up and registered at this time. Can you test the phones to ensure they are up and working? We are monitoring this case for a few days to go back in and review the sessions. Once they are showing cleared we will move one of the phones back to UDP and test before moving them all back over. Please let us know if there is any further issues. 

My question is how would the Meraki firewall/switches cause this issue. I have 4 other sites that are using UDP and they are working just fine. We are on a metro Ethernet connection so all sites go to one place and use 1 firewall. 

Could some one smarter than me help me shad some light on this one? 

3 Replies 3
Markus
Here to help

Hi,

 

I can only guess since I do not have details.

Could it be a problem with MTU size? Since UDP does not verify it and TCP does.

 

Other then this, the MX does nothing special to UDP packets, unless you secifically configure something in the policies, such as blocking UDP or the like.

 

Have you done packt captures already? To verify where the packets are droped?

donavon89
Comes here often

Yes the packets are leaving the MX as for as i can tell. And no i have no policies in place that mess with UDP the only thing i have set up for that vlan is QOS and its set to the highest level.

PhilipDAth
Kind of a big deal
Kind of a big deal

Two thoughts:

  • Perhaps there is a duplicate IP address affecting the small number of phones (effectively knocking the phones off the network)
  • If you are using 48 port MS switches then you could be affected by the mac synchronisation bug which should be resolved in 10.16.
Get notified when there are additional replies to this discussion.