juniper-nsp Digest, Vol 224, Issue 2
Damon Vaughn
damon.vaughn at RocklandTrust.com
Thu Aug 12 14:18:49 EDT 2021
I see the ports in Plymouth as down
-----Original Message-----
From: juniper-nsp <juniper-nsp-bounces at puck.nether.net> On Behalf Of juniper-nsp-request at puck.nether.net
Sent: Tuesday, August 10, 2021 8:01 AM
To: juniper-nsp at puck.nether.net
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
juniper-nsp at puck.nether.net
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
juniper-nsp-request at puck.nether.net
You can reach the person managing the list at
juniper-nsp-owner at puck.nether.net
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 <ankost at podolsk.ru>
To: Jerry Jones <Jerry.Jones at walkerfirst.com>
Cc: Juniper nsp <juniper-nsp at puck.nether.net>
Subject: Re: [j-nsp] DHCP server recommendation for subscribers
management
Message-ID: <b9f18e8a3ab335686019c3334102f73a at podolsk.ru>
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 <bjorn at mork.no>
To: Andrey Kostin via juniper-nsp <juniper-nsp at puck.nether.net>
Subject: Re: [j-nsp] DHCP server recommendation for subscribers
management
Message-ID: <87lf5er0ik.fsf at miraculix.mork.no>
Content-Type: text/plain; charset=utf-8
Andrey Kostin via juniper-nsp <juniper-nsp at puck.nether.net> 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 <ankost at podolsk.ru>
To: Bj?rn Mork <bjorn at mork.no>
Cc: Andrey Kostin via juniper-nsp <juniper-nsp at puck.nether.net>
Subject: Re: [j-nsp] DHCP server recommendation for subscribers
management
Message-ID: <8f322f8aa20fd13170e22e0e56b4e8e0 at podolsk.ru>
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 <juniper-nsp at puck.nether.net> 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 <bjorn at mork.no>
To: Andrey Kostin via juniper-nsp <juniper-nsp at puck.nether.net>
Subject: Re: [j-nsp] DHCP server recommendation for subscribers
management
Message-ID: <87fsvmqsqh.fsf at miraculix.mork.no>
Content-Type: text/plain; charset=utf-8
Andrey Kostin <ankost at podolsk.ru> writes:
> Bj?rn Mork via juniper-nsp ????? 2021-08-06 12:38:
>> Andrey Kostin via juniper-nsp <juniper-nsp at puck.nether.net> 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 <ankost at podolsk.ru>
To: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] DHCP server recommendation for subscribers
management
Message-ID: <fd608365883d0d7a5158477cdda1a4d9 at podolsk.ru>
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 <bjorn at mork.no>
To: Andrey Kostin via juniper-nsp <juniper-nsp at puck.nether.net>
Subject: Re: [j-nsp] DHCP server recommendation for subscribers
management
Message-ID: <87r1f1lh0f.fsf at miraculix.mork.no>
Content-Type: text/plain; charset=utf-8
Andrey Kostin via juniper-nsp <juniper-nsp at puck.nether.net> 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 <juniper-nsp at daork.net>
To: Bj?rn Mork <bjorn at mork.no>
Cc: Andrey Kostin via juniper-nsp <juniper-nsp at puck.nether.net>
Subject: Re: [j-nsp] DHCP server recommendation for subscribers
management
Message-ID: <68C7BFE7-8307-4257-B8D7-FCDCC93633D4 at daork.net>
Content-Type: text/plain; charset=utf-8
> On 10/08/2021, at 10:40 PM, Bj?rn Mork via juniper-nsp <juniper-nsp at puck.nether.net> 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
juniper-nsp at puck.nether.net
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
*******************************************
More information about the juniper-nsp
mailing list