Meraki

GIdenJoe · ‎Feb 5 2020

Yes your picture is completely correct in terms of HA setup and STP behavior. In a stack only have four uplinks where two will be blocked because the BPDU's leave 1/0/1 and 1/0/2 with a lower Port-ID than 2/0/1 and 2/0/2 and the MX just forwards the STP messages since it does not participate in it.

GIdenJoe · ‎Jan 26 2020

@cmrif the link of SW02 to the warm spare fails or SW02 itself fails you get a dual active scenario because the warm spare mx no longer receives VRRP heartbeats. In this case you can only save yourself by downlinking the WAN links from both MX'es each to their respective SW they are connected to on the LAN side so the WAN also goes down for the warmspare. Else you get two MX'es that claim ownership of the upstream IP!!

GIdenJoe · ‎Jan 26 2020

No you actually should connect two stacked switches with 4 links to a HA pair MX'es. You will have two links blocked but you will have full redundancy if one stackmember fails or one MX fails or a link between them. So example: 2 MX appliances and 2 MS250's; Connect MX active port 3 to SW01 on port 47 and port 4 to SW02 port 48. Then connect MX warm spare port 3 to SW02 port 47 and port 4 to SW01 port 48. Make sure you DO NOT SELECT drop untagged packets on the MX trunk going downstream but use a DATA VLAN as native so STP packets will flow. You should see an STP block on SW02 ports 47 and 48.

GIdenJoe · ‎Jan 23 2020

To be considered compliant with 802.3af or at, the midspan must deliver between 48 and 57 Volts.

GIdenJoe · ‎Jan 11 2020

There are plenty of different approaches but simple MAC filtering is dirty on Meraki. In that case you need to enable splash login without valid users and just whitelist certain devices (based on MAC address) or give them a group policy that bypasses the splash screen. Other people will be able to join the SSID but will get a splash page where they can't login to. Else you need a radius server, or Meraki MDM if all your endpoints are Windows, MacOS,iOS or android. I think you'll need to do some extra homework on this 😕

GIdenJoe · ‎Jan 11 2020

I'd recommend two access points for that amount of users. MR74 if most of your end devices have no more than 2x2 radios. MR84 if you want more speed and you have devices with 3x3 or better radios. Antenna choice will depend on your coverage area. In most cases you can get way with 2x a set of MA-ANT-20 per AP. If your AP is mounted on a pole in more centrally in your coverage area this would be the way to go. However if your AP's will be mounted against a building you could use a semi-directional patch antenna MA-ANT25 to have the coverage point away from the building. (1 per AP) There is MAC authentication possible but the builtin solution is not sufficient. You'd need an external radius server where you can point your AP's to where the MAC addresses are stored.

GIdenJoe · ‎Jan 11 2020

So if I read this correctly you won't need an SM enrolled devices only access SSID but you can change this to a WPA2-Enterprise SSID. And with Sentry coupling you can still enforce the correct authorization on each user based on the pushed security tags. Basically it's a mini ISE 😛

GIdenJoe · ‎Jan 11 2020

Why not change the native VLANs on your trunks? Or even leave native blank, then all VLANs are tagged across. I myself always use VLAN 99 as native VLAN between switches and use native VLAN (management between switches and AP's/MX'es.

GIdenJoe · ‎Jan 9 2020

Well you can connect to an ap that has no internet but it will not let you hardcode the tx power. It will tell you the ap has never connected to the meraki cloud but you will be able to enable site survey mode. You'll just have to wait until the ap realises it has no uplink and starts broadcasting a setup ssid. Having the internet at first is more handy though, however I've had serveral issues with MR42 and MR52 models that just kinda freeze after turning to site survey mode and then just rebroadcast their setup ssid's claiming they never connected.. oopsie bug 😜 The MR33 however is quite stable.

GIdenJoe · ‎Jan 8 2020

You need to first connect the MR to the internet. Then make a NAT SSID. Then using NAT SSID connect to the local status page and put the AP in site survey mode. The AP will reboot and broadcast site-survey:MACADDRESS You can now do range testing.

GIdenJoe · ‎Jan 8 2020

Renew CCNP with the new ENCOR exam. Start learning ISE integrations with both Meraki switch/AP and Catalyst switch/AP. Get a customer to buy the new MS390. Start using ekahau for site surveying.

GIdenJoe · ‎Jan 8 2020

It depends on a few factors. First how wide is your channel on the AP (20, 40, 80)? Then how many spatial streams does your AP support? Then how many spatial streams does your client support? The lowest of the two previous questions counts and are you indoor with enough reflections so you actually can use those spatial streams? How clear is your channel? All that will amount on a certain MCS your client will have (on windows this is translated to a PHY rate eg: 867Mbps) If you have that and completely clear channels (80 MHz clear) and your pc does not have any slow downs due to disk reads and writes and the actual sending to the WiFi NIC then you should be able to get a topspeed of around 500 Mbps. That ideal situation however usually is out of bounds for most deployments.

GIdenJoe · ‎Jan 5 2020

The L3 header should get the marking but I haven't that the chance to test it. But it should be normal that this is implemented. The whole reason a company would choose a WAN solution instead of a public internet connection (like an MPLS connection with QoS queues from the SP) is to have that differentiated service.

GIdenJoe · ‎Jan 5 2020

You would need a full solution like Cisco ISE to profile your clients before letting them onto the network. It at least merits investigation if you can completely profile clients on OS version.

GIdenJoe · ‎Dec 30 2019

It's possible this question has been asked multiple times but the search function does not yield the answers I'm looking for. So we have alot of regular Meraki customers and we co-manage them all through our MSP portal. However we also have alot of small customers who are a bit cheap and have with Aruba switching at this time. Since Meraki go does not have a required subscription license anymore I see an opportunity to upgrade some of these customers to a more managed solution 🙂 My questions are about the management of these devices: - Can you have multiple accounts managing the same network? - If not can you easily switch accounts on the app to manage another network? So you basically setup an account both we and the customer has the credentials for. And another one about the security appliance and switches: - The datasheet says the switches have multiple VLANs possible, but what about the security appliance can you create several VLANs on the inside? And final one: - What are the main restrictions on these GO devices if you compare those to the regular Meraki solutions?

GIdenJoe · ‎Dec 29 2019

They are actually: the 2802I or E are Aironet models.

GIdenJoe · ‎Dec 28 2019

There is a difference in how Catalyst switches enforce UDLD than the Meraki MS switches. It is possible that when the port comes up after your reboot the Meraki switch is possibly waiting too long to begin transmitting it's own UDLD hello's and the Catalyst has already had it's multiple timeouts or the MS is transmitting UDLD hellos but not using the correct identifier. A SPAN capture on the catalyst side (when it operates normally and when your MS had a reboot) could show more info. According to the Cisco documentation the default udld message interval is 15 seconds and the link is deemed unidirectional and shut down after 3x this so 45 seconds. So if you can't live with the 30 seconds wait time before the errdisable recovery I could suggest following workaround. Put the catalyst switch on normal mode instead of aggressive and put the MS on enforce mode. As I can read from the Meraki documentation an MS switch still checks for udld messages after the expiry so the Catalyst side would not block the link but the MS would block all other traffic but still listen for udld so it can re-enable the port at the first receipt of an udld message.

GIdenJoe · ‎Dec 25 2019

Thanks, so if I understand you correctly you don't have any control over it. It's the app developers that choose to send their own markings. Merry Christmas back!

GIdenJoe · ‎Dec 19 2019

While we're on the subject. Is there a way you can customly push policy to apps to let their traffic be tagged a certain way on mobile devices like an iOS device? Like in windows you have a QoS policy under gpedit. Or are you completely at the mercy of the app writers?

GIdenJoe · ‎Dec 19 2019

Azure by default uses some sort of VPN gateway where you can OR connect 1 tunnel using policy based IKEv1 or if you need multiple sites IKEv2 route based VPNs. At this time Meraki MX platforms do not support IKEv2 negotiation yet (there is a closed beta running I heard). So you can't use the native VPN gateway of Azure. You can however spin up a virtual firewall that does support the Meraki sites to connect to Azure. Preferable a vMX as I mentioned in my previous post but you'll have to license it and spend money on the needed resources to run it.

GIdenJoe · ‎Dec 18 2019

This is a supported design and should not give any problems. I do prefer not to use trunk ports towards the SP router/modem though. Or at least only allow your external vlan 671 on the port to the router/modem. If you don't prune off the internal VLANs on the link leading to the router all internal traffic will be flooded there also which is bad. If you specifically set your management VLAN IP on one of the internal VLANs behind the MX the uplink should be the port leading up to the LAN interface of the active MX. So example: Your switch has it's management IP in VLAN 2. And the external VLAN is 671. Then you should have on the switch: switchport mode access, access VLAN 671 on 3 ports ( one leading to the router, and two leading to WAN1 of both MX'es ) That VLAN 671 should have a /29 or lower so it can support both MX interface IP's and preferably a vIP too. Then the ports on the LAN side of the MX'es should return to that switch or a pair of switches if you have a redundant design where only the internal VLANs are trunked on. Do make sure you do NOT use drop untagged traffic since that will cause an RSTP loop between those switches and your MX'es. Use one of the used downstream VLANs as native between MX'es and MS. I've done this design and never had issues. And if you have a second ISP you could run those links towards your second switch with external VLANs so you could have a switch fail but traffic will still be forwarded albeit on the other WAN connection.

GIdenJoe · ‎Dec 18 2019

Yeah, you can use several virtual firewalls to connect to in Azure like a pfsense for example but... if you do then you don't get the benefits of SD-WAN. So you can't do two simultaneous tunnels if you would have two WAN connections per site with policies which traffic uses which uplink under what performance circumstances. The vMX provides a virtual appliance where you can do autoVPN to. So you don't need to worry about switching IP's when an uplink goes down.

GIdenJoe · ‎Dec 12 2019

pm = private message 😉

GIdenJoe · ‎Dec 12 2019

You'll find an announcement from end September on this thread: https://community.meraki.com/t5/Full-Stack-Network-Wide/IPv6-Meraki/m-p/53677#U53677

GIdenJoe · ‎Dec 12 2019

I like your spoiler 😄

About GIdenJoe

GIdenJoe

Joey Debra

Community Record

Badges