Relay agent dhcp on network operating system (NX-OS)

In most enterprise networks, DHCP servers are located in a designated services segment in a data center or some other central location. DHCP requests initiated by hosts at the LAN edge are forwarded by edge routers to centralized DHCP servers on behalf of the originating hosts. On Cisco IOS, this functionality is enabled by configuring an IP "helper" address on the edge interface. For example, if we wanted to forward all DHCP requests from VLAN 10 to a DHCP server at 192.168.100.42, we would use the command ip helper-address under the SVI configuration:

interface Vlan10
 ip address 192.168.10.1 255.255.255.0
 ip helper-address 192.168.100.42

By default, this feature forwards not only DHCP traffic, but all UDP-based broadcast traffic, including TFTP, DNS, NTP, and others. The specific protocols (well, ports) which are forwarded can be tweaked using the command ip forward-protocol.

When migrating from IOS to NX-OS, one could be forgiven for assuming this functionality was carried over to the Nexus world. Unfortunately, NX-OS operates a bit differently. While we can of course still forward DHCP requests out of a local subnet, the mechanism NX-OS uses to accomplish this deserves attention.

On IOS, the IP helper feature simply forwarded all UDP broadcasts to the specified IP address. The analagous NX-OS command ip dhcp relay forwards only DHCP broadcasts. More importantly, it forwards all DHCP broadcasts. Here's what the command looks like applied to an SVI on a Nexus switch:

interface Vlan10
 ip dhcp relay address 192.168.100.42

Seems simple enough, right? But let's take a look under the hood with the command show system internal access-list:

Nexus# show system internal access-list vlan 10

slot  1
=======

Policies in ingress direction:
         Policy type              Policy Id      Policy name
------------------------------------------------------------
    DHCP                               5          Relay

No Netflow profiles in ingress direction

Tcam 1 resource usage:
----------------------
 Label_b = 0x801
 Bank 0
 ------
   IPv4 Class
     Policies: DHCP(Relay)  [Merged]
     6 tcam entries

0 l4 protocol cam entries
 0 mac etype/proto cam entries
 0 lous
 0 tcp flags table entries
 1 adjacency entries

No egress policies
No Netflow profiles in egress direction

We can see that an access list has been created for VLAN 10 to match traffic to be relayed. Results are shown per line module; here, only slot one is listed.

We can dig deeper into the access list itself by appending the parameter input config. This yields the structure of the access list itself:

Nexus# show system internal access-list vlan 10 input config

slot  1
=======

Policy id:  5, Type: DHCP, Protocol: IPv4   Name: Relay
  redirect: to sup

redirect udp 0.0.0.0/0.0.0.0  range 67 68  255.255.255.255/255.255.255.255
redirect udp 0.0.0.0/0.0.0.0  255.255.255.255/255.255.255.255  range 67 68
permit ip 0.0.0.0/0.0.0.0  0.0.0.0/0.0.0.0  *

The output is a little unpolished, but we can interpret the ACL easily enough. The first line matches all broadcast UDP traffic sourced from any address on port 67 or 68, and the second line matches all broadcast UDP traffic from any address destined for port 67 or 68. The action for both of these lines is "redirect." The last line is an implicit (denoted by the asterisk) permit statement which allows all other traffic to pass.

Currently, there is no feature available on NX-OS to forward arbitrary UDP traffic like on IOS. Although this may be limiting in some situations, I think it's justified given that the Nexus series is oriented toward datacenter networking.

More detail concerning the differences between the IOS and NX-OS implementations of this feature can be found in Cisco's excellent Docwiki.