[Kea-users] Lease allocation on option 82

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

[Kea-users] Lease allocation on option 82

Bjørn Skovlund
Hi,

I'm rather new to KEA, so I might be asking an obvious question.

We added the premium hooks, in the interest of the flex-id, however I'm coming up a bit short for our use-case.

We want to assign leases based on option 82, sub 2, which I've extracted with the flex-id and mapped to client-id with replace-client-id. However, it seems that this only works for host reservations and I was hoping to use it for lease assignment.

Use case:
We get endusers online with unknown option 82 and want to assign one, and only one, IP address to this option 82, sub 2. If the enduser comes online with a new MAC address, we want to offer them the same IP that they originally got.

It seems this would be possible with a host reservation on the client-id, but I'm trying to avoid having to copy the lease information into host reservations.

Is this possible?

Best, Bjorn

_______________________________________________
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] Lease allocation on option 82

Francis Dupont
=?UTF-8?Q?Bj=C3=B8rn_Skovlund?= writes:
> I'm rather new to KEA, so I might be asking an obvious question.
>
> We added the premium hooks, in the interest of the flex-id, however I'm
> coming up a bit short for our use-case.
>
> We want to assign leases based on option 82, sub 2, which I've extracted
> with the flex-id and mapped to client-id with replace-client-id. However,
> it seems that this only works for host reservations and I was hoping to use
> it for lease assignment.

=> with replace-client-id it should work with leases too even the flex-id
feature was designed mainly for host reservations.

> Use case:
> We get endusers online with unknown option 82 and want to assign one, and
> only one, IP address to this option 82, sub 2. If the enduser comes online
> with a new MAC address, we want to offer them the same IP that they
> originally got.

=> if the synthesized client-id is the same it should be considered as
the same client (unless match-client-id was explicitly set to false).
But this does not enforce to get the same IP: you need a known lease for
the client and expired leases are reclaimed (so become unknown) after a
(settable) delay.

> It seems this would be possible with a host reservation on the client-id,
> but I'm trying to avoid having to copy the lease information into host
> reservations.

=> host reservations are of course the only way to really reserve an address.
But you can play with lifetime and expired-leases-processing timers to
make more likely a client to get the same IP address.

Regards

Francis Dupont <[hidden email]>
_______________________________________________
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] Lease allocation on option 82

Bjørn Skovlund
Hi Francis,

Thanks for the prompt reply!

On Thu, May 2, 2019 at 12:48 PM Francis Dupont <[hidden email]> wrote:
> It seems this would be possible with a host reservation on the client-id,
> but I'm trying to avoid having to copy the lease information into host
> reservations.

=> host reservations are of course the only way to really reserve an address.
But you can play with lifetime and expired-leases-processing timers to
make more likely a client to get the same IP address.

I'm not that concerned about getting the same IP, but more concerned about not handing out multiple addresses to the same client-id.

I think my problem, and misunderstanding of the client-id when it comes to lease allocation, may stem from having an active-active HA setup. It seems I am limited to two IP addresses, one from each of the servers. It could look a bit like my replication of IP addresses broke when I enabled the flex-id.

I'll have a closer look at those.

Thanks for your help.

Best, Bjorn 

_______________________________________________
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] Lease allocation on option 82

Bjørn Skovlund
Hi again,

I haven't debugged the logic completely, but it seems a bit inconsistent.

If I have two DHCP servers in HA mode, using flex-id to map to client-id with a value that's the same for two clients, they will get a lease each - one from each server I believe. Whichever one last did the REQUEST, will be the only entry in the database, as the client-id is the same.

What I was hoping to get to, is that a specific client-id can only ever take up one IP, which the client changing hwaddr will result in being offered the same IP as the client-id had with the first hwaddr. Is this a possibility?

Would an active-standby scenario work better for this use-case?

Config for test bed is attached below:
{
    "Dhcp4": {
        "control-socket": {
            "socket-name": "/opt/run/kea-dhcp4/kea.socket",
            "socket-type": "unix"
        },
        "dhcp-ddns": {
            "enable-updates": false
        },
        "expired-leases-processing": {
            "flush-reclaimed-timer-wait-time": 25,
            "hold-reclaimed-time": 3600,
            "max-reclaim-leases": 100,
            "max-reclaim-time": 250,
            "reclaim-timer-wait-time": 10,
            "unwarned-reclaim-cycles": 5
        },
        "hooks-libraries": [
            {
                "library": "/usr/local/lib/hooks/libdhcp_lease_cmds.so",
                "parameters": {}
            },
            {
                "library": "/usr/local/lib/hooks/libdhcp_host_cmds.so",
                "parameters": {}
            },
            {
                "library": "/usr/local/lib/hooks/libdhcp_legal_log.so",
                "parameters": {
                    "base-name": "kea-forensic4",
                    "path": "/var/kea/log"
                }
            },
            {
                "library": "/usr/local/lib/hooks/libdhcp_flex_id.so",
                "parameters": {
                    "identifier-expression": "relay4[9].hex",
                    "replace-client-id": true
                }
            },
            {
                "library": "/usr/local/lib/hooks/libdhcp_ha.so",
                "parameters": {
                    "high-availability": [
                        {
                            "heartbeat-delay": 1000,
                            "max-ack-delay": 5000,
                            "max-response-delay": 10000,
                            "max-unacked-clients": 0,
                            "mode": "load-balancing",
                            "peers": [
                                {
                                    "name": "dhcp-01.test.site.fastspeed.dk",
                                    "role": "primary",
                                    "url": "http://172.16.1.2:8079"
                                },
                                {
                                    "name": "dhcp-02.test.site.fastspeed.dk",
                                    "role": "secondary",
                                    "url": "http://172.16.1.3:8079"
                                }
                            ],
                            "sync-timeout": 60000,
                            "this-server-name": "dhcp-02.test.site.fastspeed.dk"
                        }
                    ]
                }
            }
        ],
        "host-reservation-identifiers": [
            "client-id"
        ],
        "hosts-database": {
            "host": "snip",
            "name": "kea",
            "password": "snip",
            "type": "mysql",
            "user": "kea"
        },
        "interfaces-config": {
            "dhcp-socket-type": "udp",
            "interfaces": [
                "*"
            ]
        },
        "lease-database": {
            "host": "snip",
            "name": "kea",
            "password": "snip",
            "type": "mysql",
            "user": "kea"
        },
        "match-client-id": true,
        "next-server": "0.0.0.0",
        "option-data": [
            {
                "data": "8.8.8.8, 8.8.4.4",
                "name": "domain-name-servers"
            }
        ],
        "rebind-timer": 600,
        "renew-timer": 300,
        "subnet4": [
            {
                "id": 1684209664,
                "option-data": [
                    {
                        "data": "100.99.0.1",
                        "name": "routers"
                    },
                    {
                        "data": "8.8.8.8, 8.8.4.4",
                        "name": "domain-name-servers"
                    },
                    {
                        "data": "172.16.1.3",
                        "name": "dhcp-server-identifier"
                    }
                ],
                "pools": [
                    {
                        "client-class": "HA_dhcp-01",
                        "pool": "100.99.0.2 - 100.99.0.247"
                    },
                    {
                        "client-class": "HA_dhcp-02",
                        "pool": "100.99.0.248 - 100.99.1.238"
                    }
                ],
                "subnet": "100.99.0.0/23"
            }
        ],
        "valid-lifetime": 1200
    }
}


On Thu, May 2, 2019 at 2:44 PM Bjørn Skovlund <[hidden email]> wrote:
Hi Francis,

Thanks for the prompt reply!

On Thu, May 2, 2019 at 12:48 PM Francis Dupont <[hidden email]> wrote:
> It seems this would be possible with a host reservation on the client-id,
> but I'm trying to avoid having to copy the lease information into host
> reservations.

=> host reservations are of course the only way to really reserve an address.
But you can play with lifetime and expired-leases-processing timers to
make more likely a client to get the same IP address.

I'm not that concerned about getting the same IP, but more concerned about not handing out multiple addresses to the same client-id.

I think my problem, and misunderstanding of the client-id when it comes to lease allocation, may stem from having an active-active HA setup. It seems I am limited to two IP addresses, one from each of the servers. It could look a bit like my replication of IP addresses broke when I enabled the flex-id.

I'll have a closer look at those.

Thanks for your help.

Best, Bjorn 

_______________________________________________
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] Lease allocation on option 82

Matt Peterson
Suggest removing the HA portion first to confirm the ideal host lease scheme is working correctly.

We are trying to change the Kea behaviour of lease allocations - being based purely on source MAC address, to instead include source MAC + option 82 information. This syntax appears to be valid but testing has been mixed in our limited experience, further debugging is needed but maybe this approach would work for you too.

    "Dhcp4": {
        "match-client-id": true,
        "reservation-mode": "disabled",
...
                "library": "/usr/lib64/kea/hooks/libdhcp_flex_id.so",
                "parameters": {
                    "identifier-expression": "concat(relay4[1].hex, hexstring(pkt4.mac, ':'))",
                    "replace-client-id": true

--Matt

On Thu, May 9, 2019 at 9:02 AM Bjørn Skovlund <[hidden email]> wrote:
Hi again,

I haven't debugged the logic completely, but it seems a bit inconsistent.

If I have two DHCP servers in HA mode, using flex-id to map to client-id with a value that's the same for two clients, they will get a lease each - one from each server I believe. Whichever one last did the REQUEST, will be the only entry in the database, as the client-id is the same.

What I was hoping to get to, is that a specific client-id can only ever take up one IP, which the client changing hwaddr will result in being offered the same IP as the client-id had with the first hwaddr. Is this a possibility?

Would an active-standby scenario work better for this use-case?

Config for test bed is attached below:
{
    "Dhcp4": {
        "control-socket": {
            "socket-name": "/opt/run/kea-dhcp4/kea.socket",
            "socket-type": "unix"
        },
        "dhcp-ddns": {
            "enable-updates": false
        },
        "expired-leases-processing": {
            "flush-reclaimed-timer-wait-time": 25,
            "hold-reclaimed-time": 3600,
            "max-reclaim-leases": 100,
            "max-reclaim-time": 250,
            "reclaim-timer-wait-time": 10,
            "unwarned-reclaim-cycles": 5
        },
        "hooks-libraries": [
            {
                "library": "/usr/local/lib/hooks/libdhcp_lease_cmds.so",
                "parameters": {}
            },
            {
                "library": "/usr/local/lib/hooks/libdhcp_host_cmds.so",
                "parameters": {}
            },
            {
                "library": "/usr/local/lib/hooks/libdhcp_legal_log.so",
                "parameters": {
                    "base-name": "kea-forensic4",
                    "path": "/var/kea/log"
                }
            },
            {
                "library": "/usr/local/lib/hooks/libdhcp_flex_id.so",
                "parameters": {
                    "identifier-expression": "relay4[9].hex",
                    "replace-client-id": true
                }
            },
            {
                "library": "/usr/local/lib/hooks/libdhcp_ha.so",
                "parameters": {
                    "high-availability": [
                        {
                            "heartbeat-delay": 1000,
                            "max-ack-delay": 5000,
                            "max-response-delay": 10000,
                            "max-unacked-clients": 0,
                            "mode": "load-balancing",
                            "peers": [
                                {
                                    "name": "dhcp-01.test.site.fastspeed.dk",
                                    "role": "primary",
                                    "url": "http://172.16.1.2:8079"
                                },
                                {
                                    "name": "dhcp-02.test.site.fastspeed.dk",
                                    "role": "secondary",
                                    "url": "http://172.16.1.3:8079"
                                }
                            ],
                            "sync-timeout": 60000,
                            "this-server-name": "dhcp-02.test.site.fastspeed.dk"
                        }
                    ]
                }
            }
        ],
        "host-reservation-identifiers": [
            "client-id"
        ],
        "hosts-database": {
            "host": "snip",
            "name": "kea",
            "password": "snip",
            "type": "mysql",
            "user": "kea"
        },
        "interfaces-config": {
            "dhcp-socket-type": "udp",
            "interfaces": [
                "*"
            ]
        },
        "lease-database": {
            "host": "snip",
            "name": "kea",
            "password": "snip",
            "type": "mysql",
            "user": "kea"
        },
        "match-client-id": true,
        "next-server": "0.0.0.0",
        "option-data": [
            {
                "data": "8.8.8.8, 8.8.4.4",
                "name": "domain-name-servers"
            }
        ],
        "rebind-timer": 600,
        "renew-timer": 300,
        "subnet4": [
            {
                "id": 1684209664,
                "option-data": [
                    {
                        "data": "100.99.0.1",
                        "name": "routers"
                    },
                    {
                        "data": "8.8.8.8, 8.8.4.4",
                        "name": "domain-name-servers"
                    },
                    {
                        "data": "172.16.1.3",
                        "name": "dhcp-server-identifier"
                    }
                ],
                "pools": [
                    {
                        "client-class": "HA_dhcp-01",
                        "pool": "100.99.0.2 - 100.99.0.247"
                    },
                    {
                        "client-class": "HA_dhcp-02",
                        "pool": "100.99.0.248 - 100.99.1.238"
                    }
                ],
                "subnet": "100.99.0.0/23"
            }
        ],
        "valid-lifetime": 1200
    }
}


On Thu, May 2, 2019 at 2:44 PM Bjørn Skovlund <[hidden email]> wrote:
Hi Francis,

Thanks for the prompt reply!

On Thu, May 2, 2019 at 12:48 PM Francis Dupont <[hidden email]> wrote:
> It seems this would be possible with a host reservation on the client-id,
> but I'm trying to avoid having to copy the lease information into host
> reservations.

=> host reservations are of course the only way to really reserve an address.
But you can play with lifetime and expired-leases-processing timers to
make more likely a client to get the same IP address.

I'm not that concerned about getting the same IP, but more concerned about not handing out multiple addresses to the same client-id.

I think my problem, and misunderstanding of the client-id when it comes to lease allocation, may stem from having an active-active HA setup. It seems I am limited to two IP addresses, one from each of the servers. It could look a bit like my replication of IP addresses broke when I enabled the flex-id.

I'll have a closer look at those.

Thanks for your help.

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

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