[nsp] RBE aggregation issues

Mark E. Mallett mem at mv.mv.com
Tue Oct 28 13:15:05 EST 2003


Hi-

We are backhauling DSL service from LECs over DS3 ATM circuits,
using a 7206VXR/NPE-300 chassis running 12.1(5)T12 IOS
(specifically, c7200-is-mz.121-5.T12.bin)

Customers are bridged across one or more PVCs (not one PVC per
customer).  A few months ago we converted from an IRB setup to using
RBE.  Each PVC is configured as an unnumbered interface with reference
to a loopback, pretty cookbook.  The hope was that RBE would solve the
issue where customers on the same subnet and PVC could not see each
other.

Unfortunately, it didn't solve the issue, and furthermore it
seems to have simply created a lot of other problems.   I'm
seriously considering going back to the IRB style.

The primary problem is the one I've mentioned before:  IOS will only
install a route to a customer if it sees a DHCP
DISCOVER/OFFER/REQUEST/ACK sequence.  Don't get me wrong: validating
the leases is great, that's one of the benefits I looked forward to.
However, its incompleteness is challenging.  If we reboot the router
or make other changes, we lose connectivity to at least half of our
customers.  When they call us, we can have them do a release/renew on
their end, if indeed they can do it (some DSL routers make it really
difficult to do that).  Not everyone calls right away, meaning they
have lots of downtime.  Most of the affected people are understandably
put out.

Many or most DHCP clients do not try a release/renew when they lose
connectivity.  The majority do seem to do a request/ack sequence to
verify their lease: the situation would be so much better if IOS would
use a DHCP ACK to install the route, rather than having to see the
discover/offer sequence too.  The situation would be even better if it
would do a dhcp lease inquiry on seeing an not-yet-validated ARP
packet.  As it is, people are simply left without connectivity.
(One could blame it on poor dhcp clients, but that's the way it
is out there.)

We do have a dhcp lease database configured.  Unfortunately this is
only marginally successful too.  Using rcp mode dhcp lease database,
the database is only successfully written if the file doesn't already
exist on the server (even though IOS thinks the operation was
successful).  (FTP mode does work, in some sense of the word "work" --
the database is written, but having this lease database does not seem
to help the situation where users are cut off after a reboot-- so I'd
have to say that the entire process doesn't work.)

Any relevant comments would be appreciated.

Yours,
-mm-


More information about the cisco-nsp mailing list