About GIdenJoe

GIdenJoe

Once again, Meraki will not change tags if you don't configure it to. I sane person would never tag CS7 on user traffic. But it clearly shows in your first screenshot you configured Meraki to do so. So downstream you won't see the tags coming in to the wired interface of the AP but you will see the tags your Zoom config has. Upstream traffic will first be tagged by your client and then be sent over the air. When it reaches the AP will keep the current tag if no matching rule has found OR if you did put a rule that matches or put the use default QoS rules it will apply those to the packets leaving the wired interface of the AP.

GIdenJoe

I see CS5 and CS7 in your capture so I assume you captured while having all those rules in place. If your endpoints AND the downstream traffic is already tagged by your zoom installation you should not include them in your rules, then it will keep the original tagging. That was the whole point of my post: if your traffic is DSCP tagged it will add the correct WMM UP tagging but to see those tags you must do an OTA capture since those tags will or stripped by your OS or re translated to COS tags but that depends too much on the behavior of your OS.

GIdenJoe

A few key points to consider: 1) If the downstream traffic (flowing from the MX down to the access point) already has the correct DSCP tag (should be DSCP 46 (EF), not CS7 which is reserved for network protocols the AP will tag it at layer 2 with the correct 802.11 UP marking of 6 which translates to the voice queue. However that is also contested since zoom does not use a separate stream for their audio and thus should actually be put into DSCP 34 (AF41) with a layer 2 tagging of 5 (video queue). 2) Upstream traffic is dependent on the tagging the endpoint gives to the traffic so the network can't even influence how fast those packets reach the air. 3) Meraki needs a way to just match on existing DSCP value to modify or add layer 2 marking manually.

GIdenJoe

Just out of curiosity, are you running DF-bit pingtests to determine the upstream MTU or is there a way to see it on the MX itself what MTU it is using?

GIdenJoe

You'll have to check if BPDU guard for example was on that port and disabled it.

GIdenJoe

No the switches are quite different. The local status page is always on the 1.1.1.100 page so you actually need to temporarily put your pc in the 1.1.1.0/24 range if you want to reach that page and that page should only be used if the switch cannot reach the dashboard. Check out on this page: https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Meraki_Device_Local_Status_Page

GIdenJoe

The MS125 has an annoying bug that renders that page unavailable via the backport. You can actually reach the switch on that network if you just connect to a port on the front. You'll have to manually put your pc in that same subnet to be able to reach it.

GIdenJoe

I know, you can get discounts up to ridiculous levels. But if they would start off with list prices that are more comparable to the competition it would be easier to sell it. As a Cisco first engineer it sometimes is hard to defend Cisco against cheaper alternative to the smaller businesses we are working with.

GIdenJoe

I haven't used either in production yet. However having looked at both GUI's and just can't seem to find my way in the Clearpass GUI while I did in the ISE GUI. I guess if you're more used to actual Cisco products your mind is kind of layed out in a way 😉 What I do not get is why Cisco keeps being a bit more expensive than Aruba for most things. They would win many customers back if they just corrected their prices more.

GIdenJoe

I think you need non Meraki switches at each port participating in the test and have them to the port mirroring so you have an honest setup so you can verify the actual behavior.

GIdenJoe

Great job!

GIdenJoe

In ETSI area channels 36 - 64 only allow up to 23 dBm whilst channels 100 and above allow up to 30 dBm that is why you have the difference.

GIdenJoe

You have a typo in your drawing (10.17.6.0 is a /24, not /23). You could also for the moment leave the other ports on the MX in access mode since you don't want VLAN 66 to be reachable over the switch and you don't get any other bleedthroughs. If you want to keep the old router you will have to point the default gateway of the non migrated endpoints to the temporary MX IP. But the rest seems ok 😉

GIdenJoe

I know what's going on. I'm sorry I didn't think about this earlier. The MX uses the same MAC address on both interfaces causing a MAC flap on VLAN 1 on the switch. You'll have to change the design to two MX devices with a direct link in between them and route between those.

GIdenJoe

6. height of the antenna installation 7. downangle of the antenna installation 8. what do you count as your cut off value

GIdenJoe

It should work unless there is still something else in your network blocking it or the WAN is not working when you replace the old router with the new MX. When you move a pc you should wait for it's new IP address and then you should be able to ping your default gateway (the MX) and see the ARP entry in your ARP table. You should be able to ping your server from the new VLAN. Then after that you can move your server and do the same tests. Always check ARP entries on the end hosts and on the MX to the end hosts to see if they see each other on the switch.

GIdenJoe

It's not the same problem. The original problem added another 6 dB because the MR46E has 4x4 antenna design. So you would have 20 - 6 - 4 = 10 dBm as max Tx power. You mention 12 dB which is not the same issue. Perhaps your antenna is not correct or the dashboard at least thinks so.

GIdenJoe

You sure you selected the correct antenna? ETSI 2.4 GHz = max 20 dBm EIRP If it would be wrong and for example are using the default stubby dipole that has 3.8 dBi gain you would go no higher than 10 dBm Tx power, not 12 dBm.

GIdenJoe · ‎08-27-2023

Yes that's the one you should definitely try. Let us know how it goes!

GIdenJoe · ‎08-27-2023

When you talk about users not having the issues when they are not connected to a Meraki network. Do you mean different switches/AP's in the same office space or do you mean you have a branch without Meraki gear and a branch with? Also are the Zoom calls between your office and an external site/external partner or internal to a site? In case of different sites what is the scale of the current site (amount of unique endpoints, intervlan (east-west bound) routing volume, local/internet (north-sound bound) volume and what MX model are you using?

GIdenJoe · ‎08-27-2023

Looks ok but I see you are using a second MX. That is certainly valid but if you need reachability between those networks then you'll need a separate routing subnet between both MX'es. You could do this all on one MX instead and save the extra configuration. You shouldn't have any loops since you are using access ports on the MX('es) and different VLAN interfaces on the MX'es which will prevent packets from looping over the MX('es).

GIdenJoe · ‎08-27-2023

As you have already told there are many unmanaged switches in the building which means you cannot for the moment use VLAN's to switch between the old and the new network. Because if you wanted to do that you would have to change all the devices at the same time that are connected to unmanaged switches. Also the lack of config changing on the old router means you have no choice but to make 2 VLAN interfaces on the MX (MX84 = end of sale so I hope it's a different model if it is new) and take both addresses and disconnect the old router. You will need to cheat a bit on the VLAN side to have both VLAN's bleed into the same VLAN on your switch and unmanaged switches. Make sure you have two ports on your MX that each are in ACCESS mode and one has the old VLAN and the other one has the other VLAN. However they will have to connect to the switch both on ports also in ACCESS mode but in the same VLAN. This way both VLAN interfaces of the router will bleed into for example VLAN 1 on your switches and then you can just start modifying the endpoint IP configuration and test reachability.

GIdenJoe · ‎08-27-2023

First main difference is that Meraki switches only have bandwidth queue's so no priority queue available. That means if you really want to give absolute priority to your voice traffic you will have to add only DSCP EF to the highest queue you are using and add no other DSCP values to that queue. The upside is that lower queues can borrow from higher queues if those higher queues are not using all bandwidth so the voice queue will for the largest part not be used and will give alot to the lower queues. So all the QoS settings are found on the Switch -> Switch Settings page. The rules you add there are matching rules, so you can match on source VLAN and on TCP and UDP ports and choose to apply a DSCP tag or just trust the incoming tag. So if your voice application has it's own VLAN you could just match on that VLAN and set trust imcoming DSCP. Then you have the green link on top that says DSCP to CoS map. In Meraki they used CoS to refer to queues, not to the layer 2 PCP field CoS value. What you can do on that page is map a DSCP tag to a queue between 0 and 5. Queues 6 and 7 cannot be configured since they are reserved for L3 and L2 protocols. Each queue has double the bandwidth reservation than the previous. I hope this will help you on your way 😉

GIdenJoe · ‎08-26-2023

Well you should try doing a mirror capture on the port where the main station is OR on the device you want to pair. Then start your capture and see what connections are being made. When your pairing breaks you should see certain packets not being answered. It is possible you will have to do captures on both sides to determine what device is not responding and check it's connection and then you will have your evidence that it is not the network that fails but the devices that just stop making a connection. Or if the devices are trying to communicate using their mesh link instead of the switches. It has been very long luckily that I had to troubleshoot a device like that so I'm not clear what connections are actually being made so you'll have to rely and your eyes and common sense.

GIdenJoe · ‎08-25-2023

Be very careful with Sonos gear and it's meshing function. Sonos is notoriously evil on networks creating mesh connection between it's devices while at the same time being connected to a wired connection effectively causing L2 loops crashing your entire network. Secondly I have yet to encounter a Sonos that supports mDNS as a protocol to announce it's services. Sonos always seems to only use uPNP which is a broadcast (255.255.255.255) which cannot cross any VLAN boundary. However as you are not dealing with VLAN's the Sonos devices are probably dropping their connections on their own. If you are tech savvy enough or know someone that is you could add a switchport mirror and effectively look at the packets. Since traffic on Sonos has usually been unicast I don't think the IGMP snooping querier feature will do you any good. You could also see this in the packets it is sending. If the IP is in the range of 224. or above then you are dealing with multicast. Since Sonos techs are pointing fingers to the network you would need to do the correct packet captures so you can show them facts and you can point back at them with proof.

GIdenJoe

Joey Debra

Community Record

Badges