Meraki

GIdenJoe · ‎Jul 22 2019

Ok, thanks again!

GIdenJoe · ‎Jul 22 2019

That's because if you implement MST in a phased manner you have to make sure to start from the root bridge (your distri switch) and make sure it is root bridge. Then you won't get the PVST simulation errors. Fun fact is. If a non MST switch is running PVST or RPVST and it is the root bridge. Then all VLANs need a lower bridge ID than VLAN 1. So VLAN 1 needs a bridge prio of 4096 and the rest 0 then you also won't get that error. If you don't do that each instance of PVST will use the VLAN number as it's ext-sys-id and cause the priority to be higher. In that case MST will be confused that there might be an instance with a higher BID than itself while the same link has a lower BID due to your config. Long story short: make sure the MST region has the CIST root bridge!!

GIdenJoe · ‎Jul 20 2019

I do hope they will support MST at some in the future. In scenario’s where clients don’t want to pay for stacked switches in the core you have a single STP topo without the possibility to load balance VLANs across it.

GIdenJoe · ‎Jul 20 2019

Yep, this needs to be done alot if your provider router only has one LAN interface and you need to connect an HA firewall pair. Just use an external VLAN on your switch. Make sure that VLAN is pruned off from any trunks inside the LAN and make sure your switch mgmt ip is on an internal VLAN.

GIdenJoe · ‎Jul 20 2019

If you really need to extend your L2 domain then you could expand you stack. If not make 2 distribution blocks andconnect them L3.

GIdenJoe · ‎Jul 20 2019

Great, thanks for that clarification. Follow up question: As you can see in the wireshark output there is actual traffic going from a private IP = MPLS WAN interface towards a public IP (91.x.x.x) = public internet WAN2 on the other MX. This seems way less common but does happen. The site is about the same as the other encapsulated packets which contain Windows RDP traffic. So there is traffic flowing back from the primary WAN towards the secondary WAN. Would you contribute that to keepalive traffic or does the MX keep track of flows inside the tunnel. So policy router traffic leaving WAN2 and entering WAN1 on the other side getting response over the same tunnel? I also assume that if WAN1-WAN1 tunnel goes down traffic can still exit WAN1 but go through tunnel towards WAN2?

GIdenJoe · ‎Jul 19 2019

Hey, over two years ago I used to work for a Belgian ISP as technician and they were on the forefront of IPv6 in pretty much entire Europe. They also use DHCP-PD for assigning prefixes to customers. They also had their own modem/routers that supported a nifty feature called hiërarchical prefix delegation. That means the ISP assigns a /56 prefix on the WAN side of that modem/router and that further could give out /60 prefixes to downstream routers so they could further subdivide those into /64 client networks. I believe for the global unicast addressing that support on all L3 devices for hiërarchical prefix delegation is crucial to deal with dynamic addressing. If Meraki is to support features like this in the future it is also important that just like on a cisco ISR you can define the subnet part of each of your subnets. So you dynamically get your global prefix from upstream and you put the subnet part in it which is fixed to your preference.

GIdenJoe · ‎Jul 19 2019

I have a question about how the uplink traffic is sent over SD-WAN. I'm hoping a Meraki employee could also give an insight on this. My example below is the following and I have simplified it to one spoke site and the hub. So we have MX'es on all sites with both uplinks in use. WAN1 is connected to an MPLS provider that provides an internet breakout on the MPLS so that autoVPN tunnels can be formed over the WAN1 uplinks. WAN2 is connected to the public internet. Not counting every SA that would be made for every direction and local subnet you should have 4 logical connections. From the hub WAN1 to WAN1 on the spoke, WAN1 hub to WAN2 spoke, WAN2 hub to WAN1 spoke and WAN2 hub to WAN2 spoke. When you define SD-WAN uplink policies you can choose your uplink based on traffic matching criteria. However this only selects your outgoing WAN interface. You have 2 logical tunnels from that uplink towards both WAN uplinks on the other side. So how does the MX handle this and is this configurable? As you can see, on the right part of the drawing, for traffic going from WAN1 to the other side on WAN2 it has to break out of the MPLS and route through the internet to the other side. Another question: outside of actually performing a packet capture like I did below, is there a way to see which logical tunnel the traffic takes? The uplink selection page only shows the selected uplink, and the uplink stats only shows latency, jitter, packet loss and MOS score. No traffic utilization and it's not always as clear which tunnel is always shown. You can clearly see there is actual traffic crossing from the private MPLS IP's to the public address of the other MX.

GIdenJoe · ‎Jun 7 2019

Correct, the option in the switch settings page counts for every switch unless overridden. So you could have omitted it from the switches if you had set in in switch settings.

GIdenJoe · ‎Jun 4 2019

Or you can set the management VLAN on the uplink of each switch individually or you can set it there like on your screenshot. It's the VLAN your switch uses to reach the cloud.

