Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
9111
Views
0
Helpful
10
Replies

Clients not getting DHCP in VRF

John Capobianco
Level 1
Level 1

‎03-05-2014 08:35 AM - edited ‎03-07-2019 06:32 PM

Good morning -

We have devices in the global routing table (not in a VRF) getting DHCP addresses without issue. The SVI is configured as such:

interface Vlan2301

description BLUE

ip address 172.19.68.1 255.255.255.0

ip helper-address 10.4.16.222

interface Vlan2512
description RED
vrf forwarding RED
ip address 10.217.5.1 255.255.255.0
ip helper-address 10.4.16.222


Clients in BLUE are getting DHCP but clients in RED are not. If I statically assign an address I have connectivity and can reach the DHCP server (which is also DNS server; with a static IP in VLAN 2512 I can do name resolutions for example).

I am at a bit of a loss. Is there anything special I need to do for VRF IP HELPER-ADDRESS configuration? A capture on my firewall interface shows the DHCP server is trying to reply - it is like the helper-address is not forwarding the dhcp reply (or is not getting it)

11:11:52.915180 IP (tos 0x0, ttl 254, id 17478, offset 0, flags [none], proto UDP (17), length 337)

    10.217.5.1.67 > 10.4.16.222.67: BOOTP/DHCP, Request from xx, length 309, hops 1, xid 0xb53a220c, Flags [none]

          Gateway-IP 10.217.5.1

          Client-Ethernet-Address xx [|bootp]

11:11:52.918761 IP (tos 0x0, ttl 124, id 28096, offset 0, flags [none], proto UDP (17), length 344)

    10.4.16.222.67 > 10.217.5.1.67: BOOTP/DHCP, Reply, length 316, xid 0xb53a220c, Flags [none]

          Your-IP 10.217.5.12

          Server-IP 10.4.16.222

          Gateway-IP 10.217.5.1

          Client-Ethernet-Address xx [|bootp]

Any ideas?

1 person had this problem
Labels:
0 Helpful
10 Replies 10

John Capobianco
Level 1
Level 1

‎03-05-2014 11:47 AM

I have also done a wireshark capture of the traffic between the Core and Distribution layer (where the SVI / IP HELPER lives)

Helper (10.217.5.1) sends DHCP Discover to the DHCP server (10.4.16.222)
DHCP Server sends DHCP Offer to the Helper (10.217.5.1)

This is the only DHCP traffic I see - it's like the DHCP Offer is not forwarded to the client from the helper?

Is this related to the IP HELPER config in the VRF context?

Any ideas would be appreciated. I am going to capture between the distribution and access next and see if this DHCP offer is being sent to the clients or not.

0 Helpful

John Capobianco
Level 1
Level 1
In response to John Capobianco

‎03-10-2014 09:47 AM

We appear to have hit a L3 MEC bug - when I shut down the link from my 4500 on the switch that is the stand-by switch DHCP works fine to the client!

When I have both links up in my etherchannel DHCP does not work; when I shut a link it works fine. A local DHCP pool on the 4500 works; if we put the pool on the 6513 directly it still fails unless I shut one of my etherchannel links.

"Something" in the L3 port-channel MEC does not work for the VRF only. My global routing table is still getting DHCP! Very odd. Waiting for TAC to get back to me.

0 Helpful

John Capobianco
Level 1
Level 1
In response to John Capobianco

‎03-11-2014 06:31 AM

Good morning -

I have a pair of 6513 in a VS40 (VSS quad sup) connected via L3 MEC to a VSS pair of 4500X. Active to Active and Standby to Standby connected in a L3 MEC port-channel that is also a vnet trunk:

(Core)
interface Port-channel5
description Distribution Uplink
no switchport
vnet trunk
ip dhcp snooping limit rate 100
ip address 172.20.68.1 255.255.255.252
ip ospf message-digest-key 1 md5 XXX
spanning-tree guard root

(4500 Distribution)
interface Port-channel1
description Core Uplink
vnet trunk
ip arp inspection trust
ip address 172.20.68.2 255.255.255.252
ip ospf message-digest-key 1 md5 XXX

The interfaces are all using LACP mode Active inside the channels

On the 4500 we have a global routing table and a vrf. Both have helper addresses pointing to the DHCP server which is extranet service behind the 6513 Core.

interface Vlan2301
description Global Routing Table
ip address 172.19.68.1 255.255.255.0
ip helper-address 10.4.16.222

interface Vlan2512
description VRF
vrf forwarding RED
ip address 10.217.5.1 255.255.255.0
ip helper-address 10.4.16.222

DHCP for the Global Routing Table subnet works. DHCP for the VRF does not.

What is interesting is if we shut down the link that is connected to the standby 4500 (Te2/1/1) DHCP starts to work for the VRF.

Using <debug ip dhcp server packet detail> at the 4500 here is what I am seeing.

When both links are up and DHCP is failing for the VRF:

Mar 10 20:02:02.419: DHCPD: BOOTREQUEST from 0100.1a6b.3a56.13 forwarded to 10.4.16.222.

Mar 10 20:02:10.473: DHCPD: Reload workspace interface Vlan2512 tableid 3.

Mar 10 20:02:10.473: DHCPD: tableid for 10.217.5.1 on Vlan2512 is 3

Mar 10 20:02:10.474: DHCPD: client's VPN is RED.

Mar 10 20:02:10.474: DHCPD: using received relay info.

When I shut the Te2/1/1 link down in the L3 MEC at the 4500 DHCP starts to work for the VRF RED:

Mar 10 20:04:41.354: DHCPD: BOOTREQUEST from 0100.1a6b.3a56.13 forwarded to 10.4.16.222.

Mar 10 20:04:41.369: DHCPD: Reload workspace interface Port-channel1.2002 tableid 3.

Mar 10 20:04:41.369: DHCPD: tableid for 172.20.68.2 on Port-channel1.2002 is 3

Mar 10 20:04:41.369: DHCPD: client's VPN is .

Mar 10 20:04:41.369: DHCPD: forwarding BOOTREPLY to client 001a.6b3a.5613.

Mar 10 20:04:41.369: DHCPD: no option 125

Mar 10 20:04:41.369: DHCPD: broadcasting BOOTREPLY to client 001a.6b3a.5613.

Mar 10 20:04:41.369: DHCPD: no option 125

Mar 10 20:04:44.808: DHCPD: Reload workspace interface Vlan2512 tableid 3.

Mar 10 20:04:44.808: DHCPD: tableid for 10.217.5.1 on Vlan2512 is 3

Mar 10 20:04:44.808: DHCPD: client's VPN is RED.

It is like there is a bug that is treating the L3 MEC as a L2 MEC when both links are present; or the VNET trunk is not being processed correctly.

Has anyone else used a L3 MEC with a VRF and a DHCP helper with success? Is this a bug?

03.05.01.E is the code we are running on the 4500X-32(SPF+)

This is also with TAC but I thought I would share with the community in case anyone else has a similar environment or if Cisco experts want to comment.

0 Helpful

rhub
Level 1
Level 1
In response to John Capobianco

‎07-03-2014 12:13 PM

Hi all,

I have the same issue with 4500X-32SFP. DHCP-Clients are in dedicated VRF, the DHCP-Server is in global. DHCP-Clients don't get an

IP-Address from the server. If configuring a fixed IP-Address on the clients, everything works fine 

0 Helpful

Vasilii Mikhailovskii
Level 7
Level 7

‎03-05-2014 11:57 AM

Hello, John.

Does you DHCP server have a correct route to VL2512?

Can you ping DHCP server from VRF RED: "ping vrf RED 10.4.16.222 so vl2512"?

Do you have any L2 security feature enabled (on distribution or access) like DHCP snooping of IP verify?

0 Helpful

John Capobianco
Level 1
Level 1
In response to Vasilii Mikhailovskii

‎03-05-2014 12:12 PM

Thank you - when I statically assign a client I can do nslookups, for example, and AD credentials, etc. All from the same box hosting DHCP. I am using this as a sign that routing is in place. We do have DHCP snooping, ip verify, and DAI configured at access and distribution - but I am not getting any snooping errors.

Can I selectively turn off dhcp snooping / DAI on just this VLAN as a test?

0 Helpful

Vasilii Mikhailovskii
Level 7
Level 7
In response to John Capobianco

‎03-05-2014 10:05 PM

Hello, John.

>Can I selectively turn off dhcp snooping / DAI on just this VLAN as a test?

Sure, but ask your security team first

0 Helpful

John Capobianco
Level 1
Level 1
In response to Vasilii Mikhailovskii

‎03-06-2014 05:14 AM

I disabled both on this VLAN with no affect

I have enabled debug ip dhcp server packets at the distribution layer

Mar  6 08:12:26.527: DHCPD: Reload workspace interface Vlan2512 tableid 3.

Mar  6 08:12:26.527: DHCPD: tableid for 10.217.5.1 on Vlan2512 is 3

Mar  6 08:12:26.527: DHCPD: client's VPN is ISSUP.

Mar  6 08:12:26.527: DHCPD: using received relay info.

Mar  6 08:12:26.527: DHCPD: Looking up binding using address 10.217.5.1

Mar  6 08:12:26.527: DHCPD: setting giaddr to 10.217.5.1.

Mar  6 08:12:26.528: DHCPD: BOOTREQUEST from 0100.1a6b.3a56.13 forwarded to 10.4.16.222.

Based on my captures we see 10.4.16.222 send back the DHCPOFFER but that is where this ends

Any other ideas?

0 Helpful

Vasilii Mikhailovskii
Level 7
Level 7
In response to John Capobianco

‎03-07-2014 07:57 AM

Hello, John.

Do you have any security device (including ACL) or PBR or IPSec between your DHCP server and VRF enbaled interface?

Do you have any ACL (VACL) on your switches?

0 Helpful
Customers Also Viewed These Support Documents
Review Cisco Networking products for a $25 gift card