Project

General

Profile

Actions
Copy link

Bug #15795

closed

Removing a route from the High Availability primary node does not remove the entry from the routing table on the secondary node

Added by Craig Coonrad 11 months ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Assignee:
Marcos M
Category:
High Availability
Target version:
-
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
24.11
Release Notes:
Default
Affected Version:
Affected Architecture:
All

Description

Version: 24.03-RELEASE
Platform: PVE, 6100

Example:

Primary (netstat -nr)

9.9.9.9            192.168.1.1        UGHS     vtnet3

Secondary

9.9.9.9            192.168.1.1        UGHS     vtnet3

Delete static route from primary

Primary (route is removed from primary GUI)

<route no longer exists in routing table>

Secondary (route is removed from secondary GUI)

9.9.9.9            192.168.1.1        UGHS     vtnet3
Actions
Copy link
 #1

Updated by Danilo Zrenjanin 11 months ago

  • Status changed from New to Confirmed

I have replicated this behavior.

Tested on PVE, pfSense Plus version 24.03.

Actions
Copy link
 #2

Updated by Marcos M 11 months ago

  • Subject changed from HA: removing static route from primary removes static route from secondary GUI, but route still exists in routing table on secondary. to Removed route changes on an HA primary node are not applied to the secondary node
  • Status changed from Confirmed to In Progress
  • Assignee set to Marcos M
  • Target version set to 2.8.0
  • Plus Target Version set to 24.11
Actions
Copy link
 #3

Updated by Marcos M 11 months ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #4

Updated by Danilo Zrenjanin 11 months ago

I applied the patch to the HA pair operating on the latest development release. However, the issue remains unresolved.

The phantom route is removed from the secondary system following a reboot.

Please check again.

Actions
Copy link
 #6

Updated by Danilo Zrenjanin 11 months ago

  • Status changed from Feedback to Resolved

The issue was resolved by applying the second patch subsequent to the first one.

I am closing this ticket as resolved.

Actions
Copy link
 #7

Updated by Jim Pingle 10 months ago

  • Subject changed from Removed route changes on an HA primary node are not applied to the secondary node to Removing a route from the High Availability primary node does not remove the entry from the routing table on the secondary node
Actions
Copy link
 #8

Updated by Azamat Khakimyanov about 1 month ago

  • Status changed from Resolved to Assigned
  • Target version changed from 2.8.0 to 2.9.0
  • Plus Target Version changed from 24.11 to 25.11

Tested on 24.11

I'm afraid this bug wasn't fixed completely.
There is a still an issue with syncing of static routes in case we use IP Alias as a Destination Network.
Steps to reproduce:
1. create a big IP Alias with about 200 IPs in it.
2. create static route with this alias as a Destination.
3. edit this alias: delete some IPs in the center of alias
so the content of the IP Alias will be synced properly to the Secondary node BUT in the Diagnostics/Routes on the Secondary node we can still static routes for the IPs we've just deleted from the IP Alias.

Another strange issue: on Primary node static routes for deleted IPs are not removed when you press Save after deleting some IPs and pressing Reload Filter. They are removed only if you press edit for this alias and then press Save (without changing anything). I can reproduce this issue on standalone 24.11 with all patches applied.

If to press Edit for this Alias on Secondary node and then press Save (without changing anything), it changes nothing, wrong routes are still in route table.

Actions
Copy link
 #9

Updated by Marcos M about 1 month ago

  • Status changed from Assigned to Closed
  • Target version deleted (2.9.0)
  • Plus Target Version changed from 25.11 to 24.11

That needs a separate issue report since it's more related to the alias/static route implementation rather than the sync issue originally reported on this redmine.

Actions
Copy link
 #10

Updated by Craig Coonrad about 1 month ago

Added #16343 to track the issue reported by Azamat.

Actions
Copy link

Also available in: Atom PDF