Re: HSRP and ip helper-address

ivanwood · ‎03-01-2002

I have 6 routers in Cat 6000 switches running HSRP. I want to use ip helper-address to get DHCP messages to forward out of one VLAN over to a server in another VLAN. Should I put the "ip helper-address 192.168.1.100" in that VLAN interface on all the routers, or just one of the routers?

If I put it on all the routers, won't the broadcast be sent 6 times to the destination server?

Any information you have on HSRP and ip helper-address would be greatly appreciated.

Thanks,

Ivan

vsahagian · ‎03-01-2002

Place the IP helper-address on the interfaces running HSRP. If you do not and the active router fails. The standby router will not have the ip helper-address and will not forward new DHCP requests. If you have six routers in an HSRP group, the same applies. If five routers fail and the sixth does not have ip helper, the DHCP requests will not forward.

ivanwood · ‎03-01-2002

I see the failover reason to have the ip helper-address on the interface for every router running HSRP, but is there a disadvantage for the number of packets that will be created on the network, and the confusion that may result on the DHCP(Win2K) server?

vsahagian · ‎03-01-2002

The client DHCP requests will only forward through the active router interface. The other router interfaces will be in standby.

ivanwood · ‎03-01-2002

HSRP allows multiple routers to pretend to be one IP address (a shared ip address) to the routing world. The actual IP address of the router (which is required even if you are running HSRP) is always active on a Layer 2 and Layer 3 level and should react to any broadcast on that subnet based on the IOS configuration on the router.

Does anyone currently use ip helper-address in an HSRP environment and see any problems that have come about because of the multiple routers?

Thank you for the help,

Ivan

jessedavis · ‎03-09-2002

We currently use HSRP across 4 MSFC's in dual 6509's.

We use HSRP to balance the ARP handling across the two routers in each switch. IP-helper addresses are enabled on all interfaces as well. The active routing interface is controlled by the active HSRP virtual router. ARP handling duties are HSRP responsibility while the actual packet routing is done by the interface attached to that HSRP intstance. We have no problems across the multiple routers and seamless transition from client point of view in failure scenarios.

cheers!

Ajay Chakravarthy Netti · ‎01-06-2015

See the below example you understand why helper address should be given on all routers.Actually if we give on all routers,They would be no duplicate packets created,Otherwise request would from all the routers on which ip heper address is not used.

Link for Below Solution

https://blog.initialdraft.com/archives/2239/

Credit - Daniel of Network Faculty. - https://blog.initialdraft.com

Think of this exam situation: You have a “client” (R1) behind two routers where you have to put HSRP (R2 and R3), and this client is going to ask an IP address via HSRP from a server on another network (R4). You may be happy because you finally got an easy task. But nothing comes easy in the CCIE exam, later in the task you are asked to avoid any duplicate/redundant request to the DHCP server. And now you got yourself into trouble.

When you have a helper address configured on the HSRP interfaces on the same broadcast domain, both devices are going to forward the DHCP request to the server no matter what device has the active HSRP state. If you think about it, there is nothing in the configuration that ties the HSRP state to the helper-address.

Lets see this on a typical configuration.

R2

interface FastEthernet0/0
 ip address 10.0.123.2 255.255.255.0
 ip helper-address 10.0.234.4
 ip ospf 1 area 0
 duplex auto
 speed auto
 standby 1 ip 10.0.123.254
 standby 1 preempt

R3

interface FastEthernet0/0
 ip address 10.0.123.3 255.255.255.0
 ip helper-address 10.0.234.4
 ip ospf 1 area 0
 duplex auto
 speed auto
 standby 1 ip 10.0.123.254
 standby 1 priority 90
 standby 1 preempt

R4

ip dhcp excluded-address 10.0.123.0 10.0.123.50
ip dhcp pool TEST
   network 10.0.123.0 255.255.255.0
   default-router 10.0.123.254

I turned on debugging for dhcp server packets and events on R4 to have as much information as possible from the situation and configured R1 to ask for the IP via DHCP (ip address DHCP):

*Mar  1 00:24:45.347: DHCPD: Adding binding to radix tree (10.0.123.52)
*Mar  1 00:24:45.347: DHCPD: Adding binding to hash tree
*Mar  1 00:24:45.347: DHCPD: assigned IP address 10.0.123.52 to client
0063.6973.636f.2d63.3230.302e.3133.6463.2e30.3030.302d.4661.302f.30.
*Mar  1 00:24:45.351: DHCPD: Sending DHCPOFFER to client
0063.6973.636f.2d63.3230.302e.3133.6463.2e30.3030.302d.4661.302f.30 (10.0.123.52).
*Mar  1 00:24:45.351: DHCPD: unicasting BOOTREPLY for client c200.13dc.0000 to relay 10.0.123.3.
*Mar  1 00:24:45.355: DHCPD: Sending notification of DISCOVER:
*Mar  1 00:24:45.355:   DHCPD: htype 1 chaddr c200.13dc.0000
*Mar  1 00:24:45.355:   DHCPD: remote id 020a00000a00ea0400000000
*Mar  1 00:24:45.355:   DHCPD: circuit id 00000000
*Mar  1 00:24:45.355: DHCPD: DHCPDISCOVER received from client
0063.6973.636f.2d63.3230.302e.3133.6463.2e30.3030.302d.4661.302f.30 through relay 10.0.123.2.
*Mar  1 00:24:45.359: DHCPD: Seeing if there is an internally specified pool class:
R4#
*Mar  1 00:24:45.359:   DHCPD: htype 1 chaddr c200.13dc.0000
*Mar  1 00:24:45.359:   DHCPD: remote id 020a00000a00ea0400000000
*Mar  1 00:24:45.359:   DHCPD: circuit id 00000000
*Mar  1 00:24:45.359: DHCPD: Sending DHCPOFFER to client
0063.6973.636f.2d63.3230.302e.3133.6463.2e30.3030.302d.4661.302f.30 (10.0.123.52).
*Mar  1 00:24:45.363: DHCPD: unicasting BOOTREPLY for client c200.13dc.0000 to relay 10.0.123.2.
*Mar  1 00:24:45.527: DHCPD: DHCPREQUEST received from client
0063.6973.636f.2d63.3230.302e.3133.6463.2e30.3030.302d.4661.302f.30.
*Mar  1 00:24:45.527: DHCPD: Sending notification of ASSIGNMENT:
*Mar  1 00:24:45.527:  DHCPD: address 10.0.123.52 mask 255.255.255.0
*Mar  1 00:24:45.527:   DHCPD: htype 1 chaddr c200.13dc.0000
*Mar  1 00:24:45.531:   DHCPD: lease time remaining (secs) = 86400

As you can see we are getting duplicate request/reply for the R1 initial attempt to obtain an IP address. If you are not aware of this in the exam you just lost “easy” points, and even if you know what is happening, you may not know about a cool feature we can put in place avoid this and fulfill the requirements.

This feature (UDP Forwarding Support for IP Redundancy Virtual Router Groups) ties together the active state on the HSRP to the helper address. In other words, only the HSRP group interface with the active state forwards packets to the DHCP, the other device will not forward packets even when it has the helper address configured. In our case only if R3 becomes the active device is going to start forwarding requests to the DHCP server (R4).

The configuration is very simple, and all we have to change is this:

R2

interface FastEthernet0/0
 ip helper-address 10.0.234.4 redundancy CCIE
 standby 1 name CCIE

R3

interface FastEthernet0/0
 ip helper-address 10.0.234.4 redundancy CCIE
 standby 1 name CCIE

As you can see I configured a name for the HSRP group, and tied it with the “redundancy” option on the helper-address. You can avoid the configuration of the name by looking at the default name provided by the router with the “show standby” command and look for the “Group name”.

And now on the the DHCP server, we only see the traffic forwarded by R2 (Active HSRP state), when R1 ask for a IP.

*Mar  1 00:32:20.623: DHCPD: Adding binding to radix tree (10.0.123.53)
*Mar  1 00:32:20.623: DHCPD: Adding binding to hash tree
*Mar  1 00:32:20.627: DHCPD: assigned IP address 10.0.123.53 to client
0063.6973.636f.2d63.3230.302e.3133.6463.2e30.3030.302d.4661.302f.30.
*Mar  1 00:32:20.627: DHCPD: Sending DHCPOFFER to client
0063.6973.636f.2d63.3230.302e.3133.6463.2e30.3030.302d.4661.302f.30 (10.0.123.53).
*Mar  1 00:32:20.627: DHCPD: unicasting BOOTREPLY for client c200.13dc.0000 to relay 10.0.123.2.
*Mar  1 00:32:20.847: DHCPD: DHCPREQUEST received from client
0063.6973.636f.2d63.3230.302e.3133.6463.2e30.3030.302d.4661.302f.30.

Jeff Boyer · ‎09-23-2015

Great post Ajay. Thanks for including the name of the feature and saving me several minutes of hunting in the feature navigator. Unfortunately this falls into the "lack of feature parity" list for IOS-XE devices, so it is not available on the ISR 4k line.

Vinay Harish · ‎12-17-2015

Hi Ajay,

Thanks for the details above, I am using the same scenario or diagram which is shown above, but there is a slight change here, assumption is R1 is a host device and is directly connected to R3, both R2 and R3 are running HSRP in active/stand-by mode and have ip helper address configured, R2 and R3 are connected to each-other over a port-channel and the vlans are allowed over this.

R2 is the HSRP primary switch and R3 is configured as HSRP stand-by switch, so now my question is I see that R1 is not receiving the ip address from the DHCP server R4, can you let me know what is the problem here?