[cisco-bba] About converting from IRB to RBE

Mark E. Mallett mem at mv.mv.com
Thu Aug 14 03:35:44 EDT 2003


> 
> not many choices if you are going to use range or create multiple subints
> if you want them to share the same IP.  they have to be unnumbered.
> you can unnumber to a loopback (recommended way) or to some other
> interface (lan, wan, bvi, etc).  a loopback is better as it's an interface
> that is always up.

Thanks for the response.  I had some chance to experiment some more
but am still running into at least one issue.  This is on
a 7206 where DSL customers are delivered across a few different
PVCs.  The remaining issue is one that is well-predicted in cisco
documentation but alas without a solution that I see.

If I have a new RBE configuration such as:

Interface Loopback1
 ip address 192.168.10.1 255.255.255.0
 no ip directed-broadcast
!
interface atm1/0
! LEC needs to see a constant MAC for their filters
 mac-address aaaa.bbbb.cccc
!
interface atm1/0.301 point-to-point
 description DSL RBE PVC 1/301
 ip unnumbered loopback 1
 atm route-bridge ip
 ip helper-address 192.168.12.10
 pvc dsl-301 1/301
  encapsulation aal5snap
!
interface atm1/0.302 point-to-point
 description DSL RBE PVC 1/302
 ip unnumbered loopback 1
 atm route-bridge ip
 ip helper-address 192.168.12.10
 pvc dsl-302 1/302
  encapsulation aal5snap
!
interface atm1/0.303 point-to-point
 description DSL RBE PVC 1/303
 ip unnumbered loopback 1
 atm route-bridge ip
 ip helper-address 192.168.12.10
 pvc dsl-303 1/303
  encapsulation aal5snap
!

The interfaces appear to come up fine.  Now, RBE wants to validate all
of the ARP entries that it installs onto the interfaces configured in
this way.  (No complaints there, I think this is great, it helps to
prevent people from hijacking IP addresses by simply arping them as
they could with bridged interfaces.)  The ARP entries are installed
when certain DHCP requests and results are seen.  The problem here is
that there are already a large number of DSL customers out there
exchanging traffic, and they are effectively cut off until they do the
proper DHCP dialog.  By observation it appears that a
DISCOVER/OFFER/REQUEST/ACK sequence is required (or at least the
DISCOVER/OFFER sequence).  Of the clients that find themselves not
passing traffic, extremely few of them will automatically try a
release/obtain (i.e. in order to generate the DISCOVER).  And in fact
not very many of them even try an automatic renew.  So after the
IRB-to-RBE conversion most existing DSL customers do not have connectivity.

I may have missed it: is there a migration solution that doesn't
involve coordinating with every existing customer out there?  One
useful setting might be "do not validate ARP entries-- install every
ARP observed on these subnets/these interfaces" for a time.

It also occured to me that I could use the "ip dhcp database"
facility-- I could easily hand-construct a dhcp cache file that would
be loaded into the router upon reload.  However, that would involve
getting the information out of the IRB configuration to populate that
fake database, information that would include VPI/VCI for each
installed ARP entry, and again I have run into a wall trying to find
that.

Any hints?

Yours,
-mm-


More information about the cisco-bba mailing list