cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6543
Views
0
Helpful
15
Replies

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

Tomasz Tuzimek
Level 1
Level 1

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

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

View solution in original post

15 Replies 15

xthuijs
Cisco Employee
Cisco Employee

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

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

 

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

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

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

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?

 

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

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

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

>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.

 

 

 

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.

 

Todd S
Level 1
Level 1

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.

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

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: