<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><font face="Courier">I would like to say thank you for sharing
        this information<font face="Courier">.  I'<font face="Courier">ve
            <font face="Courier">been looking for a way to hold <font
                face="Courier">all my pools in a central location <font
                  face="Courier">instead of having to <font
                    face="Courier">double<font face="Courier">/</font>tr<font
                      face="Courier">iple up on pool sizes in order to
                      account for an LNS failure.</font></font></font></font></font></font></font></font></p>
    <p><font face="Courier"><font face="Courier"><font face="Courier"><font
              face="Courier"><font face="Courier"><font face="Courier"><font
                    face="Courier"><font face="Courier"><font
                        face="Courier">Andrew.</font><br>
                    </font></font></font></font></font></font></font></font></p>
    <br>
    <div class="moz-cite-prefix">On 7/5/2017 11:29 AM, Arie Vayner
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAP9daneV+YS0ijcNR56txSm50qosQZE=n=s=t=4gZr2CiB=JzA@mail.gmail.com">
      <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"
            moz-do-not-send="true">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"
            moz-do-not-send="true">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" moz-do-not-send="true">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"
            moz-do-not-send="true">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"
            moz-do-not-send="true">cisco-bba@puck.nether.net</a><br>
          <a href="https://puck.nether.net/mailman/listinfo/cisco-bba"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://puck.nether.net/mailman/listinfo/cisco-bba</a><br>
        </blockquote>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
cisco-bba mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cisco-bba@puck.nether.net">cisco-bba@puck.nether.net</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/cisco-bba">https://puck.nether.net/mailman/listinfo/cisco-bba</a></pre>
    </blockquote>
    <br>
  </body>
</html>