Create a single registry of default port values that daemons
are using. Most of these are vty ports, but there are some
others for features like ospfapi and zebra FPM.
Signed-off-by: Mark Stapp <mjs@labn.net>
Structure size of bgp_path_info_extra when compiled
with vnc is 184 bytes. Reduce this size to 72 bytes
when compiled w/ vnc but not necessarily turned
on vnc.
With 2 full bgp feeds this saves aproximately 100mb
when compiling with vnc and not using vnc.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
pahole reports that the hash_bucket has 2 4 byte holes
in the data structure. Let's reorganize this a bit
and save 8 bytes per hash_bucket instance.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add tests in bgp_vrf_route_leak_basic topotest to check that route
leaking from the default VRF results in an operational route.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add a test in bgp_vrf_route_leak_basic topotest to check that route
leaking from a non existing VRF results in an inactive route.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Update bgp_vrf_route_leak_basic to set up the VRF interfaces. Otherwise
the routes to the VRF interface are inactives.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Previously, routes leaked from one VRF to another VRF were associated
with the original nexthop interface.
Due to this change, the `bgp_srv6l3vpn_route_leak` topotest always fails
because it still expects the nexthop interface.
This commit fixes the expected interface name in the
`bgp_srv6l3vpn_route_leak` topotest.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Leaked connected routes have now the following nexthop interfaces:
- lo for routes imported from the default VRF
- or the VRF interface for routes imported from the other VRFs.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Leaked routes from prefixes defined with 'network <prefix>' are inactive
because they have no valid nexthop interface.
> vrf r1-cust1
> ip route 172.16.29.0/24 192.168.1.2
> router bgp 5227 vrf r1-cust1
> no bgp network import-check
> address-family ipv4 unicast
> network 172.16.29.0/24
> rd vpn export 10:1
> rt vpn import 52:100
> rt vpn export 52:101
> export vpn
> import vpn
> exit-address-family
> exit
> !
> router bgp 5227 vrf r1-cust4
> bgp router-id 192.168.1.1
> !
> address-family ipv4 unicast
> network 192.0.2/24
> rd vpn export 10:1
> rt vpn import 52:101
> rt vpn export 52:100
> export vpn
> import vpn
> exit-address-family
> exit
Extract from the routing table:
> VRF r1-cust1:
> S>* 172.16.29.0/24 [1/0] via 192.168.1.2, r1-eth4, weight 1, 00:47:53
>
> VRF r1-cust4:
> B 172.16.29.0/24 [20/0] is directly connected, unknown (vrf r1-cust1) inactive, weight 1, 00:03:40
Routes imported through the "network" command, as opposed to those
redistributed from the routing table, do not associate with any specific
interface.
When leaking prefix from other VRFs, if the route was imported from the
network statement (ie. static sub-type), set nh_ifindex to the index of
the VRF master interface of the incoming BGP instance.
The result is:
> VRF r1-cust4:
> B>* 172.16.29.0/24 [20/0] is directly connected, r1-cust1 (vrf r1-cust1), weight 1, 00:00:08
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
It allows people not familiar with libyang and FRR internals to use
mgmtd FE API by looking only at `mgmt_msg_native.h` header. We still use
the same values to avoid a lot of mapping code, and ensure that any
change doesn't slip unnoticed by using static asserts.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
We don't need to create an actual tree to print an empty tree, libyang
handles NULL just fine. The actual problem is that `yang_dnode_new`
creates a tree by validating it, and the validation creates all implicit
default nodes. Therefore, when called with "with-default" flags, instead
of getting an empty tree, we get a tree with all top-level default set.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
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 <dmytro.shytyi@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Enable the SRv6 SID prefix generation in make_prefix()
function of bgp_nht.c.
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
fixup: bgpd: extend make_prefix to form srv6-based prefix
In bgp_adj_in_set(), attr has not yet been interned. adj->attr is always
different from attr. adj->attr is always uninterned and interned even if
attr and adj->attr are identical.
Fix the comparison.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Without this change when we change the route-map, we never reinstall the route
if the route-map has changed.
We checked only some attributes like aspath, communities, large-communities,
extended-communities, but ignoring the rest of attributes.
With this change, let's check if the route-map has changed.
bgp_route_map_process_update() is triggered on route-map change, and we set
`changed` to true, which treats aggregated route as not the same as it was before.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
