Meraki

GIdenJoe · ‎Apr 23 2024

Problems where some clients have issues showing the splash page do happen but are usually client problems where they don't want to use their mini-browser pop-ups. If this happens you can test that client by trying to visit a purely http site (not https) and that could very well trigger the splash page for that device. It is also important to differentiate layer 2 authentication vs layer 3 authentication. Open, WPA2/3 personal, OWE, Identity PSK are layer 2 authentications that happen BEFORE the client has any kind of access to the network. Splashpage whether it is just a passthrough click button or a form that is a form of layer 3 authentication where the client already has an IP on the network but is only prohibited to pass any traffic other than dns, dhcp and the connection to the splash page itself (or a walled garden). Both L2 and L3 authentications can be mixed. So you can have open for L2 and a click through for L3 or you can have WPA PSK with or without a splash page. However on Meraki there is a limitation where you cannot use WPA Enterprise or MAC auth in combination with a login splash page. I think the closest Meraki itself has to offer is the sponsored client login where the user has to fill in a name and email. But then only is the mail sent to the sponsor to approve. So if you want anything else you will have to work with a custom solution that could be available on the 3rd parties or build your own portal page where you can use your own login to approve access to the network.

GIdenJoe · ‎Apr 23 2024

Hey, Philip is kinda wrong in this case 😜 sorry. The MS can use group policy ACL's but only if they are applied as a Filter-ID in a Radius response. When you would look at your client in dashboard you can actually have a group policy applied AND a 802.1X group policy. It even lists it that way. The switch can only use the L3/4 firewall rules of course. So in fact you can see it as being applied as a Filter-ID on a Catalyst switch so in essence a session based port ACL. You do have to read the documentation about this especially about the limitations. You can't have many rules with L4 ports since the TCAM space on regular MS switches is more limited than Catalyst hardware. https://documentation.meraki.com/MS/Access_Control/Meraki_MS_Group_Policy_Access_Control_Lists

GIdenJoe · ‎Apr 22 2024

