vivek [Mon, 25 May 2020 21:17:12 +0000 (14:17 -0700)]
bgpd: During NHT change evaluation, skip inappropriate paths
When there is a NHT change and the paths dependent on that NHT are being
evaluated, skip those that are marked for removal or as history.
When a route gets withdrawn, its valid flag is cleared and it is flagged
for removal; in the case of an EVPN route, it is also unimported from
VRFs (L2 and/or L3). bgp_process is then scheduled. Under rare timing
conditions, an NHT update for the route's next hop may arrive right after,
and if routes flagged for removal are not skipped, they may not only be
incorrectly marked as valid but also re-imported in the case of EVPN,
which will be a serious error.
vivek [Mon, 25 May 2020 20:48:37 +0000 (13:48 -0700)]
bgpd: Enhance BGP NHT show commands
Display next hop resolution information, whether the "detail" option is
specified or not as it is quite fundamental and only minimally increases
the output.
Introduce option to look at a specific NHT entry, which will also show
the paths associated with that entry.
Rafael Zalamena [Thu, 21 May 2020 21:47:00 +0000 (18:47 -0300)]
ospfd: change retransmit-interval minimum value
The command `area ... virtual-link ... retransmit-interval` supports
1-65535 range and the documentation already said
`ip ospf retransmit-interval` supports that, lets make the DEFUN to
accept that value.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
GalaxyGorilla [Fri, 22 May 2020 21:18:46 +0000 (21:18 +0000)]
tests: Fix JSON diff for nested lists
The involved piece of code is supposed to find a 'closest' match for two
JSON structures using another JSON diff. However, it can happen that
during that new diff the JSON structures are altered (elements from a
list are deleted when 'found'). This is in general ok when the deleted
element is part of the JSON structure which 'matches', but when it later
turns out that some other element of the structure doesn't fit, then the
whole structure should be recovered. This is now realized by using a
deepcopy for the besaid new JSON diff such that the original is only
altered (e.g. deleted) when the diff is clean.
Donald Sharp [Thu, 14 May 2020 13:58:36 +0000 (09:58 -0400)]
zebra: Allow zebra to gracefully handle rtadv when not configured
Currently zebra when you compile without router advertisements
will just say something like `cannot handle message 42`. Which
is not terribly useful to an end user.
Add some smarts to the zapi message handling to just do nothing
and output a debug if someone has it turned on.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Allow user to pre-configure peers with a profile. If a peer is using a
profile any configuration made to the peer will take precedence over
the profile configuration.
In order to track the peer configuration we have now an extra copy of
the peer configuration in `peer_profile` inside `struct bfd_session`.
This information will help the profile functions to detect user
configurations and avoid overriding what the user configured. This is
especially important for peers created via other protocols where the
default `shutdown` state is disabled (peers created manually are
`shutdown` by default).
Profiles can be used before they exist: if no profile exists then it
will use the default configuration.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Kuldeep Kashyap [Wed, 13 May 2020 18:38:41 +0000 (18:38 +0000)]
tests: Add bgp-multi-vrf-topo2 testsuite
1. Adding 4 testcases to this testsuite to verify BGP multi-vrf functionality
2. Adding supporting JSON file to create topology and base config
3. Execution time is ~3 mins
Kuldeep Kashyap [Wed, 13 May 2020 18:33:36 +0000 (18:33 +0000)]
tests: Add bgp-multi-vrf-topo1 testsuite
1. Adding 22 testcases to this testsuite to verify BGP multi-vrf functionality
2. Adding supporting JSON file to create topology and base config
3. Execution time is ~7 mins.
if mpls-te is enabled in the area, on creating a circuit we
must refresh the link params - else interfaces that are enabled
for IS-IS after configuring 'mpls-te on' will not correctly
advertise link parameters.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
in the CLI we state that the bandwidth of a link is
in Megabits per second, but when converting it to
Bytes per second for TE purposes we were treating
it as Kilobits. Fix the conversion error.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
Philippe Guibert [Tue, 19 May 2020 11:57:08 +0000 (12:57 +0100)]
lib, zebra: update interface name at netlink creation
the interface name was not present in the hook in charge of updating the
interface context to the registered hook service. For that, update the
name before informing it.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
zebra: dynamically detect vxlan link interfaces in other netns
this is used when parsing the newly network namespaces. actually, to
track the link of some interfaces like vxlan interfaces, both link index
and link nsid are necessary. if a vxlan interface is moved to a new
netns, the link information is in the default network namespace, then
LINK_NSID is the value of the netns by default in the new netns. That
value of the default netns in the new netns is not known, because the
system does not automatically assign an NSID of default network
namespace in the new netns. Now a new NSID of default netns, seen from
that new netns, is created. This permits to store at netns creation the
default netns relative value for further usage.
Because the default netns value is set from the new netns perspective,
it is not needed anymore to use the NETNSA_TARGET_NSID attribute only
available in recent kernels.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Fri, 20 Dec 2019 16:51:37 +0000 (17:51 +0100)]
lib, zebra: reuse and adapt ns_list walk functionality
the walk routine is used by vxlan service to identify some contexts in
each specific network namespace, when vrf netns backend is used. that
walk mechanism is extended with some additional paramters to the walk
routine.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Fri, 25 Oct 2019 12:25:00 +0000 (14:25 +0200)]
zebra: when parsing local entry against dad, retrieve config
when duplicate address detection is observed, some incrementation,
some timing mechanisms need to be done. For that the main evpn
configuration is retrieved. Until now, the VRF that was storing the dad
config parameters was the same VRF that hosted the VXLAN interface. With
netns backend, this is not true, as the VXLAN interface is in the
same VRF as the bridge interface. The modification takes same definition
as in BGP, that is to say that there is a single bgp evpn instance, and
this is that instance that will give the correct config settings.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Fri, 11 Oct 2019 12:11:13 +0000 (14:11 +0200)]
bgpd: evpn nexthop can be changed by default
There can be cases where evpn traffic is not meshed across various
endpoints, but sent to a central pe. For this situation, remove the
nexthop unchanged default behaviour for bgp evpn. Also add route
reflector commands to bgp evpn node.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
zebra: zvni_map_to_vlan() adaptation for all namespaces
this change is needed when a MAC/IP entry is learned by zebra, and the
entry happens to be in a different namespace. So that the entry be
active, the correct vni match has to be found.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
this information is necessary for local information, because the
interface associated to the mac address is stored with its ifindex, and
the ifindex may not be enough to get to the right interface when it
comes with multiple network namespaces.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
zebra: bridge layer2 information records ns_id where bridge is
when working with vrf netns backend, two bridges interfaces may have the
same bridge interface index, but not the same namespace. because in vrf
netns backend mode, a bridge slave always belong to the same network
namespace, then a check with the namespace id and the ns id of the
bridge interface permits to resolve correctly the interface pointer.
The problem could occur if a same index of two bridge interfaces can be
found on two different namespaces.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
zebra, lib: new API to get absolute netns val from relative netns val
when receiving a netlink API for an interface in a namespace, this
interface may come with LINK_NSID value, which means that the interface
has its link in an other namespace. Unfortunately, the link_nsid value
is self to that namespace, and there is a need to know what is its
associated nsid value from the default namespace point of view.
The information collected previously on each namespace, can then be
compared with that value to check if the link belongs to the default
namespace or not.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
zebra, lib: store relative default ns id in each namespace
to be able to retrieve the network namespace identifier for each
namespace, the ns id is stored in each ns context. For default
namespace, the netns id is the same as that value.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
zebra, lib: add an internal API to get relative default nsid in other ns
as remind, the netns identifiers are local to a namespace. that is to
say that for instance, a vrf <vrfx> will have a netns id value in one
netns, and have an other netns id value in one other netns.
There is a need for zebra daemon to collect some cross information, like
the LINK_NETNSID information from interfaces having link layer in an
other network namespace. For that, it is needed to have a global
overview instead of a relative overview per namespace.
The first brick of this change is an API that sticks to netlink API,
that uses NETNSA_TARGET_NSID. from a given vrf vrfX, and a new vrf
created vrfY, the API returns the value of nsID from vrfX, inside the
new vrf vrfY.
The brick also gets the ns id value of default namespace in each other
namespace. An additional value in ns.h is offered, that permits to
retrieve the default namespace context.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
zebra: map vxlan interface to bridge interface with correct ns id
an incoming bridge index has been found, that is linked with vxlan
interface, and the search for that bridge interface is done. In
vrf-lite, the search is done across the same default namespace, because
bridge and vxlan may not be in the same vrf. But this behaviour is wrong
when using vrf netns backend, as the bridge and the vxlan have to be in
the same vrf ( hence in the same network namespace). To comply with
that, use the netnamespace of the vxlan interface. Like that, the
appropriate nsid is passed as parameter, and consequently, the search is
correct, and the mac address passed to BGP will be ok too.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Thu, 26 Sep 2019 16:49:59 +0000 (18:49 +0200)]
zebra: importation of bgp evpn rt5 from vni with other netns
With vrf-lite mechanisms, it is possible to create layer 3 vnis by
creating a bridge interface in default vr, by creating a vxlan interface
that is attached to that bridge interface, then by moving the vxlan
interface to the wished vrf.
With vrf-netns mechanism, it is slightly different since bridged
interfaces can not be separated in different network namespaces. To make
it work, the setup consists in :
- creating a vxlan interface on default vrf.
- move the vxlan interface to the wished vrf ( with an other netns)
- create a bridge interface in the wished vrf
- attach the vxlan interface to that bridged interface
from that point, if BGP is enabled to advertise vnis in default vrf,
then vxlan interfaces are discovered appropriately in other vrfs,
provided that the link interface still resides in the vrf where l2vpn is
advertised.
to import ipv4 entries from a separate vrf, into the l2vpn, the
configuration of vni in the dedicated vrf + the advertisement of ipv4
entries in bgp vrf will import the entries in the bgp l2vpn.
the modification consists in parsing the vxlan interfaces in all network
namespaces, where the link resides in the same network namespace as the
bgp core instance where bgp l2vpn is enabled.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Tue, 24 Sep 2019 08:44:58 +0000 (10:44 +0200)]
zebra: across network namespace, vxlan remembers the link information
the link information of vxlan interface is populated in layer 2
information, as well as in layer 2 vxlan information. This information
will be used later to collect vnis that are in other network namespaces,
but where bgp evpn is enabled on main network namespaces, and those vnis
have the link information in that namespace.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
rgirada [Mon, 18 May 2020 05:02:34 +0000 (22:02 -0700)]
ospfd: Restoring the original tag in external lsas
Description:
When a routemap applied to set a tag, all the permitted routes are
refreshed with new tag, but when a different route map applied with
a different action still the same tag persits in the external route.
The actual tag received from zebra is expected to be set back to the
routes here. Corrected this behaviour by restoring a original tag
received from zebra.
rgirada [Mon, 18 May 2020 04:40:48 +0000 (21:40 -0700)]
ospfd: Route-tag is not set to external lsas when applying with rmap
Description:
Route-tag is not set to external lsas originated by ospf when a routemap
applied by setting a specific tag. When applying a route-map on redistribution,
external lsas will be refreshed if there is any change in the route parametrs
after applying routemap. But changing tag is not handled here.
Added the apripriate fix to correct this.
projects / mirror_frr.git / log