[Kea-users] Moving to implementing shared-networks

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[Kea-users] Moving to implementing shared-networks

Tim Požár
I am working with a small ISP that got a /22 of v4 space and is using
kea 1.6.2 in HA mode on two VMs.  From the /22 they use a /23 for DHCP
customers.  The rest is for statics, loopbacks, etc.

The servers are sitting behind a Juniper MX104 using subscriber services
so the stanard, get a dhcp packet with a particular DHCP Agent info of
double tag, start to build the demux interface, look the customer up in
Radius and assign them an IP address via DHCP and finish the demux
interface on the last DHCP ACK.

They have nearly exhausted the /23 so they would like to add another
small prefix (/26) to get them another 60 addresses or so to tied them
over until the can pick up another /22 or so to move their dhcp
customers too.

Working REDACTED config...
---
{
     "Dhcp4": {
         "interfaces-config": {
             "interfaces": [ "eth0", "eth1", "eth2" ]
         },
[...]
         "valid-lifetime": 4000,
         "renew-timer": 1000,
         "rebind-timer": 2000,
         "reservation-mode": "disabled",
         "control-socket": {
             "socket-type": "unix",
             "socket-name": "/tmp/kea-dhcp4-ctrl.sock"
         },
         "lease-database": {
             "type": "memfile",
             "persist": true,
             "name": "/var/lib/kea/kea-leases4.csv",
             "lfc-interval": 3600
         },
[...]
         "option-data": [
             {
                 "name": "domain-name-servers",
                 "data": "9.9.9.9, 8.8.8.8"
             }
         ],
[...]
         // For a list of available hook libraries, see
https://gitlab.isc.org/isc-projects/kea/wikis/Hooks-available
         "hooks-libraries": [
             {
                 "library": "/usr/lib64/kea/hooks/libdhcp_ha.so",
                 "parameters": {
                     "high-availability": [
                         {
                             "this-server-name": "dhcp01",
                             "mode": "load-balancing",
                             "peers": [
                                 {
                                     "name": "dhcp01",
                                     "url": "http://10.1.9.2:8080/",
                                     "role": "primary"
                                 },
                                 {
                                     "name": "dhcp02",
                                     "url": "http://10.1.9.3:8080/",
                                     "role": "secondary"
                                 }
                             ]
                         }
                     ]
                 }
             }
         ],
         "subnet4": [
             {
                 // "name": "Networks",
                 "option-data": [
                     {
                         "data": "1.2.3.1",
                         "name": "routers"
                     }
                 ],
                 "pools": [{"pool": "1.2.3.2 - 1.2.4.254"}],
                 "reservations": [],
                 "subnet": "1.2.3.0/23",
                 "relay": {
                     "ip-addresses": [ "1.2.3.1","1.2.5.1" ]
                 }
             },
[...]

I moved the subnet4 stanza for the 1.2.3.1/23 pool to a shared-network
stanza and added a new /26 that looks like:
[...]
         "shared-networks": [
             {
                 "name": "BNG-Users1",
                 "relay": {
                     "ip-addresses": [ "1.2.3.1","1.2.5.1" ]
                  },
                 "subnet4": [
                     {
                         // "name": "Customer Network Prefix #2",
                         "option-data": [
                             {
                                 "data": "1.2.5.1",
                                 "name": "routers"
                             }
                         ],
                         "pools": [{"pool": "1.2.5.2 - 1.2.5.62"}],
                         "reservations": [],
                         "subnet": "1.2.5.0/26",
                         "id": 5
                     },
                     {
                         // "name": "Customer Network Prefix #1",
                         "option-data": [
                             {
                                 "data": "1.2.3.1",
                                 "name": "routers"
                             }
                         ],
                         "pools": [{"pool": "1.2.3.2 - 1.2.4.254"}],
                         "reservations": [],
                         "subnet": "1.2.3.0/23",
                         "id": 110
                     }
                 ]
             }
         ],
[...]

In starting this up, it hands out the /26 pool and then doesn't assign
much (6 to 12) from the old /23 pool.  Reversing the prefixes will mean
it will only assign perhaps a dozen leases and then stops.

Running TCPDUMP on the Kea VMs I see a bunch of broken DHCP handshakes
where I see:

DHCP Discover
DHCP Offer

and not the full handshake of:
DHCP Discover
DHCP Offer
DHCP Request
DHCP ACK

Or I will see a number of Discover/Offer exchanges and after some time a
Discover/Offer/Request/ACK.

If I look at the API with something like:

curl -X POST -H "Content-Type: application/json" -d '{ "command":
"stat-lease4-get","service": [ "dhcp4" ]}' http://127.0.0.1:8080/ |
python3 -m json.tool
[
     {
         "arguments": {
             "result-set": {
                 "columns": [
                     "subnet-id",
                     "total-addreses",
                     "assigned-addreses",
                     "declined-addreses"
                 ],
                 "rows": [
                     [
                         1,
                         509,
                         499,
                         0
                     ],
                     [
                         2,
                         967,
                         0,
                         0
                     ],
                     [
                         3,
                         1013,
                         219,
                         0
                     ],
                     [
                         4,
                         1013,
                         0,
                         0
                     ]
                 ],
                 "timestamp": "2020-11-13 06:08:34.067055"
             }
         },
         "result": 0,
         "text": "stat-lease4-get[all subnets]: 4 rows found"
     }
]

This is an example of a working dhcp server.  If I try the
shared-networks, the pools always show 0 assigned-addresses.

Is shared-networks pretty stable on 1.6.2?  Any suggestion on why only a
small percent or none of these handshakes work?  Any suggestion on
debugging this further?  I did create some rather large kea logs with
logging set to DEBUG and debug set to 99 if that can be of help.

Tim Pozar




_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Moving to implementing shared-networks

Peter Davies
Hi Tim,
   I notice that you are using "subnet id"s in the "shared network" example whereas in your non "shared network example there appears to be no "subnet id"s.
Also the "subnet id"s returned in "stat-lease4-get" call don't seem to match your config?
If you are seeing relayed "offers" being sent from Kea but no "requests" being received then either
  1. The offers are not getting through to the client
  2. The requests from the client are not get back to Kea
  3. The client doesn't like the offer and does not send a request or it has received an offer from some other source that it requests. If the reason is that the client for some reason does not like the offer then you should be seeing multiple discoveries from the client 
Clients that already have leases should be unicasting renewal requests directly to Kea.

/Peter

Sent from Outlook

From: Kea-users <[hidden email]> on behalf of Tim Požár <[hidden email]>
Sent: 14 November 2020 02:05
To: [hidden email] <[hidden email]>
Subject: [Kea-users] Moving to implementing shared-networks
 
I am working with a small ISP that got a /22 of v4 space and is using
kea 1.6.2 in HA mode on two VMs.  From the /22 they use a /23 for DHCP
customers.  The rest is for statics, loopbacks, etc.

The servers are sitting behind a Juniper MX104 using subscriber services
so the stanard, get a dhcp packet with a particular DHCP Agent info of
double tag, start to build the demux interface, look the customer up in
Radius and assign them an IP address via DHCP and finish the demux
interface on the last DHCP ACK.

They have nearly exhausted the /23 so they would like to add another
small prefix (/26) to get them another 60 addresses or so to tied them
over until the can pick up another /22 or so to move their dhcp
customers too.

Working REDACTED config...
---
{
     "Dhcp4": {
         "interfaces-config": {
             "interfaces": [ "eth0", "eth1", "eth2" ]
         },
[...]
         "valid-lifetime": 4000,
         "renew-timer": 1000,
         "rebind-timer": 2000,
         "reservation-mode": "disabled",
         "control-socket": {
             "socket-type": "unix",
             "socket-name": "/tmp/kea-dhcp4-ctrl.sock"
         },
         "lease-database": {
             "type": "memfile",
             "persist": true,
             "name": "/var/lib/kea/kea-leases4.csv",
             "lfc-interval": 3600
         },
[...]
         "option-data": [
             {
                 "name": "domain-name-servers",
                 "data": "9.9.9.9, 8.8.8.8"
             }
         ],
[...]
         // For a list of available hook libraries, see
https://gitlab.isc.org/isc-projects/kea/wikis/Hooks-available
         "hooks-libraries": [
             {
                 "library": "/usr/lib64/kea/hooks/libdhcp_ha.so",
                 "parameters": {
                     "high-availability": [
                         {
                             "this-server-name": "dhcp01",
                             "mode": "load-balancing",
                             "peers": [
                                 {
                                     "name": "dhcp01",
                                     "url": "http://10.1.9.2:8080/",
                                     "role": "primary"
                                 },
                                 {
                                     "name": "dhcp02",
                                     "url": "http://10.1.9.3:8080/",
                                     "role": "secondary"
                                 }
                             ]
                         }
                     ]
                 }
             }
         ],
         "subnet4": [
             {
                 // "name": "Networks",
                 "option-data": [
                     {
                         "data": "1.2.3.1",
                         "name": "routers"
                     }
                 ],
                 "pools": [{"pool": "1.2.3.2 - 1.2.4.254"}],
                 "reservations": [],
                 "subnet": "1.2.3.0/23",
                 "relay": {
                     "ip-addresses": [ "1.2.3.1","1.2.5.1" ]
                 }
             },
[...]

I moved the subnet4 stanza for the 1.2.3.1/23 pool to a shared-network
stanza and added a new /26 that looks like:
[...]
         "shared-networks": [
             {
                 "name": "BNG-Users1",
                 "relay": {
                     "ip-addresses": [ "1.2.3.1","1.2.5.1" ]
                  },
                 "subnet4": [
                     {
                         // "name": "Customer Network Prefix #2",
                         "option-data": [
                             {
                                 "data": "1.2.5.1",
                                 "name": "routers"
                             }
                         ],
                         "pools": [{"pool": "1.2.5.2 - 1.2.5.62"}],
                         "reservations": [],
                         "subnet": "1.2.5.0/26",
                         "id": 5
                     },
                     {
                         // "name": "Customer Network Prefix #1",
                         "option-data": [
                             {
                                 "data": "1.2.3.1",
                                 "name": "routers"
                             }
                         ],
                         "pools": [{"pool": "1.2.3.2 - 1.2.4.254"}],
                         "reservations": [],
                         "subnet": "1.2.3.0/23",
                         "id": 110
                     }
                 ]
             }
         ],
[...]

In starting this up, it hands out the /26 pool and then doesn't assign
much (6 to 12) from the old /23 pool.  Reversing the prefixes will mean
it will only assign perhaps a dozen leases and then stops.

Running TCPDUMP on the Kea VMs I see a bunch of broken DHCP handshakes
where I see:

DHCP Discover
DHCP Offer

and not the full handshake of:
DHCP Discover
DHCP Offer
DHCP Request
DHCP ACK

Or I will see a number of Discover/Offer exchanges and after some time a
Discover/Offer/Request/ACK.

If I look at the API with something like:

curl -X POST -H "Content-Type: application/json" -d '{ "command":
"stat-lease4-get","service": [ "dhcp4" ]}' http://127.0.0.1:8080/ |
python3 -m json.tool
[
     {
         "arguments": {
             "result-set": {
                 "columns": [
                     "subnet-id",
                     "total-addreses",
                     "assigned-addreses",
                     "declined-addreses"
                 ],
                 "rows": [
                     [
                         1,
                         509,
                         499,
                         0
                     ],
                     [
                         2,
                         967,
                         0,
                         0
                     ],
                     [
                         3,
                         1013,
                         219,
                         0
                     ],
                     [
                         4,
                         1013,
                         0,
                         0
                     ]
                 ],
                 "timestamp": "2020-11-13 06:08:34.067055"
             }
         },
         "result": 0,
         "text": "stat-lease4-get[all subnets]: 4 rows found"
     }
]

This is an example of a working dhcp server.  If I try the
shared-networks, the pools always show 0 assigned-addresses.

Is shared-networks pretty stable on 1.6.2?  Any suggestion on why only a
small percent or none of these handshakes work?  Any suggestion on
debugging this further?  I did create some rather large kea logs with
logging set to DEBUG and debug set to 99 if that can be of help.

Tim Pozar




_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Moving to implementing shared-networks

Tim Požár
Peter...

Thanks for getting back on this.   Alas, I had my head in a data center
this weekend.

We started off with no IDs in the non-shared example and found that
moving to the shared example and adding the new prefix, we had a
conflict with the leases db.  In looking through the documentation, it
suggested we assign Ids to pools, which make sense.  That was added to
avoid the conflict in the prefixes.

The API call I demostrated was for the non-shared config in showing that
we were able to get leases out that way.  Alas, I didn't keep the result
from the API call when we tried to move to a shared-networks config.  My
bad.

I do have PCAP files for both servers from the time we were trying to
deploy this.  Would that be helpful?

Tim

On 11/14/20 1:27 AM, Peter Davies wrote:

> Hi Tim,
>     I notice that you are using "subnet id"s in the "shared network"
> example whereas in your non "shared network example there appears to be
> no "subnet id"s.
> Also the "subnet id"s returned in "stat-lease4-get" call don't seem to
> match your config?
> If you are seeing relayed "offers" being sent from Kea but no "requests"
> being received then either
>
>  1. The offers are not getting through to the client
>  2. The requests from the client are not get back to Kea
>  3. The client doesn't like the offer and does not send a request or it
>     has received an offer from some other source that it requests. If
>     the reason is that the client for some reason does not like the
>     offer then you should be seeing multiple discoveries from the client
>
> Clients that already have leases should be unicasting renewal requests
> directly to Kea.
>
> /Peter
>
> Sent from Outlook <http://aka.ms/weboutlook>
> ------------------------------------------------------------------------
> *From:* Kea-users <[hidden email]> on behalf of Tim
> Požár <[hidden email]>
> *Sent:* 14 November 2020 02:05
> *To:* [hidden email] <[hidden email]>
> *Subject:* [Kea-users] Moving to implementing shared-networks
> I am working with a small ISP that got a /22 of v4 space and is using
> kea 1.6.2 in HA mode on two VMs.  From the /22 they use a /23 for DHCP
> customers.  The rest is for statics, loopbacks, etc.
>
> The servers are sitting behind a Juniper MX104 using subscriber services
> so the stanard, get a dhcp packet with a particular DHCP Agent info of
> double tag, start to build the demux interface, look the customer up in
> Radius and assign them an IP address via DHCP and finish the demux
> interface on the last DHCP ACK.
>
> They have nearly exhausted the /23 so they would like to add another
> small prefix (/26) to get them another 60 addresses or so to tied them
> over until the can pick up another /22 or so to move their dhcp
> customers too.
>
> Working REDACTED config...
> ---
> {
>       "Dhcp4": {
>           "interfaces-config": {
>               "interfaces": [ "eth0", "eth1", "eth2" ]
>           },
> [...]
>           "valid-lifetime": 4000,
>           "renew-timer": 1000,
>           "rebind-timer": 2000,
>           "reservation-mode": "disabled",
>           "control-socket": {
>               "socket-type": "unix",
>               "socket-name": "/tmp/kea-dhcp4-ctrl.sock"
>           },
>           "lease-database": {
>               "type": "memfile",
>               "persist": true,
>               "name": "/var/lib/kea/kea-leases4.csv",
>               "lfc-interval": 3600
>           },
> [...]
>           "option-data": [
>               {
>                   "name": "domain-name-servers",
>                   "data": "9.9.9.9, 8.8.8.8"
>               }
>           ],
> [...]
>           // For a list of available hook libraries, see
> https://gitlab.isc.org/isc-projects/kea/wikis/Hooks-available 
> <https://gitlab.isc.org/isc-projects/kea/wikis/Hooks-available>
>           "hooks-libraries": [
>               {
>                   "library": "/usr/lib64/kea/hooks/libdhcp_ha.so",
>                   "parameters": {
>                       "high-availability": [
>                           {
>                               "this-server-name": "dhcp01",
>                               "mode": "load-balancing",
>                               "peers": [
>                                   {
>                                       "name": "dhcp01",
>                                       "url": "http://10.1.9.2:8080/ 
> <http://10.1.9.2:8080/>",
>                                       "role": "primary"
>                                   },
>                                   {
>                                       "name": "dhcp02",
>                                       "url": "http://10.1.9.3:8080/ 
> <http://10.1.9.3:8080/>",
>                                       "role": "secondary"
>                                   }
>                               ]
>                           }
>                       ]
>                   }
>               }
>           ],
>           "subnet4": [
>               {
>                   // "name": "Networks",
>                   "option-data": [
>                       {
>                           "data": "1.2.3.1",
>                           "name": "routers"
>                       }
>                   ],
>                   "pools": [{"pool": "1.2.3.2 - 1.2.4.254"}],
>                   "reservations": [],
>                   "subnet": "1.2.3.0/23",
>                   "relay": {
>                       "ip-addresses": [ "1.2.3.1","1.2.5.1" ]
>                   }
>               },
> [...]
>
> I moved the subnet4 stanza for the 1.2.3.1/23 pool to a shared-network
> stanza and added a new /26 that looks like:
> [...]
>           "shared-networks": [
>               {
>                   "name": "BNG-Users1",
>                   "relay": {
>                       "ip-addresses": [ "1.2.3.1","1.2.5.1" ]
>                    },
>                   "subnet4": [
>                       {
>                           // "name": "Customer Network Prefix #2",
>                           "option-data": [
>                               {
>                                   "data": "1.2.5.1",
>                                   "name": "routers"
>                               }
>                           ],
>                           "pools": [{"pool": "1.2.5.2 - 1.2.5.62"}],
>                           "reservations": [],
>                           "subnet": "1.2.5.0/26",
>                           "id": 5
>                       },
>                       {
>                           // "name": "Customer Network Prefix #1",
>                           "option-data": [
>                               {
>                                   "data": "1.2.3.1",
>                                   "name": "routers"
>                               }
>                           ],
>                           "pools": [{"pool": "1.2.3.2 - 1.2.4.254"}],
>                           "reservations": [],
>                           "subnet": "1.2.3.0/23",
>                           "id": 110
>                       }
>                   ]
>               }
>           ],
> [...]
>
> In starting this up, it hands out the /26 pool and then doesn't assign
> much (6 to 12) from the old /23 pool.  Reversing the prefixes will mean
> it will only assign perhaps a dozen leases and then stops.
>
> Running TCPDUMP on the Kea VMs I see a bunch of broken DHCP handshakes
> where I see:
>
> DHCP Discover
> DHCP Offer
>
> and not the full handshake of:
> DHCP Discover
> DHCP Offer
> DHCP Request
> DHCP ACK
>
> Or I will see a number of Discover/Offer exchanges and after some time a
> Discover/Offer/Request/ACK.
>
> If I look at the API with something like:
>
> curl -X POST -H "Content-Type: application/json" -d '{ "command":
> "stat-lease4-get","service": [ "dhcp4" ]}' http://127.0.0.1:8080/ 
> <http://127.0.0.1:8080/> |
> python3 -m json.tool
> [
>       {
>           "arguments": {
>               "result-set": {
>                   "columns": [
>                       "subnet-id",
>                       "total-addreses",
>                       "assigned-addreses",
>                       "declined-addreses"
>                   ],
>                   "rows": [
>                       [
>                           1,
>                           509,
>                           499,
>                           0
>                       ],
>                       [
>                           2,
>                           967,
>                           0,
>                           0
>                       ],
>                       [
>                           3,
>                           1013,
>                           219,
>                           0
>                       ],
>                       [
>                           4,
>                           1013,
>                           0,
>                           0
>                       ]
>                   ],
>                   "timestamp": "2020-11-13 06:08:34.067055"
>               }
>           },
>           "result": 0,
>           "text": "stat-lease4-get[all subnets]: 4 rows found"
>       }
> ]
>
> This is an example of a working dhcp server.  If I try the
> shared-networks, the pools always show 0 assigned-addresses.
>
> Is shared-networks pretty stable on 1.6.2?  Any suggestion on why only a
> small percent or none of these handshakes work?  Any suggestion on
> debugging this further?  I did create some rather large kea logs with
> logging set to DEBUG and debug set to 99 if that can be of help.
>
> Tim Pozar
>
>
>
>
> _______________________________________________
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ 
> <https://www.isc.org/contact/> for more information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users 
> <https://lists.isc.org/mailman/listinfo/kea-users>.
>
> Kea-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/kea-users 
> <https://lists.isc.org/mailman/listinfo/kea-users>
_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users