IP helper (now DHCP relay) works differently on the Nexus 7000 than on the Cisco 6500. The N7K imposes a VACL to filter local DHCP broadcast traffic, under the assumption that you’d be using DHCP relay when there is no local DHCP server. So if you are planning on using a local DHCP server with the DHCP relay (former helper) address providing fallback to a remote DHCP server, you need to put in a DHCP relay line for the local server as well as the remote one.
For full details and a configuration example, see “DHCP Relay on the Nexus7000/NXOS Vs. IP Helper on the 6500/IoS”
NX-OS’s implementation of a DHCP relay on a Nexus 7000 differs from that of how we implement the DHCP helper address on the Catalyst 6500 and other IoS based platforms.
On the Nexus 7000 we use a VACL to redirect all DHCP broadcast traffic to the CPU when the DHCP relay function is implemented. When this redirect occurs the Nexus 7000 does NOT broadcast these DHCP broadcast packets to all ports within the VLAN as one would expect. This is done based on the fact that it is believed that if a DHCP relay agent is configured, than the DHCP server does not exist on the local vlan and there is no need to broadcast this traffic locally.
This is different than what occurs on the Catalyst 6500. On the Cisco 6500 switches all DHCP broadcast are leaked to the CPU and flooded to all ports within the vlan.
On the N7k you can view the redirect VACL in hardware via the following command, ‘show system internal access-list vlan X input statistics’. Below shows what the ACL redirect would look like for a relay agent configrued on SVI 10. This only shows the redirect VACL for module 2. If you have mulitple modules in the device, this VACL redirect would be configured for every module (this is because there is a forwarding engine on every module on a N7k):
7000-1# sh system internal access-list vlan 10 input statistics
slot 2
=======Tcam 1 resource usage:
———————-
Label_b = 0x801
Bank 0
——
IPv4 Class
Policies: DHCP Snooping() [Merged]
Entries:
[Index] Entry [Stats]
———————
[0003] redirect(0x800) udp 0.0.0.0/0 255.255.255.255/32 eq 68 [0]
[0004] redirect(0x800) udp 0.0.0.0/0 255.255.255.255/32 eq 67 [0]
[0005] redirect(0x800) udp 0.0.0.0/0 eq 68 255.255.255.255/32 [0]
[0006] redirect(0x800) udp 0.0.0.0/0 eq 67 255.255.255.255/32 [0]
[0007] permit ip 0.0.0.0/0 0.0.0.0/0 [0]
The issue with not broadcasting the DHCP discover when a relay agent is configured is that in certain scenarios this can break functionality, when a local servers need to hear the DHCP broadcast packet. This can also occur if the server is not directly attached to the N7k, but to get to the server the traffic must pass through a N7k with the DHCP relay agent configured for that vlan.
In order to get around scenarios where the local DHCP discover needs to be heard by a specific device on the local subnet as well as the DHCP server an additional DHCP relay-agent address would need to be configured on the SVI of that vlan. This relay-agent address would need to point to the local device that needs to hear this traffic. Since DHCP traffic is redirected to all relay-agents configured the DHCP discover would be sent to the DHCP server(12.3.4.6) as well as the local server(10.0.0.2). An example of this can be been below:
Interface vlan 12
ip address 10.0.0.1 255.255.255.0
ip dhcp relay 12.3.4.6 <—DHCP server
ip dhcp relay 10.0.0.2 <—IP address of local server.
If multiple devices on that subnet need to hear this traffic, you can specify a local a relay-agent as the directed broadcast address of the local subnet. This will cause the DHCP traffic to be flooded throughout the local subnet (as destination 10.0.0.255) as well as being sent to the DHCP server(12.3.4.6):
Interface vlan 12
ip address 10.0.0.1 255.255.255.0
ip dhcp relay 12.3.4.6 <—DHCP server
ip dhcp relay 10.0.0.255 <—Local subnet broadcast
Since the relay-agent is simply forwarding this traffic to the configured address, this will allow this traffic to get to the correct location.
Below is a step-by-step walk through of the DHCP Process on the N7k and 6500 discussing the difference above.
DHCP Relay-agent Process on the Nexus7000
- DHCP discover is sent by the client
- When this packet ingresses the N7k it is redirected to the CPU/relay agent by the ingress forwarding engine and is not broadcast on the vlan.
- The relay agent redirects the DHCP discover to the DHCP server.
- DHCP server responds to the IP address of the relay-agent in the giaddr field of the discover/request packet with a DHCP offer, which is relayed to the client.
- DHCP client responds with DHCP request (whether it be an unicast or broadcast response), this is redirected to the relay-agent and forwarded on to the DHCP server.
- DHCP server ACK’s the request, which is sent to the relay-agent. This is then relayed to the client, finishing the DHCP process.
DHCP Helper Address Process on the Catalyst 6500
- DHCP discover is sent by the client
- When this packet ingresses the catalyst 6500 it is leaked to the CPU/relay agent based on a destination index, which includes the vlan broadcast.
- The relay agent redirects the DHCP discover to the DHCP server.
- DHCP server responds to the IP address of the relay-agent in the giaddr field of the discover/request packet with a DHCP offer, which is relayed to the client.
- DHCP client responds with DHCP request (whether it be an unicast or broadcast response), this is redirected to the relay-agent and forwarded on to the DHCP server.
- DHCP server ACK’s the request, which is sent to the relay-agent. This is then relayed to the client, finishing the DHCP process.
—Reference from https://supportforums.cisco.com/docs/DOC-14753
More…
Cisco Catalyst 6500 vs. Cisco Nexus 7000 Switch
To Answer the Questions from Cisco Nexus 1000V InterCloud Users and Analysts
Cisco Nexus 6000 Switches: High-Density, Compact Form Factor
