Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Register or Sign in
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About DerekH
DerekH
Here to help
Member since Apr 28, 2020
Jan 5 2021
Community Record
9
Posts
1
Kudos
0
Solutions
Badges
Jan 3 2021
8:24 PM
Can anyone point me to the Meraki documentation that details the default aging timers for the MAC address table and arp cache please? I doubt that they will follow the Cisco usual defaults of 5mins for cam table and 4hrs for arp cache.
... View more
Sep 28 2020
4:32 PM
Hi, I’ve created a new template from an existing template that our sites are bound to and I want to move one of those template bound sites to the new template. The issue is that I only see sites that are not bound to a template as options to bind to this new template. Do I have to unbind a site and then rebind it manually, I can’t just move a site To a new template in 1 step? I was trying to keep as much information per site as possible.
... View more
I have a number of ssids with local offload (ie bridged mode with a vlan tag) either for direct internet access ie guest or standard internal corp access within the SDWAN. I have one ssid which needs to be carried back to the DC for special treatment and this is what I am checking to see if it works. The MR and MX concentrator in the DC uses the same public IP address to talk to the cloud, they both match the same outgoing nat rule on our central firewall. Is it just that the "test connectivity" function on the ssid only tries to establish the tunnel with the NAT ip of the DC controller, whereas if I just configure L3 Roaming on the spoke MR to the hub MX and save the config, then the MR would try the additional paths and establish the MR autovpn tunnel via the internal ip address? Are there any issues with having the auto-vpn tunnel for the MR establish over the existing MX/MX autovpn tunnel ie mtu issues that can happen with tunnel in tunnel?
... View more
I have an MX in vpn concentrator mode at our hub and an MX, MS (switch) and MR (AP) at a spoke site. The spoke has dual links, one via the internet and one via the internal network. The spoke MX is up and working via autovpn into the hub MX over both links, and the MS and MR on the LAN of the spoke have Meraki cloud connectivity via the central MX internet connectivity path. I've bought up a new ssid at the spoke and am trying to test connectivity to the MX in the datacentre (via the Test connectivity button under addressing and traffic on the MR) and I can see in our firewall logs that the MR is trying to establish an auto-vpn tunnel to the external NAT IP of the hub MX, which of course is failing as you would need to go externally and come back in via the hub internet to match that NAT entry. I know that the MRs are probably built to be used independently of MR/MX infrastructure, but I thought that the MR would have tried to build the autovpn tunnel via the internal internal as well ie internal IP of the MR and internal IP of the hub MX. Is there anyway to configure the AP to build the autovpn from the MR to the MX at the hub via the internal network. I've tried both Layer 3 roaming with a concentrator and VPN: tunnel data to a concentrator as options on the ssid but I have the same issue with both. I know that I could probably put the MR on an internet facing vlan at the spoke and then it would build the auto-vpn tunnel over the internet back into the hub MX and work because it would match the NAT, but then I lose redundancy should the internet link at the spoke fail.
... View more
Apr 30 2020
4:37 AM
Hi CN, thanks for you help, I really appreciate it. Support told me that the error that I am getting when configuring the dhcp relay is not expected behaviour and that I should be able to add this even with only a default route advertised from the hub. They've passed it to the engineering team to look at and provide a resolution. They say that they can add the dhcp servers in the backend manually to resolve the issue, but I'd need to contact support to change, add etc, so obviously not a scalable solution, especially for numerous spokes. They also said as an alternative they can disable hub/hub tunnel formation in the backend (was this was you were referring to previously - I thought that was just disabling the readvertisment of of hub local networks), but I don't know what the knock on effect of this would be. I guess hub/hub tunnels are there for purpose and breaking that could lead to other issues. I tried to get out of the support person what this could be. He said he would find out, but didn't elaborate when he emailed me later so I'll follow up. Do you know any caveats to disabling the hub/hub tunnel, or if this should be avoided?
... View more
Apr 29 2020
3:04 PM
1 Kudo
Awesome thanks I'll open a ticket with support. Do you know if this lack of more specific routes over the autovpn tunnel is the reason that I can't configure the dhcp forwarder/relay IPs? Out of interest, is there a list of these "features" that support can enable in the backend (so customers are aware) & some roadmap for them being available for customers to configure themselves?
... View more
Apr 29 2020
4:46 AM
I have an mx250s in vpn concentrator mode in one building and I've setup an mx67 spoke and it has formed an autovpn tunnel. Routing is working fine and I can access all internal subnets within the hubs ie dns, dhcp, ad etc. I can see in the spoke routing table that I have 2 defaults, 1 over the autovpn tunnel (Meraki VPN: VLAN with a next-hop of the Hub peer - I'm using full tunnel), and then 1 default WAN route. I'm trying to configure a DHCP relay forwarder on a few local vlans I've created on the spoke mx67 but it won't let me save the DHCP server IPs. I am getting the error message below: There were errors in saving this configuration: The DHCP relay IP address must be in a subnet connected to this Meraki network or to a Meraki network reachable through site-to-site VPN. Relaying through a non-Meraki VPN peer is not supported. I don't have any non-Meraki peers or any other static routes on the hub or spoke. I have a default route over the autovpn, but I don't have the more specific for the DHCP servers of course. Does the Meraki need to see a more specific route for the DHCP servers (even a 10.0.0.0/8 etc) via the autovpn, or is it enough that it has the default over the autovpn? I can't create VPN "Local Networks" on the Hub VPN concentrators so that the spokes see the more specifics over the autovpn tunnel due to this issues -https://community.meraki.com/t5/Security-SD-WAN/OSPF-advertises-entire-route-table/m-p/68841. If I did then it would create an issue for the rest of my internal network and I can't be filtering these hub re-advertised routes on our core network. Any ideas?
... View more
Apr 29 2020
3:42 AM
Thanks for the suggestions. Given my topology it's normal for both Meraki concentrators to advertise the spoke routes? I didn't know if it's a Meraki peculiarity. There are other unequal cost routes still shown in the route table for other prefixes (not from Meraki),just not marked as the current best route.I fell foul of the below, so I need to wait for another change window to test just incase to bring up the second tunnel. https://community.meraki.com/t5/Security-SD-WAN/OSPF-advertises-entire-route-table/m-p/68841
... View more
Apr 28 2020
5:52 AM
I have setup 2 mx250s in vpn concentrator mode in different buildings (not ha/warm spare, they are separate devices). They are connected together by a stretched vlan into our core switch. I've configured ospf on this vlan and I can see that the core switch has 2 neighbors established, one to each of the 2 meraki controllers. I've bought up an mx67 spoke and it has formed autovpn tunnels into the two separate hub concentrators. The odd thing is that only one of the meraki hub concentrators is advertising the spokes routes to the core switch. When I isolate the hub concentrator that is advertising the routes to the core, the 2nd hub concentrator starts advertising the spoke routes to the core. I thought that both of the meraki controllers would be advertising the same routes to the core switch, just with the costs that I setup for the ospf neighbor config on the mx250s. Is this the default behaviour ie only 1 hub will advertise the spoke routes? The hubs are running 14.39.
... View more
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 1 | 6978 |
© 2024 Cisco Systems, Inc.
