DHCP helper config for VRF with DHCP server on the Global VRF

[Difan_Zhao]

Hi experts,

I am testing this in the lab. I have a Cisco 9500 switch configured with the DHCP helper of 10.0.1.1 (which is a Cisco 2851 router) on its VLAN 2 SVI and it is in the VRF test. Its VLAN 1 interface is in the global and it has IP 10.0.1.2 for reaching the DHCP server. Here is my config on the switch

interface Vlan2
 ip vrf forwarding test
 ip address 10.0.2.2 255.255.255.0
 ip helper-address global 10.0.1.1
end
!
interface Vlan1
 ip address 10.0.1.2 255.255.255.0
end
!
no ip dhcp snooping information option

Here is the config on the C2851 serving as the DHCP server

ip dhcp excluded-address 10.0.2.1 10.0.2.10
ip dhcp pool test
 network 10.0.2.0 255.255.255.0
 default-router 10.0.2.2

With the debug like "debug IP dhcp server events and packets", I see that the router is assigning addresses but maybe the switch is not getting it and not forwarding back to the client..

--- Cisco 9500 ---
*Sep 22 20:42:59.193: Option 82 not present
*Sep 22 20:42:59.193: DHCPD: Reload workspace interface Vlan2 tableid 2.
*Sep 22 20:42:59.193: DHCPD: tableid for 10.0.2.2 on Vlan2 is 2
*Sep 22 20:42:59.193: DHCPD: client's VPN is test.
*Sep 22 20:42:59.193: Option 82 not present
*Sep 22 20:42:59.193: DHCPD: Sending notification of DISCOVER:
*Sep 22 20:42:59.193:   DHCPD: htype 1 chaddr 1880.9024.d862
*Sep 22 20:42:59.193:   DHCPD: table id 2 = vrf test
*Sep 22 20:42:59.193:   DHCPD: interface = Vlan2
*Sep 22 20:42:59.193:   DHCPD: class id 636973636f706e70
*Sep 22 20:42:59.193: DHCPD: FSM state change INVALID
Switch#
*Sep 22 20:42:59.193: DHCPD: Workspace state changed from INIT to INVALID
*Sep 22 20:42:59.193: DHCPD: Looking up binding using address 10.0.2.2
*Sep 22 20:42:59.193: DHCPD: setting giaddr to 10.0.2.2.
*Sep 22 20:42:59.193: DHCPD: BOOTREQUEST from 0063.6973.636f.2d31.3838.302e.3930.3234.2e64.3836.322d.4769.302f.32 forwarded to 10.0.1.1.


--- Cisco 2851 DHCP server ---
*Sep 22 21:11:03.536: DHCPD: client's VPN is .
*Sep 22 21:11:03.536: DHCPD: No option 125
*Sep 22 21:11:03.536: DHCPD: Sending notification of DISCOVER:
*Sep 22 21:11:03.536:   DHCPD: htype 1 chaddr 1880.9024.d862
*Sep 22 21:11:03.536:   DHCPD: remote id 020a00000a00010101000000
*Sep 22 21:11:03.536:   DHCPD: circuit id 00000000
*Sep 22 21:11:03.536: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d31.3838.302e.3930.3234.2e64.3836.322d.4769.302f.32 through relay 10.0.2.2.
*Sep 22 21:11:03.536: DHCPD: Seeing if there is an internally specified pool class:
*Sep 22 21:11:03.536:   DHCPD: htype 1 chaddr 1880.9024.d862
*Sep 22 21:11:03.536:   DHCPD: remote id 020a00000a00010101000000
*Sep 22 21:11:03.536:   DHCPD: circuit id 00000000
*Sep 22 21:11:03.536: DHCPD: Found previous server binding
*Sep 22 21:11:03.536: DHCPD: Sending DHCPOFFER to client 0063.6973.636f.2d31.3838.302e.3930.3234.2e64.3836.322d.4769.302f.32 (10.0.2.12).DHCPD: Setting only requested parameters
*Sep 22 21:11:03.536: DHCPD: no option 125
*Sep 22 21:11:03.536: DHCPD: unicasting BOOTREPLY for client 1880.9024.d862 to relay 10.0.2.2.

 Is this configuration supported? If so, where did I do wrong? Thanks!

[paul driver]

Hello
This seems to suugest missing route table entries and route leaking between the vrf test and GRT.(gloabl route table)
Based on your OP addressing try the following:
switch
ip route 0.0.0.0 0.0.0.0 Vlan1 10.0.1.1
ip route vrf test 0.0.0.0 0.0.0.0 Vlan1 10.0.1.1 global
ip route 10.0.2.0 255.255.255.0 Vlan2

rtr
ip route 10.0.2.0 255.255.255.0 <interface> 10.0.1.2

[Difan_Zhao]

Hey Paul thanks for the reply! sorry I was away for the past few days...

Your solution worked! However, is there a way to eliminate all these route leaking config...? Can I specify the source interface for the relay message? I read about option 82 and I am wondering if that will work. I am building a proper Windows DHCP server to properly test it. Any advice is welcome!

[paul driver]

Hello
So you need to tell the rtr how reach the hosts in its vrf and as the server resides in the GRT and then you need to tell vrf how to reach the dhcp server - hence the route leaking - instead of default route in the vrf table you could try a more specific route to the dhcp server instead or even have the windows server dual connected so one of its nics resides in the vrf -then create a dhcp scope for that vrf?

[Difan_Zhao]

Sorry, Paul for taking so long to respond... I finally tried this in the lab and I am able to achieve it without leaking routes. HEre is my config

interface Vlan2
 ip vrf forwarding test
 ip dhcp relay source-interface Vlan1
 ip address 10.0.2.2 255.255.255.0
 ip helper-address global 10.0.1.254
end

I did two things to get it working

1. upgrade the switch from 16.4 to 17.3.4

2. Used a Windows 2019 server as the DHCP server

Essentially, the "source-interface" config enabled option 82 to be inserted. The DHCP server will then use that option to assign IP, instead of using the GIADDR filed, which remains as the VLAN 1 IP. It works fine with two caveats,

1. The Switch will broadcast the DHCP offer and DHCP ACK for some reason to 255.255.255.255. I will upload a packet capture

2. "ip dhcp compatibility suboption server-override standard" config doesn't work... I am hoping this command will even change the GIADDR to the vlan 2 IP. This is trivial problem.

I have opened a tac case and I hope they can answer why #1 is happening.. 

[Difan_Zhao]

err I can't upload pcap file apparently... here is a screenshot instead