[dhcpmon] Delay Counter Snapshot During Indeterminate State

[tahmed-dev]

This PR fixes a rare, however possible, condition when the DHCP RX
packet do happen before dhcpmon timer kicks in and DHCP TX packets
happens after. If DHCP remains silent for the next bucket duratrion,
those TX packet will be snapshot without switching DHCP state to
healthy.

signed-off-by: Tamer Ahmed tamer.ahmed@microsoft.com

- Why I did it
Fix issue were DHCP is reported unhealthy due to perfect packet split of rx happening before check timer kicks in and tx happens after timer is serviced.

- How I did it
Do not update snapshot counters if DHCP state indeterminate

- How to verify it
When delaying TX packet to take place after timer is serviced. The issue happens

Sep 29 21:57:13.433168 str-s6000-acs-14 ALERT dhcp_relay#dhcpmon[43]: dhcpmon detected disparity in DHCP Relay behavior. Duration: 306 (sec) for vlan: 'Agg-Vlan1000'
Sep 29 21:57:13.433168 str-s6000-acs-14 NOTICE dhcp_relay#dhcpmon[43]: [    Agg-Vlan1000-Snapshot rx/tx] Discover:         6/        0, Offer:         6/        6, Request:         6/      288, ACK:         6/        6
Sep 29 21:57:13.433168 str-s6000-acs-14 NOTICE dhcp_relay#dhcpmon[43]: [    Agg-Vlan1000- Current rx/tx] Discover:         7/        0, Offer:         6/        6, Request:         6/      288, ACK:         6/        6

- Which release branch to backport (provide reason below if selected)

• 201811
• 201911
• 202006

[pavel-shirshov]

LGTM
Please wait for other reviewers

[jleveque]

Is it enough to check state_data[0].dhcp_status != DHCP_MON_STATUS_INDETERMINATE here? Should you also check that state_data[1].dhcp_status != DHCP_MON_STATUS_INDETERMINATE?

[lguohan]

@tahmed-dev, wonder what is the status for this pr?

[tahmed-dev]

@tahmed-dev, wonder what is the status for this pr?

@lguohan I'd like to hold off on this PR until I get more data from the current dhcpmon. The current dhcpmon will show more logs that will prove the theory above. Also, the current dhcpmon has bucket size of 18 sec which might indeed solve the current issue as 1 min is not an integral multiple of buckets anymore. This case is very slim and would happen if there is only one dhcp client that has its timer aligned with the monitor timer.