Meraki

KarstenI · ‎Jul 29 2021

Yes, for Netgear it is the wrong place ... This is Meraki here, but you'll be fine after correcting your network. 😉 In general, DHCP-Snooping and DAI is quite similar with different vendors. DAI needs a working DHCP-Snooping, but DHCP-Snooping does not need DAI. Typically you first activate DHCP-Snooping and then you have to wait for the Snooping-database to be populated. If this database is not complete (learned or manually configured), DAI can not do its work as it is not aware of the systems IP-to-Mac-binding.

KarstenI · ‎Jul 28 2021

In addition to that what is already answered: My rule of thumb is "Never buy unpowered switches for the access-layer". Every time I bought a switch without PoE because I thoughts I don't need it, some time later I regretted it because it had been nice to have PoE.

KarstenI · ‎Jul 25 2021

You should roll back to 16.8. The certificate gets regenerated after you change your dynamic DNS-hostname (to something new and then back to the original name). *Never* educate your users to accept untrusted certificates or they will also do it when it can kill your company.

KarstenI · ‎Jul 24 2021

If you want to measure (and graph) your internet throughput, query the MX with SNMP and an external tool like CheckMK.

KarstenI · ‎Jul 20 2021

That would be a perfect addition to my collection of Cisco Mugs!

KarstenI · ‎Jul 20 2021

The devices can freely move between networks without any problem. This is probably done quite often.

KarstenI · ‎Jul 16 2021

Welcome to the most prestigious program in 2021! 🙂

KarstenI · ‎Jul 15 2021

I think I am not the only one who is hoping for policy-objects in other places like MR, NAT and so on ... For the LAN isolation, as already mentioned, this has to be done outside of the MX. The MS switches also have a "Port Isolation" feature.

KarstenI · ‎Jul 15 2021

@KarstenI mentioned needing to "Deny all of our networks". Is there a way to do that without doing each individual VLAN? We have over 10 and shift them around. Managing a rule for each would be complicated. I typically use an object-group "RFC1918" for this purpose. With that, the rule is still correct when new networks are added at a later point.

KarstenI · ‎Jul 12 2021

With this rule you allow access to the MX, but not to the internet. You need: Deny 192.168.134.0/24 with Any Source-Port -> "all your Networks" with Any Destination-Port Allow 192.168.134.0/24 with Any Source-Port -> Any Destination with Any Destination-Port

KarstenI · ‎Jul 7 2021

As already mentioned, IP does not work the way you want to have it. But there is a workaround that is not very elegant and is some initial work, but could improve the situation if there is no budget to increase the bandwidth: 1) Try to find out which users are needing a better uplink to the internet and which users are fine with a low uplink and a high downlink. 2) make sure that these users have fixed IPs or DHCP reservations 3) configure Flow-preferences (under Security & SD-WAN -> SD-WAN & Traffic Shaping) to steer the users to the optimal uplink.

KarstenI · ‎Jul 6 2021

I don’t know anything about the roadmap, but for the host name, I would deploy AnyConnect profiles which “hide” the name from the client. Not the same, but perhaps the way to go. This should be also a better solution to not break the failover to the secondary ISP in case of failure of the primary ISP.

KarstenI · ‎Jul 6 2021

The APs will get the firmware, but based on the settings that are configured for the network. And if you can't upgrade the firmware after moving the AP to the new network, it is already on the desired version.

KarstenI · ‎Jul 6 2021

The question here is, which firmware version is configured for the new network. Be aware that the firmware-version is *not* configured on the AP, it is configured on the network and the APs "inherit" this setting. And when adding a new network, the dashboard automatically assigns a default firmware-version (I think it is the latest stable, but had to check that) to that network.

KarstenI · ‎Jul 5 2021

When the configured IP-settings are not visible, then the MX can not use them to reach the dashboard. As already mentioned, first make sure with a PC that these IPs are actually working.

KarstenI · ‎Jul 3 2021

The "S" in "IoT" stands for security ... 😉 I don't trust these devices at all and try to put them in a separate WLAN and VLAN if possible. For some devices where the controlling device needs to be in the same IP subnet as the IoT-device, I put them in the same VLAN, but control access on then WLAN itself. One of the MPSK-solution (both with or without RADIUS) can be of great help here.

KarstenI · ‎Jun 29 2021

I have a new avatar! (Well, not really new, I just exchanged the Avatars between the Cisco- and Meraki Community)

KarstenI · ‎Jun 20 2021

I don't think that it will be that easy as the MX will not see the request. Same as with Tor, either we block the ingress-nodes or we are blind for the communication.

KarstenI · ‎Jun 20 2021

I would expect that the relevant sites will end up in the "Proxy Avoidance and Anonymizers" category when the feature is eventually established.

KarstenI · ‎Jun 16 2021

@Shadius The overlap is more or less the URL-Filtering that can be done both on the MX and in Umbrella. But Umbrella is such a great product that really should be considered for advanced security.

KarstenI · ‎Jun 16 2021

Yes, it's a separate product in the Cisco portfolio. What are you looking for exactly? For example, if you have the MX with Security-license, it's not DNS-security, but there is some feature-overlap.

KarstenI · ‎Jun 16 2021

Yes, in combination with Cisco Umbrella which can be integrated on the MX and MR devices.

KarstenI · ‎Jun 16 2021

Perhaps what caused the confusion: On the "Firmware Upgrades" page you do not see what firmware the devices are running. It only shows the firmware-version that should be used if the devices are capable of this version.

KarstenI · ‎Jun 14 2021

As a customer, I typically would not buy this adapter. Why waste an Ethernet-port when a plain USB-C adapter does the job. The only reason I can think of is if there is only ethernet available and the next power plug is far away.

KarstenI · ‎Jun 14 2021

Practically, you can't. You can easily restrict/shape traffic and with a well-thought QoS-policy you can make all traffic-handling more "smooth". But you can't directly guarantee a bandwidth. You could shape all other traffic so that you have "rest" for that specific PC, but before doing that I would rethink about my requirements.

About KarstenI

KarstenI

Karsten Iwen

Community Record

Badges