Meraki

GIdenJoe

It would be extremely handy to be able to configure it but it is not so 😉

GIdenJoe

Whenever you have to automate across multiple networks or templates in your case the sole answer will always be. Use the dashboard API. You can start here and try to find the correct resources to call: https://developer.cisco.com/meraki/api-v1/introduction/ But I do have to question why you have 30 templates. Since you do have local overrides per network, could a refactoring of your templates be in order?

GIdenJoe

It depends on your setup. At the one armed concentrator you still need an upstream router/firewall for internet or WAN connectivity. If the servers you need to reach are in the same subnet as the MX concentrator then the MX can directly reach those devices although it is not best practice. It is better that the one armed concentrator lives in it's own mini subnet and the upstream router/switch/firewall routes towards the server. At the spoke you can have that MX be the router of all the local subnets there. If you want more depth information it would be great if you added some more details about your setup though.

GIdenJoe

Server errors do happen after some changes via API. You'll need support to check what is causing the issue.

GIdenJoe

Just add your order ID to your dashboard if you have co-term licensing and then you will have added both the switches and the license. If you have already claimed other switches or licenses from the same order then you have to enter them manually by serial number.

GIdenJoe

The MR57 was just at the cusp before having the dual persona hardware. The WiFi 7 equivalents are now: CW9166 -> CW9176 MR57 -> CW9178 There will be lower end models later on that will then refresh the CW9164 and 9162 for sure. The Cisco vision is single hardware, single licensing but the ability to choose your management between cloud (dashboard) and on prem (Catalyst center).

GIdenJoe

If you're tagging the VLAN inside the group policy itself you won't be able to make a difference between users. If the tag is on the SSID config itself you can select a different VLAN for AP's containing a specific tag.

GIdenJoe

I believe he wants an ISSU style upgrade which to my knowledge is not possible on an MS425 stack.

GIdenJoe

I can only confirm that this was the behavior I noticed. However it is important to note that this was matching traffic by regular L3/4 rules, not the L7 application layer detection. So I cannot guarantee it 100%.

GIdenJoe

I'm hoping this means in the 802.1bn standard you could roam between AP's using one band whilst still being connected to the current AP to have a smoother handover.

GIdenJoe

Oh really? That probably has to do with the fact that Catalyst switches with modules contain every possibility in the running config. Since I was dealing with C9300L in this case I didn't run into this issue.

GIdenJoe

I'm not ready to go native just yet but I wish they would hurry and get it stable!

GIdenJoe

I assumed by mentioning the VLAN profiles feature you would know I meant at least network wide with an option to do them org wide 😉 I did however explicitly mentioned that in my make a wish to Meraki 😉 They could also employ an intelligent system where all the access port VLANs are automatically created + the selected management VLAN. The only 'problem' I see with this approach is onboarding the switch into dashboard where if it only had VLAN 1 to begin with you would need to use that for initial bootstrap or have to use the LSP to manually set the mgmt VLAN.

GIdenJoe

So, I'm finally on my first rodeo configuring C9300L switches with native Meraki persona. Since I prefer to use VLAN numbers above 2000 I already had a few fights with dashboard. As you all know Meraki has a bizarre way of provisioning VLANs. To be able to use allowed all Meraki simply creates every possible VLAN number on their native MS switches so you don't have to and can simply use Trunk allowed all on your trunkports. However since the Catalysts don't waste their CAM/TCAM space, they limit the amount of VLANs to 1000 in the current releases and will further limit it to the high 990's according to the firmware info pages. The issue I ran into was that the very first thing I did was set the switch management VLAN (in switch settings) to 2001. Then I wanted to change the trunk ports to the correct VLAN mask like allow 1,2001-2050. However dashboard kept yelling at me that VLANs 1-1000, 2001-2050 were in use... but I removed 1-1000 ... I finally had to first set the management VLAN back to 1 to keep it within the limit before changing my trunk ports to the correct mask. After that I could change the mgmt VLAN back to 2001 and all is rosy. So this story serves everyone who might get into trouble for this. However I would very much like to urge Meraki to change the behavior on Catalyst switches to how it is actually managed on Catalyst. In Catalyst you have to create your VLANs. By setting the trunk ports to allow all, it will only forward on the created VLANs. So you never run into these strange limitations. Since Meraki has made the VLAN profiles page. This would be the perfect place to create your VLANs and provision them like that onto the switches. Pretty please!

