<div dir="ltr">Cisco has an interesting feature called ODAP (On Demand Address Pools). The idea is that the router will go and request additional pools from a DHCP server whenever a utilization threshold has been hit. It also has the capablity to release pools back (on router restart or if utilization went down).<div><br></div><div>I do not think it is widely implemented, but I have implemented it in the past and it works.</div><div><br></div><div><a href="http://www.cisco.com/c/en/us/td/docs/net_mgmt/access_registrar/1-7/user/guide/odap.html">http://www.cisco.com/c/en/us/td/docs/net_mgmt/access_registrar/1-7/user/guide/odap.html</a><br></div><div><a href="https://youtu.be/V7Qc25B-51I">https://youtu.be/V7Qc25B-51I</a><br></div><div><br></div><div>Tnx</div><div>Arie</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 5, 2017 at 3:35 AM Krzysztof Adamski <<a href="mailto:k-list@adamski.org">k-list@adamski.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 2017-07-05 at 08:23 +0100, James Bensley wrote:<br>
> On 4 July 2017 at 22:41, Juergen Marenda <<a href="mailto:cnsp@marenda.net" target="_blank">cnsp@marenda.net</a>> wrote:<br>
> >> You don't need to have a contiguous IP block in an IP Pool. You can simply<br>
> >> do something like this:<br>
> >><br>
> >> TestBNG(config)# ip local pool dynamic-dsl 192.168.0.0 192.168.255.255<br>
> >> TestBNG(config)# ip local pool dynamic-dsl 172.16.0.0 172.31.255.255<br>
> >> TestBNG(config)# ip local pool dynamic-dsl 10.0.0.0 10.255.255.255<br>
> ><br>
> > Remember that there exists an special IPv4 Address-range for "Carrier Grade<br>
> > NAT".<br>
> ><br>
> > Why not assign fixed (real) IPv4/32 for each dial-up account ?<br>
> ><br>
> > Just my 0.01 $<br>
> ><br>
> > Juergen.<br>
><br>
> We use static IPs for all xDSL customers/sites, one problem we have<br>
> from this is that each LNS (depending on which one the customer<br>
> connects to) is announcing loads of /32's into our iBGP that aren't<br>
> aggregatable/summary routes, which they would be if we had a unique<br>
> pool per LNS. We have thousands of extra routes in our iBGP because of<br>
> this, it's not a major issues but still not ideal.<br>
><br>
> Cheers,<br>
> James.<br>
<br>
You can have each LNS aggregate part of the address space, then when a<br>
customer with IP that matches the aggregate lands on this LNS<br>
customers /32 won't be advertised, but when the customer lands on a<br>
different LNS /32 will go into your iBGP. Depending on luck you could<br>
cut in half the number of /32 in your iBGP.<br>
<br>
_______________________________________________<br>
cisco-bba mailing list<br>
<a href="mailto:cisco-bba@puck.nether.net" target="_blank">cisco-bba@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-bba" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-bba</a><br>
</blockquote></div>