cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1448
Views
0
Helpful
7
Replies

ipv4 dhcp relay not working in 5.3.4

iglaser
Level 1
Level 1

Hello,

I am trying to get the ipv4 dhcp relay function to work on an ASR9904 using IOS-XR 5.3.4.

What I have configured is the following:

interface GigabitEthernet0/0/0/3
negotiation auto
l2transport
!
l2vpn
bridge group vlans
bridge-domain DWD-Telefon
interface GigabitEthernet0/0/0/3
!
routed interface BVI490

!

interface BVI490
description DWD-Telefonnetz
vrf dwd
ipv4 address 172.24.240.253 255.255.255.252
flow ipv4 monitor FM sampler FS ingress
!

dhcp ipv4
profile ip-phone relay
helper-address vrf dwd 141.38.43.10
helper-address vrf dwd 141.38.112.10
!
interface BVI490 relay profile ip-phone
!

Using debug dhcp ipv4, I do not see any dhcp packets, although the connected devide on gi0/0/0/3 is sending them repeatedly.

I know this should be quite esay to set up, so I think I must be missing something. Does anyone see what it is?

I have already tried to also use the giaddr, and had also configured vrf dwd relay profile ip-phone under the dchp ipv4 section, but this did not help either.

Thanks very much, and best regards,

Ilona

1 Accepted Solution

Accepted Solutions

yeah that makes sense, some phones have that voice vlan (although that generally is negotiated by an attached switch).

if you know the vlan, you'd create this EFP:

int g 0/0/0/3.100 l2trans

encap dot1q <tag>

rewrite ingress tag pop 1 sym

this way you'll strip the vlan on ingress so the bvi can handle it (and relay the dhcp) and the sym part of that cmd will slap the vlan back on in the outgoing direction.

xander

View solution in original post

7 Replies 7

Aleksandar Vidakovic
Cisco Employee
Cisco Employee

hi Ilona,

I hope you are doing well!

You should associate the l2transport interfaces (the attachment circuits in the bridge domain) with the DHCP relay profile, e.g.:

dhcp ipv4
profile ip-phone relay
helper-address vrf dwd 141.38.43.10
helper-address vrf dwd 141.38.112.10
!
interface GigabitEthernet0/0/0/0.200 relay profile ip-phone
interface GigabitEthernet0/0/0/1.200 relay profile ip-phone
!
interface GigabitEthernet0/0/0/0.200 l2transport
<blah blah>
!

BVI is not going to see the DHCP packets because they by default not routed out of the bridge domain. Please see this year's BRKSPG-2904 from Cisco Live Berlin. There was a section on BVI.

Hope this helps,

/Aleksandar

you know this should work though. since it is a broadcast it would go out of every bridge port including bvi.

what I think may go wrong in this case is that the g0/0/0/3 is probably getting tagged packets in.

the bvi doesnt understand tagging hence I think that that is where it may go wrong sicen we need to pop the tag for the vlan.

I think you'd need to configure the EFP's like this:

int g 0/0/0/3.100 l2trans

encap dot1q <>

rewrite ingress tag pop 1 sym

and you could use your original dhcp config and modify the bridge domain to use the EFP subinterface instead of a "catchall main interface".

xander

RP/0/RSP0/CPU0:A9K-BNG#debug dhcp ipv4 packet

Wed Mar  1 13:12:00.504 EDT

RP/0/RSP0/CPU0:A9K-BNG#RP/0/RSP0/CPU0:Mar  1 13:12:17.985 : dhcpd[1086]: DHCPD PACKET: TP564: L3 Packet RX from addr = 0.0.0.0, port = 68, application len 576, vrf 0x60000002 (1610612738), tbl 0xe0000011 (3758096401)

RP/0/RSP0/CPU0:Mar  1 13:12:17.985 : dhcpd[1086]: DHCPD_PACKET: pktRx id 1: ---------- IPv4 DHCPD --- dhcpd_iox_l3_conn_hlr -------

RP/0/RSP0/CPU0:Mar  1 13:12:17.985 : dhcpd[1086]: DHCPD_PACKET: pktRx id 1: VRF name (id): RED (0x60000002)

RP/0/RSP0/CPU0:Mar  1 13:12:17.985 : dhcpd[1086]: DHCPD_PACKET: pktRx id 1: L3 src: 0.0.0.0

RP/0/RSP0/CPU0:Mar  1 13:12:17.985 : dhcpd[1086]: DHCPD_PACKET: pktRx id 1: L3 dst: 255.255.255.255

RP/0/RSP0/CPU0:Mar  1 13:12:17.985 : dhcpd[1086]: DHCPD_PACKET: pktRx id 1: L3 src port: 68

RP/0/RSP0/CPU0:Mar  1 13:12:17.985 : dhcpd[1086]: DHCPD_PACKET: pktRx id 1: L3 dst port: 67

RP/0/RSP0/CPU0:Mar  1 13:12:17.985 : dhcpd[1086]: DHCPD_PACKET: pktRx id 1: metadata: L3 input Intf: BVI111

oh one more thing:

- netflow on bvi is not supported (unrelated to dhcp :)

- make sure you set the allow untrusted under the relay profile, otherwise packets incoming without a giaddr set (generally a client of course) wont get forwarded.

x

Hello Aleksandar, Xander,

thank you both very much for your replies. I have tried all of them, but it is still not working.

GI0/0/0/3 is not getting tagged packets, the ip phone is directly attached there. I have change the config to

interface GigabitEthernet0/0/0/3.490 l2transport

encapsulation untagged

though, and have put this interface into the dhcp ipv4 config section. What puzzles me at the moment is what giaddr will be inserted into the dhcp packet since the AC has no ip address....