GIdenJoe

You can always link a non managed switch to an MX but make sure you don't use VLANs in that case and don't double downlink your MX or you will cause a loop.

GIdenJoe

I haven't really used the built in cable test feature that much. If there are AP's that are really unstable or negotiating a lower speed often then I would personally go onsite with a fluke to verify onsite. The only real useful thing about the builtin test is to get a sense of the length of the cable. This way I could catch an electrician that pulled all the AP cables towards the same switch... 170 meters long... If you don't get any responses it does not hurt to callin and input the case number. There is a slight possibility that the problem is hardware related or extremely difficult to solve and maybe they just binned it. But you need to know why. I personally also have an issue that has been open for years and they have not been able to solve it yet and that is the unique client identifier issue. The moment you enable that some clients are no longer showing up on the correct switchports and you get all kinds of incorrect logging. I had two cases open for that issue since when that feature originally came out and it is still unsolved. This is the reason I have to split up MX networks from MS+MR networks where there is L3 switching going on (even Meraki L3 switching).

GIdenJoe

If your voice solution is using regular SIP with regular G711 codec you can even capture and analyse this with wireshark. You can always perform a packet capture on the LAN side or the WAN side of the MX and then see in the telephony analysis if you are having packet loss or jitter. You can even playback the audio which is cool.

GIdenJoe

Anyone know what the difference will be between the 802.11be R1 and R2 standards? I just hope these will be fully compliant and we don't have another MR45/55 range on our hands.

GIdenJoe

It was in enquiry I made to our AM at Meraki London who then forwarded it to an engineer internally. I had a customer with several networking closets but only 3 pairs of fiber to each while having cascaded fiber links. So I had to look for a solution to get all access switches directly connected to distribution and still having a spare pair here and there. So I had to change the solution to C9300L stacks and some C9200CX compact switches that are in Meraki monitoring mode to get this to work.

GIdenJoe

Meraki Engineer says on the native MS switches (MS1x, MS2x, MS3x, MS4x they would not work. On all Catalyst switches (c9300-m, MS390) they should work just fine.

GIdenJoe

Also it is best practice to have at least one switch in your stack with dual power supply. It is not intended to work with all stackmembers only having a single psu.

GIdenJoe

Nice to hear. So essentially it is up to the intelligence of the client driver to have a good experience.

GIdenJoe

Meraki logging says that phase 2 is up, however your screenshot of the Microtik log does not explicitely says phase 2 is up. If you would do a small packet capture on the internet side of your MX filtering on the public IP of the ipsec peer you should see ESP packets going back and forth. If you are not seeing that but seeing constant IKE informational messages then you probably have an issue with your phase 2.

GIdenJoe

If your Hub and spoke locations are running in Routed/NAT mode and you have 2 ISP's at the hub and 1 ISP at the spoke you will essentially have 2 AutoVPN tunnels. That means you will be able to control the traffic at the Hub but not at the spoke. If you would have 2 ISP's at both locations you would have 4 tunnels. As I have found earlier this year the SD-WAN uplink policies have effect in both upstream and downstream direction. So if you match certain traffic at the hub site to take WAN1 it should leave via WAN1 but also arrive at WAN1. This had been tested with simple L3/4 matching criteria.

GIdenJoe

Make sure the AP's are on a network that can reach meraki cloud on UDP/7351. And if you are on a newer firmware version also have them allow TCP/443 outbound. And if you are using a firewall that does SSL decryption, don't let the firewall do that because it messes up the connection.

About GIdenJoe

GIdenJoe

Joey Debra

Community Record

Badges