GIdenJoe · ‎Jun 4 2019

Have you tried another channel? There could be non-wifi interference with a high duty cycle. In case of high usage due to someone overusing it, then just put a per client bw limit.

GIdenJoe · ‎Jun 4 2019

Yep I find this annoying if you have a customer with a multitude of sites (not small sites where you can use templates) and they want the same SSID's in every site...

GIdenJoe · ‎Jun 4 2019

Both, MR32 and MR34 use VHT as modulation so you should not have a problem mixing them. Just make sure the AP's have access to the same L2 VLANs. MU-MIMO can only be used if your clients send large frames and if they are far apart. If you have mostly voice packets or small data then MU-MIMO doesn't help at all.

GIdenJoe · ‎Jun 4 2019

Well, if you're able to use 40 MHz if the channel plan allows for it. Then you will have the advantage of using it because even though you cap the througput of every client to 25 Mbps, they will need less time on the air to actually transmit that 25Mbps of traffic. Because if 40MHz is possible, the potential datarate per device can go up and you could potentially have more efficient use of the airtime. However if the channel plan doesn't allow it because you get co-channel interference from a distant AP on the same channel and then you need to fall back to 20 MHz. This is one of the main reasons to keep your celsizes on the small side and avoid putting AP's in corridors.

GIdenJoe · ‎May 21 2019

The most important fact has not been checked. Since you're using 1AP per classroom you should survey those areas around that classroom and above and below to see how far that signal actually bleeds even at lowest transmit powers. Keep in mind that although people use -67 dBm as a celborder definition, the signal can cause signal detect at 4 dB above noise floor. That means if your noise floor is -92 at your area your AP and connected clients can still be heard at -88 dBm from neighboring AP's causing deferred transmissions. So when determining your channel plan, see how far the signal goes down to -86 or -88 depending on noise and that is your actual border wherein you cannot reuse that channel. So if you still have room for enough channels, then go with 40MHz, but if you don't have enough channels, move down to 20MHz. Also consider changing your RX-SOP thresholds. And of course use high mandatory datarates like 24Mbps minimum to avoid overhead.

GIdenJoe · ‎May 19 2019

The AP will still be sending it's survey SSID with the MAC address in it. Just connect to it using a laptop and browse to http://10.128.128.128. Login using it's serial or local login if you have set any and then just put site survey mode on disable.

GIdenJoe · ‎May 8 2019

The L2 topo also shows some weird behavior on the MX'es going to the internet since a few months.

GIdenJoe · ‎May 8 2019

If all critical devices in your org support 5GHz and your coverage meets the requirement on 5GHz, then go for it!

GIdenJoe · ‎May 8 2019

Is your client showing up as authenticated int the guest logins section?

GIdenJoe · ‎May 8 2019

Yeah, the co-termination has it's ups and downs. For instance removing a device and license from an org does not return it's value to the license co-termination pool. Renewals have to have all devices in it or it removes other devices.. very strange way of working. I'd rather have the individual licenses per device so you can retire a device by not renewing it but renewing other stuff.

GIdenJoe · ‎May 8 2019

If you'd have 4 fibers you could cross connect them for full redundancy but in this case it's just from the stack of 225's each one cable to a 220.

GIdenJoe · ‎May 8 2019

If you want to keep management inline you'll have to use 10.0.0.1 IP as local IP on the switch and use 10.0.0.2 as default gw. Do mind if you have a switch stack you'll need to have a big enough subnet to support all stackmembers and the SVI of the stack. I never used an out of band solution for this since it gave me some headaches keeping the routing separate from the management.

GIdenJoe · ‎May 8 2019

Still, for some administrative work you can have problems with licenses of individual devices being ended. You can only see when you added a certain device license for a certain period. We had a case once where an org merged and wanted to move devices from their org, to the main org so they could use autoVPN instead of non-Meraki VPN. The co-termination was still 3 years in the future but their core switches had expired licenses, so when moving the devices to the other org, the switches were no longer covered because their license could not be transferred, even not from support. So the customer had to buy new licenses for those switches.

GIdenJoe · ‎May 4 2019

@PhilipDAthI do believe if you have a higher license limit than actual devices in your network you're losing co-termination time because you spread your licenses of devices you don't have. And the dangerous thing with license renewals is that you have make sure ALL your devices are in that one license renewal key or you lose those devices.

GIdenJoe · ‎May 4 2019

The problem I have with split networks is that you can't click through on a client with problems from the MX to the switch or AP. So troubleshooting becomes a thing where you're going back and forth between networks. There is however the big problem with combined networks and a L3 switch that you can have duplicate traffic types from ghost clients because in combined networks you can only use track clients by MAC address.

About GIdenJoe

GIdenJoe

Joey Debra

Community Record

Badges