Re: [Kea-users] Will v1.2 Support Massive Amounts of Subnets?

2016-09-14 Thread Joe Nelson
We looked at private VLAN's initially and it would definitely be a
more elegant solution.  At the time we did our testing it didn't look
like our wireless gear was going to play nice with the private VLAN's.
I wonder if I should re-visit that though.

Joe

On Wed, Sep 14, 2016 at 12:18 PM, Hugo Slabbert  wrote:
>
> On Tue 2016-Sep-13 13:25:09 -0600, Joe Nelson 
> wrote:
>
>> Hello, everyone.  I'm looking for some advice/help/suggestions.
>>
>> I work for a fixed wireless ISP.  We deliver a last mile connection to
>> our customers via a modified 802.11N or 802.11AC device (Ubiquiti).
>> We're working on an entirely new network topology that relies on
>> having a single VLAN per customer. Each VLAN will have a /29 of
>> private IPv4 or /30 public IPv4 and a /64 of IPv6 space. Without this
>> VLAN setup, all customers on a wireless access point would be in one
>> broadcast domain which is not acceptable to us.  In addition, the
>> individual VLAN's provide other benefits that are specific to a
>> wireless network.
>
>
> This may have floated already, but what about private VLANs?  Restrict
> direct inter-user access at L2, but still permit you to slice the VLANs
> based on capacity (i.e. more than a single VLAN per AP if that would be too
> large a broadcast domain, but less than 1 VLAN per customer) rather than
> requiring a single VLAN per customer.
>
> That may create its own set of challenges, though?
>
>
>> The problem I'm having is finding a DHCP server to hand out addresses
>> to so many VLAN's - and to configure it on the fly.  My idea is to
>> have DHCP relay enabled on the router at each site and a pair of DHCP
>> servers at the head end listening on anycast IP's.  The relay would
>> set option 82 with the appropriate router and VLAN information that
>> the DHCP server can use to classify the customer with.  Each time a
>> customer is provisioned, a new network/pool would need to be created
>> for their VLAN.  I would need to be able to load a new network/pool
>> into the server without manually editing config files or reloading the
>> server.  I'm not at all interested in tracking individual hosts since
>> these are end customer devices and can change without our knowledge, I
>> just need to configure the subnet per VLAN.
>>
>> I've been watching Kea for some time now and I believe that this will
>> be able to be done in the 1.2 version that's scheduled for (hopefully)
>> later this year.  Specifically, ticket 4285
>> (http://kea.isc.org/ticket/4285) seems to reference an API for
>> subnets.  Am I correct in understanding what this new API will do?
>> Also, how well will this scale?  We currently have approximately 9000
>> customers and provision about 20-25 new customers per day.  I don't
>> doubt that the server could handle the number of leases, but I don't
>> know if having everything split into so many subnets would affect
>> performance.
>>
>> Thank you,
>>
>> Joe Nelson
>> Senior Network Engineer
>> Utah Broadband
>
>
> --
> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
> pgp key: B178313E   | also on Signal
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users


Re: [Kea-users] PXE booting to PHP file and on commit, release, expiry

2016-09-14 Thread Klaus Steden
Yeah, I'm doing something similar with my iPXE setup -- although I have to
use the kkpxe variant because some of my servers are requesting a lease
twice and get two different leases, which KEA can't manage since it can't
isolate a single device lease.

On Wed, Sep 14, 2016 at 9:31 AM, Christoffer Jönsson 
wrote:

> Hi there.
>
> I have tried to find the ID using tcpdump on my dhcp server running
> openbsd. But I only get some kind useless output.
> Have tried these commands:
>
> tcpdump -lenx -s 1500 -i vio1 port bootps or port bootpc:
>
> 18:15:39.199104 36:39:31:35:37:30 ff:ff:ff:ff:ff:ff 0800 450: 0.0.0.0.68 >
> 255.255.255.255.67: xid:0x9f31e34 secs:14 vend-rfc1048 DHCP:REQUEST
> MSZ:1472 T93:0 T94:1.2.1 VC:80.88.69.67.108.105.101.
> 110.116.58.65.114.99.104.58.48.48.48.48.48.58.85.78.68.73.58.48.48.50.48.48.49
> T77:1766873157 
> PR:SM+DG+NS+LOG+HN+DN+RP+VO+VC+TFTP+BF+119+128+129+130+131+132+133+134+135+175+203
> T175:177.5.1.26.244.16.0.235.3.1.0.0.23.1.1.34.1.1.19.1.1.
> 17.1.1.39.1.1.25.1.1.16.1.2.33.1.1.21.1.1.24.1.1.18.1.1
> CID:1.54.57.49.53.55.48 T97:0.210.70.225.140.162.19.
> 12.66.131.81.115.228.78.228.23.33 SID:10.0.0.1 RQ:10.0.0.180
>
> *very long hex*
>
> 18:15:39.199613 36:34:36:65:61:31 36:39:31:35:37:30 0800 342:
> 10.0.0.181.67 > 10.0.0.180.68: xid:0x9f31e34 secs:14 Y:10.0.0.180
> S:10.0.0.9 sname "fw" file "http://10.0.0.9/tftp/boot.php;
>  vend-rfc1048 DHCP:ACK SID:10.0.0.1
> LT:7200 SM:255.255.255.0 DG:10.0.0.1 NS:10.0.0.23,10.0.0.1 HN:"in-cc01" DN:"
> chrjsn.se" [tos 0x10]
>
> *very long hex*
>
>
>  tcpdump -vlenxx -i vio1 -s 1500  port bootps or port bootpc:
>
> 18:22:21.56 36:39:31:35:37:30 ff:ff:ff:ff:ff:ff 0800 450: 0.0.0.0.68 >
> 255.255.255.255.67: [udp sum ok] xid:0x47cead35 secs:14 vend-rfc1048
> DHCP:REQUEST MSZ:1472 T93:0 T94:1.2.1 VC:80.88.69.67.108.105.101.
> 110.116.58.65.114.99.104.58.48.48.48.48.48.58.85.78.68.73.58.48.48.50.48.48.49
> T77:1766873157 
> PR:SM+DG+NS+LOG+HN+DN+RP+VO+VC+TFTP+BF+119+128+129+130+131+132+133+134+135+175+203
> T175:177.5.1.26.244.16.0.235.3.1.0.0.23.1.1.34.1.1.19.1.1.
> 17.1.1.39.1.1.25.1.1.16.1.2.33.1.1.21.1.1.24.1.1.18.1.1
> CID:1.54.57.49.53.55.48 T97:0.210.70.225.140.162.19.
> 12.66.131.81.115.228.78.228.23.33 SID:10.0.0.1 RQ:10.0.0.180 (ttl 64, id
> 873, len 436)
>
> *very long hex*
>
> 18:22:21.569432 36:34:36:65:61:31 36:39:31:35:37:30 0800 342:
> 10.0.0.181.67 > 10.0.0.180.68: [udp sum ok] xid:0x47cead35 secs:14
> Y:10.0.0.180 S:10.0.0.9 sname "fw" file "http://10.0.0.9/tftp/boot.php;
>  vend-rfc1048 DHCP:ACK SID:10.0.0.1
> LT:7200 SM:255.255.255.0 DG:10.0.0.1 NS:10.0.0.23,10.0.0.1 HN:"in-cc01" DN:"
> chrjsn.se" [tos 0x10] (ttl 128, id 0, len 328)
>
> *very long hex*
>
> tcpdump -i vio1 -s 1500 -vvv port bootps or port bootpc also gives similar
> results.
>
> But from what I've read from tcpdumps on google, the ID changes for
> different hardware.
> Isn't there a way to simply check if undionly.kpxe is loaded and then load
> the PHP?
>
> "if not exists gpxe.bus-id" worked for all devices and also with ipxe.
>
> Thanks!
>
>
> Hi Chris,
>
> 'd-i' is the DHCP signature of the preseed Debian Installer (hence,
> 'd-i'). I've only ever used iPXE, I've never used gPXE before it, so yeah,
> a couple of minutes with tcpdump to inspect the ID it's sending in the
> option string should help you along; once you have that ID field, change
> the test condition in the second stanza and you should be good to go.
>
> BTW the problem you're encountering with the looping boot process is one
> that affected ISC DHCP in a similar way, you just have to tune the
> conditions the DHCP server uses to distinguish the state of the booting
> client in order to direct it where you want to go. ... or flash iPXE on the
> firmware of all your servers hahaha :-)
>
> cheers,
> Klaus
>
> On Tue, Sep 13, 2016 at 9:29 AM, Christoffer Jönsson 
> wrote:
>
>>
>>
>> On 2016-09-12 22:58, Klaus Steden wrote:
>>
>>
>> I don't know about updating PowerDNS, but I suspect you'll have to write
>> a plugin. As for the designated boot menu, you can still do that, although
>> the syntax is different.
>>
>> This snippet below -should- do more or less what you're doing with
>> vanilla ISC DHCP:
>>
>> -- cut --
>>   "client-classes": [
>> {
>> "name": "bootstrap",
>> "test" : "option[60].exists
>> "option-data": [
>>   {
>> "name": "boot-file-name",
>> "data": "ipxe/undionly.kpxe"
>>   }
>> ]
>> },
>> {
>> "name": "preseed",
>> "test": "option[60].hex == 'd-i'",
>> "option-data": [
>>   {
>>   "data" : "http://10.0.0.9/tftp/boot.php;,
>>   "name" : "boot-file-name"
>>}
>> ]
>>  }
>>   ],
>> -- cut --
>>
>> You're probably going to have to tune that a bit, but this is the
>> approach I'm using to manage both server and switch 

