![]() 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> |
||
---|---|---|
.github | ||
alpine | ||
babeld | ||
bfdd | ||
bgpd | ||
debian | ||
doc | ||
docker | ||
eigrpd | ||
fpm | ||
gdb | ||
grpc | ||
include | ||
isisd | ||
ldpd | ||
lib | ||
m4 | ||
mgmtd | ||
mlag | ||
nhrpd | ||
ospf6d | ||
ospfclient | ||
ospfd | ||
pathd | ||
pbrd | ||
pceplib | ||
pimd | ||
pkgsrc | ||
python | ||
qpb | ||
redhat | ||
ripd | ||
ripngd | ||
sharpd | ||
snapcraft | ||
staticd | ||
tests | ||
tools | ||
vrrpd | ||
vtysh | ||
watchfrr | ||
yang | ||
zebra | ||
.clang-format | ||
.dockerignore | ||
.flake8 | ||
.git-blame-ignore-revs | ||
.gitignore | ||
.isort.cfg | ||
.pylintrc | ||
.travis.yml | ||
bootstrap.sh | ||
buildtest.sh | ||
config.version.in | ||
configure.ac | ||
COPYING | ||
Makefile.am | ||
README.md | ||
stamp-h.in | ||
version.h |
FRRouting
FRR is free software that implements and manages various IPv4 and IPv6 routing protocols. It runs on nearly all distributions of Linux and BSD and supports all modern CPU architectures.
FRR currently supports the following protocols:
- BGP
- OSPFv2
- OSPFv3
- RIPv1
- RIPv2
- RIPng
- IS-IS
- PIM-SM/MSDP
- LDP
- BFD
- Babel
- PBR
- OpenFabric
- VRRP
- EIGRP (alpha)
- NHRP (alpha)
Installation & Use
For source tarballs, see the releases page.
For Debian and its derivatives, use the APT repository at https://deb.frrouting.org/.
Instructions on building and installing from source for supported platforms may be found in the developer docs.
Once installed, please refer to the user guide for instructions on use.
Community
The FRRouting email list server is located here and offers the following public lists:
Topic | List |
---|---|
Development | dev@lists.frrouting.org |
Users & Operators | frog@lists.frrouting.org |
Announcements | announce@lists.frrouting.org |
For chat, we currently use Slack. You can join by clicking the "Slack" link under the Participate section of our website.
Contributing
FRR maintains developer's documentation which contains the project workflow and expectations for contributors. Some technical documentation on project internals is also available.
We welcome and appreciate all contributions, no matter how small!
Security
To report security issues, please use our security mailing list:
security [at] lists.frrouting.org