Interesting.   We have predominately VVX411's and 1500s too.   Are you using MPLS to route voice traffic back to the broadsoft platform?   Are your voice endpoints sitting behind NAT?   The MX's dont allow 45 fragmented packets per packet, I think when we ran tests the maximum was 12 from memory. Start running wireshark and see how many packets you can get fragmented before the conversation is dropped.     ... View more

Hi Tony,   This turned out to be a very interesting issue that we had with our provider.   In the end Meraki support were the most helpful and eventually we proved it was a issue with our carrier. It wasn't until we swapped out the MX with a traditional ISR that we knew it wasn't the MX causing issues.   The back haul on our providers link into our MPLS network had a incorrectly configured packet size. It wasn't the MTU but rather the switched packet size itself.   If you are experiencing BLF issues as well it is possible to convert the SIP registration and BLF updates from UDP to TCP with specific tags and configuration on the handsets. Note this will tax a small percentage of your link with overheads found in TCP packets.   Hope this helps Ben ... View more

Thanks Blake,    Just about to jump onboard to check out the webinar.    Wish the LTE support was out earlier this year. We made a significant purchase with the MX64's within our network :(      ... View more

Too easy!   It would be good if Meraki could allow MPLS type AutoVPN's to have a longer timeout or set to infinite.     ... View more

Hi s4mmy,   One tip to point out, make sure you have redundancy on your internet. Once the MX's loose connectivity to the cloud the AutoVPN tunnels between branch and DC over MPLS will dropout.      ... View more

Hi MickeyDawson,   Have you contacted someone at support? They seem to have a few tricks up their sleeves that are not publicly shared. Perhaps run your scenario with them and see if they can build you a solution.     ... View more

@jdsilva   I've almost successfully deployed a full Meraki network over our MPLS / Single DC over the past year. Meraki now have no-nat mode which has been the icing on the cake. Previously we were getting around issues with 1:1 Nat with private addresses.    15.9 seems to be stable and is the latest no-nat image. no-nat allows the MX to run as a L3 router.    Regards, Ben ... View more

Hi Philip, I do not understand how lowering the MTU on the WAN interface is going to help. The application server on the carrier end is a Broadsoft SIP server. Here is a excerpt from the Broadsoft documentation about BLF: Depending on the combined length of contact information fields of the users to be monitored, the NOTIFY packets are typically larger than the MTU (maximum transmission unit) defined in the routers, firewalls, and other data transmission equipment. As a result the UDP packets have to be fragmented into a number of smaller packets to fit the MTU size as they are sent out to the network. In Ethernet networks, MTU size is typically set to 1500 bytes. A UDP datagram can be up to 65507 bytes in size. A UDP datagram of 65507 bytes will have to be fragmented into 45 packets ( Max UDP size of 65507 bytes / UDP size per packet of 1480 bytes ~ 45) to be transmitted across a network. With this many number of fragments, customer firewalls or NAT devices may prohibit the entire packet from being delivered to the endpoint. A common issue that has been observed is the firewall or NAT traversing issue. Some firewalls will simply drop any fragmented packets while the others will drop packets when the number of fragmented packets exceeds a configured or default limit. For example, the Cisco ASA 5500 firewall by default will drop a packet if the packet has been fragmented into more than 24 packets. When this happens, phones will not receive the BLF NOTIFY message. As a result phones can only display a certain number of BLF lines. The recommended solution is to configure the firewalls and/or NAT routers at customer premises to handle fragmented UDP packets correctly. These firewall and NAT routers must be configured to support the maximum UDP payload size of 65507 bytes and to allow at least 45 fragmented packets per packet. The Meraki MX64 seems to be only allowing 4 fragmented packets or roughly 5000bytes. I will try your suggestion of lowering the MTU as we are now snookered with this issue, I'll let you know how it goes. ... View more

  The large UDP packets are coming from a upstream voice switch, changing the MTU on the interface or device will not change this as the packet needs to be fragmented regardless.   The UDP datagram can potentially be up to 65507 bytes which means over a 1500MTU ethernet link it will be fragmented into 45 packets.    Traditional Cisco routers do not have this problem.     ... View more

Hi dqsg22,    We have rolled out 50 odd MX's into branches all with Ethernet handoff from our MPLS provider. I've always known on our 100M links that our provider hardcodes the link to 100 / FULL. We had a issue at one site whereby one MX had not been set with manual speed and duplex and the router had negotiated 100 / Half.    Like others have pointed out it is critical that you either have Auto to Auto or Manual to Manual with matching settings on each end.      ... View more

@PhilipDAth Existing AutoVPN tunnels do not remain up for long. I tested out this scenario recently and the tunnels tore down relatively quickly, like within a few minutes. ... View more

Hi,    I have recently returned from China last month and needed connectivity the entire time I was OS   I was always able to connect to the Client VPN back to MX64's in Australia without any issues. I used this on my iPad and iPhone to allow Facebook Messenger to work.  I also took a Z3 over with me and tested two of the Hotel Ethernet connections. Both times the Z3 was able to nail up a tunnel back to our MX100 in Australia but reported issues on the dashboard. Traffic over the tunnel worked without any issues.   I feel that if the local router at the site allows the appropriate traffic through then you won't have any troubles.   Regards, Ben   ... View more

Yes, it is a beta feature that I'm testing and I do currently have a open case with support.    I thought I'd drop a line in the community here to see if anyone else in my situation has been able to get No-Nat mode working.   Thanks for your help though!      ... View more

  Hi Philip,   The site only has a single MPLS link. I'm trying to eliminate having a L3 switch or router sitting between our provider edge and our MX64. It seems 15.4 is getting close at providing that.    Yep agree, hosts sitting on the VLAN have the MX as the default route. Its the network route within the MX that shouldn't be pointing to the MX's LAN IP.    IE I'm dealing with vlan 15 which is 10.97.160.0/24.  Our MPLS provider is routing this down the MX's /30 address. What I want is for this vlan 15 not to be nat'd through the MX's LAN / WAN address.    Currently the MX has the route listed as 10.97.160.0/24 >next hop> 10.97.160.1   I would have thought to remove NAT it should be 10.97.160.0/24 >next hop> 172.16.1.2 (Provider Edge within the /30)   Isn't this the point of 15.4 Beta and No-Nat mode?   ... View more

Hi srgjp,   One suggestion would be to upgrade to version 13. Seems to be a lot of bug fixes between 12 and 13. 13 has a new WAN interface update as well which allows you to see and change the network config from the cloud portal.   Regards, Ben   ... View more