--- Begin Message ---
I see the ports in Plymouth as down
-----Original Message-----
From: juniper-nsp <[email protected]> On Behalf Of
[email protected]
Sent: Tuesday, August 10, 2021 8:01 AM
To: [email protected]
Subject: juniper-nsp Digest, Vol 224, Issue 2
Please make sure you trust the sender before responding, clicking links, or
opening attachments.
______________________________________________________________________
Send juniper-nsp mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!DUHle9IWsHMULw!P-ehjI-ohdHxatA_XeJ6Vl4-2sCjtMzvKvFkfNc5p50slKmLQK844sSuWiC-OjpJFtN2Ndg1$
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific than "Re:
Contents of juniper-nsp digest..."
Today's Topics:
1. Re: DHCP server recommendation for subscribers management
(Andrey Kostin)
2. Re: DHCP server recommendation for subscribers management
(Bj?rn Mork)
3. Re: DHCP server recommendation for subscribers management
(Andrey Kostin)
4. Re: DHCP server recommendation for subscribers management
(Bj?rn Mork)
5. Re: DHCP server recommendation for subscribers management
(Andrey Kostin)
6. Re: DHCP server recommendation for subscribers management
(Bj?rn Mork)
7. Re: DHCP server recommendation for subscribers management
(Nathan Ward)
----------------------------------------------------------------------
Message: 1
Date: Fri, 06 Aug 2021 09:52:48 -0400
From: Andrey Kostin <[email protected]>
To: Jerry Jones <[email protected]>
Cc: Juniper nsp <[email protected]>
Subject: Re: [j-nsp] DHCP server recommendation for subscribers
management
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Jerry Jones ????? 2021-08-06 09:37:
> Strongly suggest having active lease query or bulk active lease query
>
> I believe kea has this support
>
> Jerry Jones?
Thanks for reply, Jerry.
In my understanding active leasequery can be run between routers, so might be
not needed on DHCP server, am I correct?
Interesting question what happens if we have two routers with synchronized DHCP
bindings, will be DHCP demux interfaces created on the secondary router based
on that? My guess is no, but need to test it. If then traffic switches from
primary to secondary router, will the secondary be able to pass IP traffic
right away or it will have to wait for next DHCP packet from a client to create
demux interface?
Kind regards,
Andrey
------------------------------
Message: 2
Date: Fri, 06 Aug 2021 18:38:59 +0200
From: Bj?rn Mork <[email protected]>
To: Andrey Kostin via juniper-nsp <[email protected]>
Subject: Re: [j-nsp] DHCP server recommendation for subscribers
management
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Andrey Kostin via juniper-nsp <[email protected]> writes:
> What DHCP server do you use/would recommend to deploy for subscriber
> management?
The one in JUNOS. Using RADIUS as backend.
Bj?rn
------------------------------
Message: 3
Date: Fri, 06 Aug 2021 13:55:22 -0400
From: Andrey Kostin <[email protected]>
To: Bj?rn Mork <[email protected]>
Cc: Andrey Kostin via juniper-nsp <[email protected]>
Subject: Re: [j-nsp] DHCP server recommendation for subscribers
management
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Bj?rn Mork via juniper-nsp ????? 2021-08-06 12:38:
> Andrey Kostin via juniper-nsp <[email protected]> writes:
>
>> What DHCP server do you use/would recommend to deploy for subscriber
>> management?
>
> The one in JUNOS. Using RADIUS as backend.
>
Thanks, currently using it but looking for a central server for more effective
IP usage.
Kind regards,
Andrey
------------------------------
Message: 4
Date: Fri, 06 Aug 2021 21:27:02 +0200
From: Bj?rn Mork <[email protected]>
To: Andrey Kostin via juniper-nsp <[email protected]>
Subject: Re: [j-nsp] DHCP server recommendation for subscribers
management
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Andrey Kostin <[email protected]> writes:
> Bj?rn Mork via juniper-nsp ????? 2021-08-06 12:38:
>> Andrey Kostin via juniper-nsp <[email protected]> writes:
>>
>>> What DHCP server do you use/would recommend to deploy for subscriber
>>> management?
>> The one in JUNOS. Using RADIUS as backend.
>>
>
> Thanks, currently using it but looking for a central server for more
> effective IP usage.
Probably stupid question, but here goes... How does a central server make the
IP usage more effective? Are you sharing pools between routers?
In any case, you can do that with a sufficiently smart RADIUS server too. You
don't have to let JUNOS manage the address pools even if it is providing the
DHCP frontend.
IMHO, having the DHCP frontend on the edge makes life so much easier.
Building a sufficiently redundant and robust centralized DHCP service is hard.
And the edge router still has to do most of the same work anyway, relaying
broadcasts and injecting access routes. The centralized DHCP server just adds
an unneccessary single point of failure.
Bj?rn
------------------------------
Message: 5
Date: Mon, 09 Aug 2021 10:45:46 -0400
From: Andrey Kostin <[email protected]>
To: [email protected]
Subject: Re: [j-nsp] DHCP server recommendation for subscribers
management
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Bj?rn Mork via juniper-nsp ????? 2021-08-06 15:27:
Thanks for your reply.
>
> Probably stupid question, but here goes... How does a central server
> make the IP usage more effective? Are you sharing pools between
> routers?
Yes, going to have at least two routers as BNG and trying to find a way to not
lock IP addresses if they aren't needed.
> In any case, you can do that with a sufficiently smart RADIUS server
> too. You don't have to let JUNOS manage the address pools even if it
> is providing the DHCP frontend.
I understand that it could be an option, but for vlan-per-customer model radius
authentication isn't really needed for DHCP clients. Auth is done for a parent
VLAN-demux interface, so for DHCP sessions BNG will send only accounting. In
this case it will require to develop "smart-enough"
radius backend. If there is any solution already available I'd definitely look
at it, but I'd try to avoid building a homebrew solution.
> IMHO, having the DHCP frontend on the edge makes life so much easier.
> Building a sufficiently redundant and robust centralized DHCP service
> is hard. And the edge router still has to do most of the same work
> anyway, relaying broadcasts and injecting access routes. The
> centralized DHCP server just adds an unneccessary single point of
> failure.
I agree that it's a complication, but imo it's a reasonable tradeoff for
effective IP space usage. For relatively big IP pools it would be sufficient
saving. From KEA DHCP server documentation I see that different scenarios for
HA are supported, so some redundancy can be achieved.
Another question that puzzles me is how to use multiple discontinuous pools
with DHCP server. With Junos internal DHCP I can link DHCP pools in the same
way as for PPPoE and just assign additional GW IP to lo0.
With that Junos takes care of finding available IP in pools and use proper GW
address. In case of external DHCP server, router has to insert relay option but
how can it choose what subnet to use in this case if there are more than one
available? This problem should be also actual for big cable segments, although
for cable interface IP addresses are directly configured on the interface, but
for Junos BNG a customer-facing interface is unnumbered.
Kind regards,
Andrey
------------------------------
Message: 6
Date: Tue, 10 Aug 2021 12:40:32 +0200
From: Bj?rn Mork <[email protected]>
To: Andrey Kostin via juniper-nsp <[email protected]>
Subject: Re: [j-nsp] DHCP server recommendation for subscribers
management
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Andrey Kostin via juniper-nsp <[email protected]> writes:
> Bj?rn Mork via juniper-nsp ????? 2021-08-06 15:27:
>> Probably stupid question, but here goes... How does a central server
>> make the IP usage more effective? Are you sharing pools between
>> routers?
>
> Yes, going to have at least two routers as BNG and trying to find a
> way to not lock IP addresses if they aren't needed.
Yes, can make sense in some scenarios. Main problem is the number of host
routes you must carry in your network, unless you have a level where you can
aggregate routes from those BNGs.
>> In any case, you can do that with a sufficiently smart RADIUS server
>> too. You don't have to let JUNOS manage the address pools even if it
>> is providing the DHCP frontend.
>
> I understand that it could be an option, but for vlan-per-customer
> model radius authentication isn't really needed for DHCP clients. Auth
> is done for a parent VLAN-demux interface, so for DHCP sessions BNG
> will send only accounting. In this case it will require to develop
> "smart-enough" radius backend. If there is any solution already
> available I'd definitely look at it, but I'd try to avoid building a
> homebrew solution.
I don't know where to draw the line between config and programming, but RADIUS
pool management exists as a feature:
https://urldefense.com/v3/__https://networkradius.com/doc/3.0.10/raddb/mods-available/ippool.html__;!!DUHle9IWsHMULw!P-ehjI-ohdHxatA_XeJ6Vl4-2sCjtMzvKvFkfNc5p50slKmLQK844sSuWiC-OjpJFiVxdso7$
>> IMHO, having the DHCP frontend on the edge makes life so much easier.
>> Building a sufficiently redundant and robust centralized DHCP service
>> is hard. And the edge router still has to do most of the same work
>> anyway, relaying broadcasts and injecting access routes. The
>> centralized DHCP server just adds an unneccessary single point of
>> failure.
>
> I agree that it's a complication, but imo it's a reasonable tradeoff
> for effective IP space usage. For relatively big IP pools it would be
> sufficient saving. From KEA DHCP server documentation I see that
> different scenarios for HA are supported, so some redundancy can be
> achieved.
IMHO, DHCP server failover has traditionally created more problems than it
solved. But I have no experience with KEA, so let's hope it's just working now.
> Another question that puzzles me is how to use multiple discontinuous
> pools with DHCP server. With Junos internal DHCP I can link DHCP pools
> in the same way as for PPPoE and just assign additional GW IP to lo0.
> With that Junos takes care of finding available IP in pools and use
> proper GW address. In case of external DHCP server, router has to
> insert relay option but how can it choose what subnet to use in this
> case if there are more than one available? This problem should be also
> actual for big cable segments, although for cable interface IP
> addresses are directly configured on the interface, but for Junos BNG
> a customer-facing interface is unnumbered.
The subnet choice is always up to the DHCP server. You create a shared network
with all the subnets and ranges that are supposed to share pools. This is
similar to the linked pool in JUNOS. The server will select a free address in
this shared network if the giaddr matches one of the configured subnets. Note
that there doesn't have to be mathing range if you don't want to share giaddr
and client subnets.
All routers sharing a pool must have all the same GW addresses configured on
lo0.
I don't think this is any different whether you use the local DHCP server with
RADIUS shared pool or a centralized DHCP server shared pool.
Bj?rn
------------------------------
Message: 7
Date: Wed, 11 Aug 2021 00:00:26 +1200
From: Nathan Ward <[email protected]>
To: Bj?rn Mork <[email protected]>
Cc: Andrey Kostin via juniper-nsp <[email protected]>
Subject: Re: [j-nsp] DHCP server recommendation for subscribers
management
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
> On 10/08/2021, at 10:40 PM, Bj?rn Mork via juniper-nsp
> <[email protected]> wrote:
>
>>> In any case, you can do that with a sufficiently smart RADIUS server
>>> too. You don't have to let JUNOS manage the address pools even if
>>> it is providing the DHCP frontend.
>>
>> I understand that it could be an option, but for vlan-per-customer
>> model radius authentication isn't really needed for DHCP clients.
>> Auth is done for a parent VLAN-demux interface, so for DHCP sessions
>> BNG will send only accounting. In this case it will require to
>> develop "smart-enough" radius backend. If there is any solution
>> already available I'd definitely look at it, but I'd try to avoid
>> building a homebrew solution.
>
> I don't know where to draw the line between config and programming,
> but RADIUS pool management exists as a feature:
> https://urldefense.com/v3/__https://networkradius.com/doc/3.0.10/raddb
> /mods-available/ippool.html__;!!DUHle9IWsHMULw!P-ehjI-ohdHxatA_XeJ6Vl4
> -2sCjtMzvKvFkfNc5p50slKmLQK844sSuWiC-OjpJFiVxdso7$
Yep - for most use cases this works pretty well ?out of the box?. You should
also consider sqlippool, which has had a lot more work recently, particularly
with postgres as a DB. I have contributed some of those changes, and as a
?reference? case, for one customer I run reasonable size (low 6 figures) pools
in sqlippool with 15 min accounting updates and no scaling problems in sight.
The ippool module is quite old, and slow, and doesn?t support any failover if
you have multiple RADIUS servers. I don?t think it?s seen love in a number of
years.
PS - Make sure you run a recent FreeRADIUS - 3.0.10 is pretty old these days.
It only gets complicated and in to ?home-brew? territory if you?re wanting to
do complex policy. If you?re fine with a single ?pool? (which might be a single
pool with addresses from many subnets) then you?ll be fine.
If you want different users on different pools, a very easy solution is to pull
a pool name for that user from wherever your RADIUS users are stored (i.e. DB
or whatever), which is then used the sqlippool to look up an address to assign.
You have to do a little extra config in FreeRADIUS to handle that, but I think
that stuff might even be in the documentation as examples - it should be very
easy.
You can get really fancy with FreeRADIUS config - but for basic use cases you
don?t need to.
In my view, learning and operating a whole new system (DHCP server) is harder
than adding a bit of extra functionality to something you already have - RADIUS.
>>> IMHO, having the DHCP frontend on the edge makes life so much easier.
>>> Building a sufficiently redundant and robust centralized DHCP
>>> service is hard. And the edge router still has to do most of the
>>> same work anyway, relaying broadcasts and injecting access routes.
>>> The centralized DHCP server just adds an unneccessary single point
>>> of failure.
>>
>> I agree that it's a complication, but imo it's a reasonable tradeoff
>> for effective IP space usage. For relatively big IP pools it would be
>> sufficient saving. From KEA DHCP server documentation I see that
>> different scenarios for HA are supported, so some redundancy can be
>> achieved.
>
> IMHO, DHCP server failover has traditionally created more problems
> than it solved. But I have no experience with KEA, so let's hope it's
> just working now.
Centralised DHCP has three problems, in my view (and experience):
1) More resources. It has to process DHCP messages roughly every lease
half-life, x 2 or 3 if you are doing IPv6 IA_NA and IA_PD. RADIUS only
processes auth, then one update per session. In a broadband environment you
might want to have low DHCP timers so your customers re-connect if your BNG
loses state for some reason (interface down, reboot, etc.), which translates in
to a lot of messages. RADIUS-backed dhcp-local-server doesn?t mean more
processing, at least not noticeably so - the BNG is processing the DHCP
regardless of whether it?s relayed, or processed with RADIUS.
2) Fragile. Even with HA, your DHCP server *must* be available to keep
customers online. After a DHCP server outage of sufficient length, if your
network is of sufficient scale, you may find that the customers send
retransmissions of messages as your BNG and DHCP server try to get everyone
online - and that only pushes the DHCP server harder, causing more
retransmissions. You?ll hit control plane policers on your BNG, and it will be
a prolonged outage that comes in waves. With RADIUS based IP assignment, the
BNG handles RADIUS retransmissions (and failover to other RADIUS servers), and
blocks any CPEs sending lots of requests - either after an outage, or because
there?s some bug where it spams you with DHCP requests for some reason.
3) Static IPs. Static IPs in DHCP means your option82 (or similar) must be
correct - as that?s all the DHCP server sees. If you are using RADIUS, you can
use any parameter available to RADIUS in order to identify the customer and
hand out a static address. To the BNG, a static address for a RADIUS backed
DHCP subscriber looks just like a dynamic one, no special BNG config required
(same as DHCP relay).
It is good that you are considering KEA, which *somewhat* reduces these
concerns. ISC dhcpd restarting with a large number of addresses in a pool,
leases, etc. can sometimes take a long time - at which point you start dropping
customers offline as their leases expire, and the DHCP request storm starts.
Obviously though, my strong recommendation is to use RADIUS for this, despite
KEA being a little better than ISC dhcpd (where is where my war stories are
from).
>> Another question that puzzles me is how to use multiple discontinuous
>> pools with DHCP server. With Junos internal DHCP I can link DHCP
>> pools in the same way as for PPPoE and just assign additional GW IP
>> to lo0. With that Junos takes care of finding available IP in pools
>> and use proper GW address. In case of external DHCP server, router
>> has to insert relay option but how can it choose what subnet to use
>> in this case if there are more than one available? This problem
>> should be also actual for big cable segments, although for cable
>> interface IP addresses are directly configured on the interface, but
>> for Junos BNG a customer-facing interface is unnumbered.
>
> The subnet choice is always up to the DHCP server. You create a
> shared network with all the subnets and ranges that are supposed to
> share pools. This is similar to the linked pool in JUNOS. The server
> will select a free address in this shared network if the giaddr
> matches one of the configured subnets. Note that there doesn't have
> to be mathing range if you don't want to share giaddr and client subnets.
Just to pull this out and make it obvious, the key words here are ?shared
network?, which is a term used in the ISC dhcpd config to signal that subnets
configured in that shared network are to be treated as one big pool.
> All routers sharing a pool must have all the same GW addresses
> configured on lo0.
I don?t know if this is completely true, I *think* you can tell the DHCP relay
to replace the gateway address, but it certainly makes things easier so good to
just do that.
Note that you also must have a unique address as the primary address on the
interface as the giaddr - which the the centralised dhcp server talks to. If
that giaddr is shared across BNGs, your replies will go to the wrong place a
large % of the time, and not get to the subscriber.
The giaddr does not need to be an address in any of the subnets you want to
hand out addresses in - in isc dhcpd, you can configure the giaddr in a subnet
as part of the ?shared network? you want to hand out addresses from, which if
you have a lot of BNGs saves you a handful of addresses you can give to
customers.
Note that (from memory) the address used as the giaddr is also used as the
?DHCP server address?. It?s what your CPE will send renew messages to. That
does not confuse CPE, in my experience.
> I don't think this is any different whether you use the local DHCP
> server with RADIUS shared pool or a centralized DHCP server shared pool.
With RADIUS you can certainly hand out different router addresses for whatever
reason - though not sure why you?d want to.
--
Nathan Ward
------------------------------
Subject: Digest Footer
_______________________________________________
juniper-nsp mailing list
[email protected]
https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!DUHle9IWsHMULw!P-ehjI-ohdHxatA_XeJ6Vl4-2sCjtMzvKvFkfNc5p50slKmLQK844sSuWiC-OjpJFtN2Ndg1$
------------------------------
End of juniper-nsp Digest, Vol 224, Issue 2
*******************************************
--- End Message ---
