isisd: Fix memory leaks when the transition of neighbor state from non-UP to DOWN #15716
Conversation
|
Does the failed test make sense, or in other words, should the neighbor not be deleted when transitioning from UP to DOWN state? |
I re-run the failed test to be sure it is not a false positive. Now, regarding your question, the neighbor is created when you add it in the configuration and when IS-IS Hello messages are received on the given interface and are deleted when you remove it in the configuration. I think, we must keep the context when the interface goes from UP to DOWN to speed up the process when the interface goes from DOWN to UP. In particular, when an interface (frequent when optical connector SFP reach end of life) flap (going Down, then Up, then Down ...), if you remove the context, the code will delete dynamic memory allocation and then recreate it and so on. This could decrease performance and at the end the risk of a memory corruption. So, I think it is preferable to keep the context if the interface goes DOWN and only remove the context when the neighbor is removed from the configuration |
Does 'remove the context when the neighbor is removed from the configuration' refer to the command 'clear isis neighbor [WORD]'? |
|
|
this says there are linter problems, but it doesn't show that the are ... let's try rerunning ci to see if we can find them |
|
ci:rerun |
Does this mean that when the IS-IS configuration is not removed on the specified interface, we do not need to consider potential memory leaks caused by frequent changes in the System ID due to neighbor updates? |
|
@Mergifyio backport stable/10.0 |
🟠 Waiting for conditions to match
|
|
@frrbot rereview |
…n-UP to DOWN When receiving a hello packet, if the neighbor state transitions directly from a non-ISIS_ADJ_UP state (such as ISIS_ADJ_INITIALIZING) to ISIS_ADJ_DOWN state, the neighbor entry cannot be deleted. If the neighbor is removed or the neighbor's System ID changes, it may result in memory leakage in the neighbor entry. Test Scenario: LAN link between Router A and Router B is established. Router A does not configure neighbor authentication, while Router B is configured with neighbor authentication. When the neighbor entry on Router B ages out, the neighbor state on Router A transitions to INIT. If Router B is then removed, the neighbor state on Router A transitions to DOWN and persists. Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com> fix frrbot styling issues found. fix frrbot styling issues found. Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
When receiving a hello packet, if the neighbor state transitions directly from a non-ISIS_ADJ_UP state (such as ISIS_ADJ_INITIALIZING) to ISIS_ADJ_DOWN state, the neighbor entry cannot be deleted. If the neighbor is removed or the neighbor's System ID changes, it may result in memory leakage in the neighbor entry.
Test Scenario:
LAN link between Router A and Router B is established. Router A does not configure neighbor authentication, while Router B is configured with neighbor authentication. When the neighbor entry on Router B ages out, the neighbor state on Router A transitions to INIT. If Router B is then removed, the neighbor state on Router A transitions to DOWN and persists.
Signed-off-by: zhou-run zhou.run@h3c.com