About GIdenJoe

GIdenJoe

That design is probably not supported. You can easily have split tunnel traffic by just not putting the MX250 as default route. But all the subnets the MX250 injects into the SD-WAN will be made available through the tunnel. That means all private traffic flowing between that Z3 local network and the networks and routes the MX250 knows and injects as VPN available. All other traffic will break out locally to the internet at the Z3. To further block traffic from the Z3 to the MX250 you can add the VPN acl to only allow radius traffic from the remote Z3 subnets towards the local MX250 networks.

GIdenJoe

I personally think because Meraki is doing SD-WAN between sites they should support PIM-SM and the forwarding of Multicast between sites. I can image some voice music streaming from the DC or phone on hold music this way.

GIdenJoe

BGP on MX appliances is only meant to import the routes of a site or datacenter into SD-WAN and vice versa to have site subnets available to BGP peers in a HQ or Datacenter site.

GIdenJoe

According to the datasheets all switches have a backplane switching capacity equal to the sum of all max portspeeds x2 so that should be non-blocking. The only scenario I can think of is when you have several stackmembers and you oversubscribe interswitch communication.

GIdenJoe

It's simple: Does your computer know when it is receiving TCP data from a webserver that it is passing 12 routers on the internet and perhaps passing through an MPLS network? No it does not. Your computer if it is connected with a wire uses ethernet to talk inside it's own network which encapsulates IP if it is an IP packet. It does not speak MPLS or VXLAN or LISP or GRE or whatever might be used upstream. That's the whole point of using the TCP/IP and OSI reference model. To give you an example like your case: You have a Meraki switch that will serve clients on a network and the router/firewall or whatever intermediate device is a VTEP. The Meraki switch will send UDP packets to it's known Meraki cloud servers upstream towards it's default gateway (so that is UDP inside of IP inside of ethernet). Then the upstream device takes that packet and sees that it needs to send that packet across it's VXLAN tunnel to the VTEP at the other end. So it encapsulates the ethernet frame inside a VXLAN header and slaps another UDP + IP + ethernet on that and routes it towards the other VTEP. That VTEP then decapsulates the outer headers to reveal the inner packet and sends it on towards the end firewall or gateway towards the internet so the switch's packet is forwarded in the direction of the Meraki cloud.

GIdenJoe

That's a good point you bring across @Aaron_Wilson . The same goes for VoIP installers: Network people are oblivious to VoIP setups and voice guys don't know enough about networking to know what questions to ask a network engineer or give any reason they want a certain design or just point at the network as being faulty while it's their own product that has a problem.

GIdenJoe

Servers, clients or other devices (like a Meraki switch) only use IP to reach other hosts or the internet. They are not aware if their traffic is encapsulated inside a VXLAN header. So in this case you should be fine 🙂

GIdenJoe

The documentation shows design scenario's and how to configure said deployments. I don't believe they have a ready testing document. What is it that you wish to test?

GIdenJoe

In one armed concentrator mode you only have one uplink, so you can never experience a dual active issue if a VPC peer switch would fail because both up and downlinks would be gone on a single appliance. However VPC is in itself cannot be used in this case because the MX does not support port-channels. Individual links to both MX'es is okay though.

GIdenJoe

If you run a syslog server behind the MX you can send syslog messages to it for every flow that is allowed or denied by the rules if you put logging on for a certain rule. However I have never tested L7 rules on a syslog server so I'm not sure if it leaves an entry for those. Might be worth testing.

GIdenJoe

This bug has been a bane in my existence for a very long time. My own MR33 luckily does not behave this way but most MR52's and MRx6 models do show the same behavior. Usually if you power the AP with a switch and set it up it works, then you power down the switchport and boot again, you're still good. If you go onsite and use a PoE injector on a battery then gone are the settings and you need to reset the AP, reconnect it to the cloud and set it back into survey mode. In the very least you should be able to set channel, channel width, txpower in survey mode manually without cloud connect. The problem usually happens at the second reboot after you configured the device. So if I have to do an APoAS I usually make sure the AP stays powered the entire day by plugging the battery in the main outlet when I take a break between walks.

