DHCP Relay on NX-OS
By stretch | Thursday, June 28, 2012 at 1:27 a.m. UTC
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.
About the Author
Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.
Posted in Switching
June 28, 2012 at 3:01 a.m. UTC
Another interesting thing I've found about using DHCP relay, is that when it's configured on an SVI, the Nexus 7k will not forward those DHCP broadcasts out other ports for that VLAN.
We had a strange setup where DHCP relay was configured on a SVI on a 7k (the DHCP server it was relaying to no longer existed), but the actual DHCP server that was being used for that subnet was on a server directly on that subnet. Servers on the same access switch were able to get DHCP addresses from the local DHCP server. But when we added that VLAN to another access switch (connected up to another port on the 7k), servers connected to the second switch weren't able to. We had to disable DHCP relay on the SVI.
June 28, 2012 at 3:07 p.m. UTC
Why are you using "vlan 10" on the first output and then "vlan 1351" on the second output? Is that a typo?
Thanks for the great info.
June 28, 2012 at 11:23 p.m. UTC
@angel_caido: Yes it was, thanks for catching that.
June 29, 2012 at 1:16 p.m. UTC
NX-OS does not forward DHCP broadcast if DHCP server is in same subnet.
You need another relay command to perform the job.
ip address 192.168.10.1 255.255.255.0
ip dhcp relay address 192.168.100.42
ip dhcp relay address 192.168.10.42
July 2, 2012 at 3:59 p.m. UTC
Thanks for the info, however it seems this command doesn't work on all Nexus :
Nexus2# show system inter a?
aaa Show information about aaa
aclmgr Aclmgr commands
adjmgr Show Adjacency Manager information
ascii-cfg Display ascii config server internal info
I'm using a Nexus5596UP with Layer 3 card and NX-OS n5000-uk220.127.116.11.N2.1.bin and the command is not recognize :
Nexus2#show system internal access-list vlan 3
% Invalid command at '^' marker.
Which NX-OS version are you using ?
Also if anyone knows a way to forward UDP packet on NX-OS the same way than with the IOS command ip forward-protocol I will take it. I doubt this exist but we never know...
Have a good one.
August 14, 2012 at 10:07 p.m. UTC
Thanks for this little gotcha with NX-OS - and I call it that just because I was performing a migration from Catalyst 6500 to Nexus 7018 and realized only then that NX-OS didnt recognize the command. Something you forgot to mention though, you need to also add the following command:
October 18, 2012 at 7:32 p.m. UTC
"We had a strange setup where DHCP relay was configured on a SVI on a 7k (the DHCP server it was relaying to no longer existed), but the actual DHCP server that was being used for that subnet was on a server directly on that subnet. Servers on the same access switch were able to get DHCP addresses from the local DHCP server. But when we added that VLAN to another access switch (connected up to another port on the 7k), servers connected to the second switch weren't able to. We had to disable DHCP relay on the SVI."
If you look further into the output of the show commands listed above, you realize that the command is actually putting a backplane ACL on the 7K. Traffic contained to the leaf switch doesn't hit the backplane of the 7K. When you forward up to the 7K and get switched out another port to another leaf switch, you hit the backplane and the ACL. I would also suspect that you would see the same behavior between slots on the 7K. Anytime you hit the crossbar you should get snagged by the ACL.