[nsp] About converting from IRB to RBE (fwd)

[Mark E. Mallett]

Here's the question about migrating from IRB to RBE for DSL
aggregation.  Thanks for your indulgence-

-mm-


> 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-