Could use a little help - CPEs not getting DHCP information | docsis.org

You are here

Could use a little help - CPEs not getting DHCP information

3 posts / 0 new
Last post
dcy
Could use a little help - CPEs not getting DHCP information

Hey ...

first time poster, occasional reader :)

I've run into an issue that I'm stuck at. The layout is a dual-bridge, with disabled routing:

Bridge-group 0:
Fa0/0.2 - link towards internet (VLAN tag set on the Fa0/0.2 outbound interface towards the next hop) - all IPs public
Cable1/0.1 - CPEs are provisioned here (same VLAN tag is set on the interface)

Bridge-group 1:
Fa0/0.0 - link towards the provisioning server (TFTP/DHCP/etc.) - again with a VLAN tag - the IPs are private
Cable1/0 - CMs are provisioned here (no VLAN tag)

Relevant config bits:

no ip routing
default cm subinterface Cable 1/0.0
default cpe subinterface Cable 1/0.1

interface Cable 1/0 - this is the interface that the CMs are connected to
no shutdown
bridge-group 1
ip address 192.168.30.1 255.255.255.0
no allow-ip-only
management-access
no cable source-verify
arp-broadcast-echo
l2-broadcast-echo
l2-multicast-echo
ip-broadcast-echo
ip-multicast-echo
no l2-broadcast-throttle
no ip dhcp relay
no ip dhcp relay information option
no ip dhcp relay validate renew
no ip dhcp relay non-broadcast
cable helper-address 192.168.30.2 cable-modem
cable helper-address 192.168.30.2 host
cable dhcp-giaddr primary
no ip directed-broadcast
no ip source-verify
no ip source-verify subif
no ip l2-bg-to-bg-routing
no ip verify-ip-address-filter

interface FastEthernet 0/0 - the link towards the provisiong server
no shutdown
bridge-group 1
no allow-ip-only
management-access
encapsulation dot1q 30
no ip directed-broadcast
no ip source-verify
no ip source-verify subif
ip l2-bg-to-bg-routing
no ip verify-ip-address-filter

interface FastEthernet 0/0.1 - administrative interface
no shutdown
ip address 192.168.111.50 255.255.255.0
no allow-ip-only
management-access
encapsulation dot1q 500
no ip directed-broadcast
no ip source-verify
no ip source-verify subif
no ip l2-bg-to-bg-routing
ip verify-ip-address-filter

interface FastEthernet 0/0.2 - the link towards the public internet
no shutdown
bridge-group 0
no allow-ip-only
management-access
encapsulation dot1q 75
no ip directed-broadcast
no ip source-verify
no ip source-verify subif
no ip l2-bg-to-bg-routing
ip verify-ip-address-filter

interface Cable 1/0.1 - the interface where the CPEs are expected to be
no shutdown
bridge-group 0
ip address 195.205.205.129 255.255.255.192 - public IP, this one is not the real one :)
no allow-ip-only
management-access
no cable source-verify
arp-broadcast-echo
l2-broadcast-echo
l2-multicast-echo
ip-broadcast-echo
ip-multicast-echo
no l2-broadcast-throttle
downstream-dhcp-server-allowed
throttle-credits initial 15 running 2
encapsulation dot1q 75 native
no encapsulation dot1q 75 encrypted-multicast
ip dhcp relay
ip dhcp relay information option
ip dhcp relay validate renew
ip dhcp relay non-broadcast
cable helper-address 192.168.30.2 host
cable dhcp-giaddr primary
no ip directed-broadcast
no ip source-verify
no ip source-verify subif
no ip l2-bg-to-bg-routing
no ip verify-ip-address-filter

The provisiong server knows to route traffic for 195.205.205.129/26 towards 192.168.30.1

And here is what happens ...
- the CMs are provisioned normally, they reach init(pt) without any troubles - but their DHCP requests are bridged across towards Ca1/0 and the DHCP relay is not involved in any way
- the CPE is mapped correctly onto Ca1/0.1 and sends a DHCP request on the network
- this CPE DHCP request is properly picked up by the CMTS (debug cable dhcp-relay, debug cable mac-address xxxx.xxxx.xxxx)
- CMTS sends the DHCP request towards the provisioning server, tcpdump on the provisiong server sees the expected information (the source IP is the public IP that is set on Ca1/0.1)
- the DHCP server finds the information in it's pool and sends a DHCP offer - again the information is correct and it is sent to 192.168.30.1

And here it breaks ... the CMTS does not pick up the information from the wire and send it on towards the CPE ....

So does anyone have a clue what I'm missing here? "ip l2-bg-to-bg-routing" is enabled on Fa0/0, so it should be able to pick up the packet and realy it onto Ca1/0.1 for the CPE - but that is never done.

To make the matter worse - I can assure that the DHCP offer is sent towards the CMTS, but unfortunately I am unable to debug anything on the CMTS - the dhcp relay debugging information does not seem to see this packet, and the interface statistics on Fa0/0 do show that there are dropped (!!!) packets in in the incoming queue, so it seems as if the CMTS tags these packets as illegal and silently drops them (well, UDP, no need to tell the sender it was dropped ^^).

If someone sees a problem with my layout, I'd be happy for a heads up :)

D.

mtntrailseeker
DHCP Relay

While I've see appliations of bridiging being used a long long time ago I've never seen dhcp relay turned totally off before on the cmts. Seems to me the CMTS has to "relay" the offer from the FE 0/0 to cable 1/0. I would remove the no ip dhcp relay and no ip dhcp relay infomartion option one at a time and see if the debug then fires on the cmts.

dcy
Actually since it's the same

Actually since it's the same VLAN and the CMTS has arp-broadcast-echo enabled on Fa0/0 that bit works ok ... the CMs get provisioned normally, the problem is between Ca1/0.1 and Fa0/0.0 ... whereby debug confirms, that the DHCP relay does kick in on Ca1/0.1 once a request is sent by the client, the DHCP relay does send the packet to the provisioning server (setting the source IP to the public IP 195.205.205.129 (the reverse route is set on the provisioning server correctly, and pinging/tracerouting to the "public" IP works)), and the DHCP offer is sent from the provisioning server towards Fa0/0 ... the trouble is, that CMTS doesn't pick the DHCP offer up on Fa0/0 and transmit it out back on Ca1/0.1 ...

Actually, thinking about it - I do see your point... I'll try enabling it on Fa0/0 ... maybe the process is not listening on Fa0/0 for the reverse route relay to work ... good hint, thank you!

D.

Log in or register to post comments