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>
Create Local routes in FRR:
S 0.0.0.0/0 [1/0] via 192.168.119.1, enp39s0, weight 1, 00:03:46
K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp39s0, 00:03:51
O 192.168.119.0/24 [110/100] is directly connected, enp39s0, weight 1, 00:03:46
C>* 192.168.119.0/24 is directly connected, enp39s0, 00:03:51
L>* 192.168.119.224/32 is directly connected, enp39s0, 00:03:51
O 192.168.119.229/32 [110/100] via 0.0.0.0, enp39s0 inactive, weight 1, 00:03:46
C>* 192.168.119.229/32 is directly connected, enp39s0, 00:03:46
Create ability to redistribute local routes.
Modify tests to support this change.
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>
The bgp_vpnv[4,6]_table_check() functions analyze the
expected label value of VPN prefixes present in the BGP table.
However, it doesn't verify if the prefixes exist before doing
this. Consequently, the tests will fail if the prefixes do not
show up immediately.
Ensure that all expected VPN prefixes are present before
executing the function.
Fixes: ae5a6bc1f6 ("topotests: add bgp mpls allocation per next-hop test")
Fixes: 37a02a8dcb ("topotests: add bgp_vpnv6 test allocation")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The zebra label manager stores the mpls label chunks,
but does not record if the label request was for a
dynamic or a static chunk.
For all label requests accepted, mark the label chunk
if the 'base' parameter is set to MPLS_LABEL_BASE_ANY,
unmark it otherwise.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When configuring manual label value in BGP L3VPN, the label
allocation conflicts with the LDP label pool which is in use.
Choose BGP label values different that the ones from LDP.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
BGP always asks zebra for a chunk of MPLS label even if it doesn't need it.
Fix this by correcting the rounding up "labels_needed" formula.
Fixes: 80853c2ec7 ("bgpd: improve labelpool performance at scale")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Also:
- replace all /* fallthrough */ comments with portable fallthrough;
pseudo keyword to accomodate both gcc and clang
- add missing break; statements as required by older versions of gcc
- cleanup some code to remove unnecessary fallthrough
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Now OSPF6 shares the /128 prefix by default. Adjusting the expected
number of next hops according to that.
Signed-off-by: Adriano Marto Reis <adrianomarto@gmail.com>
* Check if FRR is running
* Check if OSPFv3 converges
* Check OSPFv3 Routing Tables
* Check Linux Kernel Routing Table
Signed-off-by: Adriano Marto Reis <adrianomarto@gmail.com>
Don't hard-code a sharpd nhg id: those values aren't stable
if the daemons/protos/route-types change. Use json show output
to find the id in the 'resilient' nhg test case in
the all_protocol_startup suite.
Signed-off-by: Mark Stapp <mjs@labn.net>
Add a topotest to check for proper functioning of the
bgp large community list match operation under a route-map.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
There is no match mechanism to match one community from the
incoming community-list. Add the 'any' keyword to the 'match
route-map' command of communit-list and large-community-list.
> match community-list AAA any
> match large-community-list AAA any
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Fix the following warning:
tests/topotests/bgp_srv6l3vpn_sid/test_bgp_srv6l3vpn_sid.py:42
/media/SharedUTM/workspace/frr/tests/topotests/bgp_srv6l3vpn_sid/test_bgp_srv6l3vpn_sid.py:42: DeprecationWarning: invalid escape sequence '\ '
In test_bgp_srv6l3vpn_sid.py we have a comment containing some '\'
characters. Python mistakenly tries to interpret such "\" characters
as escape sequences, which leads to the above warning.
Let's tell Python to treat the comment as a raw string,
so that it simply treats backslashes as literal characters rather than
escape sequences.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Issue: https://github.com/FRRouting/frr/issues/14057
Fix: Added some sleep to make sure prune is received before
RP is changed.
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
Issue: Sometimes BGP neighbors are not up before doing any PIM
operation, that is causing some tests failures.
https://github.com/FRRouting/frr/issues/14441
Fix: Added BGP convergence for all tests where BGP is used to make
sure all BGP neigbhors
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
currently snmpwalk give results such :
BGP4V2-MIB::bgp4V2PeerRemoteAddrType.1.ipv6z.10.125.0.2 = INTEGER: ipv4(1)
BGP4V2-MIB::bgp4V2PeerRemoteAddrType.2.dns.253.0.1.37.0.0.0.0.0.0.0.0.0.0.0.3 = INTEGER: ipv6(2)
BGP4V2-MIB::bgp4V2PeerRemoteAddr.1.ipv6z.10.125.0.2 = Hex-STRING: 0A 7D 00 02
BGP4V2-MIB::bgp4V2PeerRemoteAddr.2.dns.253.0.1.37.0.0.0.0.0.0.0.0.0.0.0.3 = Hex-STRING: FD 00 01 25 00 00 00 00 00 00 00 00 00 00 00 03
the expected result is the following
BGP4V2-MIB::bgp4V2PeerRemoteAddrType.1.ipv4.10.125.0.2 = INTEGER: ipv4(1)
BGP4V2-MIB::bgp4V2PeerRemoteAddrType.1.ipv6.253.0.1.37.0.0.0.0.0.0.0.0.0.0.0.3 =
INTEGER: ipv6(2)
BGP4V2-MIB::bgp4V2PeerRemoteAddr.1.ipv4.10.125.0.2 = Hex-STRING: 0A 7D 00 02
BGP4V2-MIB::bgp4V2PeerRemoteAddr.1.ipv6.253.0.1.37.0.0.0.0.0.0.0.0.0.0.0.3 = Hex
-STRING: FD 00 01 25 00 00 00 00 00 00 00 00 00 00 00 03
in draft-ietf-idr-bgp4-mibv2-11
INDEX for Bgp4V2PeerEntry is define as follows
INDEX {
bgp4V2PeerInstance,
bgp4V2PeerRemoteAddrType,
bgp4V2PeerRemoteAddr
}
the peer instance is defined as follows
OBJECT bgp4V2PeerInstance
SYNTAX Unsigned32 (1..4294967295)
more this interpretation is conformant with the snmpwalk implementation
for instance we obtain the following result
swBgp.bgp4V2.bgp4V2Objects.bgp4V2PeerTable.bgp4V2PeerEntry.bgp4V2PeerRemotePort.1.ipv6.253.0.1.37.0.0.0.0.0.0.0.0.0.0.0.3 = Gauge32: 179
swBgp.bgp4V2.bgp4V2Objects.bgp4V2PeerTable.bgp4V2PeerEntry.bgp4V2PeerRemoteAs.1.ipv4.10.125.0.2 = Gauge32: 65200
since currently we are not supporting multi instance for bgp peer in
SNMP the bgp4V2PeerInstance value is set to 1 coforming to:
"Implementations that do not support multiple routing instances should return 1 for this object."
test is updated accordingly to fix.
currently index for bgp4V2NlriEntry is not coformant to MIB definition
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
Use an external BGP injector tool in router r1. Check that bgpd on r2 is
able to decode BGP-LS prefixes and re-encode to the r3 instance.
Link: https://github.com/louis-6wind/bgp_injector
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
This patch includes:
* Implementation of RFC 5709 support in OSPF. Using
openssl library and FRR key-chain,
one can use SHA1, SHA256, SHA384, SHA512 and
keyed-MD5( backward compatibility with RFC 2328) HMAC algs.
* Updating documentation of OSPF
* add topotests for new HMAC algorithms
Signed-off-by: Mahdi Varasteh <varasteh@amnesh.ir>
the snmp tests are using zebra.conf to setup the
address that they are binding to and immediately
after that they are starting snmpd. If snmpd
starts up *before* zebra has installed the address
the bind on the address will fail. Causing the entire
test to fail. Modify the snmpd.conf for all our
snmp tests to bind to all addresses. Things still
work and we no longer have an issue.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Fix bgp_vpnv4_noretain test descriptions
Fixes: 22dfa04b78 ("topotests: more tests in bgp_vpnv4_noretain")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add a new topotest `isis_srv6_topo1` for verifying SRv6 functionalities
in IS-IS (RFC 9352).
This topotest consists of nine tests:
* Network convergence after applying SRv6 configuration
* Disable SRv6 Locator on zebra on r1
* Enable SRv6 Locator on zebra on r1
* Disable SRv6 Locator on ISIS on r1
* Enable SRv6 Locator on ISIS on r1
* Disable SRv6 on ISIS on r1
* Enable SRv6 on ISIS on r1
* Disable SRv6 on zebra on r1
* Enable SRv6 on zebra on r1
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Update IS-IS fuzz test to match corrected output after the introduction
of SRv6-related TLVs.
The update was performed using wuschl [1] like this:
$ wuschl rebuild tests/isisd/test_fuzz_isis_tlv
$ gzip -9 tests/isisd/test_fuzz_isis_tlv_tests.h
[1] https://pypi.org/project/wuschl/
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
