Change Details

Steps to recreate: -2 IPv6 OSPF neighbors (no IPV4 configured in the test scenario) -Disconnect the neighbor pushing ::/0 to the VyOS routing table (by shutting down the interface of the neighbor) Result: -The IPv6 routing table is not cleared and the entries are not replaced with the entries pushed by the other neighbor for the same destinations -Impact ::/0 (and other destinations) still points to the disconnected neighbor and VMs behind VyOS are unable to connect to any upstream systems (including the internet) Notes: -The upstream Router is in this use case a Cisco device pushing the default route (and other routes) to VyOS Additional information: -Disconnecting both neighbors and then reconnecting either one works... The tables are then correctly cleared -On Cisco, entries for both neighbors are listed in the routing table. This is not the case on VyOS (per design?)

Steps to recreate: -2 IPv6 OSPF neighbors -Disconnect the neighbor pushing ::/0 to the VyOS routing table (by shutting down the interface of the neighbor for example) Result: -The IPv6 routing table is not cleared on 1.1.8 (but it stays connected to the remaining neighbor) and is cleared on 1.2 (as it looses connection to all neighbors). On 1.1.8, the entries are not replaced with the entries pushed by the other neighbor for the same destinations. On 1.2, it looses connections to all neighbors and the entries are cleared. -Impact ::/0 (and other destinations) still points to the disconnected neighbor in 1.1.8. In 1.2, the ipv6 routing table doesn't contain any OSPF entries anymore. For both 1.1.8 and 1.2, and VMs behind VyOS are unable to connect to any upstream systems (including the internet) as a result. Notes: -The upstream Router is in this use case a Cisco device pushing the default route (and other routes) to VyOS Additional information: -Disconnecting both neighbors on 1.1.8 and then reconnecting either one works... The tables are then correctly cleared -On 1.2, a reboot is required the reconnect to the surviving neighbor (if the one initially going down is the one pushing ::/0 to VyOS) -On Cisco, IPv6 OSPF routing entries for both neighbors are listed in the routing table. This is not the case on VyOS (per design?). IPv4 list routing entries of both neighbors (and 2 default gateways as a result). OSPF IPv4 is not affected by a neighbor going down

Steps to recreate: -2 IPv6 OSPF neighbors (no IPV4 configured in the test scenario) -Disconnect the neighbor pushing ::/0 to the VyOS routing table (by shutting down the interface of the neighbor for example) Result: -The IPv6 routing table is not cleared andon 1.1.8 (but it stays connected to the remaining neighbor) and is cleared on 1.2 (as it looses connection to all neighbors). On 1.1.8, the entries are not replaced with the entries pushed by the other neighbor for the same destinations. On 1.2, it looses connections to all neighbors and the entries are cleared. -Impact ::/0 (and other destinations) still points to the disconnected neighbor in 1.1.8. In 1.2, the ipv6 routing table doesn't contain any OSPF entries anymore. For both 1.1.8 and 1.2, and VMs behind VyOS are unable to connect to any upstream systems (including the internet) as a result. Notes: -The upstream Router is in this use case a Cisco device pushing the default route (and other routes) to VyOS Additional information: -Disconnecting both neighbors on 1.1.8 and then reconnecting either one works... The tables are then correctly cleared -On 1.2, a reboot is required the reconnect to the surviving neighbor (if the one initially going down is the one pushing ::/0 to VyOS) -On Cisco, IPv6 OSPF routing entries for both neighbors are listed in the routing table. This is not the case on VyOS (per design?). IPv4 list routing entries of both neighbors (and 2 default gateways as a result). OSPF IPv4 is not affected by a neighbor going down