Solved: DHCP relay/proxy on VRF interface - ASR drops DHCP packet and sends ICMP port unreachable to server. - Page 2

Tomasz Tuzimek · ‎10-10-2014

I have problem with DHCP relay on GigabitEthernet0/1/0/0.1200.

Access interface was assigned to vrf=LAN and configured DHCP relay.

I also tried with DHCP proxy the result was the same.

When DHCP clients try to get address the DHCP Offer from server is dropped by ASR2_PE . The ASR2_PE drops the OFFER packet from MPLS and sends ICMP port unreachable over MPLS network to DHCP server(see attachement).

I don't know why!?

Is this a bug?

All th ASRs run on the 4.2.1 version.

I also tested DHCP client directly connected to ASR0_PE and it got IP address but in this case DHCP offer didn't have MPLS header (local routing on ASR0_PE)

Topology:

DHCP Server(10.100.102.1)-------IP-----(10.100.102.2)ASR0_PE(10.100.1.10)------MPLS-------(10.100.1.9)ASR1_P(10.100.1.6)------MPLS--------(10.100.1.5)ASR2_PE(Gig0/1/0/0.1200)---IP-----(DHCP clients)

Related config:

Labels is assigned per VRF

RP/0/RSP1/CPU0:ASR2_PE#sh bgp vpnv4 unicast labels

...

omitted

...

*> 10.19.1.0/24       0.0.0.0         nolabel         16191 (second label in attachemnt)
*> 10.19.2.0/24       0.0.0.0         nolabel         16191
*> 10.19.3.0/24       0.0.0.0         nolabel         16191
*> 10.19.4.0/24       0.0.0.0         nolabel         16191
*> 10.19.5.0/24       0.0.0.0         nolabel         16191
*> 10.19.6.0/24       0.0.0.0         nolabel         16191

...

____________________________________

dhcp ipv4

profile DHCP_profil-LAN relay

helper-address vrf LAN 10.100.102.1

!

interface GigabitEthernet0/1/0/0.1200 relay profile DHCP_profil-LAN

interface GigabitEthernet0/1/0/0.1200

description vrf=LAN

vrf LAN

ipv4 address 10.119.1.1 255.255.255.0

ipv4 address 10.19.1.1 255.255.255.0 secondary

...

ipv4 address 10.19.8.1 255.255.255.0 secondary

encapsulation dot1q 1200

Statistics:

RP/0/RSP1/CPU0:ASR2_PE#sh dhcp vrf UMT_LANs ipv4 relay statistics
Fri Oct 10 15:02:46.487 CEST

DHCP IPv4 Relay Statistics for VRF UMT_LANs:

     TYPE         |    RECEIVE    |    TRANSMIT   |     DROP      |
-------------------------------------------------------------------
DISCOVER         |        21424 |        21424 |            0 |
OFFER            |            0 |            0 |            0 |
REQUEST          |        24432 |        24432 |            0 |
DECLINE          |         6964 |         6964 |            0 |
ACK              |            0 |            0 |            0 |
NAK              |            0 |            0 |            0 |
RELEASE          |          239 |          239 |            0 |
INFORM           |         9459 |         9459 |            0 |
LEASEQUERY       |            0 |            0 |            0 |
LEASEUNASSIGNED |            0 |            0 |            0 |
LEASEUNKNOWN     |            0 |            0 |            0 |
LEASEACTIVE      |            0 |            0 |            0 |
BOOTP-REQUEST    |            0 |            0 |            0 |
BOOTP-REPLY      |            0 |            0 |            0 |
BOOTP-INVALID    |           49 |            0 |           49 |

RP/0/RSP1/CPU0:ASR2_PE#

xthuijs · ‎11-14-2014

Tomasz,

correct, selection on mac (or client ID whatever) the vrf/option82 info just helps in picking the right pool, but it doesnt pertain to the issue you were dealing with.

The issue is that the dhcp process doesnt know how to get to the client/access side from the receiving LC, that is what the problem is.

ICMP pings to the giaddr work because ICMP has that knowledge and terminates locally on that receiving LC.

for relay you will want the user/access interface in the same vrf as the dhcp server ideally, for proxy it can be different. But either way the giAddr needs to be accessible from the dhcp server because that is where the dhcp server will send his responses to.

That means that the receiving LC needs to have that forwarding knowledge. And that might mean to either pull the vrf info on that LC (if you run SVD), or provide the interface address with a loopback in that receiving vrf (if different then the access interface) to make sure the routing is closed.

xander