-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
SRv6 BGP SID reachability #14810
SRv6 BGP SID reachability #14810
Conversation
Just a quick question: is this behavior something that other vendors have (SID reachability tracking)? I'm worried that we can't break anything if this is turned ON by default and can't be controlled. Maybe a knob would be handy? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good
Would this raise any scale concerns? VPN SID is similar to vpn label for MPLS VPN, which provides local information once packets reach to this PE. In the example you provide, | | If we don't sue route-map to set nexthop, the nexthop is D. Do we really want to let A, B, C all aware the reachablity of your VPN SID, or just keep it as local context to D if some chip has scale concerns with v6 prefixes. https://datatracker.ietf.org/doc/rfc8986/ section 3.3. "Routed and non-routed SRv6 SIDs are the SRv6 instantiation of how do you plan to handle these local segment use cases? |
ci:rerun |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dmytroshytyi-6WIND Thanks for the SRv6 contribution. Overall LGTM, I have only two nits.
tests/topotests/bgp_srv6_sid_reachability/test_bgp_srv6l3vpn_over_ipv6.py
Outdated
Show resolved
Hide resolved
tests/topotests/bgp_srv6_sid_reachability/test_bgp_srv6l3vpn_over_ipv6.py
Outdated
Show resolved
Hide resolved
ebfc5be
to
4086473
Compare
|
||
if (is_bgp_static) { | ||
if (pi && pi->attr && pi->attr->srv6_l3vpn) { | ||
IPV6_ADDR_COPY(&(p->u.prefix6), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no need to check for pi != NULL. it is alread done above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks fixed.
bgpd/bgp_nht.c
Outdated
@@ -660,6 +672,7 @@ static void bgp_process_nexthop_update(struct bgp_nexthop_cache *bnc, | |||
|
|||
if (BGP_DEBUG(nht, NHT)) { | |||
char buf[NEXTHOP_STRLEN]; | |||
|
|||
zlog_debug( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no need to add empty line
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Fixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2 minor issues.
also, the commit "bgpd: srv6 sid reachability information".
I would add this in the commit log:
Fixes 7f8c7d9 ("bgpd: ignore nexthop validation for srv6-vpn")
BGP IPv4 L3VPN with SRv6 SID reachability example provided in the documentation Signed-off-by: Dmytro Shytyi <[email protected]>
Enable the SRv6 SID prefix generation in make_prefix() function of bgp_nht.c. Signed-off-by: Dmytro Shytyi <[email protected]> fixup: bgpd: extend make_prefix to form srv6-based prefix
In the case of SRv6-VPN we track the reachability to the SID. We check that the SID is available in the BGP update and then we check the nexthop reachability. Fixes 7f8c7d9 ("bgpd: ignore nexthop validation for srv6-vpn") Signed-off-by: Dmytro Shytyi <[email protected]> Signed-off-by: Philippe Guibert <[email protected]>
Verify that SRv6 SID becomes unreachable and further the IPv4 route in L3VPN becomes invalid. Signed-off-by: Dmytro Shytyi <[email protected]>
4086473
to
5101463
Compare
ci:rerun |
1 similar comment
ci:rerun |
If this were in, I think we could merge this. |
This commit log includes the "Fixes" tag: And these two comments were addressed: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good
This commit brings PR FRRouting/frr#14810 from FRR mainline to SONiC SRv6 BGP SID reachability FRRouting/frr#14810 Signed-off-by: cscarpitta <[email protected]>
This commit brings PR FRRouting/frr#14810 from FRR mainline to SONiC SRv6 BGP SID reachability FRRouting/frr#14810 Signed-off-by: cscarpitta <[email protected]>
This commit brings PR FRRouting/frr#14810 from FRR mainline to SONiC SRv6 BGP SID reachability FRRouting/frr#14810 Signed-off-by: cscarpitta <[email protected]>
This commit brings PR FRRouting/frr#14810 from FRR mainline to SONiC SRv6 BGP SID reachability FRRouting/frr#14810 Signed-off-by: cscarpitta <[email protected]>
For BGP SRv6 updates, This PR considers "SRv6 SID reachability" and replaces the NH reachability with the
SRv6 SID reachability.
Today, only the NH reachability is checked, and when route is installed, if the SRv6 SID is not reachable
then the SRv6 segs route will fail to be installed.
This is what happens on kernel.
This PR:
Possible cases like the one below are not considered, and do not work anyway:
Router A and D are running BGP protocol. The route map, to set nexthop == C, is configured on
router D. Such that router C IPv6 address is verified to be reachable to flag the SRv6 reachable,
but if route on the router C that points to D router's SRv6 SID dissapears(broken link),
on node A SID is expected to be still reachable, because nexthop C is reachable.