-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IPv6 routes not propagating from APPL_DB to ASIC_DB #5040
Comments
Comments on my previous routes-not-propagating bug had questions about next-hop entries. I'm not sure how those are supposed to work with IPv6, but I don't see any v6 next hops in either DB.
By comparison, my IPv4 route next-hops have NEIGH_TABLE entries in DB 0 and ASIC_STATE:SAI_OBJECT_TYPE_NEIGHBOR_ENTRY entries in DB 1. So perhaps this is an issue with |
I turned
That's coming from https://github.com/Azure/sonic-swss/blob/master/fpmsyncd/routesync.cpp, and it looks okay. It has the right next hop and interface. The APPL DB shows the correct ROUTE_TABLE entry and no entry for the next hop. I then turned up
So, it looks like I ran
I think that's okay; I don't see any code in https://github.com/Azure/sonic-swss-common/blob/master/common/producerstatetable.cpp or any of the Lua that goes with it that knows about I suspect that the problem is here: https://github.com/Azure/sonic-swss/blob/a9479e646649e67d28d4afba395ab16c8907e7c7/neighsyncd/neighsync.cpp#L76, where it explicitly ignores v6 link-local neighbors. OSPFv3 explicitly uses link-local neighbors (as per the RFC). The pull request that added that line (sonic-net/sonic-swss#1065) mentions "some current limitations with handling link-local neighbors" but doesn't provide any details or an issue link. Does anyone have context on this? |
That makes this a duplicate of sonic-net/sonic-utilities#430, which is ~1.5 years old. Is there a plan for how best to approach this? |
This issue might not be OSPF specific. Looks like your neighbors are IPv6 link local addresses. Are you able to confirm this is the issue only happen to link local neighbors? |
I meeted the same problem, and I found that this is because sonic ignores the linklocal address when processing the neighbor table of the kernel. And, the neighbor of the linklocal address will not be issued. Therefore, the learned ipv6 route will be unable to find the nexthop and fail to config.
|
Description
Kernel IPv6 routes aren't consistently propagating from the APPL_DB to the ASIC_DB. This is seen on two different devices running recent(ish) Jenkins builds.
I'm using OSPFv6 to propagate IPv6 routes. They're appearing in the kernel just fine:
And they're in the APPL DB:
But they're not in the ASIC DB:
There is nothing useful in
/var/log/syslog
or/var/log/swss
Looking deeper, there are only 4 IPv6 routes in the ASIC DB:
For comparison,
ip -6 addr show | wc
gives 66 lines, although a few of those are ECMP routes.Oddly, the default route in the ASIC DB (::/0) isn't actually correct, either. Here's what's in the ASIC DB:
That's listed as SAI_PACKET_ACTION_DROP. However, the kernel has a default route:
The APPL DB version matches the kernel:
I'm not sure where the default drop is coming from.
Steps to reproduce the issue:
ip route add 2001:470:e959:ffff::/64 via fe80::ba6a:97ff:fe8a:7168 dev Ethernet120
redis-dump -d 0 -y | grep ffff
redis-dump -d 1 -y | grep ffff
Describe the results you received:
No route for 2001:470:e959:ffff::/64 in the ASIC DB.
Describe the results you expected:
One route for 2001:470:e959:ffff::/64 in the ASIC DB.
Additional information you deem important (e.g. issue happens only occasionally):
Output of
show version
:Attach debug file
sudo generate_dump
:sonic_dump_sw100_20200725_060652.tar.gz
The text was updated successfully, but these errors were encountered: