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
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.