I'm going to set this up here in the lab and see, if I can find out more.

Are there any specific additional debugs I could user other than debug dhcp ipv4 ... ?

Thanks again,

Ilona

hi ilona, the giaddr will be set to the ip address of the receiving l3 interface or you can specify it manually in the config. here is a config snippet how I set it up similar to your scenario:

xander

dhcp ipv4

profile CNR proxy

  helper-address vrf default 49.1.1.2 giaddr 172.28.15.254

  relay information option

  relay information policy replace

  relay information option remote-id testme

  relay information option allow-untrusted

!

interface BVI111 relay profile CNR

Thu Mar  2 08:30:44.391 EDT

interface GigabitEthernet0/0/0/2

description CPE-g0/1

mtu 1285

negotiation auto

transceiver permit pid all

!

interface GigabitEthernet0/0/0/2.1 l2transport

encapsulation untagged

l2vpn

bridge group VL111

  bridge-domain VL111

   !

   interface GigabitEthernet0/0/0/2.1

   !

   routed interface BVI111

  !

RP/0/RSP0/CPU0:Mar  2 08:28:07.317 : dhcpd[1086]: DHCPD PACKET: TP564: L3 Packet RX from addr = 0.0.0.0, port = 68, application len 576, vrf 0x60000002 (1610612738), tbl 0xe0000011 (3758096401)

RP/0/RSP0/CPU0:Mar  2 08:28:07.317 : dhcpd[1086]: DHCPD_PACKET: pktRx id 11: ---------- IPv4 DHCPD --- dhcpd_iox_l3_conn_hlr -------

RP/0/RSP0/CPU0:Mar  2 08:28:07.318 : dhcpd[1086]: DHCPD_PACKET: pktRx id 11: VRF name (id): RED (0x60000002)

RP/0/RSP0/CPU0:Mar  2 08:28:07.318 : dhcpd[1086]: DHCPD_PACKET: pktRx id 11: L3 src: 0.0.0.0

RP/0/RSP0/CPU0:Mar  2 08:28:07.318 : dhcpd[1086]: DHCPD_PACKET: pktRx id 11: L3 dst: 255.255.255.255

RP/0/RSP0/CPU0:Mar  2 08:28:07.318 : dhcpd[1086]: DHCPD_PACKET: pktRx id 11: L3 src port: 68

RP/0/RSP0/CPU0:Mar  2 08:28:07.318 : dhcpd[1086]: DHCPD_PACKET: pktRx id 11: L3 dst port: 67

RP/0/RSP0/CPU0:Mar  2 08:28:07.318 : dhcpd[1086]: DHCPD_PACKET: pktRx id 11: metadata: L3 input Intf: BVI111

RP/0/RSP0/CPU0:Mar  2 08:28:07.318 : dhcpd[1086]: DHCPD_PACKET: pktRx id 11: metadata: Output Intf: Null

RP/0/RSP0/CPU0:Mar  2 08:28:07.318 : dhcpd[1086]: DHCPD_PACKET: pktRx id 11: metadata: FROM: L3

RP/0/RSP0/CPU0:Mar  2 08:28:07.318 : dhcpd[1086]: DHCPD_PACKET: pktRx id 11: metadata: NETWORK_ORDER

RP/0/RSP0/CPU0:Mar  2 08:28:07.318 : dhcpd[1086]: DHCPD_PACKET: pktRx id 11: op:     BOOTREQUEST

RP/0/RSP0/CPU0:Mar  2 08:28:07.318 : dhcpd[1086]: DHCPD_PACKET: pktRx id 11: chaddr: 0006.2aaa.241b

RP/0/RSP0/CPU0:Mar  2 08:28:07.318 : dhcpd[1086]: DHCPD_PACKET: pktRx id 11: xid:    0x00001986

RP/0/RSP0/CPU0:Mar  2 08:28:07.318 : dhcpd[1086]: DHCPD_PACKET: pktRx id 11: flags:  0x8000 (broadcast)

RP/0/RSP0/CPU0:Mar  2 08:28:07.318 : dhcpd[1086]: DHCPD_PACKET: pktRx id 11: ciaddr: 0.0.0.0

RP/0/RSP0/CPU0:Mar  2 08:28:07.318 : dhcpd[1086]: DHCPD_PACKET: pktRx id 11: yiaddr: 0.0.0.0

RP/0/RSP0/CPU0:Mar  2 08:28:07.318 : dhcpd[1086]: DHCPD_PACKET: pktRx id 11: siaddr: 0.0.0.0

RP/0/RSP0/CPU0:Mar  2 08:28:07.318 : dhcpd[1086]: DHCPD_PACKET: pktRx id 11: giaddr: 0.0.0.0

RP/0/RSP0/CPU0:Mar  2 08:28:07.318 : dhcpd[1086]: DHCPD_PACKET: pktRx id 11: cookie: 0x63538263

RP/0/RSP0/CPU0:Mar  2 08:28:07.318 : dhcpd[1086]: DHCPD_PACKET: pktRx id 11: option: MESSAGE_TYPE: DISCOVER

Hi Xander,

again, many thanks. In the lab, it worked immediatly with my original config. The only difference here is that the phone indeed is sending tagged packets...

So, now I at least have a working config, and can try to find out why I don't see any dhcp packets at the remote side.

Thanks very much,

Ilona

yeah that makes sense, some phones have that voice vlan (although that generally is negotiated by an attached switch).

if you know the vlan, you'd create this EFP:

int g 0/0/0/3.100 l2trans

encap dot1q <tag>

rewrite ingress tag pop 1 sym

this way you'll strip the vlan on ingress so the bvi can handle it (and relay the dhcp) and the sym part of that cmd will slap the vlan back on in the outgoing direction.

xander