bgpd: fix MPLS labels in adj-RIB-in and adj-RIB-out #15205
Closed
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
|
Isn't this the second time this has been attempted to be upstreamed? What was the original PR? |
The original one is from Philippe's account. I am refreshing it but I cannot work from his account. I am refreshing it when it is ready, it will be pushed to the original one |
Move the BGP_MAX_LABEL value in the bgp_label.h header. Signed-off-by: Philippe Guibert <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>
After modifying the "label vpn export value", the vpn label information
of the VRF is not updated to the peers.
The below configuration example illustrates the 192.168.0.0/24 BGP
update sent to the 192.0.2.2 peer, with the 222 label value.
> router bgp 65500
> [..]
> neighbor 192.0.2.2 remote-as 65501
> address-family ipv4-vpn
> neighbor 192.0.2.2 activate
> exit-address-family
> exit
> router bgp 65500 vrf vrf2
> bgp router-id 192.0.1.1
> address-family ipv4 unicast
> network 192.168.0.0/24
> label vpn export 222
> rd vpn export 444:444
> rt vpn both 53:100
> export vpn
> import vpn
> exit-address-family
Changing the value of "label vpn export" in a "router bgp AS vrf VRF"
context has no effect if the session is established unless the session
is reset.
Each label value modification is stored in the 'bgp_path_info_extra'
structure of each BGP update. But the change is not detected in the code
that handles the ADJ-RIB-OUT changes for each peer. The
'bgp_path_info_extra' is never parsed, and there is no previously stored
label value in another place.
To solve this issue, duplicate the label value from the
'bgp_path_info_extra' structure to the 'bgp_adj_out' structure that is
parsed when the value is changed.
Note: an alternate solution consisted in moving the label information
from the 'bgp_path_info_extra' structure to the 'attr' structure.
Doing this resulted in performing many changes in the BGP code, which was
too risky for maintenance versions.
Signed-off-by: Philippe Guibert <[email protected]>
Signed-off-by: Louis Scalbert <[email protected]>
In a BGP L3VPN context using ADJ-RIB-IN (ie. enabled with 'soft-reconfiguration inbound'), after applying a deny route-map and then removing it, the remote MPLS label information is lost. As a consequence, BGP is unable to re-install the related routes in the RIB. The below configuration example illustrates a VPN setup with 'soft-reconfiguration' enabled > router bgp 65500 > [..] > neighbor 192.0.2.2 remote-as 65501 > address-family ipv4 vpn > neighbor 192.0.2.2 activate > neighbor 192.0.2.2 soft-reconfiguration inbound > exit-address-family > exit The 192.168.0.0/24 prefix has a remote label value of 102 in the BGP RIB. > # show bgp ipv4 vpn 192.168.0.0/24 > BGP routing table entry for 444:1:192.168.0.0/24, version 2 > [..] > 192.168.0.0 from 192.0.2.2 > Origin incomplete, metric 0, valid, external, best (First path received) > Extended Community: RT:52:100 > Remote label: 102 > Last update: Mon Mar 13 16:36:38 2023 A route-map is configured to filter incoming BGP updates from the `192.0.2.2` peer. > router bgp 65500 > address-family ipv4 vpn > neighbor 192.0.2.2 route-map rmap in > exit-address-family > exit > access-list 1 permit any > route-map rmap deny 1 > match ip address 1 The prefix is now filtered: > # show bgp ipv4 vpn 192.168.0.0/24 > # Then, the route-map is detached: because the ADJ-RIB-IN is present, a soft reconfiguration is performed. > router bgp 65500 > address-family ipv4 vpn > no neighbor 192.168.0.1 route-map rmap in The BGP RIB entry is present but the observed label value is lost: > # show bgp ipv4 vpn 192.168.0.0/24 > BGP routing table entry for 444:1:192.168.0.0/24, version 2 > [..] > 192.168.0.0 from 192.0.2.2 > Origin incomplete, metric 0, valid, external, best (First path received) > Extended Community: RT:52:100 > Last update: Mon Mar 13 16:36:38 2023 When the ADJ-RIB-IN is enabled for a given peer, and there is no filtering, incoming prefixes are present on both the RIB and the ADJ-RIB-IN database. Most of the attribute values are stored in the 'attr' structure: it is referenced by the ADJ-RIB-IN in the 'bgp_adj_in' structure, and referenced by the RIB in the 'bgp_path_info' structure. The label information is stored in the 'bgp_path_info_extra' structure, and is only referenced in the 'bgp_path_info' structure. When a BGP update is filtered, the 'bgp_path_info' structure of the given prefix of the BGP update is flushed, and the 'bgp_path_info_extra' structure is removed. When detaching the route-map, the soft reconfiguration attempts to get the label information from the 'bgp_path_info' structure if available. In our case, the structure is not available: the soft reconfiguration fails to find the label information. To solve this issue, duplicate the label value from the extra structure to the 'bgp_adj_in' structure that is parsed when a re-read is done. Note: an alternate solution consisted in moving the label information from the 'bgp_path_info_extra' structure to the 'attr' structure. Doing this resulted in performing many changes in the BGP code, which was too risky for maintenance versions. Signed-off-by: Philippe Guibert <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>
Clarify bgp_vpnv4_ebgp Signed-off-by: Louis Scalbert <[email protected]>
This test ensures that when r1 changes the label value, then the new value is automatically propagated to remote peer. This demonstrates that the ADJ-RIB-OUT to r2 has been correctly updated. Signed-off-by: Philippe Guibert <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>
The test is done on r2. A BGP update is received on r2, and is filtered on r2. The RIB of r2 does not have the BGP update stored, but the ADJ-RIB-IN is yet present. To demonstrate this, if the inbound route-map is removed, then the BGP update should be copied from the the ADJ-RIB-IN and added to the RIB with the label value. Signed-off-by: Philippe Guibert <[email protected]> Signed-off-by: Louis Scalbert <[email protected]>
louis-6wind
changed the title
louis-6wind
force-pushed
the
mpls-label-attr-92
branch
from
fe0b098 to
1096814
Compare
louis-6wind
changed the title
|
This version was duplicating the labels into adj-rib-in and adj-rib-out. Replaced by #15434 |
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.
in order to solve: