Glbp, helper-address and dhcpd

[dong_madsn]

Hi guys, I hope this is the right place to post, I'm a newbee in this forum.

My problem is as follows:

I have two 6504 core routers and they both have a connection to an access switch

R1     R2

|           |

|         |

  |       |

   SW

The vlan that I use is 260. The two vlan 260 interfaces on my R1 and R2 are running glbp. All this works like a charm. Now the problem is that I have a DHCP server on another LAN segment and I want this DHCP server to serve my clients (Alcatel IP Phones) connected to my SW. So I have added a helper-address to the interface that sends the request on to my DHCP server. The issue is that when these requests show up at the DHCP server, they do not have the virtual ip of the two interfaces but the physical. This results in my DHCP server is trying to send the DHCPOFFER package back to the wrong IP address, nemely the physical.

The two confs on R1 and R2:

R1

description *** VOIP ***
ip vrf forwarding voip
ip address XXX.XXX.XXX.162 255.255.255.224
ip helper-address YYY.YYY.YYY.189
no ip redirects
no ip proxy-arp
glbp 2 ip XXX.XXX.XXX..161
glbp 2 priority 105
glbp 2 preempt

R2

description *** VOIP ***
ip vrf forwarding voip
ip address XXX.XXX.XXX.163 255.255.255.224
ip helper-address YYY.YYY.YYY.189
no ip redirects
no ip proxy-arp
glbp 2 ip XXX.XXX.XXX..161
glbp 2 priority 95
glbp 2 preempt

On my CentOS 5.5 linux where the dhcpd server is installed i get the following when using tcpdump

tcpdump -lenv -s 1500 port bootps or bootpc -i eth0

11:08:07.865671 00:26:cb:31:00:00 > 00:25:90:0b:34:62, ethertype IPv4 (0x0800), length 355: (tos 0x0, ttl 254, id 60618, offset 0, flags [none], proto: UDP (17), length: 341) XXX.XXX.XXX.162 bootps > YYY.YYY.YYY.189.bootps: BOOTP/DHCP, Request from 00:80:9f:91:be:ea, length: 313, hops:1, xid:0x66dac1ae, secs:27, flags: [none]
          Gateway IP: XXX.XXX.XXX.162
          Client Ethernet Address: 00:80:9f:91:be:ea
          Vendor-rfc1048:
            DHCP:DISCOVER
            VO:58.2.255.255.255
            PR:SM+DG+BR+VO+RN+RB
            HN:"ALCATEL-iptouch-00809f91beea"
            VC:"alcatel.noe.0"

Here I can see that the Gateway IP on the incomming package is not the virtual which should be XXX.XXX.XXX.161

[cadet alain · Accepted solution]

Hi,

This is working the way it is supposed to.

A VIP( Virtual IP) is not  a real physical device so it won't ever do what you desire.

Why do you want this?

Regards.

Alain.

[dong_madsn]

Hmmm okay, well my reason for wanting the VIP to be the one that I see coming from the interface is that if, that interface (162) goes down then my DHCP server is replying to an address which is not working anymore . My idea was that if the gateway was 161 then the DHCP server would always be able to answer the request. But okay if it is working the way it is supposed to, then I'm happy :-) Thanks for posting back by the way!

[jonathanaxford]

Hi there,

I think in this example, if the .162 interface goes down, then DHCP requests would start to come from the .163 interface and tyhe DHCP server would simply start to respond to this address instead. It should all work fine,

Cheers

Jonathan

[dong_madsn]

Yes you are right, it is excatly what happens, thanks for helping understand this!