Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ISIS Three-Way-Handshake State Change Issue #16162

Closed
2 tasks done
beith12 opened this issue Jun 4, 2024 · 4 comments
Closed
2 tasks done

ISIS Three-Way-Handshake State Change Issue #16162

beith12 opened this issue Jun 4, 2024 · 4 comments
Labels
triage Needs further investigation

Comments

@beith12
Copy link

beith12 commented Jun 4, 2024

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 #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.
@beith12 beith12 added the triage Needs further investigation label Jun 4, 2024
@donaldsharp
Copy link
Member

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

@beith12
Copy link
Author

beith12 commented Jun 12, 2024

Opened #16207

Copy link

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
Copy link

frrbot bot commented Dec 10, 2024

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

@frrbot frrbot bot closed this as completed Dec 17, 2024
@frrbot frrbot bot removed the autoclose label Dec 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage Needs further investigation
Projects
None yet
Development

No branches or pull requests

2 participants