Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

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

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#

 

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

yeah the problem is with the

yeah the problem is with the software path Tomek. The LC CPU that handles the dhcp relay doesnt have that vrf knowledge, that is the crux of the issue.

configuring svd requires a reload to activate, so that dummy (sub)interface is porbably easiest to do.

regards

xander

Xander Thuijs CCIE #6775 Principal Engineer ASR9000, CRS, NCS6000 & IOS-XR
15 REPLIES
Cisco Employee

hi tomasz,the interface to

hi tomasz,

the interface to which the dhcp server is found is likely not on the same linecard and you may be running into selective vrf download issues. this means that the vrf lan is not known by that linecard receiving the dhcp offer and therefore sending an icmp unreach.

either disable selective vrf download (which is default off in XR43) or configure a dummy subinterface on the linecard that receives the offer in that vrf LAN to pull the routing info of that vrf on that LC.

for dhcp relay/proxy it is best to run 434 or 513 btw.

xander

Xander Thuijs CCIE #6775 Principal Engineer ASR9000, CRS, NCS6000 & IOS-XR
Community Member

Thanks Xanderbutremaining

Thanks Xander

 

 

Does problem concern only traffic directed to local process(in my case it is DHCP Relay)?

SVD=If LC hasn't got  VRF X on any port this LC won't download any routes from RSP for VRF X to local CEF.

but remaining traffic (not DHCP packets) from MPLS core(first LC) to vrf=LAN(second LC card) is passed successfully. Problem is only related to DHCP Relay received from MPLS core to vrf=LAN.

but I also read that core LC (with enabled MPLS. I doesn't use LDP I have pure TE) downloads all VRF routes from  RSP. Is it true?

 

Tomek

 

Cisco Employee

yeah the problem is with the

yeah the problem is with the software path Tomek. The LC CPU that handles the dhcp relay doesnt have that vrf knowledge, that is the crux of the issue.

configuring svd requires a reload to activate, so that dummy (sub)interface is porbably easiest to do.

regards

xander

Xander Thuijs CCIE #6775 Principal Engineer ASR9000, CRS, NCS6000 & IOS-XR
Community Member

but I have only one A9K-AIP

but I have only one A9K-AIP-LIC-B license(edge LC) so when I will create dummy subinterface on core LC assigned to vrf=LAN I will get license error

Am I right?

so

I will have to disable SVD and reload all ASR9010.

 

Thanks for all

Cisco Employee

hi tomasz, correct that dummy

hi tomasz, correct that dummy interface in the vrf will ask for a license.

it could b ea temporary workaround until you can reload the device with the svd disabled.

also consider the 434/513 potentially. then you could combine that "reload" with that upgrade, just a thought.

the dummy interface in vrf is a good way to make this work, we can ignore the lic warning for now, until you able to disable SVD/reload or upgrade.

cheers!

xander

Xander Thuijs CCIE #6775 Principal Engineer ASR9000, CRS, NCS6000 & IOS-XR
Community Member

I setselective-vrf-download

I set

selective-vrf-download
 disable


and then reload ASR9010

but DHCP relay still doesn't work.

I have also other ASRs the same config and DHCP Relay is working

I don't know where is the problem.

How can I check routes on CPU LC?

 

Cisco Employee

hmm that is not expected

hmm that is not expected Tomasz :)

I would like to see a single (if possible) transaction with debugs

dhcp ipv4 pack/ev/er

dhcp relay err/pack/ev

if you can grab that from a single transaction that would be helpful for me to assess why this didn't go through.

Do you have a tac case for this open?

Also remember that 421 is not the best release to run dhcp on to be honest (420 had a rewrite).

regards

xander

Xander Thuijs CCIE #6775 Principal Engineer ASR9000, CRS, NCS6000 & IOS-XR
Community Member

I changed DHCP server to 10

I enabled :
dhcpd relay all flag is ON
dhcpd relay errors flag is ON
dhcpd relay events flag is ON
dhcpd relay internals flag is ON
dhcpd all flag is ON
dhcpd errors flag is ON
dhcpd events flag is ON
dhcpd packet flag is ON

 

 

I changed DHCP server to 10.100.102.4.

Do you have a tac case for this open?

No

Cisco Employee

thanks this helps.

thanks this helps.

I see the request generated, and enqueued, I am suspecting either one of the 2 issues because there is no response coming back at all.

dhcp server not reachable in vrf

dhcp server not able to reach the address

10.119.1.1

which is the giaddr that we are sending from.

what does it look like on the dhcp server? are they receiving the request and responding back to 10.119.1.1 and is that dhcp server able to reach that addr?

regards

xander

Xander Thuijs CCIE #6775 Principal Engineer ASR9000, CRS, NCS6000 & IOS-XR
Community Member

>dhcp server not reachable in

>dhcp server not reachable in vrf

>dhcp server not able to reach the address

communication between ASR(relay agent) and DHCP server is bidirectional:

RP/0/RSP1/CPU0:G126#ping vrf LAN 10.100.102.4 source 10.119.1.1
Wed Oct 29 22:14:58.100 CET
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.100.102.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
RP/0/RSP1/CPU0:G126#

 

>which is the giaddr that we are sending from.

it is primary IP address access port on ASR:

interface GigabitEthernet0/1/0/0.1200
 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.2.1 255.255.255.0 secondary
 ipv4 address 10.19.3.1 255.255.255.0 secondary
 ipv4 address 10.19.4.1 255.255.255.0 secondary
 ipv4 address 10.19.5.1 255.255.255.0 secondary
 ipv4 address 10.19.6.1 255.255.255.0 secondary
 ipv4 address 10.19.7.1 255.255.255.0 secondary
 ipv4 address 10.19.8.1 255.255.255.0 secondary
 ipv4 address 10.19.9.1 255.255.255.0 secondary
 ipv4 address 10.19.10.1 255.255.255.0 secondary
 ipv4 address 10.19.11.1 255.255.255.248 secondary
 ipv4 address 10.119.2.1 255.255.255.0 secondary
 ipv4 address 10.119.3.1 255.255.255.0 secondary
 ipv4 address 10.119.4.1 255.255.255.0 secondary
 ipv4 address 10.119.5.1 255.255.255.0 secondary
 ipv4 address 10.119.6.1 255.255.255.0 secondary
 ipv4 address 10.119.7.1 255.255.255.0 secondary
 ipv4 address 10.119.8.1 255.255.255.0 secondary
 ipv4 address 10.119.9.1 255.255.255.0 secondary
 ipv4 address 10.119.10.1 255.255.255.0 secondary
 ipv4 address 10.119.11.1 255.255.255.192 secondary
 ipv4 address 10.119.12.1 255.255.255.0 secondary
 ipv4 address 10.119.18.1 255.255.255.0 secondary
 encapsulation dot1q 1200
!

>what does it look like on the dhcp server? are they receiving the request >and responding back to 10.119.1.1 and is that dhcp server able to reach that >addr?

Attachments include  old DHCP server which had IP=10.100.102.1. Now DHCP server has got 10.100.102.4. You can see that inner label is the same for DISCOVERY and ICMP unreachable so OFFER was received to proper VRF=LAN on ASR(DHCP relay).

 

how can you see  ASR sends  DHCP discovery and then ICMP port unreachable including DHCP offer so ASR receives DHCP OFFER packets.

I have only ran TX mirror on MPLS interface so wireshark show you unidirectional packets from DHCP Relay(ASR) to DHCP server

inner label= 16191= VRF LAN

DISCOVERY and OFFER(in ICMP port unreachable packet) have got the same TRANSACTION ID so both packets are from the same DHCP session.

I try to upgrade ASR to version 5.

 

 

 

Community Member

DHCP pool on server is

DHCP pool on server is selected by MAC address.

All DHCP pools/clients and server  belong to the same vrf.

Only MPLS core is in global vrf but it is natural. 

I don't know why ASR(dhcp relay) replies to echo ICMP from DHCP server but it drops DHCP OFFER/ACK packets from the same server? ICMP echo and DHCP packet are directed to CPU LC (both packets are processed by the same engine =control plane). One(echo ICMP) of them works but second(DHCP OFFER/ACK) fails.

 

Community Member

Your DHCP Server needs to

Your DHCP Server needs to support option 82. If the DHCP Server resides in a different VRF from your client systems, you have to enable the option 82 parameter on the Cisco Router and your DHCP server needs to support it as well. When the traffic comes back through the Server VRF. The Server VRF needs to know what the DHCP request came from to properly deliver the request.

Cisco Employee

that would definitely help in

that would definitely help in the right pool selection, but would not result in an icmp unreach.

for XR DHCP the server can be in a different vrf then the subscriber/user, when using proxy.

The following table applies here:

true: means this will work, false this model will not work.

0_1_2 means:

0 = global routing table,

1 = a vrf

2 = a different vrf then "1".

First col is access interface, second is subscriber interface, 3rd is the where the helper resides.

    true,  /* DHCPD_VRF_MATRIX_0_0_0 */
    true,  /* DHCPD_VRF_MATRIX_0_0_1 */
    true,  /* DHCPD_VRF_MATRIX_0_1_0 */
    true,  /* DHCPD_VRF_MATRIX_0_1_1 */
    false, /* DHCPD_VRF_MATRIX_1_0_0 */
    false, /* DHCPD_VRF_MATRIX_1_0_1 */
    true,  /* DHCPD_VRF_MATRIX_1_1_0 */
    true,  /* DHCPD_VRF_MATRIX_1_1_1 or 1_1_2 */

What you can glean from this table is that if the access interface is in a vrf, then the subscriber cannot be pushed into global, regardless where the helper is.

"vrf select" just helps the dhcp server to pick the right pool to choose an address from and it will always respond back to the helper/giaddr set for, so that giaddr NEEDS to be accessible by the dhcp server regardless of which vrf it is. (Otherwise, indeed as you state, it will result in an icmp unreach from the a9k back to the dhcp server).

cheers!

xander

Xander Thuijs CCIE #6775 Principal Engineer ASR9000, CRS, NCS6000 & IOS-XR
Community Member

DHCP pool on server is

DHCP pool on server is selected by MAC address.

All DHCP pools/clients and server  belong to the same vrf.

DHCP traffic(DHCP server- user) doesn't pass between two different VRFs.

Only MPLS core is in global vrf but it is natural. 

I don't know why ASR(dhcp relay) replies to echo ICMP from DHCP server but it drops DHCP OFFER/ACK packets from the same server? ICMP echo and DHCP packet are directed to CPU LC (both packets are processed by the same engine =control plane). One(echo ICMP) of them works but second(DHCP OFFER/ACK) fails.

Cisco Employee

Tomasz,correct, selection on

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

Xander Thuijs CCIE #6775 Principal Engineer ASR9000, CRS, NCS6000 & IOS-XR
881
Views
0
Helpful
15
Replies
CreatePlease to create content