03-18-2011 03:05 AM - edited 03-04-2019 11:47 AM
Hi!
I have a data center with virtual desktops and other shared infrastructure serving remote sites, some of which are connected to the data center with GRE over IPsec.
IP address management including DHCP is centralized in my architecture, but I simply cannot figure out how to relay DHCP requests through GRE over IPsec to my DHCP server cluster. I am working with Cisco 800 series VPN peers, and the VPNs are terminated either on a 1841 or a Juniper SRX. Everything else is just fine and dandy, but DHCP is not forwarded across the GRE tunnel.
As a workaround I am forced to use local DHCP pools on the VPN peers, which is extra work from a management point of view, and also precludes static IP address assignment where a local DHCP pool is in a VRF. My LAN devices are mostly thin clients, so I don't care if DHCP stops working when the WAN link fails. As such local pools have no upsides, they are only a tremendous hassle.
My config is very basic, public WAN in global routing table and WAN + GRE tunnel in a VRF. NAT is not used. Here are the DHCP-related configs I have tried:
In every case, I can see the UDP broadcasts hit the LAN gateway, but relayed packets never arrive at the other GRE tunnel endpoint let alone the DHCP server. Can anyone help?
Solved! Go to Solution.
03-27-2011 07:33 AM
Hello Tuukka,
Thank you very much for the info!
Let's make an experiment to see what is really going on. Try to run the following debugs:
debug ip dhcp server packet
debug ip dhcp server events
debug ip packet 199
where the ACL 199 is as follows:
access-list 199 permit udp any eq bootpc any eq bootps
access-list 199 permit udp any eq bootps any eq bootpc
This should help us to see whether the DHCP Relay Agent actually kicks in, how does it repackage the DHCP message, and most importantly, where does it send it. The one thing I am wondering is whether the IOS resolves your IP helper address in the VRF PRIVATE namespace or in the global routing table. I would be then very interested in seeing the debug outputs.
By the way, try entering the following two commands into your configuration, just to be on the safe side:
service dhcp
ip dhcp use vrf connected
Best regards,
Peter
03-26-2011 04:02 AM
Hello Tuukka,
Sorry for replying lately.
Using a DHCP Relay over a GRE/IPsec tunnel should not be different in any way from any other DHCP Relay deployment. You seem to have correctly applied the ip helper-address on your LAN interface. You should not need to redefine the ip forward-protocol, nor create DHCP pools with the relay option.
Are you using the crypto profiles together with the tunnel protection ipsec command, or are you using crypto maps applied on the outgoing interface?
A few things to consider:
Can you confirm that the relayed DHCP packets are not reaching the DHCP server? Also, would it be possible to post here the configuration of the router on the remote site where the DHCP clients are located?
Thank you!
Best regards,
Peter
03-27-2011 06:12 AM
Hi Peter, thanks for the reply!
I am indeed using crypto profiles with tunnel protection ipsec on the tunnel interface. The DHCP server is reachable, a pool for the LAN exists, but the DHCP server logs do not contain any messages from the LAN.
The remote router is a Cisco 887VDSL2 with C880DATA-UNIVERSALK9-M, Version 15.0(1)M4. Here's the relevant config with just the ip helper-address set:
ip vrf PRIVATE rd 1:1 crypto isakmp policy 1 encr aes 256 authentication pre-share group 5 crypto isakmp key XXX address XXX crypto isakmp invalid-spi-recovery crypto isakmp keepalive 10 ! ! crypto ipsec transform-set ESP_AES_256 esp-aes 256 esp-sha-hmac ! crypto ipsec profile CIPHER-AES-256 set transform-set ESP_AES_256 interface Tunnel0 ip vrf forwarding PRIVATE ip address 172.20.0.58 255.255.255.252 tunnel source Vlan100 tunnel mode ipsec ipv4 tunnel destination XXX tunnel protection ipsec profile CIPHER-AES-256 interface Vlan1 ip vrf forwarding PRIVATE ip address 10.212.11.1 255.255.255.128 ip helper-address 10.211.0.86 ip tcp adjust-mss 1350 interface Vlan100 ip address XXX ip virtual-reassembly ip route 0.0.0.0 0.0.0.0 XXX ip route vrf PRIVATE 0.0.0.0 0.0.0.0 172.20.0.57
Unicast ICMP and TCP from the LAN to the DHCP server works:
XXX#sh ip ro vrf PRIVATE Routing Table: PRIVATE Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, + - replicated route Gateway of last resort is 172.20.0.57 to network 0.0.0.0 S* 0.0.0.0/0 [1/0] via 172.20.0.57 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 10.212.11.0/25 is directly connected, Vlan1 L 10.212.11.1/32 is directly connected, Vlan1 172.20.0.0/16 is variably subnetted, 2 subnets, 2 masks C 172.20.0.56/30 is directly connected, Tunnel0 L 172.20.0.58/32 is directly connected, Tunnel0 XXX#ping vrf PRIVATE 10.211.0.86 so vl1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.211.0.86, timeout is 2 seconds: Packet sent with a source address of 10.212.11.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms XXX#telnet 10.211.0.86 domain /vrf PRIVATE /source vl1
Trying 10.211.0.86, 53 ... Open [Connection to 10.211.0.86 closed by foreign host]
XXX#
03-27-2011 07:33 AM
Hello Tuukka,
Thank you very much for the info!
Let's make an experiment to see what is really going on. Try to run the following debugs:
debug ip dhcp server packet
debug ip dhcp server events
debug ip packet 199
where the ACL 199 is as follows:
access-list 199 permit udp any eq bootpc any eq bootps
access-list 199 permit udp any eq bootps any eq bootpc
This should help us to see whether the DHCP Relay Agent actually kicks in, how does it repackage the DHCP message, and most importantly, where does it send it. The one thing I am wondering is whether the IOS resolves your IP helper address in the VRF PRIVATE namespace or in the global routing table. I would be then very interested in seeing the debug outputs.
By the way, try entering the following two commands into your configuration, just to be on the safe side:
service dhcp
ip dhcp use vrf connected
Best regards,
Peter
05-09-2011 02:02 AM
Hi Peter,
thank you for your help with this issue. This is a production circuit, but I finally managed to get a window for running the tests. Lo and behold, it started working!
The DNS server configuration or the router running-config have not been changed at all, the only difference is that I applied the commands "service dhcp" and "ip dhcp use vrf connected" to the router. I must admit that I don't understand what happened before, but the most important thing is that now we have a functioning setup.
Thanks again!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide