I'm having a problem getting DHCP working with an ASR9k as shown in this document. I've successfully implemented very similar setups with some Cisco IOS routers, but the IOS XR on the ASR seems to be defeating me.
I have:
- Router A (happens to be a 3750)
- A DHCP/BOOTP/TFTP server, connected to router A
- Router B - this is the ASR, running software version 4.0.3.
- Router A and B are connected by a layer-3 link.
- Router C (happens to be a Broadcom embedded router). It's connected to Router B by a VLAN trunk link.
- Device 1, this one needs to get its configuration by DHCP/BOOTP/TFTP. It's connected to Router C by a VLAN trunk link.
- Device 2, this one doesn't need any DHCP/BOOTP/TFTP. It's connected to Router C by a VLAN trunk link (its port is the same as Device 1's)
Device 2 works great - it can ping the DHCP/BOOTP/TFTP server (and vice versa) and everything else it needs.
Device 1 is the problem - I can't get it to receive BOOTP replies from the DHCP/BOOTP/TFTP server.
The ASR is configured like this:
| ASR Configuration |
|---|
interface GigabitEthernet0/2/0/8 description MCH Port 0/15 ! interface GigabitEthernet0/2/0/8.77 l2transport description MCH Port 0/15, VL77 trunk encapsulation dot1q 77 rewrite ingress tag pop 1 symmetric !interface BVI77
ipv4 address 172.18.162.241 255.255.255.248 ipv4 directed-broadcast !l2vpn bridge group IRB bridge-domain Vlan77 interface GigabitEthernet0/2/0/8.77 ! routed interface BVI77 ! !dhcp ipv4 profile LAB_VIDEO_SDM relay helper-address vrf default 172.18.161.10 ! interface BVI77 relay profile LAB_VIDEO_SDM interface GigabitEthernet0/2/0/8.77 relay profile LAB_VIDEO_SDM ! |
The problem is strange. When Device 1 reboots it sends a DHCP request. This is forwarded to the TFTP server as expected - I can see the BOOTP Requests at that server (confirmed with tcpdump). I can also see the BOOTP Replies leave that server (confirmed with monitor session on Router A). However, those BOOTP replies are never broadcast to the Vlan77 devices - those packets never show up on Router C (confirmed with monitor session).
What might cause such behavior? I have tried various options like enabling forward-protocol udp 67 and forward-protocol udp 68 with no change in behavior.
I hope this picture will illustrate the setup:
