Meraki

GIdenJoe · ‎Oct 16 2024

That will work for both voice and video if NBAR can detect the application. However you want only voice to have the EF treatment. So inside that category group you should only add the voice version of the application and give it EF. Then have a second rule below it matching all voip and video conferencing and give that AF41 with high bandwidth queue.

GIdenJoe · ‎Oct 15 2024

If you're talking about outbound QoS on the MX appliance towards another location or the internet then you need to set this on the Security & SD-WAN -> traffic shaping page. Then you need to add a rule where you match on your voice application or a L3/4 match criterium and set the DSCP value to 46 - EF. This will effectively put voice traffic on the realtime queue.

GIdenJoe · ‎Oct 13 2024

There should be alot of companies moving on from MX100 hardware to newer hardware. Perhaps you can talk to an MSP with alot of customer to find several with MX100's waiting to renew.

GIdenJoe · ‎Oct 12 2024

Here you go: Once you start capture, have the other user try to connect to the VPN. If you wait too long the capture will stop too soon so you'll have to be on the phone to do this correctly.

GIdenJoe · ‎Oct 11 2024

Actual telnet on devices is run on TCP/23. So just make an outbound rule that blocks destination port TCP/23 from or to the subnet you want to block it. Telnetting to other ports is only used to see if you can get a TCP handshake. But you're not exchanging any commands for that protocol.

GIdenJoe · ‎Oct 11 2024

LACP is not used for the speed. LACP is used so you can make simple bundels of 2 LAN ports to go to two members of the connected stack without having blocked ports. The whole Meraki design is about simplified campus architecture by using stacks everywhere thus eliminating blocked links. However the MX appliance does not play ball here. If we uplink another vendors firewall to the access or distribution stack (yes in smaller networks the firewalls get connected directly to the distribution switch). We can use 1 port channel per firewall and each of them have a port on both stackmembers. This is the most stable design and does not suffer from transient loops that occur on MX250's in our case each time we add or remove a VLAN.

GIdenJoe · ‎Oct 11 2024

True, I don't expect all the bells and whistles. However I do expect all basic must haves to finally come on MX'es so I don't have to excuse it all the time. Without LACP and STP support there are still weird issues happening that can't be helped. Without more customization on the site 2 site VPN side you can't always integrate with other solutions. Having no firewall rules on site 2 site non Meraki VPN's is definitely a big no no.

GIdenJoe · ‎Oct 11 2024

I'm not sure about this. However you can make a Meraki group policy with that specific block in it and apply it to a test client on your network. This way you can safely test on a client before rolling out to the entire network.

GIdenJoe · ‎Oct 11 2024

Usually if you're dealing with actual visitors or student brought gear a simple PSK with guest only access is enough. Be sure to have deny local LAN on and p2p blocking on. If you have a student housing and each student needs their devices to be able to talk to each other then a solution like WPN (wireless private network) is ideal!

GIdenJoe · ‎Oct 11 2024

You need your NPS access rule to match a specific AD group. In this case that would be the domain computers group. And only if that condition is met you can send the access-accept. Usually when you create a network policy on NPS you need to put in following conditions: nas-port-type = 802.11 wireless called station id contiains SSIDname domain computer = the machine group containing your windows machines. And make sure this rule is above the default rules.

GIdenJoe · ‎Oct 11 2024

Could the printer's LAN port be going into sleep mode? Some devices that use WoL change their behavior when the LAN port goes into sleep mode. Perhaps the switch is not liking it.

GIdenJoe · ‎Oct 11 2024

I'm not throwing stones at Meraki here but I do want to give my opinion. The place I work at does several vendors for networking and security. I'm a Cisco only guy, but I can impart my general networking knowledge to my colleagues doing other vendors. The issue is that the security people also work alot with another vendor that starts with F and ends in T and find it very weird that things they can accomplish easily has no support in Meraki. And yes this is quite hard to defend it sometimes. Funny thing was that on my last Cisco live I had a meet the engineer session and he told me they didn't expect that there would be so many people would be asking about LACP support on the MX and that it was pretty low on their priorities list and perhaps has to be reevaluated. Over half a year later, it's still not on the list...

GIdenJoe · ‎Oct 11 2024

So let me get this straight. They start to support an advanced feature like having eBGP over a non Meraki VPN tunnel but they still don't support something basic like a route based non Meraki VPN? I do question what features get priority... How about: - More rule granularity (L7 allow rules), IPS rules only on specific L3/4 rules - STP and LACP support on the LAN ports - Bouncing VPN sessions - Viewing queue status and explicit configuration of the realtime queue. - Viewing and killing of open firewall sessions.

GIdenJoe · ‎Oct 10 2024

If all your traffic is internet based (north south) and you only have lower tier MX'es then you problably are overdoing your AP models. If you have alot of east west traffic, going to local servers then your choice of switches is too low. You are using the lowest end models without any stacking capabilities. In the first case you would probably be better served by using CW9162 AP's. In the second case consider using C9300L-24P/48P-4X models instead and probably upgrade your MX'es too.

GIdenJoe · ‎Oct 10 2024

Using device based group policy is not recommended because the profiling is not customizable like you have in a radius server like ISE. So the system is too rigid and you would have too many devices not fitting the profiles correctly and not getting the correct VLAN/group policy. You still need some way to see the groups of the users/machines and then apply the correct policy to it. Usually this can only be done using a radius server. In case of meraki mdm instead of Azure you could have sentry wifi policies selecting the correct group policy.

GIdenJoe · ‎Oct 9 2024

Indeed, the setting you are showing here is effectively enabling 802.11r (FT) on the clients. If your SSID is configured to support FT then the whole radius thing does not need to happen every time you move between AP's. If you go to your client in dashboard and look at roaming analytics you will also see the type of roam which should be an 802.11r roam taking as few as 20-50 ms to complete the roam.

GIdenJoe · ‎Oct 9 2024

Only a select few switch can handle NAT and that is then limited to the TCAM space they have. A C1300 is too limited a switch to do NAT. I can perfectly understand if you use an upstream router for each ISP and they NAT to a private "WAN" space but then your MX will NAT again to the internal network, unless you place the MX'es as transparent (passthrough). I think you need to think your design through because it is making less and less sense 😉

GIdenJoe · ‎Oct 7 2024

I believe you actually have to buy the Meraki license. But you could get a better discount if you can show you have an active DNA license.

GIdenJoe · ‎Oct 7 2024

The MX is actually the most expensive device as far as licensing goes. It's the device where the license is usually more expensive than the hardware. In Co-term licensing you have 3 license tiers (enterprise, advanced sec, SD-WAN) and in subscription licensing you have 2 license tiers (essentials, advantage) that equal the two higher tiers on the co-term model. Any Meraki device will always be uploading client data, statistics and downloading config. So the moment the dashboard sees you have too little licenses your grace period will start to count. In case of Co-term licensing your grace period is 30 days with a hard shutdown of your network. Devices will stop forwarding traffic. In case of subscription licensing your grace period could be 90 days but I'm not sure, however your network will still forward but not be configurable.

GIdenJoe · ‎Oct 7 2024

It would make more sense to have the same fast circuit for both MX'es WAN1 and the same slow circuit for both MX'es WAN2 and then use the mobile backup as Cellular failover link (you can deploy the failover WAN3 option on the newer MX models). This way if WAN1 fails, it will fail for both MX'es and you have a more determinate failover scenario. However if circuit 2 is too slow then it would make no sense to use it. If your mobile service is faster I would use that as WAN2 then but also on both MX'es.

GIdenJoe · ‎Oct 7 2024

You already posted the same issue in this forum but for another switch type. If two different switches show the same problems you clearly have something incorrect. It's time to show some pictures of: The SFP modules at both ends. The fiber patch cables being used at both ends. the running config of your ports (C9500 can only be Meraki monitored so you still have a normal running config).

GIdenJoe · ‎Oct 6 2024

That is if you want to do it across the entire network. You can also disable individual radios on AP's by selecting the AP and changing the mode of the 5 channel to off.

GIdenJoe · ‎Oct 6 2024

That the MX'es receive private IP addresses is very possible. Many providers only give 1 public IP on the WAN side of their own routers and then NAT to an internal range so your two MX devices can take each an IP from that with a third being the vIP. And just DMZ host feature on that vIP. I don't however see why you think the intermediate switches would give an IP to the MX. The switches usually are L2 in that part and the upstream router is the one providing the IP space for your MX'es. VRRP always runs on the LAN side of the MX, never on the WAN side at least for routed mode. The upstream connectivity test is purely done using the uplink monitor (icmp, dns, http).

GIdenJoe · ‎Oct 4 2024

It should not matter if the other switch is using their own SFP as long as the type of link is the same. The technology in use is 1000BASE-LX and that probably seems the same on both ends. However according to a document that standard describes that it can use wavelengths between 1270–1355 nm. Cisco always uses 1310 nm for LX optics but that seems to be the same for that Korenix so it must be something else. Maybe if you have DOM on the other switch check out if you are actually sending and receiving light. Perhaps the interface is in a shutdown state for some reason like BPDU guard. Or the fiber patchcable lead must be swapped places.

GIdenJoe · ‎Oct 4 2024

You can use small dashboard based captures for small troubleshooting. If you want to have long duration captures on the LAN side, then just do a span port on the switch. If you want to do that on the WAN side you will have to have the WAN port of the MX connected to an 'external' vlan of a managed switch and do the spanning there.

About GIdenJoe

GIdenJoe

Joey Debra

Community Record

Badges