- About benny
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
benny
Getting noticed
Member since Sep 19, 2017
16 hours ago
Kudos given to
Community Record
44
Posts
2
Kudos
0
Solutions
Badges
11-11-2019
04:54 PM
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
11-11-2019
04:48 PM
Hi Philip, Handset logs show nothing obvious in logs. Would it be the session border controller timing out and clearing the registration?
... View more
11-11-2019
01:15 PM
Hi All, I have a handful of single Polycom handsets hanging off Z1's and Z3's nailing up a AutoVPN tunnel back to our DC. The Polycom handsets are registered back to the Broadsoft VSP with the routes accessible only through the VPN tunnel. I believe the advertised routes are all correct. Voice, Video and registrations all work as expected, with the exception of some sites whereby registration fails to renew causing the handset to become unavailable to incoming calls. Outgoing calls from the handset out are never a problem. Where do I begin to troubleshoot this issue? Anyone have experience or ideas on what I can check or troubleshoot? Thanks, Ben
... View more
09-03-2019
03:27 PM
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
08-26-2019
10:07 PM
Hi All, I am trialling BGP in our test DC and can successfully advertise the networks learnt from the hub to the DC BGP router. The networks advertised from the DC BGP router are not accessible from the spoke. If I manually add the local networks at the hub then connectivity works. Any tricks or tips to pass BGP networks to the hub and through to the spoke? Hub is running in one-armed concentrator mode MX100 Spoke is a MX64 DC BGP router is a Cisco ISR Many Thanks
... 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
02-24-2019
08:59 PM
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
10-18-2018
04:16 PM
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
10-18-2018
03:16 PM
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
08-27-2018
06:37 PM
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
07-31-2018
07:58 PM
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
07-17-2018
07:51 PM
1 Kudo
+1 on those two wishes. I've put these in before to Meraki
... View more
07-05-2018
10:07 PM
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
07-05-2018
10:03 PM
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
07-05-2018
09:51 PM
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
06-24-2018
08:43 PM
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
06-24-2018
08:29 PM
@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
05-10-2018
08:34 PM
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
05-09-2018
11:11 PM
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
05-09-2018
10:35 PM
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
05-09-2018
10:26 PM
Hi Community, I've come across a issue with MX64 routers and large UDP packets sent over the WAN to LAN hosts. It seems Meraki limit the UDP payload size or fragmented packets to 4 fragmented packets, I think this roughly translates to 5000 bytes. The issue causes problems with our Polycom VOIP handsets and the BLF status of other handsets. This results in call drops and unusable phones within the branch. When I revert back to a old Cisco 871 router it handles these fragmented packets without any issues. Anyone experience this particular issue or have any ideas how to overcome this?
... View more
05-09-2018
10:02 PM
@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
05-08-2018
08:06 PM
@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
05-06-2018
11:23 PM
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
05-01-2018
11:56 PM
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
Kudos given to
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 1 | 827 | |
| 1 | 11398 |
