[c-nsp] Forcing dhcp lease renewal

Bob Tinkelman bob at tink.com
Fri Jan 16 11:34:45 EST 2009


For a cisco router with an interface like this:
   interface FastEthernet0/1
    description Verizon EVDO via Cradlepoint CBA250
    ip address dhcp

I'm looking for a way to force the router to issue a dhcp
lease renewal request.

I can do this manually, for example via
   config term
    int fa0/1
    shut
    no shut
    exit
but I'm looking for a way to trigger this automatically.


(Or possibly I'm trying to solve a problem in the wrong way.)



Background:

We have a good many customers with T1 or multi-T1 service,
and with fall-back routing configured over a "cheap path",
typically a dynamic-ip cable-modem service or dsl.  Our
configs use a combination of gre-tunnels (to preserve
customer-site address ranges) and sometimes object tracking
and policy routing (often to direct web requests to a
higher-speed cable-modem service in cases where NATing is
acceptable).  We've been doing this for a good while and
have a set of configs that provide pretty solid service.

I have been testing, in a lab environment, a configuration
to do the same thing with Verizon's EVDO service using a
Cradlepoint CBA250 (Cellular Broadband Adapter).  It's not a
router; just a "pass-through device".

The same configuration that we use with dynamic-ip cable-
modems works.  However, several times/day, things "break".

Output of "show interface", "show dhcp lease", etc., show
that the cisco router doesn't think anything's changed.  The
interface has the same dhcp-assigned ip address and default
gateway.  But the default gateway is no longer pingable.

Doing a "clear int Fa0/1" doesn't help.  A "shut" and "no
shut" will cause the router to issue a new dhcp request, get
a new (and different) ip address and gateway, and start
working again.


My current working hypothesis is that the EVDO link between
the CBA250 and Verizon was interrupted, possibly very
briefly, that Verizon noticed and invalidated the dhcp
lease, but that no indication of this reached the router.

It's a weak hypothesis.  I'm bothered by the fact we've
never seen this problem with similar cable-modem setups,
e.g., with Time Warner and with Cablevision.  I've sent
email to support at cradlepoint.com even though I really don't
see how their equipment could be involved.



I could use object tracking to discover when the link over
EVDO stops working.  But I'm not sure what do to with that
info.  Is there a way to force a new dhcp request to go out
based on object tracking?  (To date, I've used object
tracking mostly to enable/disable specific ip route
commands.)


I have the strong feeling that I'm trying to solve this in
the wrong way, and that if I really understood what was
going wrong, I'd be working in a different direction.

So, any hints would be much appreciated

- Bob


More information about the cisco-nsp mailing list