Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
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 kea-dev digest..."
Today's Topics:
1. kea 0.9.2 and tunl0 interfaces (Angelo Failla)
2. Re: kea 0.9.2 and tunl0 interfaces (Angelo Failla)
3. Re: kea 0.9.2 and tunl0 interfaces (Francis Dupont)
4. Re: kea 0.9.2 and tunl0 interfaces (Angelo Failla)
5. Re: Leasing from multiple IPv4 subnets to the same relay
(Marcin Siodelski)
----------------------------------------------------------------------
Message: 1
Date: Wed, 18 Nov 2015 14:16:29 +0000
From: Angelo Failla <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [kea-dev] kea 0.9.2 and tunl0 interfaces
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello everybody,
At Facebook we use BGP anycast technology to balance DHCP traffic. To do so we
advertise a global VIP via BGP, VIP that then ends up in the rack switch dhcp
relayers.
We then receive UDP datagrams that have the VIP IP as the destination IP,
therefore we need to bring up tunl0/ip6tnl0 interfaces onto our machines that
have the VIP assigned so that applications can get those datagrams destined to
the VIP address.
I?ve been testing kea 0.9.2 in our production environment and I?ve noticed a
regression compared to 0.9:
KEA refuses to listen on tunl0 or ip6tnl0 interfaces.
I get an error like this:
2015-11-18 06:09:11.451 WARN [kea-dhcp4.dhcpsrv/650885]
DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface tunl0 is down or
has no usable IPv4 addresses configured
Even though I assign an IP to the interface, see:
$ ip addr show tunl0
9: tunl0: <NOARP> mtu 0 qdisc noop state DOWN
link/ipip 0.0.0.0 brd 0.0.0.0
inet 10.127.255.68/32 scope global tunl0
valid_lft forever preferred_lft forever
And basically our DICOVERY packets are never seen by the server.
I am currently reading lib/dhcp/iface_mgr.cc but I wanted to give you an heads
up...
--
Angelo Failla
Cluster Infrastructure - Dublin
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20151118/89e17b21/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 18 Nov 2015 14:32:44 +0000
From: Angelo Failla <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] kea 0.9.2 and tunl0 interfaces
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
ok the problem was that I forgot to up the interface. :P
so I did a `ip link set dev tunl0 up` and now I see the server not complaining
about it anymore...
--
Angelo Failla
Cluster Infrastructure - Dublin
[email protected]
On 11/18/15, 2:16 PM, "Angelo Failla"
<[email protected]<mailto:[email protected]>> wrote:
Hello everybody,
At Facebook we use BGP anycast technology to balance DHCP traffic. To do so we
advertise a global VIP via BGP, VIP that then ends up in the rack switch dhcp
relayers.
We then receive UDP datagrams that have the VIP IP as the destination IP,
therefore we need to bring up tunl0/ip6tnl0 interfaces onto our machines that
have the VIP assigned so that applications can get those datagrams destined to
the VIP address.
I?ve been testing kea 0.9.2 in our production environment and I?ve noticed a
regression compared to 0.9:
KEA refuses to listen on tunl0 or ip6tnl0 interfaces.
I get an error like this:
2015-11-18 06:09:11.451 WARN [kea-dhcp4.dhcpsrv/650885]
DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface tunl0 is down or
has no usable IPv4 addresses configured
Even though I assign an IP to the interface, see:
$ ip addr show tunl0
9: tunl0: <NOARP> mtu 0 qdisc noop state DOWN
link/ipip 0.0.0.0 brd 0.0.0.0
inet 10.127.255.68/32 scope global tunl0
valid_lft forever preferred_lft forever
And basically our DICOVERY packets are never seen by the server.
I am currently reading lib/dhcp/iface_mgr.cc but I wanted to give you an heads
up...
--
Angelo Failla
Cluster Infrastructure - Dublin
[email protected]<mailto:[email protected]>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20151118/c7b9a680/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 18 Nov 2015 14:40:37 +0000
From: Francis Dupont <[email protected]>
To: Angelo Failla <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] kea 0.9.2 and tunl0 interfaces
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
ISC DHCP has a PREINIT script to solve this situation but I don't understand
how you can get an interface down on a server (PREINIT scripts are for
clients). IMHO you should launch Kea only when the interface is UP,
RUNNING and has an IPv4 address (it seems it doesn't matter this address
is 0.0.0.0).
Regards
Francis Dupont <[email protected]>
------------------------------
Message: 4
Date: Wed, 18 Nov 2015 14:49:14 +0000
From: Angelo Failla <[email protected]>
To: Francis Dupont <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] kea 0.9.2 and tunl0 interfaces
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
>ISC DHCP has a PREINIT script to solve this situation but I don't understand
>how you can get an interface down on a server (PREINIT scripts are for
>clients).
One word: containers. :P
>IMHO you should launch Kea only when the interface is UP,
>RUNNING and has an IPv4 address (it seems it doesn't matter this address
>is 0.0.0.0).
Yeah see my last message, was my fault I forgot to up the interface, now that
the interface is up the server doesn?t complain about tunl0.
However it?s still not responding to DISCOVER packets:
This is a tshark dump on the dhcp server side:
110.641303 10.88.105.10 -> 10.127.255.68 DHCP DHCP Discover - Transaction ID
0xc9cc2bea
110.641303 10.88.105.10 -> 10.127.255.68 DHCP DHCP Discover - Transaction ID
0xc9cc2bea
112.618545 10.88.105.10 -> 10.127.255.68 DHCP DHCP Discover - Transaction ID
0xc9cc2bea
112.618545 10.88.105.10 -> 10.127.255.68 DHCP DHCP Discover - Transaction ID
0xc9cc2bea
116.573179 10.88.105.10 -> 10.127.255.68 DHCP DHCP Discover - Transaction ID
0xc9cc2bea
116.573179 10.88.105.10 -> 10.127.255.68 DHCP DHCP Discover - Transaction ID
0xc9cc2bea
124.482385 10.88.105.10 -> 10.127.255.68 DHCP DHCP Discover - Transaction ID
0xc9cc2bea
124.482385 10.88.105.10 -> 10.127.255.68 DHCP DHCP Discover - Transaction ID
0xc9cc2bea
140.300951 10.88.105.10 -> 10.127.255.68 DHCP DHCP Discover - Transaction ID
0xc9cc2bea
140.300951 10.88.105.10 -> 10.127.255.68 DHCP DHCP Discover - Transaction ID
0xc9cc2bea
180.670604 10.88.105.10 -> 10.127.255.68 DHCP DHCP Discover - Transaction ID
0x150ab12
180.670604 10.88.105.10 -> 10.127.255.68 DHCP DHCP Discover - Transaction ID
0x150ab12
184.680157 10.88.105.10 -> 10.127.255.68 DHCP DHCP Discover - Transaction ID
0x150ab12
184.680157 10.88.105.10 -> 10.127.255.68 DHCP DHCP Discover - Transaction ID
0x150ab12
192.699151 10.88.105.10 -> 10.127.255.68 DHCP DHCP Discover - Transaction ID
0x150ab12
192.699151 10.88.105.10 -> 10.127.255.68 DHCP DHCP Discover - Transaction ID
0x150ab12
10.127.255.68 is the IP of the tunl0 interface
10.88.105.10 is the IP of the RSW dhcp relayer
Something is wrong there, I see the packets hitting my machine but the server
isn?t picking them up
I see nothing in the server logs.
Ip addr output on the dhcp server side:
6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:02:c9:dd:0d:5e brd ff:ff:ff:ff:ff:ff
inet 10.35.139.79/24 brd 10.35.139.255 scope global br0
valid_lft forever preferred_lft forever
inet6 2401:db00:3011:b:face:0:3b:0/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::202:c9ff:fedd:d5e/64 scope link
valid_lft forever preferred_lft forever
9: tunl0: <NOARP,UP,LOWER_UP> mtu 0 qdisc noqueue state UNKNOWN
link/ipip 0.0.0.0 brd 0.0.0.0
inet 10.127.255.68/32 scope global tunl0
valid_lft forever preferred_lft forever
Rack switch configuration:
interface Vlan2105
no ip redirects
ip address 10.88.105.10/24
ip directed-broadcast
ipv6 address 2401:db00:3010:4069::000a/64
ipv6 nd ra-interval 4
ipv6 nd prefix 2401:db00:3010:4069::/64
no ipv6 redirects
ip dhcp relay address 10.127.255.68 <????????? this is the same ip as in
tunl0 on the server side
no shutdown
mtu 9000
no autostate
description SERVERS
vrrp 1
priority 30
address 10.88.105.1
no shutdown
vrrp 2
priority 30
address 10.88.105.2
no shutdown
------------------------------
Message: 5
Date: Wed, 18 Nov 2015 15:55:54 +0100
From: Marcin Siodelski <[email protected]>
To: Guido Marelli <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Leasing from multiple IPv4 subnets to the same
relay
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Guido,
Kea treats "subnet" as a client's point of attachment and hence it
assumed that the particular client (on the particular link) belongs to
one subnet.
Together with fully fledged "client classification" (planned for Kea 1.1
release) Kea will get some more flexibility. In particular, it will be
possible to use expressions defining additional conditions for subnet
selection. In other words, it will be possible to select different
subnet, depending on what options the client has sent. This is to better
facilitate the case that I described in my first email to you, and also
other use cases like PXE boot etc.
Whether "client classification" will be suitable for the multi-network
scenario you're describing, it is up for consideration. I'd like to
understand this use case a bit more.
Suppose there is a single DHCPv4 server, single CMTS (relay) and a
single CPE. It probably doesn't matter from the server perspective
whether we're talking about the CM or router part of CPE trying to
obtain its DHCP configuration. The CPE initiates a DHCP exchange via
CMTS. The server receives message from the CPE. The server has three
networks (subnets and pools) configured, from which it could assign an
address and options to this CPE. The question is, how does the server
determine which subnet it should use to make this assignment? Relay
agent address doesn't appear to be sufficient because all networks are
associated with the same CMTS. I guess the server would need to look
into some specific options or fixed fields of the DHCPv4 message to make
this determination? Which fields and options?
I also wonder why multiple networks are needed for a single CPE? You say
that these networks are "the same". I am not sure I understand what it
means. They should at least have different (non-overlapping) address
pools? If this is the case, couldn't you just define a single subnet and
multiple address pools within the same subnet? Of course, that wouldn't
be feasible if they use a different address prefix. But, that I don't
know from your description.
Also, if the client has obtained an address from a given network/subnet,
is it possible for this client to move onto another network/subnet under
some conditions?
Another question about the matter of many networks. Would configuration
of these subnets include the same option sets? In other words, if the
client A obtains configuration from subnet/network X and the client B
obtains configuration from subnet/network Y, would they get the same
options, e.g. the same dns servers list etc?
I believe that client classification will support many, if not all, use
cases. However, there is always a possibility to write a custom hook
library which will customize server's behavior with respect to many
things, including subnet selection. If you decide to go down that path,
we can serve with advice.
Marcin
On 13.11.2015 15:58, Guido Marelli wrote:
> Hi Marcin, thank you for clarifying.
>
> On the other hand, a scenario that I have observed in many deployments
> with DHCPv4, is the existence of multiple networks configured in the
> same relay/CMTS that are eligible for leasing to the same type of
> device. This is: there is no difference between networks A, B and C but
> any of these networks can be use to assign addresses, for example, to
> CPEs.
>
> From your comments, I understand that this is now not possible with Kea:
> Do you plan to include this type of functionality?
>
>
> Guido Marelli
> Intraway Corp.
> Project Leader
> AR Office: +54 (11) 6040 4000 x4033
> US Office: +1 (516) 620 3890 X4033
>
> Mobile: +54 (911) 5424 9574
> Email: [email protected] <mailto:[email protected]>
>
>
> Visit our website at http://www.intraway.com <http://www.intraway.com/>
> Proud to be an ISO 9001:2008 certified company
>
>
> On Thu, Nov 12, 2015 at 6:25 AM, Marcin Siodelski <[email protected]
> <mailto:[email protected]>> wrote:
>
>
> On 10.11.2015 17:00, Guido Marelli wrote:
> > Hi,
> >
> > I'm analyzing the feasibility of using Kea in DOCSIS networks.
> However,
> > I didn't managed to configure Kea to use more than one IPv4
> subnet with
> > the same relay/giaddr.
> >
> > What I observed is that Kea depletes leases from the first
> subnet and
> > that the other subnets, which were configured with the same
> relay, are
> > ignored. I think this behavior is due to the method "CfgSubnets4 ::
> > selectSubnet" which iterates subnets until it finds the first subnet
> > that matches the giaddr, but it doesn't check lease availability.
> >
> > Any thoughts on this?
> >
> >
> > Regards,
> > Guido
> >
> >
> > Guido Marelli
> > Intraway Corp.
> > Project Leader
> > AR Office: +54 (11) 6040 4000 x4033
> > US Office: +1 (516) 620 3890 X4033
> >
> > Mobile: +54 (911) 5424 9574
> > Email: [email protected]
> <mailto:[email protected]>
> <mailto:[email protected]
> <mailto:[email protected]>>
> >
> >
> > Visit our website at http://www.intraway.com
> <http://www.intraway.com/>
> > Proud to be an ISO 9001:2008 certified company
> >
> >
> >
>
> Hi Guido,
>
> Thanks for your email and your interest in Kea.
>
> We have implemented "limited" support for DOCSIS in 2013 and
> successfully tested it with one cable network. This limited support
> facilitates the case when devices connected to the same link obtain
> addresses from different subnets. The devices are differentiated
> by the
> contents of the Vendor Class Identifier. It is assumed that that a
> device is a CM if the identifier is "docsis3.0". It is assumed
> that the
> device is a router if the identifier is "eRouter1.0".
>
> As per the Kea User's Guide:
> http://kea.isc.org/docs/kea-guide.html#dhcp4-client-classifier
>
> you can create a subnet with address pools dedicated exclusively
> for CMs
> with a configuration similar to this:
>
> "Dhcp4": {
> "subnet4": [
> {
> "subnet": "192.0.2.0/24 <http://192.0.2.0/24>",
> "pools": [ { "pool": "192.0.2.10 - 192.0.2.20" } ],
> "relay": {
> "ip-address": "10.0.0.1"
> },
> "client-class": "VENDOR_CLASS_docsis3.0"
> }
> ],
> ...
> }
>
> Note that the "docsis3.0" is an identifier sent in the Vendor Class
> Identifier option by CM. If your CMs send different identifier, the
> class name is "VENDOR_CLASS_<your-cm-identifier>".
>
> One final note. The "proper" implementation of DOCSIS requires full
> support for client classification, i.e. the server must be able to
> extract arbitrary expressions from various DHCP options and use
> them to
> assign a client to a particular class or set of classes. Then, classes
> are used to assign subnets, options etc according to the
> configuration.
> The first part of this generic client classification will be available
> with the Kea1.0 release (December 2015). The next release (Kea1.1) is
> fully devoted to finish up client classification. So, if the current
> "limited" support for DOCSIS is not sufficient for your
> deployment, you
> may wish to monitor the progress on client classification for 1.0 and
> 1.1 releases to make sure it would address your needs.
>
> I should also note that Kea has a built-in mechanism of "hooks" which
> allows for customizing packet processing at various stages. The server
> calls out to custom/user-defined C++ library to perform common tasks
> like subnet selection, options assignment etc. It is possible for
> you to
> create a simple C++ library which replaces standard subnet selection
> mechanism with customized one, required in your deployment.
>
> More about writing your own hooks can be found in Kea Developer's
> Guide:
>
> http://git.kea.isc.org/~tester/kea/doxygen/df/d46/hooksdgDevelopersGuide.html
>
> Marcin Siodelski
> DHCP Software Engineer
> ISC
>
>
>
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 20, Issue 8
**************************************
