[rbak-nsp] IP Address Assignment Methods

[Tomas Lynch]

If your customers don't need a fixed IP address then assign addresses
with a local pool on the SE.

With local pools you are also reducing your routing table: you assign
a /24 to one box and there is no need to propagate all the /32s. With
the framed-ip-address-attribute, if a customer moves from one SE to
another then you will need to propagate that /32. The more prefixes
you have on your routing table, the more memory is used.

You can even save addresses with local pools if you know what is the
maximum of customers connected at the same time: let's say you have
100 subscribers but you know that there are never more than 60
connected, then you can assign a pool of 60 addresses on that SE and
save 40 for another.

On Fri, Aug 3, 2012 at 5:53 AM, Caillin Bathern
<sp.solutions.architect at gmail.com> wrote:
> Hi List,
>
> I am just wondering how other SP's are managing their IP address
> assignments.
>
> Are you using IP Pools to randomly assign an IP to a subscriber when they
> initiate a session OR are you maintaining the IP address for a subscriber bu
> pushing it back with the framed-ip-address attribute?
>
> I know of SPs using both methods however each provides its own issues such
> as route table scale, ability or inability to keep track of subscriber IPs
> (Lawful intercept issues, flow based billing issues, etc) which are all
> highlighted when you have 1+1 redundancy of the BRAS'.
>
> Which methods have you chosen?  Why?  How have you overcome the limitations
> of each issue?
>
> Cheers.
>
> _______________________________________________
> redback-nsp mailing list
> redback-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/redback-nsp
>