Repository navigation
bgpd: track the color of vrf leaked paths in nexthop tracking (backport #24317) - #24334
Merged
Merged
Conversation
A colored L3VPN route imported in a VRF does not follow the state of the SR-TE policy of its color. A 'set sr-te color 1' route-map is applied on the VPN routes received from 4.4.4.4, and the SR policy color 1 to 4.4.4.4 is created by a PCE after the route of 10.200.0.0/24 is imported in vrf l3vrf1. The route stays resolved over the IGP prefix-SID of 4.4.4.4, without the segment list of the policy: > north# show ip route vrf l3vrf1 > [..] > B> 10.200.0.0/24 [200/0] via 4.4.4.4 (vrf default) (recursive), SR-TE color 1, label 102, weight 1, 00:09:39 > * via 10.125.0.2, ntfp3 (vrf default), label 1044/102, weight 1, 00:09:39 The opposite happens when the policy goes down: the route keeps the labels of the segment list that is no more valid. The VRF route is tracked by the colorless nexthop, while only the VPN route is tracked by the colored nexthop: > north# show bgp nexthop detail > Current BGP nexthop cache: > 4.4.4.4 valid [IGP metric 40], #paths 1, peer 4.4.4.4 > Resolved prefix 4.4.4.4/32 > gate 10.125.0.2, if ntfp3, ifindex 5 > Last update: Tue Nov 10 10:20:21 2026 > Paths: > 1/1 10.200.0.0/24 VRF l3vrf1 flags 0x4018 > SR-TE color 1 - 4.4.4.4 valid [IGP metric 40], #paths 1 > Resolved prefix 4.4.4.4/32 > gate 10.125.0.2, if ntfp3, ifindex 5 > Last update: Tue Nov 10 10:20:21 2026 > Paths: > 1/3 10.200.0.0/24 RD 444:2 VRF default flags 0x418 When the policy state changes, zebra notifies the colored nexthop only: the VPN route is evaluated again, but the VRF route is not reinstalled, and zebra does not resolve it again. A 'clear bgp *' fixes the route. Since commit 9d23a3a, the SR-TE color is stored in the bgp_path_info_extra structure, and no more in the attribute. In leak_update(), leak_update_nexthop_valid() registers the nexthop of the leaked path before bgp_path_info_extra_propagate() copies the color from the source path. bgp_find_or_add_nexthop() reads the color with bgp_path_info_get_srte_color(), and finds no color yet: the leaked path is attached to the colorless nexthop. The color is copied just after, so the route is installed in zebra with the color. When the color was in the attribute, it was already present at nexthop registration. Fix this by copying the color before registering the nexthop, for the new leaked paths and for the updated ones. When the policy goes down, the VRF path is now evaluated with the colored nexthop: > BGP: VRF default(0): Rcvd NH update 4.4.4.4/32(0)(1) - metric 40/0 #nhops 1/1 flags Valid Reg Label Valid redistributing protocol isis > BGP: nhop via 10.125.0.2 if 5 (I) (1 labels) > BGP: NH update for 4.4.4.4/32(0)(1)(VRF default) - flags Valid Reg Label Valid chgflags Changed Metric - evaluate paths > BGP: ... eval path 1/1 10.200.0.0/24 VRF l3vrf1 flags 0x4018 > BGP: ... eval path 1/3 10.200.0.0/24 RD 444:2 VRF default flags 0x418 Fixes: 9d23a3a ("bgpd: Move srte_color from attr struct to bgp_path_info_extra") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> (cherry picked from commit 7973359)
The SR-TE color set by a route-map on EVPN type-5 routes is lost when these routes are imported in a VRF. With 'set sr-te color 1' applied on the EVPN routes received from a neighbor, the matching IPv4 or IPv6 routes in the VRF are installed in zebra without color, and do not use the SR policy of that color. Since commit 9d23a3a, the SR-TE color is stored in the bgp_path_info_extra structure of the path, and no more in the attribute. bgp_create_evpn_bgp_path_info() builds the VRF path from the EVPN path attribute and labels, but does not copy the color from the EVPN path extra data. install_evpn_route_entry_in_vrf() does not copy it either when the VRF path is updated, and only compares the attributes to detect a change, so a color change made by a route-map is not seen. bgp_path_info_get_srte_color() then only finds the Color extended community, when present in the attribute. Fix this by copying the color from the EVPN path when the VRF path is created or updated, and by comparing the colors to detect a change, as leak_update() does for the routes leaked between VRFs. Fixes: 9d23a3a ("bgpd: Move srte_color from attr struct to bgp_path_info_extra") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> (cherry picked from commit c89c8e4)
Add a step 7 to isis_sr_te_topo1. rt6 exports 10.200.0.0/24 from vrf1 to L3VPN, and rt1 imports it in vrf1, with the 'set sr-te color 1' route-map applied on the VPN routes received from rt6. The SR Policy color 1 to 6.6.6.6 comes up after the route is installed, then goes down. The VRF route must use the IGP path, then the segment list of the policy, then the IGP path again. Without the commit "bgpd: track the color of vrf leaked paths in nexthop tracking", the step fails when the SR Policy comes up: > topo: With the SR Policy up, the VRF route should use its segment list > topo: Function returned expected labels [16050, 16060] before the VPN label, got [[16060], [16060]] Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> (cherry picked from commit e4a080e)
|
Target branch |
This file contains hidden or 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
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.
A colored L3VPN route imported in a VRF does not follow the state of the
SR-TE policy of its color. A 'set sr-te color 1' route-map is applied on
the VPN routes received from 4.4.4.4, and the SR policy color 1 to
4.4.4.4 is created by a PCE after the route of 10.200.0.0/24 is imported
in vrf l3vrf1. The route stays resolved over the IGP prefix-SID of
4.4.4.4, without the segment list of the policy:
The opposite happens when the policy goes down: the route keeps the
labels of the segment list that is no more valid.
The VRF route is tracked by the colorless nexthop, while only the VPN
route is tracked by the colored nexthop:
When the policy state changes, zebra notifies the colored nexthop only:
the VPN route is evaluated again, but the VRF route is not reinstalled,
and zebra does not resolve it again. A 'clear bgp *' fixes the route.
Since commit 9d23a3a, the SR-TE color is stored in the
bgp_path_info_extra structure, and no more in the attribute. In
leak_update(), leak_update_nexthop_valid() registers the nexthop of the
leaked path before bgp_path_info_extra_propagate() copies the color
from the source path. bgp_find_or_add_nexthop() reads the color with
bgp_path_info_get_srte_color(), and finds no color yet: the leaked path
is attached to the colorless nexthop. The color is copied just after,
so the route is installed in zebra with the color. When the color was
in the attribute, it was already present at nexthop registration.
Fix this by copying the color before registering the nexthop, for the
new leaked paths and for the updated ones. When the policy goes down,
the VRF path is now evaluated with the colored nexthop:
This is an automatic backport of pull request #24317 done by [Mergify](https://mergify.com).