You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 #14640 but more research has been carried out to get to root of problem.
Checklist
I have searched the open issues for this bug.
I have not included sensitive information in this report.
The text was updated successfully, but these errors were encountered:
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.
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.
If ISIS state change is Up -> Initializing -> Down when holdtime expires then neighbor entry remains stuck in neighbor table.
We have tested a potential fix by changing a line in isisd/isis_adjacency.c and compiled it in a custom build:
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
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 #14640 but more research has been carried out to get to root of problem.
Checklist
The text was updated successfully, but these errors were encountered: