It doesn;t sound right but I really don't know how it is supposed to work aside from the practicality of having to reboot the modem if you swap routers and the IP being tied to the router (by its MAC).

I now have the much maligned Superhub so both components automatically get rebooted together.

In reply to a post by mixt:

When I was on cable, I always used to notice something a bit quirky.

If I have a router with mac address A connected to the cable modem and I power on the cable modem, and then the router, the router would normally DHCP shout and have no problems being allocated an IP.

If I then disconnect that router, and connect another completely different router, with mac address B, and let it try and DHCP, it would fail (it just wouldn't get any responses from its DHCP shouts). Only if I turn the cable modem off and back on would router B then be given a new IP via DHCP (the network responds as normal to the shouts). The IP is usually completely different, as this is a new mac address the network hasn't seen before.

I've seen this behaviour time and time again on cable, and it really puzzles me. I don't really understand what's going on but it certainly ain't normal, and it seems to me to be some weird side affect of the whole cable infrastructure that causes this. Maybe you can explain? Might be indirectly upsetting the Cisco, but this is purely speculation.

No, that's supposed to happen. There's a setting on the configuration files 'Max-CPE' which indicates how many MAC addresses the modem is allowed to speak to on client side. Virgin have this value at 1 on all home packages so the modem will learn the MAC address of the first device connected to it and will only forward packets to that device.

Even if you connect a new device and send a DHCP renew the modem won't pay any attention, it will learn one MAC address at a time and no more, per the configuration file.

Nice, thanks for explaining that!

Seeing something very similar - I've replied to your post on your blog as well

No it is not normal from how I understand it. A dhcp client may request an update from the server at any time. Normally clients start to do this half way though their lease or so to refresh it to zero again. This is so that it never expires.

At least from what I have seen that is what both windows + linux dhcp clients typically do.

It should defiantly not be ignoring you.

I'm going to try to get to the bottom of this properly. I'm sending a cheap router to site to try various connection options. Hopefully I'll get to the position where I can packet capture good and bad (ie Cisco) DHCP conversations.

As you're using an 877 I assume you're using one of the ethernet ports in its own VLAN with the VLAN interface requesting the DHCP address?

I have a hunch, having just spoken to VM, that the presence of the internal switch in the routers may be causing the problem.
Once I canget my site online somehow via the cable modem I can move the primary connection off the routed port (fe0/0) and onto a VLAN interface, leaving the layer3 capable physical interface (fe0/0) free to try on cable.

I'll keep you posted!

In reply to a post by ionic:

As you're using an 877 I assume you're using one of the ethernet ports in its own VLAN with the VLAN interface requesting the DHCP address?

I have a hunch, having just spoken to VM, that the presence of the internal switch in the routers may be causing the problem.
Once I canget my site online somehow via the cable modem I can move the primary connection off the routed port (fe0/0) and onto a VLAN interface, leaving the layer3 capable physical interface (fe0/0) free to try on cable.

Yes I am using a separate vlan. Though I did shut down all the other switch ports at one stage to test for something like that and the same thing was happening. Would be interested to know if you could try the same and have any success.

If possible a nice tcpdump from a linux machine would be nice with full mac headers etc...

Also something worth pointing out before the cisco there was a us robotics router on the connection which had the same issue's from time to time kind of like this. But would eventually work after a combination of reboots after an outage.

The config I am using is somewhat complicated to begin with and not the best to debug with as the adsl port is also active using another provider with a some load balancing between them. Though there are currently some plans to separate this off to glbp like I have done on another site.

hmm.. hadn't looked at glbp. I'm doing something similar but at other sites am using multple VRFs (mainly to allow multiple DMVPN tunnels to a singel head-end)

I'm hoping I an find a wokring WRT54G in the junk cupboard. One of those with openwrt (or simlar)on would be ideal and I can L2 bridge the ports together to try the cisco again if needs be

In reply to a post by mixt:

Nice, thanks for explaining that!

Not a problem, it's not immediately obvious unless you know how these things work, common sense says that connecting a new device the modem should learn its MAC address from its ARP broadcasts.

In reply to a post by Moto:

It seems a common problem when looking at Virgin's support forums.
In my case I cannot renew my firewall's IP address and have to do a release then discover at intervals to keep my connection working. In Virgin's defense it appears to be a problem with the linux drivers for one Intel NIC chipset and the problem affects users on other cable systems worldwide.

Looks like we may have got to the bottom of this. Somebody sent me a dump. So I think i know why the cisco will dump it. Quite simply virgin dhcp server is not responding in time.

The best I have seen is a response time of about 25 seconds in the dump after the last client request this is over 60 seconds since the first request normally. The worst I have seen is around 120 seconds after the last request is sent.

To confuse matters. The xid on a cisco changes from request attempt to the next attempt. This is why it is failing. Other implementations may not do this. If they use the same xid on each request set then they get lucky and see the correct response from the first set of requests.

So it runs like this with a seconds column

Client requests
000 Client -> Discover #1
004 Client -> Discover #1
012 Client -> Discover #1
024 Client -> Discover #1
040 Client -> Discover #1
060 Client -> Timeout Close #1
120 Client -> Discover #2
124 Client -> Discover #2
126 Server -> Responsed to #1
126 Client -> Incorrect response drops packet. Since reply code is incorrect

So yeah virgin need to fix their dhcp servers ....