Re: [Kea-users] Will v1.2 Support Massive Amounts of Subnets?

2016-09-14 Thread Hugo Slabbert


On Tue 2016-Sep-13 13:25:09 -0600, Joe Nelson  wrote:


Hello, everyone.  I'm looking for some advice/help/suggestions.

I work for a fixed wireless ISP.  We deliver a last mile connection to
our customers via a modified 802.11N or 802.11AC device (Ubiquiti).
We're working on an entirely new network topology that relies on
having a single VLAN per customer. Each VLAN will have a /29 of
private IPv4 or /30 public IPv4 and a /64 of IPv6 space. Without this
VLAN setup, all customers on a wireless access point would be in one
broadcast domain which is not acceptable to us.  In addition, the
individual VLAN's provide other benefits that are specific to a
wireless network.


This may have floated already, but what about private VLANs?  Restrict 
direct inter-user access at L2, but still permit you to slice the VLANs 
based on capacity (i.e. more than a single VLAN per AP if that would be too 
large a broadcast domain, but less than 1 VLAN per customer) rather than 
requiring a single VLAN per customer.


That may create its own set of challenges, though?


The problem I'm having is finding a DHCP server to hand out addresses
to so many VLAN's - and to configure it on the fly.  My idea is to
have DHCP relay enabled on the router at each site and a pair of DHCP
servers at the head end listening on anycast IP's.  The relay would
set option 82 with the appropriate router and VLAN information that
the DHCP server can use to classify the customer with.  Each time a
customer is provisioned, a new network/pool would need to be created
for their VLAN.  I would need to be able to load a new network/pool
into the server without manually editing config files or reloading the
server.  I'm not at all interested in tracking individual hosts since
these are end customer devices and can change without our knowledge, I
just need to configure the subnet per VLAN.

