Opened 2 years ago

Last modified 2 years ago

#5413 new defect

Different behavior with the same network address.

Reported by: xcme Owned by:
Priority: medium Milestone: Kea1.x
Component: dhcp4 Version: git
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: Low
Sub-Project: DHCP Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

Hello!
I'm trying to implement Kea in my network. I tested it in different situations and found an odd behavior.

For example, I want to allocate some addresses for specific class or mac-address. Because I can't apply client-class directly to the pool, I tried to use something like this (it's a contrived example):

"shared-networks": [ {
    "name": "ISP",
    "subnet4": [
        { "subnet": "100.64.0.0/24", "pools": [ { "pool": "100.64.0.32/32" } ], "client-class": "class1" },
        { "subnet": "100.64.0.0/24", "pools": [ { "pool": "100.64.0.33/32" } ] },
        { "subnet": "100.64.0.0/24", "pools": [ { "pool": "100.64.0.32/30" } ],
        "reservations": [
            { "hw-address": "mac1", "ip-address": "100.64.0.32" },
            { "hw-address": "mac2", "ip-address": "100.64.0.33" },
            { "hw-address": "mac3", "ip-address": "100.64.0.34" },
            { "hw-address": "mac4", "ip-address": "100.64.0.35" }
            ]
        }
        ]
    } ]

In this case I got a message: failed to select a subnet for incoming packet.

But when I change second line:

        { "subnet": "100.64.0.0/24", "pools": [ { "pool": "100.64.0.33/32" } ] },

to:

        { "subnet": "100.64.0.1/24", "pools": [ { "pool": "100.64.0.33/32" } ] },

Kea now can allocate address 100.64.0.33 to the client.

Why is this happening, because 100.64.0.0/24 and 100.64.0.1/24 points to the same network address - 100.64.0.0/24?

Subtickets

Attachments (2)

dhcp_discovery_fail.pcap (384 bytes) - added by xcme 2 years ago.
kea-dhcp4.conf (1.1 KB) - added by xcme 2 years ago.

Download all attachments as: .zip

Change History (5)

comment:1 Changed 2 years ago by fdupont

Many things are bad here... BTW can you give an idea of the incoming packet so we can reproduce exactly the same problem?

comment:2 Changed 2 years ago by fdupont

Note: subnet->inRange uses first and last addresses so should be immune to a bad prefix...

Changed 2 years ago by xcme

Changed 2 years ago by xcme

comment:3 Changed 2 years ago by xcme

I made a real configuration file and the dump of the DHCP DICOVERY packet. I attached them to the original message. Of course, this configuration for the test stand only. Look at the tail of the option 82 in the pcap-file and the first class definition in the config file. I deliberately made the mistake ('0' instead 'e') that the DISCOVERY packet does NOT come under the classification rules. In this case, it is logical that the packet should be mapped to the subnet for which classes are not used, and the address should be allocated from the pool 100.64.0.32/30. However, in this case I get the error "failed to select a subnet for incoming packet". However (again:), if I change the subnet №3 to something else, for example "100.64.0.55/24", the client obtains an IP address normally. One gets the impression that the subnet is defined as a STRING and NOT as a NETWORK ADDRESS, because a subnet "100.64.0.0/24" and subnet "100.64.0.55/24" have different string representation, but points to the same network address - 100.64.0.0.

Note: See TracTickets for help on using tickets.