About GIdenJoe

GIdenJoe

You could probably ask support. They have the ability to do some fine grained config like disabling protocols you can't via dashboard. I asked once to disable UDLD on a copper port and they were happy to do that. They need to do this change on the backend. Open a case and you'll see how it goes.

GIdenJoe

If necessary you can disable wifi 6 features using RF profiles. There's a little disable 802.11ax checkmark there.

GIdenJoe

Hi @hdr , there is currently no Meraki AP that has XOR or dual 5GHz radios like the Cisco Aironet 2802/3802 or Catalyst 9120/9130 for macro micro cell or better mesh performance. All main Meraki AP's have 1 2.4GHz radio, 1 5GHz radio, 1 scanning radio, 1 IoT radio.

GIdenJoe

Oh cool, does that mean the MS390 is utilizing the device sensor feature from the catalyst underlying switch?

GIdenJoe

I believe you can perfectly use 2x 10GB SFP+ ports for flexible stacking on the 425. It does cut the bandwidth between members and can have oversubscription issues if you do so in a traffic dense environment. If both MS425's are in the same rack you can use simple 10GB twinax cables to inter link both switches and modify those ports to stacking. MA-CBL-TA-1M is the partnumber I believe. Then you can use any kind of 40GB transceiver SR or BiDi or a 40GB DAC cable to link to the other devices. Then you still have 2x 40GB uplink to other switches on the leftover two ports.

GIdenJoe

Don't take the term "virtual stacking" too literal. It is actually a marketing term for the feature that lists all your switchports from a dashboard network on one page, nothing more. It does open the abilities to config ports over multiple switches in one go by using the correct filters. The term virtual stacking should NOT be mistaken for flexible stacking which is the term you believe the MS125 should be able to do, but it does not support any kind of real stacking. Flexible stacking is the term used to modify normal ports to stackports. The only switch in the Meraki portfolio that supports flexible stacking is the MS425 aggregation switch.

GIdenJoe

@misterguitar, The VLAN setting in the switch -> switch settings screen is the default for all switches. Then you can input it again per switch which gives the option to override it per switch if you wanted. However if your upstream VLAN tagging in your uplink trunk you should not have gotten the warning when you only changed the VLAN setting on the switch itself.

GIdenJoe

Hmm are you sure both ends use the same SFP kind? Most SFP's are NOT multi speed, so usually a 10G SFP cannot transmit 1G. Yes there are exceptions but the standard SFP's are not that 🙂 SFP's adhering to the same standard like 10G SR should linkup just fine independent of the brand used. Only some DAC cables of other vendors can give trouble on some devices (usually not Meraki). So there is no link negotiation on these SFP's. Are you sure the MS225 is detecting the 10G-SR SFP correctly? Also are you sure you're not using a stackmember that is an MS210 instead of an MS225 to uplink?

GIdenJoe

Hey @misterguitar Contrary to what other people have said here. The switches management VLAN does NOT have to be the native VLAN!! You only need to be aware that if you use a different VLAN for the native VLAN between switches, like an unused VLAN like Cisco best practices have always described you could have an issue getting your switch online the first time if you haven't staged the switch first with the correct native VLAN. Having said that, the MS390 does have some bugs still and could have some trouble. Normally you should look at two area's. First is the IP of the switch itself. If you are using a different managemet VLAN from the configured management vlan (under switch -> switch settings which defaults to 1) you have to put the actual VLAN number in the IP config, even if you are using DHCP. Second the trunk config on the uplink must of course match on both ends so you don't have any VLAN hopping. Do mind that if you're not staging a switch then it defaults to native VLAN 1. Usually I first configure the switch default management VLAN on the switch > switch settings page. And then I still config it for each switch too.

GIdenJoe

If you are referring to L3/L4 firewall logging it will actually mention it in each line. So if you enable a syslog server on your network and point the Meraki network to it, you can choose to add the "flow" logs. Then each firewall rule will have a box to enable or disable logging for that specific rule. These will be included. But what about group policies? They are logged by default and the syslog message will actually say: allowed due to group policy. It will however not mention what rule it matches though.

GIdenJoe

I strongly agree with @Bruce here. The catalyst switches themselves are very stable but the integration with Meraki software is going a bit bumpy. Once they got the hang of it, porting other members of the catalyst portfolio to the newer MS line will be less troublesome. All catalyst switches use the same kind of UADP chip in one generation (except the 9200's) and the software behaves the same over the entire family. The traditional MS line is more stable but has way fewer supported features than a catalyst switch, Smaller customer that exclusively route traffic over the upstream appliance albeit an MX or a 3rd party device will be just fine with the current MS family. However if those customers grow and go to a routed distribution layer/core then segmentation becomes more important and that is where the trustsec/adaptive policy value lies.

GIdenJoe

The firewall has it's L3/L4 rules and it's L7 content filters. Group policies can also contain these rules but can dynamically pushed to a network client. However group policies can also apply to a wireless client and then it's the AP firewall that counts. These rules in group policies can override the firewall or in case of content filtering it can work additive to the existing policies.

GIdenJoe

It's strange, I can find the policy objects in dashboard under help API docs, but the interactive API docs doesn't have these endpoints yet. These are handy because they contain examples and an import for Postman. By the looks of the POST and PUT calls you can only add or modify one policy object at a time. And for action batches, normally if the documentation would have been complete then you would have known if these calls can be put in an action batch. For now, you'll need to script a series of these calls and just catch the error if you made too many calls and make it wait the time.

GIdenJoe

Don't forget if you're routing between VLANs on the MX you're not only passing the MR but also the MX and you can be blocked at any of the two touchpoints. So having the allow local lan, or specific subnet/IP on the MR is one thing, but if you're still blocking the traffic on the MX then yes you won't reach the printer.

GIdenJoe · ‎04-02-2021

I just got some e-mails today detailing that the old calls should still work but they created a new location for the now called "policy objects'. It seems they are in fact going to implement service objects in addition to network objects which is just awesome. Maybe try to get the new API calls and check if anything changed.

GIdenJoe · ‎03-29-2021

When the users installed the CA certificate of your domain, did they actually install the cert or just copied it to their store? If it is correctly installed do they actually select the correct ca cert for server validation in the WiFi profile?

GIdenJoe · ‎03-23-2021

Debugging! There are several things you cannot troubleshoot with captures alone. You need an insight at what each device is doing in a certain situation.

GIdenJoe · ‎03-23-2021

In network-wide -> general there is an option to disable meshing. EDIT: nvm you are actually using meshing for the patch antenna. If you want to do special tricks like disabling this on an individual device you should open a support ticket and ask them if they can do that for you.

GIdenJoe · ‎03-23-2021

Have you done a packet capture on your client to see after a roam the client is actually sending mDNS queries and the AP is not responding to them? The AP should only hold the list of the mDNS services and respond to queries. If they would time out on the AP then the AP's themselves are not listening to new discoveries. If the client itself is timing out entries then you should really see if the client is actively trying to query for the entries. Capture using capture filter host 224.0.0.251 on the client pc.

GIdenJoe · ‎03-23-2021

I'm really curious where it goes wrong then. Clients who refuse to connect at some time, or AP's failing to give them an AID. Or some failure in the 4way handshake. It's difficult to troubleshoot since the AP's can only capture traffic from clients or other clients that it receives. It would be handy if there would be a way to have the AP's do intelligent capture like in the catalyst world so you can have each assoc and roam on record and have the state machine in a sort of debug log.

GIdenJoe · ‎03-14-2021

They take some initial time setting up but once you have your objects and groups, they're great. Service objects would be a nice complement though 🙂 I also see the objects are also available on site2site vpn firewall rules. The only place where it does not work is on AP's and subsequently on group policies since they have to be compatible with AP's.

GIdenJoe · ‎03-08-2021

Hmm, there's no easy way you can troubleshoot this remotely. Since AP's only capture incoming frames you can't see what the AP is sending out. You can only hope that another AP is close enough to match the channel and try an OTA using the other AP. You'll have to see what's going on. Is the client probing and on the correct channels? Are the AP's responding to the probe? Does the client in fact connect but get kicked off or refused association? etc...

GIdenJoe · ‎03-08-2021

Is there a reason why you cannot enter custom service definitions? I have a customer who uses non-Apple devices for screen presenting and they seem to use _googlecast._tcp.local and _airtame._tcp.local as service definitions. However they also need guest users on the guest SSID to be able to present. This works by directly using the IP of the screen (we allowed unicast on the MX), however we can't list the screens for some reason. When I put All services in the configuration I can see responses coming in on the wire of an access point but I'm not sure it actually gets sent in the air since the AP packet capture only goes inbound. So I'm not exactly sure if the all services actually works. However even if it does work I would prefer if you could still limit the kinds of devices that are available on the guest Wi-Fi. You can configure stuff like this on a Cisco classic environment so why not on Meraki?

GIdenJoe · ‎03-08-2021

The Meraki switches run LACP mode active with slow timers. So normally if you configure mode active or mode passive on your Catalysts and don't change the timers you should have a succesful connection. If you are doing MEC (etherchannel on 2 stacked Meraki switches) make sure their stacking config is working. Else you will get two different actor ID's and the bundle will fail.

GIdenJoe · ‎03-08-2021

Hi, when having clients that use an MX at the head end with alot of windows users connecting to it using L2TP/IPsec client VPN we see the following logmessages at each IPsec Phase 1 negotiation: msg: received broken Microsoft ID: MS NT5 ISAKMPOAKLEY msg: invalid DH group 19. msg: invalid DH group 20. Now about the broken Microsoft ID: The ID it sends is 9 which corresponds to the MS documentation. So why this is perceived as broken... I don't know. As wireshark also shows this as unkown this could be an issue that nobody really updated their lists or something. I do believe Meraki can do something about this. However for the invalid Diffie Hellman groups where 19 and 20 are elliptical curves, I did some digging on my own to get around this. So basically a windows 10 client by default will send 5 IKE phase 1 proposal transforms: 1) AES256, SHA-1, DH20, PSK, 28800 2) AES128, SHA-1, DH19, PSK, 28800 3) AES256, SHA-1, DH14, PSK, 28800 4) 3DES, SHA-1, DH14, PSK, 28800 5) 3DES, SHA-1, DH2, PSK, 28800 And viewing from the wireshark capture, the MX will only accept the fifth one which is the only one with a more legacy DH group. So was looking around how to change the parameters of the IPsec in windows and found some powershell commands that will help us all. So up until now I always define my client VPNs via Powershell as split tunnels using these cmdlets: Add-VpnConnection -Name "Companyname" -AuthenticationMethod Pap -TunnelType L2tp -SplitTunneling -RememberCredential -L2tpPsk "SomeSecretKey" -EncryptionLevel Optional -ServerAddress "hostname-or-IP" -DnsSuffix "companyname.local" -Force And then I add the routes which only appear when the VPN is up: Add-VpnConnectionRoute -ConnectionName "Companyname" -DestinationPrefix "10.0.0.0/24" I also go the the GUI and disable the classfull route add so it does not route the entire 10.0.0.0/8 over the VPN. To verify this I use: (Get-VpnConnection -ConnectionName "Companyname").Routes DestinationPrefix : 10.0.0.0/24 InterfaceIndex : InterfaceAlias : CompanyName AddressFamily : IPv4 NextHop : 0.0.0.0 Publish : 0 RouteMetric : 1 PolicyStore : However this still tells nothing about how the actual IPsec is negotiated so I found next commands to change the negotiation for that connection alone and verify it: Configure: Set-VpnConnectionIPsecConfiguration -ConnectionName "Companyname" -DHGroup 2 -EncryptionMethod DES3 -PfsGroup None -CipherTransformConstants AES128 -AuthenticationTransformConstants SHA196 -IntegrityCheckMethod SHA1 Verify: (Get-VpnConnection -ConnectionName "Companyname").IPSecCustomPolicy AuthenticationTransformConstants : SHA196 CipherTransformConstants : AES128 DHGroup : Group2 IntegrityCheckMethod : SHA1 PfsGroup : None EncryptionMethod : DES3 I assumed the TransformConstants + PfsGroup are the phase 2 parameters and the rest are the phase 1 parameters except lifetime. I then tried a few other sets and for the time being I found that phase 1 only works with 3DES, DH2 and SHA but phase 2 does support AES128 at least. Maybe other combinations are possible but at least I know these work 🙂 After changing this, the MX no longer complains because it does not receive these high DH groups it does not support! I hope this helps at least someone or is at least educational for the rest 🙂

GIdenJoe

Community Record

Badges