Some temporary files are hardwritten in /tmp folder. Use the bmp log
folder instead. Replace the bmp log file argument with bmp log folder.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
DEBUG_PCAP can be set True to manually enable pcap debugging when
running bmp tests.
Save bmp pcap in logdir (ie. /tmp/topotests/bgp_bmp.bgp_bmp_X/ instead
of /tmp.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Multiple BMP tests can run in parallel but, when one instance ends,
it kills the BMP server process of all BMP tests.
Save the PID of a BMP server and only kill it at the end.
Link: https://github.com/FRRouting/frr/issues/17465
Fixes: 875511c466 ("topotests: add basic bmp collector")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
When configuring the bgp_bmp test with an additional
peer that sends empty AS-PATH, the bmp collector is stopping:
> [2024-10-28 17:41:51] Finished dissecting data from ('192.0.2.1', 33922)
> [2024-10-28 17:41:52] Data received from ('192.0.2.1', 33922): length 195
> [2024-10-28 17:41:52] Got message type: <class 'bmp.BMPRouteMonitoring'>
> [2024-10-28 17:41:52] unpack_from requires a buffer of at least 2 bytes for unpacking 2 bytes at offset 0 (actual buffer size is 0)
> [2024-10-28 17:41:52] TCP session closed with ('192.0.2.1', 33922)
> [2024-10-28 17:41:52] Server shutting down on 192.0.2.10:1789
The parser attempts to read an empty AS-path and considers the length
value as a length in bytes, whereas RFC mentions this value as
definining the number of AS-PAths. Fix this in the parser.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The bgp_bmp and bgp_bmp_vrf tests use similar routines
to test the bmp, but are duplicates. Gather the bgp_bmp
and the bgp_bmp_vrf tests in a single bgp_bmp folder.
- Create a bgpbmp.py library under the bgp_bmp test folder
- The bgp_bmp and bgp_bmp_vrf test are renamed to bgp_bmp_1
and bgp_bmp_2 test.
- Maintain separate folder for config and output results. Adapt
the bgp_bmp library accordingly.
- The json output for bgp_bmp_2 test has no referenc to hostame.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When receiving an SRv6 BGP update, the nexthop tracking is used
to find out the reachability of the BGP update.
> # show bgp ipv6 vpn fd00:200::/64
> Paths: (1 available, best #1)
> [..]
> 4:4::4:4 from 4:4::4:4 (4.4.4.4)
> Origin incomplete, metric 0, localpref 100, valid, internal, best (First path received)
> Extended Community: RT:52:100
> Remote label: 16
> Remote SID: 2001:db8:f4::
> Last update: Mon Mar 11 11:50:04 2024
The IPv6 address used is the "Remote SID". Actually, this value is
incomplete. Remote SID stands for the attribute value received in BGP,
while the label value determines a complement of SRv6 SID value. The
transposition technique authorises that in BGP, and in the above case,
the incoming BGP update has used the transposition length.
When there is a transposition in the SID attribute available, use the
real SID address. The nexthop tracking will use that forged address.
> # show bgp nexthop
> Current BGP nexthop cache:
> 4:4::4:4 valid [IGP metric 30], #paths 0, peer 4:4::4:4
> gate fe80::dced:1ff:fed6:878c, if ntfp3
> Last update: Mon Mar 11 11:50:02 2024
> 2001:db8:f4:1:: valid [IGP metric 0], #paths 2
> gate fe80::dced:1ff:fed6:878c, if ntfp3
Fixes: 26c747ed6c ("bgpd: extend make_prefix to form srv6-based prefix")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Use the advertise route-map command, and check that it
filters out correctly the undesirable prefixes. Reversely,
check that undoing that route-map recovers all prefixes.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Rework the test file by adding test methods.
Add a convergence test that checks for the incoming BGP prefixes.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
if (BGP_IS_VALID_STATE_FOR_NOTIF(peer->connection->status))
peer_notify_config_change(peer->connection);
else
bgp_session_reset_safe(peer, &nnode);
Let's add a bool return to peer_notify_config_change of whether or
not it should call the peer session reset. This simplifies
the code a bunch.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
We have about a bajillion tests of if we can
notify the peer and then we send a config change
notification. Let's just make a function that
does this.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There is an extra space in the 'Displayed' line of show bgp command,
that should not be present.
Fix this by being consistent with the output of the other address
families.
Fixes: ("a1baf9e84f71") bgpd: Use single whitespace when displaying show bgp summary
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The json display of the version attribute is originally an
integer. It has changed, most probably mistakenly.
> {
> "vrfId": 7,
> "vrfName": "vrf1",
> "tableVersion": 3,
> "routerId": "192.0.2.1",
> "defaultLocPrf": 100,
> "localAS": 65500,
> "routes": {
> "172.31.0.1/32": {
> "prefix": "172.31.0.1/32",
> "version": "1", <--- int or string ??
Let us fix it, by using the integer display instead.
Fixes: f9f2d188e3 ("bgpd: fix 'json detail' output structure")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
We do not maintain docker.com/frrouting anymore and not building custom
images for topotests.
Use local images for topotests instead.
Just use:
```
mak topotests-build
make topotests
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
During zebra shutdown, the main pthread and the FPM pthread can
deadlock if the FPM pthread is in fpm_reconnect(). Each pthread
tries to use event_cancel_async() to cancel tasks that may be
scheduled for the other pthread - this leads to a deadlock as
neither thread can progress.
This adds an atomic boolean that's managed as each pthread
enters and leaves the cleanup code in question, preventing the
two threads from running into the deadlock.
Signed-off-by: Mark Stapp <mjs@cisco.com>
The test is failing because on r2 we are looking for a metric of 777
on startup, but the start of looking for this happens to be after
the 5 second delay that is setup in the config.
On r1:
2023/09/06 17:05:14.999407 BGP: [G822R-SBMNH] config-from-file# router bgp 65001
2023/09/06 17:05:15.003060 BGP: [G822R-SBMNH] config-from-file# bgp max-med on-startup 5 777
2023/09/06 17:05:15.003342 BGP: [G822R-SBMNH] config-from-file# no bgp ebgp-requires-policy
2023/09/06 17:05:15.003453 BGP: [G822R-SBMNH] config-from-file# neighbor 192.168.255.2 remote-as 65001
2023/09/06 17:05:15.004029 BGP: [G822R-SBMNH] config-from-file# neighbor 192.168.255.2 timers 3 10
2023/09/06 17:05:15.004242 BGP: [G822R-SBMNH] config-from-file# address-family ipv4 unicast
2023/09/06 17:05:15.004329 BGP: [G822R-SBMNH] config-from-file# redistribute connected
2023/09/06 17:05:15.005023 BGP: [G822R-SBMNH] config-from-file# exit-address-family
2023/09/06 17:05:15.005140 BGP: [G822R-SBMNH] config-from-file# !
2023/09/06 17:05:15.005162 BGP: [G822R-SBMNH] config-from-file# !
2023/09/06 17:05:17.538112 BGP: [M7Q4P-46WDR] vty[25]@> enable
2023/09/06 17:05:17.546700 BGP: [M7Q4P-46WDR] vty[25]@# clear log cmdline-targets
2023/09/06 17:05:17.570635 BGP: [M7Q4P-46WDR] vty[25]@(config)# log commands
2023/09/06 17:05:17.572518 BGP: [M7Q4P-46WDR] vty[25]@(config)# log timestamp precision 6
2023/09/06 17:05:24.982647 BGP: [YNGC8-65JDM] Begin maxmed onstartup mode - timer 5 seconds
2023/09/06 17:05:26.033134 BGP: [M59KS-A3ZXZ] bgp_update_receive: rcvd End-of-RIB for IPv4 Unicast from 192.168.255.2 in vrf default
2023/09/06 17:05:29.982960 BGP: [N1747-51Y51] Max med on startup ended - timer expired.
on r2:
2023/09/06 17:05:23.976029 BGP: [G822R-SBMNH] config-from-file# !
2023/09/06 17:05:26.084086 BGP: [M59KS-A3ZXZ] bgp_update_receive: rcvd End-of-RIB for IPv4 Unicast from 192.168.255.1 in vrf default
2023/09/06 17:05:27.280103 BGP: [M7Q4P-46WDR] vty[25]@> enable
2023/09/06 17:05:27.290204 BGP: [M7Q4P-46WDR] vty[25]@# clear log cmdline-targets
2023/09/06 17:05:27.328798 BGP: [M7Q4P-46WDR] vty[25]@(config)# log commands
2023/09/06 17:05:27.335032 BGP: [M7Q4P-46WDR] vty[25]@(config)# log timestamp precision 6
2023/09/06 17:05:31.558216 BGP: [M7Q4P-46WDR] vty[5]@> enable
2023/09/06 17:05:31.562482 BGP: [M7Q4P-46WDR] vty[5]@# do show logging
2023/09/06 17:05:32.942204 BGP: [M7Q4P-46WDR] vty[5]@> enable
2023/09/06 17:05:32.946745 BGP: [M7Q4P-46WDR] vty[5]@# show ip bgp neighbor 192.168.255.1 json
2023/09/06 17:05:34.173879 BGP: [M7Q4P-46WDR] vty[5]@> enable
2023/09/06 17:05:34.178448 BGP: [M7Q4P-46WDR] vty[5]@# show ip bgp neighbor 192.168.255.1 routes json
2023/09/06 17:05:36.459365 BGP: [M7Q4P-46WDR] vty[5]@> enable
2023/09/06 17:05:36.472019 BGP: [M7Q4P-46WDR] vty[5]@# show ip bgp neighbor 192.168.255.1 routes json
2023/09/06 17:05:38.557840 BGP: [M7Q4P-46WDR] vty[5]@> enable
2023/09/06 17:05:38.558948 BGP: [M7Q4P-46WDR] vty[5]@# show ip bgp neighbor 192.168.255.1 routes json
2023/09/06 17:05:40.198563 BGP: [M7Q4P-46WDR] vty[5]@> enable
Notice that the 5 second delay for the max med expires at 29 seconds but the show routes
on r2 does not even begin until 34 seconds, long after the max med has expired and the
test has moved on.
Let's relax the max-med timer to 30 seconds and modify the test to wait a bit longer for
both finding it and expiring timer.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Test is failing locally:
2023-09-06 18:39:56,865 DEBUG: r1: vtysh result:
Hello, this is FRRouting (version 9.1-dev).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
r1# conf t
r1(config)# router ospf
r1(config-router)# ospf router-id 1.1.1.1
For this router-id change to take effect, use "clear ip ospf process" command
r1(config-router)#
2023-09-06 18:39:56,865 DEBUG: root: GOT LINE: 'SUCCESS: 1.0.0.0'
2023-09-06 18:39:56,866 DEBUG: root: GOT LINE: '2023-09-06 18:39:55,982 INFO: TESTER: root: Waiting for 1.1.1.1'
2023-09-06 18:39:56,867 DEBUG: root: GOT LINE: '2023-09-06 18:39:55,982 DEBUG: TESTER: root: expected '1.1.1.1' != '1.0.0.0''
2023-09-06 18:39:56,867 DEBUG: root: GOT LINE: 'waiting on notify'
Sure looks like the router-id is not allowed to be changed because
neighbors have already been formed. If we are changing the router-id
then let's clear the process to allow it to correctly change.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
