1. When an OSPF interface is deleted, remove the references in link-local
LSA. Delete the LSA from the LSDB so that the callback has accessibily
to the interface prior to deletion.
2. Fix a double free for the opaque function table data structure.
3. Assure that the opaque per-type information and opaque function table
structures are removed at the same time since they have back pointers
to one another.
4. Add a topotest variation for the link-local opaque LSA crash.
Signed-off-by: Acee <aceelindem@gmail.com>
A route-map can be programmed to remove the route-target which
has been set with 'rt vpn export' command, but fails to remove
it.
Fix this by applying the route-map, then considering the resulting
extended community-list.
Add some tests to catch this issue.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add a test to check that the presence of a route-map at
exportation with a 'set extcommunity rt' is enough to allow
the prefix to be exported.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Just to make sure we don't crash bgpd with double-free if an existing route
already exists.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
If we send capabilities immediately, before receiving an UPDATE message, we end up
with a notification received from the neighbor. Let's wait until we have the fully
converged topology and do the stuff.
Tested locally and can't replicate the failure, let's see how happy is the CI this time.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Configure the bmp monitor unicast loc-rib.
Check the logging messages for the updated/withdrawn prefixes with
the presence of the loc-rib peer-type.
Signed-off-by: Farid MIHOUB <farid.mihoub@6wind.com>
Add "policy" field to the logged bmp messages so policy checks within
topotests would be easier and clearer.
Signed-off-by: Farid MIHOUB <farid.mihoub@6wind.com>
These enum's have been around since 2005 and FRR
still does not have any users of these particular
values. After almost 20 years, let's simplify the
code slightly and remove them.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Allows you to run daemons under valgrind integrated with gdb. When daemons are
run with the ``--gdb-daemons/--gdb-routers`` options they will be wired up to
valgrind using vgdb (valgrind tool) so gdb will stop when valgrind errors are
encountered.
Signed-off-by: Christian Hopps <chopps@labn.net>
It's been for a while disabled by default, but this seems reasonable to flip it.
We had `bgp enforce-first-as` as a global BGP knob to enable/disable this
behavior globally, later we introduced `enforce-first-as` per neighbor, with disabled
by default. Now let's enable this by default by bringing a global `bgp enforce-first-as`
command back.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
It's tested above, and was just copied from extended-nexthop as an example
which is broken too.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
extended-nexthop capability can't be unset to interface-based peers.
Anyway, this is always silently ignored:
```
✖ [test] peer\capability extended-nexthop
► prepare: initialize bgp test environment
► case 01: set peer-flag [capability extended-nexthop] on [IP-TEST]
► error: execution of command [no neighbor IP-TEST capability extended-nexthop] has failed with code [13]
failed
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
I added a new variable to calculate the required level of neighborhood,
as well as checking if the interfaces are in the same area,
in accordance with cisco
Signed-off-by: Sososhas <1248756005hfh@gmail.com>
isis:fixed adj level in topotests
fixed adj level on rt6
Signed-off-by: Sososhas <1248756005hfh@gmail.com>
Zebra currently does a shortest prefix match for
resolving nexthops for a prefix. This is typically
an ok thing to do but fails in several specific scenarios.
If a nexthop matches to a route that is not usable, nexthop
resolution just gives up and refuses to use that particular
route. For example if zebra currently has a covering prefix
say a 10.0.0.0/8. And about the same time it receives a
10.1.0.0/16 ( a more specific than the /8 ) and another
route A, who's nexthop is 10.1.1.1. Imagine the 10.1.0.0/16
is processed enough to know we want to install it and the
prefix is sent to the dataplane for installation( it is queued )
and then route A is processed, nexthop resolution will fail
and the route A will be left in limbo as uninstallable.
Let's modify the nexthop resolution code in zebra such that
if a nexthop's most specific match is unusable, continue looking
up the table till we get to the 0.0.0.0/0 route( if it's even
installed ). If we find a usable route for the nexthop accept
it and use it.
The bgp_default_originate topology test is frequently failing
with this exact problem:
B>* 0.0.0.0/0 [200/0] via 192.168.1.1, r2-r1-eth0, weight 1, 00:00:21
B 1.0.1.17/32 [200/0] via 192.168.0.1 inactive, weight 1, 00:00:21
B>* 1.0.2.17/32 [200/0] via 192.168.1.1, r2-r1-eth0, weight 1, 00:00:21
C>* 1.0.3.17/32 is directly connected, lo, 00:02:00
B>* 1.0.5.17/32 [20/0] via 192.168.2.2, r2-r3-eth1, weight 1, 00:00:32
B>* 192.168.0.0/24 [200/0] via 192.168.1.1, r2-r1-eth0, weight 1, 00:00:21
B 192.168.1.0/24 [200/0] via 192.168.1.1 inactive, weight 1, 00:00:21
C>* 192.168.1.0/24 is directly connected, r2-r1-eth0, 00:02:00
C>* 192.168.2.0/24 is directly connected, r2-r3-eth1, 00:02:00
B>* 192.168.3.0/24 [20/0] via 192.168.2.2, r2-r3-eth1, weight 1, 00:00:32
B 198.51.1.1/32 [200/0] via 192.168.0.1 inactive, weight 1, 00:00:21
B>* 198.51.1.2/32 [20/0] via 192.168.2.2, r2-r3-eth1, weight 1, 00:00:32
Notice that the 1.0.1.17/32 route is inactive but the nexthop
192.168.0.1 is covered by both the 192.168.0.0/24 prefix( shortest match )
*and* the 0.0.0.0/0 route ( longest match ). When looking at the logs
the 1.0.1.17/32 route was not being installed because the matching
route was not in a usable state, which is because the 192.168.0.0/24
route was in the process of being installed.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When specified `--gdb-use-emacs` will launch the daemon with gdb inside a
running emacs server using `emacsclient --eval` commands.
Signed-off-by: Christian Hopps <chopps@labn.net>
There is no test that ensures the test of the 'redistribute
table-direct' facility. Add a test that checks that routes
created before and after BGP is started, is correctly imported.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
If we modify the prefix-list that is used to define the routes to be
advertised, all of them MUST be advertised.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
There is no test that checks for the label allocation mechanisms
involved when using BGP and/or LDP.
- Some configuration changes are applied in the BGP configuration,
and the impact is checked on the BGP contexts, and on the label
manager.
- The label manager dynamic range is reconfigured, BGP auto mode
is checked against the new range, along with LDP when restarting.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The expected tableVersion is wrong, when checking r1 table.
The tableVersion value increments at each route updates. The
previous commit brought an additional route update with the
'vpn_leak_postchange_all()' call.
Keep the function call, and do not check the table version
in bgp_srv6l3vpn_to_bgp_vrf[2,3] tests.
Fixes: 205b62ffae2c ("bgpd: fix hardset l3vpn label available in mpls pool")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
