3

I'm adding DHCP Snooping to the core switches but I'm unable to find the equivalent of ip dhcp snooping information option allow-untrusted from Cisco IOS in Cisco NX-OS.

I've done some tests without this option and my packages are dropped on the core, so I'm guessing this may be the issue. For VLANs that does not leaves the core DHCP snooping appears to be working.

According to Cisco documentation the only options available are pretty basic: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus3000/sw/security/7x/b_Cisco_n3k_Security_Config_7x/b_Cisco_n3k_Security_Config_7x_chapter_01000.html

I'm running a little old version of NX-OS 7.0 on Nexus 3048.

Software
  BIOS: version 4.0.0
  NXOS: version 7.0(3)I4(6)
  BIOS compile time:  12/05/2016
  NXOS image file is: bootflash:///nxos.7.0.3.I4.6.bin
  NXOS compile time:  3/9/2017 22:00:00 [03/10/2017 07:05:18]

So is this option necessary/available on NX-OS? Is there an equivalent option?

11
  • Are you enabling DHCP snooping on the core? You should enable it on the access switches, not core switches. It should be enabled where the untrusted end-devices connect on the access switches.
    – Ron Maupin
    Commented Jun 27, 2020 at 23:59
  • 1
    Yes. I want to enable this because the routing and DHCP relay is done on the firewall, and its plugged on the core. There's no L3 routing on the access layer, so I tough it was a good idea to enable it on the core, so I can have a snooping table working on the core too because it's handy. We don't have a distribution layer. Commented Jun 28, 2020 at 0:04
  • You do not connect untrusted end-devices into the core, so you do not run DHCP snooping on the core. You run DHCP snooping on the access switches, which is where you connect untrusted end-devices, and you mark the uplink interfaces on the access switches as trusted because that is the direction of the DHCP servers. You trust the server connections, not the end-device connections.
    – Ron Maupin
    Commented Jun 28, 2020 at 0:07
  • 1
    Ok, the best practices always have some exceptions. Here the virtualization infrastructure is plugged directly on the core. The DHCP server is on a VM running in this infrastructure. We have a container platform running inside the VMs. So when an developer fires up an DHCP server for accident in a container my core will be dead. You may say that I should put an access switch on the VM platform as a best practice, but we don't have it. I'm just bringing one case, that probably will not happen, but as an example of why I want to turn on the feature in the core. Commented Jun 28, 2020 at 0:21
  • 1
    BPDU protection is in place on the core and working. I know that best practices should be followed always, but sometimes you don't have the money to do this. We are a public university from a developing country, this is what we got. I'm just trying to reduce the attack surface with what I got. The switch should support proper execution of DHCP snooping, and that's why I opened the question in first place. Commented Jun 28, 2020 at 0:30

1 Answer 1

1

The platform you're using is basically a bugware, seems like this switch was made by some trainee before doing some real (not the "unlimited-money CVDs") networking for the first time.

Entire DHCP snooping is basically useless in a scenario with deployment in the core - binding database is limited to 2000 entries and building it cannot be disabled (database is required for DAI or DHCPRELEASE protections, but could be optional and still protect against rogue DHCP servers).

The knobs you're looking for are simply missing. Just like the MAC ACLs (sic!)... And beware, that even with TCAM-carved ARP ACLs ...they can only match any MAC address (only IP filtering within ARP packets is possible). At least you can use port-security feature and select some interfaces ...until you hit 8000 entries limit.

Anyway, even with DHCP snooping in action, there are no logs of blocked rogue servers (even with logging level dhcp_snoop 7), which makes this function effectively some syntactic sugar only.

Suggested workaround: filter rogue DHCP servers by using plain ACLs.

All of this makes this switch a non-core solution. Unfortunately it is also not too good at access perimeter, due to the hard QoS settings (CoS vs ToS/DSCP mappings and their respective trust states), missing MAC filtering and loop-protection. Not the *STP stuff, but real malicious (and every other BPDU-filtered) loops. There is only mac address-table loop-detect port-down on/off switch, without per-port configuration (trusted, priority!) nor MAC move thresholds configuration. There is also no traffic segmentation (good luck with private VLANs) nor VLAN translation (only for ...VXLAN).

Also keep in mind, that the CPU of this switch get's all the ARP packets from the network. And by "all" I mean exactly this - unicast, bridged data, that should remain in data-plane, are casted to control plane god knows why. You can watch them in tcpdump from run bash or directly via ethanalyzer local interface inband... or by show policy-map interface control-plane class copp-s-arp. That's right, 200 pps of ARPs in entire network (with CoPP maximum about 6700 pps) makes your switch unavailable on it's in-band management interface during some ARP storm in any VLAN bridged (and not L3-terminated on the switch). Unless you craft separate CoPP rule (there are 4 slots available, hooray!) to handle ARPs that are really destined to the CPU, which seems to be another must-have for n3k in the core.

Update: There is one more important thing to know about DHCP snooping operation. In contrary to other devices, which block untrusted responses (i.e. OFFER, ACK, NAK), this switch apparently doesn't forward client requests (DISCOVER, REQUEST) to untrusted ports, so the rogue servers have nothing to reply to. As fas as this might seem clever, there are consequences. First, mentioned above - there are no logs of such servers. Second - owner of any misconnected device doesn't see too much devices requesting addresses and eventual resource starvation. This is the next reason to block offending DHCP by using plain ACLs - one could attach some diagnostic box and pass everything to it, before blocking DHCP globally. This is especially important on networks with clients terminated on dumb switches, where the DHCP snooping won't prevent mess in a zone behind a single port.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.