Further test to confirm MA-CBL can be used for 1G / 10G mixed.    MS225-48FP SFP+ port >>> MA-CBL-3M >>> MS220-8P SFP port came up once I changed the link negotiation to 1Gbps  ... View more

Hi Baka,  I understand there is a official datasheet however, I have had mixed results in the past and have had the MA-CBLs come up at 1Gbps line rate.    Image attached, I have a MS210-48LP uplinked via its SFP port using MA-CBL-TA-1M into a MS410-16 SFP port. The interface is up and the speed negotiated at 1Gbps     ... 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

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

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

Hi ccnewmeraki,   Thank you for your extensive reply. I'll get back in touch with Support and hope we can get this sorted out.    Regards, Ben   ... View more

Hi ccnewmeraki,   Thanks for the update and advice on how you have successfully enabled the NO-NAT feature.    Support have advised me there is no modification to the inbound rule, yet the NO-NAT mode still is not working for me. I have quoted word for word what you supplied in your last post. Apparently as well the NO-NAT mode does not work on VLAN based exceptions and can only be done per interface. Have you had this issue?   Regards, Ben ... View more

Hi Owen,   Same problem here. What I've had to do is create a 1:1NAT rule for external hosts to be able to get to internal hosts.    Okay for a dozen or so hosts in some of the small deployments that I have but I'm not looking forward to filling out a whole /24 for a voice network!    Support are working on 15.4 with me and my situations, they've explained that they're are continuing to develop this new no-nat mode in the labs.   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