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
The ip rule recovery should not affect routes belonging to other rules.
Current Behavior
Running NSM v1.9.0, in case of forwarder restart (not graceful restart) the policy recovery sometimes flush routing tables which belongs to other rule (connection).
Failure Information
When the nsm interface is deleted the routes which belongs to the link are removed, but not the rules which refers to these routes. At forwarder restart the creation order can change and that leads to faulty ip rules. During recovery some rule in NSC refer to empty table or to a table which belongs to other rule (which was created meantime). The flush operation always delete the routes without any check.
Steps to Reproduce
Start the example spire and basic setup
Apply the following patch to the examples/features/mutually-aware-nses:
# ip rule
0: from all lookup local
32758: from 214.14.131.114 lookup 4
32759: from 214.14.131.113 lookup 3
32760: from 214.14.132.66 lookup 2
32761: from 214.14.132.65 lookup 1
32766: from all lookup main
32767: from all lookup default
# ip route show table all
default via 172.16.16.1 dev nsm-1 table 1 onlink
default via 172.16.16.1 dev nsm-1 table 2 onlink
default via 172.16.1.1 dev nsm-0 table 3 onlink
default via 172.16.1.1 dev nsm-0 table 4 onlink
After forwarder restart the configuration has changed to a faulty one:
# ip rule
0: from all lookup local
32762: from 214.14.132.66 lookup 3
32763: from 214.14.131.114 lookup 2
32764: from 214.14.132.65 lookup 2
32765: from 214.14.131.113 lookup 1
32766: from all lookup main
32767: from all lookup default
# ip route show table all
default via 172.16.1.1 dev nsm-0 table 1 onlink
default via 172.16.1.1 dev nsm-0 table 2 onlink
default via 172.16.16.1 dev nsm-1 table 3 onlink
Expected Behavior
The ip rule recovery should not affect routes belonging to other rules.
Current Behavior
Running NSM v1.9.0, in case of forwarder restart (not graceful restart) the policy recovery sometimes flush routing tables which belongs to other rule (connection).
Failure Information
When the nsm interface is deleted the routes which belongs to the link are removed, but not the rules which refers to these routes. At forwarder restart the creation order can change and that leads to faulty ip rules. During recovery some rule in NSC refer to empty table or to a table which belongs to other rule (which was created meantime). The flush operation always delete the routes without any check.
Steps to Reproduce
Failure Logs
Connection 7de77836-9123-443c-b84c-7ac601a8375d has the following policy set in IPContext:
Connection cfb49ee2-3f61-4e5c-b7e1-0b4c17cf7b05 has the following policy set in IPContext:
Configuration set in NSC:
After forwarder restart the configuration has changed to a faulty one:
Slice from forwarder log:
The text was updated successfully, but these errors were encountered: