ISIS Three-Way-Handshake State Change Issue

[beith12]

trafficstars

Description

When ISIS three-way-handshake is enabled (default setting) we see an issue with the logic of the state changes during events such as one-way communication.

If ISIS state change is Up -> Down then neighbor entry is cleared from neighbor table.

# sh isis ne
Area LAB:
  System Id           Interface   L  State        Holdtime SNPA
# 

If ISIS state change is Up -> Initializing -> Down when holdtime expires then neighbor entry remains stuck in neighbor table.

# sh isis ne
Area LAB:
System Id           Interface   L  State        Holdtime  SNPA
ABC                    ens5        2   Down       Expiring   2020.2020.2020

We have tested a potential fix by changing a line in isisd/isis_adjacency.c and compiled it in a custom build:

void isis_adj_state_change
...
    } else if (circuit->circ_type == CIRCUIT_T_P2P) {
...
        } else if (old_state == ISIS_ADJ_UP) { << Current
        } else if (old_state == ISIS_ADJ_UP || old_state == ISIS_ADJ_INITIALIZING) { << Modification

Looking for some guidance on whether this is the correct approach for a fix or not. Its also possible to use another elseif statement of course to explicitly call out 'old_state == ISIS_ADJ_INITIALIZING' and 'new_state == ISIS_ADJ_DOWN'.

Version

Issue is seen and tested on versions 8.3.1, 8.4.4, 8.5.2, 9.1

How to reproduce

Seen in situations where one-way communications exists - Side A is receiving and sending ISIS packets but Side B is only sending ISIS packets (none received from Side A).

Expected behavior

When ISIS holdtime expires the neighbor should be gracefully removed from the neighbor table

Actual behavior

When the ISIS holdtime expires the neighbor is not always removed from the neighbor table.

Additional context

Previously reported in https://github.com/FRRouting/frr/issues/14640 but more research has been carried out to get to root of problem.

Checklist

• [X] I have searched the open issues for this bug.
• [X] I have not included sensitive information in this report.

[donaldsharp]

this looks reasonable to me. Please open a PR with this fix.

[beith12]

Opened https://github.com/FRRouting/frr/pull/16207

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. Comment or remove the autoclose label in order to avoid having this issue closed.

[frrbot[bot]]

This issue will be automatically closed in the specified period unless there is further activity.