Change the comment in the code that refers to ZEBRA_FLAG_XXX
defines.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Until now, when a FEC entry is added in zebra, driven by the
reception of a BGP labeled unicast update, an LSP entry is
created. That LSP entry is resolved by using the route entry
which is also installed by BGP labeled unicast.
This route entry is not available when we face with i-bgp
peering session. I-BGP labeled sessions are used to establish
IP connectivity across separate IGPs.
The below dumps illustrate a 3 IGP topology. An attempt to create
connectivity between the north and the south machines is done.
The 3 separate IGPs are configured in Segment routing:
- north-east
- east-west
- west-south
We create BGP peerings between each endpoint of each IGP:
- iBGP between (north) and (east)
- iBGP between (east) and (west)
- iBGP between (west) and (south)
Before that patch, the FEC entries could not be resolved on the
east machine:
Before:
east-vm# show mpls fec
192.0.2.1/32
Label: 18
Client list: bgp(fd 48)
192.0.2.5/32
Label: 17
Client list: bgp(fd 48)
192.0.2.7/32
Label: 19
Client list: bgp(fd 48)
east-vm# show mpls table
Inbound Label Type Nexthop Outbound Label
--------------------------------------------------------
1011 SR (OSPF) 192.168.2.2 1011
1022 SR (OSPF) 192.168.2.2 implicit-null
11044 SR (IS-IS) 192.168.3.4 implicit-null
11055 SR (IS-IS) 192.168.3.4 11055
30000 SR (OSPF) 192.168.2.2 implicit-null
30001 SR (OSPF) 192.168.2.2 implicit-null
36000 SR (IS-IS) 192.168.3.4 implicit-null
east-vm# show ip route
[..]
B 192.0.2.1/32 [200/0] via 192.0.2.1 inactive, label implicit-null, weight 1, 00:17:45
O>* 192.0.2.1/32 [110/20] via 192.168.2.2, r3-eth0, label 1011, weight 1, 00:17:47
O>* 192.0.2.2/32 [110/10] via 192.168.2.2, r3-eth0, label implicit-null, weight 1, 00:17:47
O 192.0.2.3/32 [110/0] is directly connected, lo, weight 1, 00:17:57
C>* 192.0.2.3/32 is directly connected, lo, 00:18:03
I>* 192.0.2.4/32 [115/20] via 192.168.3.4, r3-eth1, label implicit-null, weight 1, 00:17:59
B 192.0.2.5/32 [200/0] via 192.0.2.5 inactive, label implicit-null, weight 1, 00:17:56
I>* 192.0.2.5/32 [115/30] via 192.168.3.4, r3-eth1, label 11055, weight 1, 00:17:58
B> 192.0.2.7/32 [200/0] via 192.0.2.5 (recursive), label 19, weight 1, 00:17:45
* via 192.168.3.4, r3-eth1, label 11055/19, weight 1, 00:17:45
[..]
After command "mpls fec nexthop-resolution" was applied, the FEC
entries will resolve over any non BGP route that has a labeled path
selected.
east-vm# show mpls table
Inbound Label Type Nexthop Outbound Label
--------------------------------------------------------
17 SR (IS-IS) 192.168.3.4 11055
18 SR (OSPF) 192.168.2.2 1011
19 BGP 192.168.3.4 11055/19
1011 SR (OSPF) 192.168.2.2 1011
1022 SR (OSPF) 192.168.2.2 implicit-null
11044 SR (IS-IS) 192.168.3.4 implicit-null
11055 SR (IS-IS) 192.168.3.4 11055
30000 SR (OSPF) 192.168.2.2 implicit-null
30001 SR (OSPF) 192.168.2.2 implicit-null
36000 SR (IS-IS) 192.168.3.4 implicit-null
Co-developed-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When an LSP entry is created from a FEC entry, multiple labels
may now be appended to the LSP entry, instead of one single.
Upon lsp creation, the LSP trace will display all the labels
appended.
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
There are two ways of iterating over nexthops of a given
route entry.
- Either only the main nexthop are taken into account
(which is the case today when attempting to install an
LSP entry on a BGP connected labeled route.
- Or by taking into account nexthops that are resolved
and linked in nexthop->resolved of the previous nexthop
which has RECURSIVE flag set. This second case has to be
taken into account in the case where recursive routes may
be used to install an LSP entry.
Introduce a new API in nexthop that will parse over the
appropriate nexthop, if the nexthop-resolution flag is turned
on or not on the given VRF.
Use that API in the lsp_install() function so as to walk
over the appropriate nexthops.
Co-developed-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
This commit addresses an issue that happens when using bgp
labeled unicast peering with a rr client, with a received prefix
which is the local ip address of the bgp session.
When using bgp ipv4 labeled session, the local prefix is
received by a peer, and finds out that the proposed prefix
and its next-hop are the same. To avoid a route loop locally,
no nexthop entry is referenced for that prefix, and the route
will not be selected.
As it has been done for ipv4-unicast, apply the following fix
for labeled address families: when the received peer is
a route reflector, the prefix has to be selected, even if the
route can not be installed locally.
Fixes: f874552557 ("bgpd: authorise to select bgp self peer prefix on rr case")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Upon reconfiguring nexthop-resolution updates, update the
lsp entries accordingly.
If fec nexthop-resolution becomes true, then call again
fec_change_update_lsp() for each fec entry available.
If fec nexthop-resolution becomes false, then call again
fec_change_update_lsp() for each fec entry available, and
if the update fails, uninstall any lsp related with the fec
entry. In the case lsp_install() and no lsp entry could be
created or updated, then consider this call as a failure, and
return -1.
Co-developed-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Topotest relevant changes:
- add support for `timeout` arg to `cmd_*()`
- handle invalid regexp in CLI commands
- fix long interface name support
Full munet changelog:
munet: 0.14.9: add support for `timeout` arg to `cmd_*()`
munet: 0.14.8: cleanup the cleanup (kill) on launch options
munet: 0.14.7: allow multiple extra commands for shell console init
munet: 0.14.6:
- qemu: gather gcda files where munet can find them
- handle invalid regexp in CLI commands
munet: 0.14.5:
- (podman) pull missing images for containers
- fix long interface name support
- add another router example
munet: 0.14.4: mutest: add color to PASS/FAIL indicators on tty consoles
munet: 0.14.3: Add hostnet node that runs it's commands in the host network namespace.
munet: 0.14.2:
- always fail mutest tests on bad json inputs
- improve ssh-remote for common use-case of connecting to host connected devices
- fix ready-cmd for python v3.11+
munet: 0.14.1: Improved host interface support.
Signed-off-by: Christian Hopps <chopps@labn.net>
After modifying the "label vpn export value", the vpn label information
of the VRF is not updated to the peers.
For example, the 192.168.0.0/24 prefix is announced to the peer with a
label value of 222.
> 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
> 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 label with "label vpn export" does not update the label
value to the peer unless the BGP sessions is re-established.
No labels are stored are stored struct bgp_adj_out so that it is
impossible to compare the current value with the previous value
in adj-RIB-out.
Reference the bgp_labels pointer in struct bgp_adj_out and compare the
values when updating adj-RIB-out.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
In a BGP L3VPN context using ADJ-RIB-IN (ie. enabled with
'soft-reconfiguration inbound'), after applying a deny route-map and
removing it, the remote MPLS label information is lost. As a result, BGP
is unable to re-install the related routes in the RIB.
For example,
> 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
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
A route-map now filter all incoming BGP updates:
> route-map rmap deny 1
> router bgp 65500
> address-family ipv4 vpn
> neighbor 192.0.2.2 route-map rmap in
The prefix is now filtered:
> # show bgp ipv4 vpn 192.168.0.0/24
> #
The route-map is detached:
> 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 remote label 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
The reason for the loose is that labels are stored within struct attr ->
struct extra -> struct bgp_labels but not in the struct bgp_adj_in.
Reference the bgp_labels pointer in struct bgp_adj_in and use its values
when doing a soft reconfiguration of the BGP table.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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 <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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 <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Small rework to fix the following checkpatch warning:
> < WARNING: Too many leading tabs - consider code refactoring
> < #2142: FILE: /tmp/f1-1616988/vnc_import_bgp.c:2142:
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
In route_vty_out_detail(), tag_buf stores a string representation of
the VNI label.
Rename tag_buf to vni_buf for clarity and rework the code a little bit
to prepare the following commits.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
num_labels cannot be greater than BGP_MAX_LABELS by design.
Remove the check and the override.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add bgp_path_info_labels_same() to compare labels with labels from
path_info. Remove labels_same() that was used for mplsvpn only.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
In bgp_update(), path_info *new has just been created and has void
labels. bgp_labels_same() is always false.
Do not compare previous labels before setting them.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
No need to init labels at extra allocation. num_labels is the number
of set labels in label[] and is initialized to 0 by default.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
The handling of MPLS labels in BGP faces an issue due to the way labels
are stored in memory. They are stored in bgp_path_info but not in
bgp_adj_in and bgp_adj_out structures. As a consequence, some
configuration changes result in losing labels or even a bgpd crash. For
example, when retrieving routes from the Adj-RIB-in table
("soft-reconfiguration inbound" enabled), labels are missing.
bgp_path_info stores the MPLS labels, as shown below:
> struct bgp_path_info {
> struct bgp_path_info_extra *extra;
> [...]
> struct bgp_path_info_extra {
> mpls_label_t label[BGP_MAX_LABELS];
> uint32_t num_labels;
> [...]
To solve those issues, a solution would be to set label data to the
bgp_adj_in and bgp_adj_out structures in addition to the
bgp_path_info_extra structure. The idea is to reference a common label
pointer in all these three structures. And to store the data in a hash
list in order to save memory.
However, an issue in the code prevents us from setting clean data
without a rework. The extra->num_labels field, which is intended to
indicate the number of labels in extra->label[], is not reliably checked
or set. The code often incorrectly assumes that if the extra pointer is
present, then a label must also be present, leading to direct access to
extra->label[] without verifying extra->num_labels. This assumption
usually works because extra->label[0] is set to MPLS_INVALID_LABEL when
a new bgp_path_info_extra is created, but it is technically incorrect.
Cleanup the label code by setting num_labels each time values are set in
extra->label[] and checking extra->num_labels before accessing the
labels.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Configuration:
```
vtysh <<EOF
configure
vrf vrf100
vni 10100
exit-vrf
router bgp 50
address-family l2vpn evpn
advertise-all-vni
exit-address-family
exit
router bgp 100 vrf vrf100
exit
EOF
```
TL;DR; When we configure `advertise-all-vni` (in this case), a new BGP instance
is created with the name vrf100, and ASN 50. Next, when we create
`router bgp 100 vrf vrf100`, we look for the BGP instance with the same name
and we found it, but ASNs are different 50 vs. 100.
Every such a new auto created instance is flagged with BGP_VRF_AUTO.
After the fix:
```
router bgp 50
!
address-family l2vpn evpn
advertise-all-vni
exit-address-family
exit
!
router bgp 100 vrf vrf100
exit
!
end
donatas.net(config)# router bgp 51
BGP is already running; AS is 50
donatas.net(config)# router bgp 50
donatas.net(config-router)# router bgp 101 vrf vrf100
BGP is already running; AS is 100
donatas.net(config)# router bgp 100 vrf vrf100
donatas.net(config-router)#
```
Fixes: https://github.com/FRRouting/frr/issues/16152
Fixes: https://github.com/FRRouting/frr/issues/9537
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Fixes:
zebra/zebra_netns_notify.c: In function 'zebra_ns_ready_read':
zebra/zebra_netns_notify.c:266:40: error: implicit declaration of function 'basename' [-Wimplicit-function-declaration]
266 | if (strmatch(VRF_DEFAULT_NAME, basename(netnspath))) {
| ^~~~~~~~
Fixed by including libgen.h, then since basename may modify its
parameter, allocate a copy on the stack, using strdupa, and pass the
temporary string to basename.
According to the man page for basename:
With glibc, one gets the POSIX version of basename() when
<libgen.h> is included, and the GNU version otherwise.
The POSIX version of basename may modify the contents of path,
so we should to pass a copy when calling this function.
[1] https://man7.org/linux/man-pages/man3/basename.3.html
Signed-off-by: Georgi Valkov <gvalkov@gmail.com>
I had problem by running container after build.
It gave the error below in container,
[FATAL tini (7)] exec /usr/lib/frr/docker-start failed: Permission denied
So I have fixed the permission issues after building images.
Signed-off-by: Çağatay Erem <cagatayerem@gmail.com>
The 'show running-config' does not display the ipv6 source address
when a locator is not configured. Fix this by systematically displaying
the ipv6 source address.
Fixes: 6a0956169b ("zebra: Add encap source address to SRv6 config write function")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