GIdenJoe

There were CVD like documents in the past but alot of them have been removed since. You can try finding stuff in documentation.meraki.com.

GIdenJoe

Hmm, the configuration of IPsec VPN peers does not have the ability to insert 0.0.0.0/0 as local network so the other side will not be able to use 0.0.0.0/0 as remote network so I fear that setup is not supported. You could only fix it by putting an MX/Z appliance at that remote site and use full tunnel.

GIdenJoe

If you have the call manager IP as uplink test IP or if you are using VoIP health then yes there would be alot of icmp originating from the MX. Else you might capture at the LAN side of the MX'es if you see the icmp echoes coming from an internal device to the call manager IP.

GIdenJoe

The pattern is way more spherical than the MR33. For the MR33 there is a huge difference how you mount it. If there is a 6 dB difference then you effectively double or halve the usable distance in that direction. By the way the charts on the datasheet are still wrong. On the right the keep messing up their X and Y planes. I would like for someone from Meraki to finally fix that.

GIdenJoe

Nice Bruce, you seem to be the only one sofar that mentions the important fact that the VLAN needs an IGMP querier for IGMP snooping to work properly. This is another case for keeping user LAN's behind a coreswitch instead of directly terminating it to the MX. I'm curious if the Meraki switches behave correctly in this regard if you would let your management VLAN layer 2 through the coreswitch onto the MX if multicast packets are not flooded across the L3 interfaces into other VLANs.

GIdenJoe

I personally DO rely on STP to resolve these uplinks. If you designed your network well then you should not have any STP events that could cause an STP crash at your Core switches. It is in the design documents of Meraki and they will fully support this. A stackmember failure can happen too causing a blackhole because someone onsite has to refit the uplink to the other switch... In the above drawing you can see a stack that is uplinked to two MX appliances in a HA configuration. I would always uplink two stack members, not three or more so you can easily predict what should happen with the blocked links. Here you can see the first switch blocking both it's links that go to the master and the spare. On the second switch you can see port 23 that goes to the spare which is not marked as uplink because of it and port 24 that is connected to the master MX so that port is marked as uplink for the stack. The uplinks are made as follows: MX Master 3 -> SW1/23 MX Master 4 -> SW2/24 MX Spare 3 -> SW2/23 MX Spare 4-> SW1/24 The only weird thing in my book is that stackmember two is apparently having lower switchport ID's and thus it gets the forwarding ports instead of switch 1. It does not matter in the end but that's one of the things that you just cannot configure on Meraki 🙂

GIdenJoe

@BruceI'll let you in on a secret. A layer 3 port on a catalyst switch under the hood is a single port that has access to an internal VLAN and has an interface in that same internal VLAN. Same for an L3 port-channel. It are bonded ports that use an internal VLAN and the switch has a vlan interface on that internal VLAN. So strictly speaking an L3 port-channel is technically the same as L2 with the restriction of single VLAN traffic. @whistlebloweraccording to the linked document the algorithm uses both source AND destination L2,3 and 4 information. So chances are very good you'll have an even distribution amongst channel members.

GIdenJoe

I have a customer with a stack of MS225-48LP that were partly replaced due to the fan issue. In the two years they run those switches there have been 2 instances that in the night the stack kind of breaks and all links are blocked due to LACP. Only a hard reboot solved this issue in each case.

GIdenJoe

Then set the other VLAN to native 😛

GIdenJoe

Make sure you have another VLAN interface on the MX and delete the VLAN 1 interface afterwards.

GIdenJoe

Thanks for your response, I was hoping for some more response though 😉 It seems that critique posts aren't responded to much.

GIdenJoe

300 is about the price of any proctored exam though. Cisco exams are the same.

GIdenJoe

I remember Batman saying to Mr Fox about the tumbler: Does it come in black?

GIdenJoe

Does the uplink traffic increase if you have your clients downloading a bunch of stuff on that exact AP? It's just weird. Unless there are simply no clients connected to that access point for a long while.

GIdenJoe

Community Record

Badges