Meraki

BlakeRichardson · ‎Jul 28 2021

I strongly agree with @KarstenI on all edge switches having POE. The cost difference is not worth the risk of putting in a device without it and having to replace it.

Bruce · ‎Jul 27 2021

The recommended topologies are shown in this document, https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair. However these don't cover the scenario with only a single LAN switch. I would suggest that you have two links from the switch to each of the MX, that way the failure of a single link won't cause a dual active scenario. You will need to ensure your LAN switch supports Spanning-Tree Protocol (STP) so that you don't end up with a Layer 2 loop.

Bruce · ‎Jul 23 2021

@TravisFleming1, I believe what you may be seeing is a consequence of asymmetric routing. I’m guessing you have an interface for VLAN 27 on both the MX and MS, and likewise for VLAN 30. I would suggest you create a transit VLAN between the MX and MS, say VLAN 99 if you’re not already using it. Create VLAN 99 on the MX and a corresponding SVI on the MS stack, and make sure it’s permitted on the trunk between the MX and the MS. Set the default route (0.0.0.0/0) on the MS stack to use the VLAN 99 interface on the MX. Then remove VLAN 27 and VLAN 30 from the MX, so they only have interfaces on the MS stack. You then need to add a static route on the MX for the subnets of VLAN 27 and VLAN 30 with a next hop of the VLAN 99 MS stack SVI. The only other thing to be aware of is that the management interface on the MS switches can’t be in the same subnet as a Layer 3 interface on the MS. Hopefully all your MS management interfaces are in a separate VLAN and the Layer 3 interface for that VLAN remains on the MX - if not then this is probably a good time to separate them.

Dutra · ‎Jul 23 2021

@Bruce Thank you for the answer!

Bruce · ‎Jul 21 2021

@Dunky, yep if you had a vMX in Azure then you could put in a Site-to-site VPN firewall rule and it would work, since the traffic will be Outbound at the vMX (and so hit the firewall). That would be another solution - nice idea.

GuiCarvalho · ‎Jul 20 2021

Thank you everyone for the help.

Bruce · ‎Jul 19 2021

Welcome @JohnTrey, I think how Meraki has grown under Cisco actually surprised all the commentators. Shows what an awesome concept it is 😀

kYutobi · ‎Jul 19 2021

Congrats everyone.

Tigers · ‎Jul 18 2021

Bruce Thanks mate. Good explanation and gives me some comfort.

GIdenJoe · ‎Jul 18 2021

It does support DHCP snooping but the implementation is different. It does not use a switchport to define where the offer/ack messages can come from but rather the MAC address of the originating server. And it also has DAI which also relies on the snooping database.

AnilPatil · ‎Jul 18 2021

Well done & congratulations all.

Rahulkumar · ‎Jul 15 2021

Thank you so much

Nizam · ‎Jul 13 2021

Hi @Bruce I know it's not the meraki issue, how do i check what is cipher that has been configure in the client windows 10?

TravisFleming1 · ‎Jul 12 2021

Talked with Meraki support and the solution you had about MPLS failover ot Meraki Auto VPN was spot on. Adding a static route down our EVPN with the "when next hop is active" option was the ticket. It will use our low latency EVPN when it's up, if that goes down, it will use the internet path. Thanks!

Bruce · ‎Jul 9 2021

If you are using the IP address that is assigned to the WAN interface then you won’t be able to create a NAT. The best you can achieve is a port forward. You’ll need to ascertain what ports you want to access on your internal server (e.g. tcp/80 for http, tcp/443 for https) and set the port forward appropriately on the MX.

Bruce · ‎Jul 8 2021

@SaravananShan based on your scenarios I don’t believe that the MX is going to be the best choice for you. The VPN to non-Meraki peers, although very functional, does not provide much in the way of customisation - in-line with Meraki’s ‘simple’ approach. You may well be best off putting a third party VPN head-end/firewall behind the MX to perform the functions you describe. Here’s my thoughts on your scenarios: Scenario 1: the encrypted traffic is defined by the addresses that you ‘include’ in the VPN, these are either locally defined subnets on a VLAN or a static route. Scenario 2: for each Meraki network the IP addresses encrypted are as Scenario 1. Although the non-Meraki peer is defined globally only local Meraki network IP addresses are encrypted. You can defined multiple tunnels to the same destination (with different remote subnets) and ‘tag’ them so they’re only established from certain Meraki networks - remember non-Meraki VPN routes aren’t passed across the AutoVPN. Scenario 3: there is no capability for NATing on non-Meraki VPN tunnels.

TLO3346 · ‎Jul 8 2021

@Bruce I don't believe so, we have static IPs on all disconnecting sites. @PhilipDAth That's a good though but we also have two WAN IPs at these sites so it should have just done load balancing to the other WAN if one fails but it just falls off the network and no messages regarding the WAN disconnecting is never recorded. Could these be False Positives??

Lock007 · ‎Jul 7 2021

@KarstenI Thanks for the information. I have done that. Right now flow preferences are based on the which applications need the most bandwidth. Otherwise one of my other ISP is supposed to give me 15Mbps upload speed but due to some network issues they can only give me 4.5Mbps for the time being.

CFlood · ‎Jul 5 2021

Thanks a lot @Bruce . I can remember learning to become a network engineer and overthinking everything made it worse haha. So I appreciate that advice!

Bruce · ‎Jul 1 2021

@ToryDav if you're using MS390 then the requirement around the Management IP are slightly less, have a look in the Layer 3 Interface Caveats listed in this document, https://documentation.meraki.com/MS/Layer_3_Switching/MS_Layer_3_Switching_and_Routing. Also, just be aware that you may end up encountering a few issues with the MS390 devices, they're physically good devices, but the firmware is still a bit raw - you'll probably want to run the latest beta firmware to get the best experience. If you're looking at future proofing, and you're not planning to do anything complex (e.g. no MAC whitelisting, not getting too carried away with 802.1x) for the moment, then you should be fine. If its a critical network (i.e. you can't afford downtime) then I'd seriously consider the MS50 or MS355 switches.

Limitless · ‎Jul 1 2021

We have added MFA to our frontend dashboard so we can limit access by function. We don't share the Meraki dashboard with anyone else

Bruce · ‎Jun 30 2021

There's nothing that I know of for this that is built into the Dashboard, or as part of the API. The best solutions I've seen in the past are either using SNMP to poll the interface, or collecting Netflow records from the MX. Then you store them for as long as you want and report on them how you want.

PhilipDAth · ‎Jun 30 2021

The only downside of using a stack is when you do a firmware upgrade both stack members need to reboot at the same time. So you will get an outage. If you are able to schedule in a 5-minute outage window every 6 months for the firmware upgrades the stack is the better option.

PhilipDAth · ‎Jun 30 2021

I don't know the answer. I recall people talking about disabling NAT-T on the Fortigate side before.

HovnanianEA · ‎Jun 30 2021

Thank you Bruce. We're currently using VTP transparent mode on all switches so it should be as simple as adding the Wireless VLAN to all switches. We're also not restricting any VLAN's on the trunk ports between switches. I plan to change the config in the office which has the AP's setup as trunk ports and turn them into access ports. This way we can keep a standard going forward as we currently use access ports for our Aruba AP's.

About Bruce

Bruce

Community Record

Badges