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.
