Page MenuHomePhabricator

OSPFv3 - IPv6 OSPF not working properly after the neighbor pushing ::/0 is disconnected
Closed, WontfixPublicBUG

Description

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

Details

Difficulty level
Unknown (require assessment)
Version
1.2
Why the issue appeared?
Will be filled on close

Event Timeline

mplanquart renamed this task from OSPFv3 - IPv6 Routing table entries of a disconnected neighbor are not cleared/replaced by the entries of the other neighbor to OSPFv3 - IPv6 OSPF not properly after the neighbor pushing ::/0 is disconnected (even though one neighbor is still alive).Jul 18 2018, 8:10 AM
mplanquart renamed this task from OSPFv3 - IPv6 OSPF not properly after the neighbor pushing ::/0 is disconnected (even though one neighbor is still alive) to OSPFv3 - IPv6 OSPF not working properly after the neighbor pushing ::/0 is disconnected .
mplanquart updated the task description. (Show Details)
mplanquart added a project: VyOS 1.2 Crux.
mplanquart changed Version from 1.1.8 to 1.2.
syncer triaged this task as Low priority.Sep 1 2018, 3:03 PM
syncer removed a project: VyOS 1.1.x (1.1.8).
syncer changed the task status from Open to On hold.Oct 13 2018, 7:00 PM
syncer added a subscriber: syncer.

requires testing on the latest rolling

pasik added a subscriber: pasik.Nov 4 2018, 11:22 AM
kroy added a subscriber: kroy.Dec 14 2018, 8:34 PM

I’ve been using ospfv3 on all the RCs and definitely haven’t seen this behavior. OSPFv3 seems immune to the problem I’m seeing in T1020

No matter what machinations I do (rebooting edge, internal routers, etc), the default route for ipv6 gets distributed as expected.

syncer closed this task as Wontfix.Feb 8 2019, 12:09 AM
syncer claimed this task.
syncer edited projects, added Rejected; removed VyOS 1.2 Crux (VyOS 1.2.0-EPA3).

can't reproduce
please try latest rolling and if the problem still persists
create new ticket with full config and env spec