3

Recently I switched from a T1 to a residential cable service (Comcast). I have a virtual machine (XenServer 5.6) running Debian 6.0.6 that is acting as the default gateway for my home network, but for some reason it looks like the upstream DHCP server is ignoring my DHCPDISCOVER requests completely.

Feb  1 20:58:34 myhost dhclient: Internet Systems Consortium DHCP Client 4.1.1-P1
Feb  1 20:58:34 myhost dhclient: Copyright 2004-2010 Internet Systems Consortium.
Feb  1 20:58:34 myhost dhclient: All rights reserved.
Feb  1 20:58:34 myhost dhclient: For info, please visit https://www.isc.org/software/dhcp/
Feb  1 20:58:34 myhost dhclient:
Feb  1 20:58:34 myhost dhclient: Listening on LPF/eth1/26:ac:40:50:5b:c7
Feb  1 20:58:34 myhost dhclient: Sending on   LPF/eth1/26:ac:40:50:5b:c7
Feb  1 20:58:34 myhost dhclient: Sending on   Socket/fallback
Feb  1 20:58:38 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4
Feb  1 20:58:42 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 5
Feb  1 20:58:47 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 9
Feb  1 20:58:56 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 14
Feb  1 20:59:10 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8
Feb  1 20:59:18 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8
Feb  1 20:59:26 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 9
Feb  1 20:59:35 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4
Feb  1 20:59:39 myhost dhclient: No DHCPOFFERS received.
Feb  1 20:59:39 myhost dhclient: No working leases in persistent database - sleeping.
  • Everything is cabled correctly, and the traffic is being bridged to the correct interface on the virtual machine. If I listen for all traffic using tcpdump, I can see lots of ARP traffic as well as my ISP's DHCP server responding to other customers who are requesting IP addresses. My DHCP packets are being broadcast but answers do not come back.
  • If I start dhclient before the modem has finished completely initializing, it serves a private IP address in the 192.168.100.0/24 network range with a low refresh interval so that dhclient will pick up the public IP address when it is ready to be served. It continues to send DHCPACK responses for the private network until it is ready to bridge the networks, at which point I stop getting responses from a DHCP server again.
Feb  1 21:16:02 myhost dhclient: Listening on LPF/eth1/26:ac:40:50:5b:c7
Feb  1 21:16:02 myhost dhclient: Sending on   LPF/eth1/26:ac:40:50:5b:c7
Feb  1 21:16:02 myhost dhclient: Sending on   Socket/fallback
Feb  1 21:16:04 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8
Feb  1 21:16:04 myhost dhclient: DHCPOFFER from 192.168.100.1
Feb  1 21:16:04 myhost dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
Feb  1 21:16:05 myhost dhclient: DHCPACK from 192.168.100.1
Feb  1 21:16:05 myhost dhclient: bound to 192.168.100.10 -- renewal in 14 seconds.
Feb  1 21:16:19 myhost dhclient: DHCPREQUEST on eth1 to 192.168.100.1 port 67
Feb  1 21:16:20 myhost dhclient: DHCPACK from 192.168.100.1
Feb  1 21:16:20 myhost dhclient: bound to 192.168.100.10 -- renewal in 13 seconds.
Feb  1 21:16:33 myhost dhclient: DHCPREQUEST on eth1 to 192.168.100.1 port 67
Feb  1 21:16:36 myhost dhclient: DHCPREQUEST on eth1 to 192.168.100.1 port 67
Feb  1 21:16:43 myhost dhclient: DHCPREQUEST on eth1 to 192.168.100.1 port 67
Feb  1 21:16:50 myhost dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
Feb  1 21:16:51 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7
Feb  1 21:16:58 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 15
Feb  1 21:17:13 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7
Feb  1 21:17:20 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 10
Feb  1 21:17:30 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 10
Feb  1 21:17:40 myhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 12
Feb  1 21:17:52 myhost dhclient: No DHCPOFFERS received.
Feb  1 21:17:52 myhost dhclient: No working leases in persistent database - sleeping.
  • In my particular case, this is an EMTA modem that also provides phone service to my house. My phone service is working, I just can't get an IP address.
  • I have tried calling in to my ISP and using the phone menu to send a reset signal to my modem, as well holding down the reset button to trigger a factory reset and re-download of firmware. Neither of these solved the problem.
  • I have a spare DOCSIS 3.0 cable modem. I worked with a technician to temporarily whitelist its MAC address, but I'm having the exact same problem with not seeing DHCP responses.

I tried calling Comcast to ask them if my MAC address has been blacklisted somehow, but they are refusing to escalate my call without adding a premium technical support service to my account. (including a one-time activation fee to discourage me from immediately unsubscribing when my problem is solved)

Why can't my VM get a DHCP response?

|improve this question
5

Don't use auto-generated virtual MAC addresses with your ISP.

Whether you are using a completely randomized MAC address or a non-vendor prefix, you are running the risk that your MAC address will confuse your ISP's infrastructure.

The workaround is to spoof the MAC address of an existing network card: preferably an old 10-base card that you never plan to use again, but any MAC address that fits the following criteria will do:

  • Is assigned to a physical network port that you actually own
  • Is not held by another VM in your infrastructure (might confuse the virtualization platform)
  • Will not be otherwise seen by the VM you are assigning it to
  • Will not be seen by any other machine on that network segment

Reconfigure your virtual NIC to spoof that MAC address, confirm that the changes are visible to your OS, and reboot your cable modem. I was able to demonstrate multiple times in my particular scenario that the cable modem reboot step was necessary.

|improve this answer
  • I had a KVM instance that wouldn't get an IP. Took the hardware MAC address, changed a random digit, assigned it to the virtual interface, and Robert is your parental male sibling. – Rob Bos May 18 '13 at 1:39
  • @Rob Keep in mind that changing the random digit is a stopgap solution. It gets you out of your current MAC collision, but the only surefire way to ensure it won't happen again is to something that isn't in a Locally Administered range (an actual device), and one that you can personally ensure will never be seen. – Andrew B May 18 '13 at 18:18
  • Locally administered. That's a helpful thing to know. – Rob Bos Jun 6 '13 at 2:45
2

The other answer saying it is the VM MAC is very close to right. First, let's clear a little confusion of yours - the modem does a DHCP request to the upstream server. It gets an unroutable address that is used by Comcast, e.g. 10.x.x.x. You do DHCP request to the modem itself, and it gives you the public WAN IP that the modem was assigned by the ISP.

Anyway, back to your problem. The modem "bonds" to the first MAC it sees. So if your host OS attempted anything on that port before the VM booted up and tried to talk to it, the modem will ignore any packets coming from the VM. I was able to do what you wanted to in the past with VMWare on RHEL by allowing RHEL to bring up the (dedicated) NIC, but there was no IP associated with it (and BootP/DHCP was turned off). Then when the VM boots and attempts to connect, it is the first packet the modem sees on the line. So to do this, you need at least two NICs in the physical host; the host OS cannot do anything else with that port; it's a direct connection to the modem only.

|improve this answer
  • I'm not sure "you do the DHCP request to the modem itself" is accurate in this case. Based on the tcpdump traffic I was sniffing, I was seeing DHCP responses being broadcast to machines that were not on my network, and a great deal of ARP traffic for hosts not on my network. My impression based on this was that I was being bridged into the cable provider's network after the modem finished initializing. In either case, your suggestion that the cable modem was binding to the VM host's MAC doesn't seem fit given the repeatedly reproducible 192.168.100.0/24 leases during initialization. – Andrew B Feb 3 '13 at 2:42
  • I should also add that the VM host's interface was not configured with an address or boot time parameters, was not rebooted during the troubleshooting, and could not obtain an IP address via dhclient. I think it's pretty safe to say that it was not binding to the MAC address of the VM host, particularly since many cable modem reboots did nothing to fix the problem until the MAC was changed. – Andrew B Feb 4 '13 at 2:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.