[kea-dev] Feature suggestion: log of packet drops and NAK reasons

[Marcin Siodelski]

Nicolas,

I think it would be useful to have a ticket submitted to cover those
enhancements.

Minor comments below.

Marcin

On 04/03/15 17:00, Chaigneau, Nicolas wrote:
> 
> Hello,
> 
> 
> I know you already have plan to improve logging.
> We previously discussed with Tomek of what we're going to do with hooks: allowing to log each DHCP packet received and sent, along with some information such as: who sent the packet, which lease was requested and so on.
> 
> This could be useful to other people, so we agreed it would be nice to have this in Kea kernel code.
> 
> To expand on this, I thought of other things that would be very useful to us.
> 
> 
> 
> For each packet dropped by Kea, I would like to see a log describing the precise reason why it was dropped.
> And same thing for rejects (NAKs).
> 
> For example:
> 
> 2015-03-03 09:08:03.520 INFO [kea-packet-info/2720] DHCP4_DROP_INFO (1) DHCPv4 Request packet (xid: 3211589407) dropped: it contains foreign server identifier
> 2015-03-03 09:08:17.315 INFO [kea-packet-info/2720] DHCP4_DROP_INFO (2) BOOTP packet dropped: BOOTP is not supported
> 2015-03-03 09:08:34.139 INFO [kea-packet-info/2720] DHCP4_DROP_INFO (3) DHCPv4 Inform packet (xid: 4435657643) dropped: client 6c:3e:6d:b2:62:02 is unreachable through address 10.156.0.127
> 2015-03-03 09:11:02.120 INFO [kea-packet-info/2720] DHCP4_REJECT_INFO (42) DHCPv4 Request packet (xid: 5532642) rejected: invalid address 10.106.238.106 requested by INIT-REBOOT client 30:a8:db:89:90:68
> 
> And so on.
> 
> 
> 
> It should be possible to automatically parse these logs without prior knowledge of each possible case.
> To do so, I suggest to have:
> - a common message identifier (for example: DHCP4_DROP_INFO, DHCP4_REJECT_INFO).
> - a numeric category identifier, allowing to classify the different reasons for dropping / rejecting.
> - and a text reason which can vary for each packet, containing relevant information.
> 

The common message identifiers are unique within the code. There should
be no more than one occurrence of the particular message. So, the
numeric category identifier is not really needed. Admittedly some of the
messages need to be improved, possibly split into more distinct messages.

> 
> Additionally, I suggest adding a new logger to handle these messages.
> This would allow to easily enable or disable such logs independently of any other logs.
> 
> 
> 
> 
> Let me expand a bit on why I would like to have this feature:
> 
> This is a pretty important need to me, because I'm replaying network captures of real DHCP traffic on our lab environment.
> I need to be able to explain everything that Kea is doing, such as how many packets are dropped or rejected and why exactly.
> Then I can conclude if there are issues that should be reported.
> 
> Currently, this is an empirical and time consuming task.
> I have to look into the DEBUG logs and try and find relevant messages (sometimes there are none), and correlate with information from the network capture.
> The capture is pretty big, and I need to do this each time a new version of Kea is available. Furthermore, in the future we plan to take and replay more network captures.
> 
> 
> 


Sounds reasonable, but I'd need to look more into our logging mechanism
and see how far we are from there. But, it sounds reasonable to me.

Marcin