CUPS in a BNG?

Wed Mar 22 22:24:59 UTC 2023

OK - That makes sense.  For scaling a CP, it only about redundancy,
correct, but with the DP it's really about scaling up and out. But still, a
CP is no longer on the bus with the DP, nor on the network.  It's on the
WAN/Internet, and latencies are orders of magnitude greater.  Is anybody
doing this and are those latencies acceptable?

On Wed, Mar 22, 2023 at 2:59 PM Joel Halpern <jmh at joelhalpern.com> wrote:

> With a reasonable design, it separates the scale issues of the control
> plane from the scale issues of the data plane.  And since the relationship
> between those two scale factors is different for different deployments, it
> allows you as an operator to build for your needs.  It also, with suitable
> designs separates the failure modes.
>
> Whether either of those applies in your case probably depends upon your
> needs and what vendors you find useful.
>
> Yours,
>
> Joel
> On 3/22/2023 5:53 PM, Tom Mitchell wrote:
>
> What is it about the architecture that makes it a preferred solution.  I
> get that centralizing the user databases makes sense, but why the control
> plane.  What benefit does that have?
>
> -- Tom
>
>
> On Wed, Mar 22, 2023 at 2:17 PM <brian.johnson at netgeek.us> wrote:
>
>> The CUPS makes a lot of sense for this application. Latency is dependent
>> on the design, and equipment used. I’ve seen/done several designs for this
>> using two different vendors equipment and two different BNG software
>> stacks.
>>
>> When I do a design for BNG from scratch, this is how I do it now. :)
>>
>> As always… YMMV.
>>
>> - Brian
>>
>> On Mar 22, 2023, at 4:02 PM, Tom Mitchell <tmitchell at netelastic.com>
>> wrote:
>>
>> Anyone have any thoughts on this CUPS thing?  I have a customer asking,
>> but it seems the lack of CP resiliency and additional latency between the
>> DP and CP make this a really dumb idea.  Has anyone tried it?  Does it make
>> any sense?
>>
>> Thanks!
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230322/397bc771/attachment.html>