Fix IPv4 routes with IPv6 link local next hops installed in FPM #8740
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
not properly installed in FPM. Reason is the netlink decoding truncates the ipv6 LL address to 4 byte ipv4 address. Ex : fe80:: is directly converted to ipv4 and it results in 254.128.0.0 as next hop for below routes show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued, r - rejected, b - backup B>* 2.1.0.0/16 [200/0] via fe80::268a:7ff:fed0:d40, Ethernet0, weight 1, 02:22:26 B>* 5.1.0.0/16 [200/0] via fe80::268a:7ff:fed0:d40, Ethernet0, weight 1, 02:22:26 B>* 10.1.0.2/32 [200/0] via fe80::268a:7ff:fed0:d40, Ethernet0, weight 1, 02:22:26 Hence this fix converts the ipv6-LL address to ipv4-LL (169.254.0.1) address before sending it to FPM. This is inline with how these types of routes are currently programmed into kernel. Signed-off-by: Nikhil Kelapure <[email protected]>
|
This PR #8740 along with PR sonic-net/sonic-swss#1903 fixes issue #8606 |
|
retest this please |
|
FRR PR for the change is already merged to master FRRouting/frr#9602 |
|
retest this please |
|
retest vs please |
|
/azpw run |
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
This deviates from the HLD design here sonic-net/SONiC#625 (comment) |
To Make the design in sync with kernel and FRR, it was decided to implement it this way. Will update the HLD as required. |
|
@dgsudharsan could you please help to review? |
dgsudharsan
previously approved these changes
Oct 19, 2021
|
@nkelapur Can you please sync to the latest? This PR has merge conflicts. |
not properly installed in FPM. Reason is the netlink decoding truncates the ipv6 LL address to 4 byte ipv4 address. Ex : fe80:: is directly converted to ipv4 and it results in 254.128.0.0 as next hop for below routes show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued, r - rejected, b - backup B>* 2.1.0.0/16 [200/0] via fe80::268a:7ff:fed0:d40, Ethernet0, weight 1, 02:22:26 B>* 5.1.0.0/16 [200/0] via fe80::268a:7ff:fed0:d40, Ethernet0, weight 1, 02:22:26 B>* 10.1.0.2/32 [200/0] via fe80::268a:7ff:fed0:d40, Ethernet0, weight 1, 02:22:26 Hence this fix converts the ipv6-LL address to ipv4-LL (169.254.0.1) address before sending it to FPM. This is inline with how these types of routes are currently programmed into kernel. Signed-off-by: Nikhil Kelapure <[email protected]>
dgsudharsan
approved these changes
Dec 14, 2021
liat-grozovik
added
the
Request for 202111 Branch
shi-su
reviewed
Jan 3, 2022
| static void zfpm_mac_info_del(struct fpm_mac_info_t *fpm_mac); | ||
|
|
||
| +static const char ipv4_ll_buf[16] = "169.254.0.1"; | ||
| +union g_addr ipv4ll_gateway; |
There was a problem hiding this comment.
What is the purpose for this g_addr ipv4ll_gateway?
shi-su
approved these changes
Jan 13, 2022
judyjoseph
pushed a commit
that referenced
this pull request
Jan 23, 2022
* Description: Currently IPv4 routes with IPv6 link local next hops are not properly installed in FPM. Reason is the netlink decoding truncates the ipv6 LL address to 4 byte ipv4 address. Ex : fe80:: is directly converted to ipv4 and it results in 254.128.0.0 as next hop for below routes show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued, r - rejected, b - backup B>* 2.1.0.0/16 [200/0] via fe80::268a:7ff:fed0:d40, Ethernet0, weight 1, 02:22:26 B>* 5.1.0.0/16 [200/0] via fe80::268a:7ff:fed0:d40, Ethernet0, weight 1, 02:22:26 B>* 10.1.0.2/32 [200/0] via fe80::268a:7ff:fed0:d40, Ethernet0, weight 1, 02:22:26 Hence this fix converts the ipv6-LL address to ipv4-LL (169.254.0.1) address before sending it to FPM. This is inline with how these types of routes are currently programmed into kernel. Signed-off-by: Nikhil Kelapure <[email protected]>
|
PR cherry-pick is failing 202106. Please create a new PR for 202106 |
|
@nkelapur Can you please create a new PR? |
|
Sure, Will do that. Is this fix required for 202106 ?
…On Tue, Mar 1, 2022 at 11:23 AM Sudharsan Dhamal Gopalarathnam < ***@***.***> wrote:
@nkelapur <https://github.com/nkelapur> Can you please create a new PR?
—
Reply to this email directly, view it on GitHub
<#8740 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE447NLSKRDXA7PHBQ35PT3U5RNMDANCNFSM5D6IJBQA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
|
|
@nkelapur The feature was introduced in 202106 branch and I believe in order for it to work, the fix is required. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why I did it
Currently IPv4 routes with IPv6 link local next hops are not properly installed in FPM.
Reason is the netlink decoding truncates the ipv6 LL address to 4 byte
ipv4 address.
Ex : fe80:: is directly converted to ipv4 and it results in 254.128.0.0
as next hop for below routes
show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
B>* 2.1.0.0/16 [200/0] via fe80::268a:7ff:fed0:d40, Ethernet0, weight 1,
02:22:26
B>* 5.1.0.0/16 [200/0] via fe80::268a:7ff:fed0:d40, Ethernet0, weight 1,
02:22:26
B>* 10.1.0.2/32 [200/0] via fe80::268a:7ff:fed0:d40, Ethernet0, weight
1, 02:22:26
How I did it
Hence this fix converts the ipv6-LL address to ipv4-LL (169.254.0.1)
address before sending it to FPM. This is inline with how these types of
routes are currently programmed into kernel.
How to verify it
Setup BGP peer over ipv6 link local interface address and learn routes.
Check the APP_DB entry for the routes should contain ipv4 Linl Local address instead of incomplete ipv6 address.
APPL_DB hgetall ROUTE_TABLE:2.2.2.2/32
ifname
Ethernet64
nexthop
169.254.0.1 >> ipv4 Link Local address
Signed-off-by: Nikhil Kelapure [email protected]