03-01-2017 07:19 AM
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
Solved! Go to Solution.
03-02-2017 06:54 AM
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
03-01-2017 08:16 AM
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
03-01-2017 09:16 AM
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
03-01-2017 09:17 AM
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
03-02-2017 04:13 AM
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
03-02-2017 04:33 AM
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
03-02-2017 06:48 AM
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
03-02-2017 06:54 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide