Re: A common problem with SLAAC in "renumbering" scenarios

[Mark Smith <[e-mail]>]

On Tue., 5 Feb. 2019, 23:26 Mikael Abrahamsson <[e-mail] wrote:

> On Tue, 5 Feb 2019, Mark Smith wrote:
>
> > I think a lot of this need in IPv4 has come from IPv4 addresses being
> > precious and expensive resources. Consequently, it has been worth the
> > expense and effort of fine grained management of them.
> >
> > In IPv6, that level of management isn't needed. Addresses are plentiful
> and
> > cheap, so you can throw lots of address space at problems.
>
> It's sometimes from re-farming of things. ISPs tend to today build largish
> access-routers and call them BNG. So when a 10GE interface is full, you
> need to split the customer load to two interfaces, or move some to a
> completely different router.
>

Yes, I know, I don't like big BNGs with 10s of 1000s of sessions on them
because they cause massive outages when they fall over or need to be
upgraded. I much rather scale out with a number of more commodity hardware
BNGs carrying far fewer sessions per BNG.


> So if you move half of the subscribers of that port to a different router,
> now you have a problem because typically you'll have a set of
> addreses-space dedicated for that router and part of that now needs to go
> to another router. Typically you don't want this type of de-aggregation.
>

Why not?

Where is the requirement that the individual BNG must be the route
aggregation boundary for subscriber routes?

That's been tradition, however I don't think it is a requirement, and I
suspect one of the original and primary reasons for it was to stop dial-up
session fluctuations causing routing protocol reconvergence events on other
routers.

If your BNGs are using BGP, how many routes and how many BNGs can you have
in a group (with no aggregation) before you run into BGP scaling limits,
when you customers are always online, and customer link fluctuations are a
fault now rather than normal expected behaviour?

My guess for typical BNG hardware is that it is at least in the order of
100 000 routes or more, and 20 or more BNGs. That may be conservative given
that BGP can cope with Internet scale routing.

You may need to deploy route aggregation, however you would do it at the
edge of your BNG group/cluster, rather than within it.

Regards,
Mark.



> --
> Mikael Abrahamsson    email: [e-mail]
>