I thought you may ask that next  😉   Unfortunately no, I do not have access to the SBC logs easily enough.    I could raise a ticket with our VSP, would that be worth going down that road?      ... View more

Hi Philip,    Handset logs show nothing obvious in logs.    Would it be the session border controller timing out and clearing the registration?  ... View more

Hi Happiman,    Yes, most certain I am using eBGP from the MX100 concentrator to our DC BGP router. iBGP only runs internally on the Meraki devices right?     ... View more

+1 seeing similar issues with MAC tables on our MS350 stack running 11.22   Support are currently investigating the issue. Seems to be only affecting our voice traffic whereby handsets are dropping out of the MAC table.    Will wait to see what support advises, otherwise perhaps a downgrade back to 10.35   Regards, Ben ... View more

Hi SCC,   There is probably a few ways to do this.   As the Nighthawk is essentially a router you could setup a separate VLAN just for your phone(s) to communicate to it as their default gateway rather than the MX68.   ... View more

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

Hi Silas1066,    The other option you have is to request Meraki support upgrade that network and device to 15.9 No-NAT beta release. You then have the option to disable NAT on the interface that is facing your MPLS Network.    Regards, Ben ... View more

+1 on those two wishes. I've put these in before to Meraki ... View more

Hi Bkeys, Yes you'll need to call Meraki support. Make sure you ask them to update these following areas 1. Update the MX to No-Nat 15.x 2. Update the Network dashboard to see and configure No-Nat 3. Apply the No-Nat feature to the interfaces (they need to do this initially) If you have trouble let me know. Not all of support are aware on how to successfully implement this No-Nat feature ... 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

@ccnewmeraki Hi Christian, Support eventually figured it out with the assistance of your ticket number. My whole Organisation dashboard was missing a setting that was necessary for the changes to take affect. Once I then rebooted the MX appliance the NO NAT finally worked as expected and required.   The No NAT has addressed some issues that we were experiencing and believed was caused by NAT.   We still have one major issue which we are still trying to work out with Meraki support.   Has anyone else come across issues with MX routers not handling fragmented UDP packets correctly? Cisco Traditional ISR's allow up to 24 fragments per packet while a Meraki MX64 only allows up to 4, which is still causing issues with our VOIP handsets.   Thanks, Ben ... 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

Hi Christian,   I've sent you a PM, if you could send me your ticket number to pass onto support that would be great!   Thanks, Ben   ... View more