I've been watching Kea for some time now and I believe that this will
be able to be done in the 1.2 version that's scheduled for (hopefully)
later this year.  Specifically, ticket 4285
(http://kea.isc.org/ticket/4285) seems to reference an API for
subnets.  Am I correct in understanding what this new API will do?
Also, how well will this scale?  We currently have approximately 9000
customers and provision about 20-25 new customers per day.  I don't
doubt that the server could handle the number of leases, but I don't
know if having everything split into so many subnets would affect
performance.

Thank you,

Joe Nelson
Senior Network Engineer
Utah Broadband


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


signature.asc
Description: Digital signature
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users


Re: [Kea-users] PXE booting to PHP file and on commit, release, expiry

2016-09-14 Thread Christoffer Jönsson

Hi there.

I have tried to find the ID using tcpdump on my dhcp server running 
openbsd. But I only get some kind useless output.

Have tried these commands:

tcpdump -lenx -s 1500 -i vio1 port bootps or port bootpc:

   18:15:39.199104 36:39:31:35:37:30 ff:ff:ff:ff:ff:ff 0800 450:
   0.0.0.0.68 > 255.255.255.255.67: xid:0x9f31e34 secs:14 vend-rfc1048
   DHCP:REQUEST MSZ:1472 T93:0 T94:1.2.1
   
VC:80.88.69.67.108.105.101.110.116.58.65.114.99.104.58.48.48.48.48.48.58.85.78.68.73.58.48.48.50.48.48.49
   T77:1766873157
   
PR:SM+DG+NS+LOG+HN+DN+RP+VO+VC+TFTP+BF+119+128+129+130+131+132+133+134+135+175+203
   
T175:177.5.1.26.244.16.0.235.3.1.0.0.23.1.1.34.1.1.19.1.1.17.1.1.39.1.1.25.1.1.16.1.2.33.1.1.21.1.1.24.1.1.18.1.1
   CID:1.54.57.49.53.55.48
   T97:0.210.70.225.140.162.19.12.66.131.81.115.228.78.228.23.33
   SID:10.0.0.1 RQ:10.0.0.180

   *very long hex*

   18:15:39.199613 36:34:36:65:61:31 36:39:31:35:37:30 0800 342:
   10.0.0.181.67 > 10.0.0.180.68: xid:0x9f31e34 secs:14 Y:10.0.0.180
   S:10.0.0.9 sname "fw" file "http://10.0.0.9/tftp/boot.php;
   vend-rfc1048 DHCP:ACK SID:10.0.0.1 LT:7200 SM:255.255.255.0
   DG:10.0.0.1 NS:10.0.0.23,10.0.0.1 HN:"in-cc01" DN:"chrjsn.se" [tos 0x10]

   *very long hex*


 tcpdump -vlenxx -i vio1 -s 1500  port bootps or port bootpc:

   18:22:21.56 36:39:31:35:37:30 ff:ff:ff:ff:ff:ff 0800 450:
   0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] xid:0x47cead35 secs:14
   vend-rfc1048 DHCP:REQUEST MSZ:1472 T93:0 T94:1.2.1
   
VC:80.88.69.67.108.105.101.110.116.58.65.114.99.104.58.48.48.48.48.48.58.85.78.68.73.58.48.48.50.48.48.49
   T77:1766873157
   
PR:SM+DG+NS+LOG+HN+DN+RP+VO+VC+TFTP+BF+119+128+129+130+131+132+133+134+135+175+203
   
T175:177.5.1.26.244.16.0.235.3.1.0.0.23.1.1.34.1.1.19.1.1.17.1.1.39.1.1.25.1.1.16.1.2.33.1.1.21.1.1.24.1.1.18.1.1
   CID:1.54.57.49.53.55.48
   T97:0.210.70.225.140.162.19.12.66.131.81.115.228.78.228.23.33
   SID:10.0.0.1 RQ:10.0.0.180 (ttl 64, id 873, len 436)

   *very long hex*

   18:22:21.569432 36:34:36:65:61:31 36:39:31:35:37:30 0800 342:
   10.0.0.181.67 > 10.0.0.180.68: [udp sum ok] xid:0x47cead35 secs:14
   Y:10.0.0.180 S:10.0.0.9 sname "fw" file
   "http://10.0.0.9/tftp/boot.php; vend-rfc1048 DHCP:ACK SID:10.0.0.1
   LT:7200 SM:255.255.255.0 DG:10.0.0.1 NS:10.0.0.23,10.0.0.1
   HN:"in-cc01" DN:"chrjsn.se" [tos 0x10] (ttl 128, id 0, len 328)

   *very long hex*

tcpdump -i vio1 -s 1500 -vvv port bootps or port bootpc also gives 
similar results.


But from what I've read from tcpdumps on google, the ID changes for 
different hardware.
Isn't there a way to simply check if undionly.kpxe is loaded and then 
load the PHP?


"if not exists gpxe.bus-id" worked for all devices and also with ipxe.

Thanks!


Hi Chris,

'd-i' is the DHCP signature of the preseed Debian Installer (hence, 
'd-i'). I've only ever used iPXE, I've never used gPXE before it, so 
yeah, a couple of minutes with tcpdump to inspect the ID it's sending 
in the option string should help you along; once you have that ID 
field, change the test condition in the second stanza and you should 
be good to go.


BTW the problem you're encountering with the looping boot process is 
one that affected ISC DHCP in a similar way, you just have to tune the 
conditions the DHCP server uses to distinguish the state of the 
booting client in order to direct it where you want to go. ... or 
flash iPXE on the firmware of all your servers hahaha :-)


cheers,
Klaus

On Tue, Sep 13, 2016 at 9:29 AM, Christoffer Jönsson > wrote:




On 2016-09-12 22:58, Klaus Steden wrote:


I don't know about updating PowerDNS, but I suspect you'll have
to write a plugin. As for the designated boot menu, you can still
do that, although the syntax is different.

This snippet below -should- do more or less what you're doing
with vanilla ISC DHCP:

-- cut --
  "client-classes": [
{
"name": "bootstrap",
"test" : "option[60].exists
"option-data": [
  {
"name": "boot-file-name",
"data": "ipxe/undionly.kpxe"
  }
]
},
{
"name": "preseed",
"test": "option[60].hex == 'd-i'",
"option-data": [
  {
  "data" : "http://10.0.0.9/tftp/boot.php
",
  "name" : "boot-file-name"
   }
]
 }
  ],
-- cut --

You're probably going to have to tune that a bit, but this is the
approach I'm using to manage both server and switch booting, and
it works well.

hth,
Klaus

On Mon, Sep 12, 2016 at 11:57 AM, Christoffer Jönsson
> wrote:

Hello again!

Since the 1.1 release i decided to try and migrate from
isc-dhcp. And there is a few things I have questions about.

For years I have been