If you get the actual error that LACP disabled the port you may have following causes: - Your aggregate members are not going to the same peer switch (common cabling issue). - One link has a different property (for example if one link negotiates to 100 Mbps while the other goes to 1000 Mbps. - You have a weird issue where the peer switch is not aware of LACP and is forwarding those LACPDU's to other switches and your main switch sees other peer switches due to this and quickly disabled the port to avoid loops. I believe from the multitude of errors you are getting I have to assume there is something wrong with which link is connected to which other link.

GIdenJoe · ‎Apr 22 2024

GLC- SFP's are usually the 1GB range of Cisco itself and is fully verified to work with Catalyst and Cisco Business line of switches. However you can't have any -COM or other suffixes which means not an official one. The GLC-SX-MMD is the official multimode 1 Gbps SFP for Cisco switches. The confusion is complete when Cisco Business switches also have their own SFP's like the MGBSX1. I have seen both of these SFP's perfectly work on Meraki switches since they're all Cisco branded. However if you do deviate from the datasheet, you are a bit on your own for supporting issues directly related to those SFP's. The easy part is that all Meraki SFP's start with MA-

GIdenJoe · ‎Apr 21 2024

I accidentally found some undocumented MX behavior while troubleshooting a customer by using iPerf. Situation: You have SD-WAN tunnels (hub to hub in this case but it would work the same in hub to spoke) between 2 MX peers both using their 2 WAN ports. So in this case you have 4 actual tunnels. WAN-1 to WAN-1, WAN-2 to WAN-2, WAN-1 to WAN-2 and WAN-2 to WAN-1. The idea is that you can only influence outbound traffic in your SD-WAN rules where you can set WAN-1 or WAN-2 as exit interface for a certain application. But you don't really have control if your traffic leaves WAN-1 on 1 appliance it would be received on WAN-1 on the other appliance. In case you are using private links or a private ISP WAN you would want this to be the behavior. The problem is that the documentation does not really reveal how in some cases traffic could be crossed between WANs. According to my troubleshooting test it seems that the SD-WAN rules are not just outbound but bi-directional. So you can actually influence on what WAN your MX receives certain traffic. The test: I had an iperf server behind the remote MX and an iperf client behind this one. The networks on one side are all subnets of 10.105.0.0/16 and on the other side are 10.106.0.0/16. There are rules on each MX that force all private network traffic over WAN2 (by using custom policy network:10.105.0.0/16 and 10.106.0.0/16). So as expected when monitoring the uplink page on both MX'es you could see both WAN-2 traffic going way up during the test. Then I added another SD-WAN rule on one side where I matched all traffic going to or coming from: TCP/5201 (default iperf port) to use WAN-1 instead. When I did the outbound test as expected both WAN-1 links were being used for that transfer. However when I did the inbound test WAN-2 was going up while WAN-1!! was going up on this side. So the remote MX peer was only matching the general WAN2 network rule while this side was matching the TCP/5201 rule and traffic was actually crossing. Background: I usually don't have customers that use datacenters to link up to Azure but rather direct internet connections. So I was not used to have many SD-WAN rules to be able to test this and the only real rules I can use is actual server usage between SD-WAN peers. The iperf test was a nice eye opener. Takeaways: So in complex SD-WAN environments where applications are used over the SD-WAN tunnels, be careful with your policies. If you don't want traffic crossing between your upstream providers which can cause extra delay or bandwidth issues be sure to double check both directions of your SD-WAN policies.

GIdenJoe · ‎Apr 21 2024

It depends how the group policy is applied. If you use radius on a switch with Filter-ID then it will only be used as a port ACL. If you set a group policy on a VLAN then it will be the default of that VLAN and will apply it on the MX. If you set it on a client then it depends if it is a wired or wireless client. Wireless clients are enforced on the AP directly and wired clients are enforced on the MX itself. Important notice is that group policy L3/4 rules are stateless so this can give issues where you still need vlan to vlan communication. There have been talks about adding the "established" keyword like security ACL's on Cisco switches have to allow for returning traffic only.

GIdenJoe · ‎Apr 21 2024

The vMX is not an edge firewall in a cloud environment. You would need to use the Azure firewall or use an appliance like the Cisco FTD. The vMX only acts as a VPN concentrator so there is no NAT'ing in this case.

GIdenJoe · ‎Apr 20 2024

If you use warm spare then yes you will run VRRP. On Meraki you don't need separate IP's in their VRRP deployment. You only define the used IP and that's it. I also go with Philip and ask why you still want to use a classic switching design instead of the simplified campus architecture using stacked (physical or virtual) switches. We know the MS425 is going EOS soon so if you would need stacking on switches that are remote then you would need to use the C9500 switches with perhaps Meraki monitoring to get this to work. Else C9300 core's or any MS2x, 3x will do the trick for local physical stacking.

GIdenJoe · ‎Apr 15 2024

You can easily downlink your MX to two switches downstream. It will not run LACP or STP at this time however the switches will block links due to the forwarding of BPDU's across the MX. If you don't use stacking switches right below your MX'es then it is important to choose the correct links to downlink from MX to both switches and to interconnect both switches. Normally you want your east-west traffic between switches to flow directly from switch A to B and not cross the link towards the MX. In that case make sure one of those two switches is the STP root and you connect a lower numbered port between the switches than the uplink towards the MX. So the link on the non-root switch towards the MX will be blocked.

GIdenJoe · ‎Apr 15 2024

Funny part is that if you block the US, most DNS providers no longer work ;p. It would have been handy if you could limit the scope of the layer 7 rules to a specific L3/4 rule.

GIdenJoe · ‎Apr 6 2024

You will have some slower roaming between the devices of both vendors. The most important thing is that you don't do salt and pepper but make sure you replace contiguous areas of AP's. And don't forget to disable any rogue AP containment or you'll have alot of issues.

GIdenJoe · ‎Apr 4 2024

The C9300-M product page has an incorrect graphic in the accessories section, see below. Link to document: https://meraki.cisco.com/product/switches/catalyst-9300-m/

GIdenJoe · ‎Apr 4 2024

I also have a customer with this issue. However after changing a bunch of VLAN's and routes it went away magically. Support said they will be implementing a bugfix in a coming release. The bug is purely visual since the fans are actually blowing at normal speeds.

GIdenJoe · ‎Apr 4 2024

OK this aged like milk 😉

GIdenJoe · ‎Apr 4 2024

It's just like they knew 😉

GIdenJoe · ‎Mar 26 2024

There have been cases where the RX power is a tad too high on the receiving end and you get constant errors. However the link did stay up without any CRC errors. Usually it is not a problem but something to think about. The MA-CBL-TA-1M is usually a better option if you want to connect a server or another switch in close proximity. And it is much cheaper too. 😉

GIdenJoe · ‎Mar 26 2024

Hi, I have noticed that under the section Optional accessories, the C9300-NM-2Y-M has an asterisk. However the note underneath only contains the two asterisk comment about the power supplies. https://documentation.meraki.com/MS/MS_Overview_and_Specifications/Catalyst_9300-M_datasheet

GIdenJoe · ‎Mar 25 2024

These switches support EAP and MAB (radius without EAP session). So you need to integrate your radius server with the switches.

GIdenJoe · ‎Mar 24 2024

AutoVPN works as follows. Each autovpn peer will try to reach two Meraki VPN registries. It announches it's own WAN IP and port it is using inside fields in packets going upstream So when a NAT exists between the MX and the registry the packet L3 and L4 header will be altered by having the public IP and port. So the VPN registry knows what the private WAN IP and port is AND the public side. This data gets forwarded to all the peers so they can attempt to form their VPN tunnels directly by using hole punching through the NAT. This can of course fail if there is an upstream router/firewall only allowing specific ports outbound. In that case you have to manually select an UDP port and fill in your public IP. That way all peers will attempt connection through that IP and port.

GIdenJoe · ‎Mar 19 2024

Ok great. I will have to perform an OTA then to verify. I always used to look for the 802.11 specification documentation but you have to pay for those documents. Didn't know the WPA documentation were freely available 😉

GIdenJoe · ‎Mar 19 2024

I assume you are still pointing to the same DNS server in the Meraki DHCP settings like your windows server DHCP?

GIdenJoe · ‎Mar 19 2024

Really? Can you show an OTA of that? I have only witnessed a difference in the PMF part. I am talking about the regular AES version, not the higher 192bit version of it.

GIdenJoe · ‎Mar 17 2024

Those behaviors are to be expected if you are relying on uPNP, broadcast or mDNS. If you use an internal DNS server you can at least use the dns suffix option in client VPN to get by in your domain. However game server discovery is going to be a problem. Most LAN games used to have an option to join directly by IP. My experience in this however stems from the time of Quake 3 and Unreal Tournament. So current games might be quite different. I think the MX will also only forward mDNS request over VLAN's, not client VPN.

GIdenJoe · ‎Mar 17 2024

Well you aren't supposed to use test net addressing in your customer networks, so perhaps they saw it fit to use those in their internals so they would never conflict with RFC1918 addresses.

GIdenJoe · ‎Mar 17 2024

That's not how I mean. If you are setting a time limit of 1 hour per day. That means that you present the redirect page every hour and then deny users access in your splash page logic if they already had an hour.

About GIdenJoe

GIdenJoe

Joey Debra

Community Record

Badges