Donald Sharp [Fri, 17 Sep 2021 09:41:37 +0000 (05:41 -0400)]
pimd: Prevent uninited usage of nexthop
pim_msdp_peer_rpf_check creates an nexthop to do
a rpf search against and doesn't initialize it
sucht that the pim_nexthop_lookup function is
making decisions against the nexthop just
created that was uninitialized.
Donald Sharp [Tue, 21 Sep 2021 11:52:54 +0000 (07:52 -0400)]
ospf6d: Use appropriate integer size and more context for reason strings
The ospfv3 spf reason strings are just presented internally in the code
without any real context. Give a tiny bit more useful information for
the developer and convert the integer to a uint32_t
Donald Sharp [Thu, 16 Sep 2021 19:12:13 +0000 (15:12 -0400)]
tests: Do not do a initial_timeout of 2 seconds for verify_bgp_rib
A bunch of tests have this pattern:
a) Install a new prefix into bgp
b) Run this loop:
foreach (router in topology) {
verify_bgp_rib(router)
}
This is to ensure that the prefix is actually disseminated.
The problem with this, of course, is that a wait of 2 seconds
for every item in that loop makes no sense. As that the initial
router verification of it's bgp rib will wait 2 seconds and
all the remaining bgp routers in the topology will have gotten
the data. So we end up waiting a bunch of extra time.
Remove the initial_wait time for verify_bgp_rib. Also
increase the failure wait time to 30 seconds. This is
to give a bigger window for bgp to send it's data for
our test systems that could be under heavy load. In the
normal case tests will never hit this.
ospf6d: fix build problem with ancient json-c versions
Some CI VMs are using really old versions of json-c (pre 2013 [1])
that expect filenames to be passed as "char *" instead of "const char *".
Add some explicit casts to fix the resulting compiler errors on those
VMs (passing "char *" when the API expects "const char *" is fine).
Hopefully this commit should be reverted once the CI is updated to use
newer versions of json-c.
Renato Westphal [Wed, 30 Jun 2021 18:12:30 +0000 (15:12 -0300)]
tests: add OSPFv3 graceful restart topotest
Add a new topotest that features a topology with seven routers spread
across four OSPF areas:
* 1 backbone area;
* 1 regular non-backbone area (0.0.0.1);
* 1 stub area (0.0.0.2);
* 1 NSSA area (0.0.0.3).
All routers have both GR and GR helper functionality enabled in
the configuration. The test consists of restarting each router,
one at time, and checking that all forwarding planes (and LSDBs)
are kept intact during those restarts.
A successful run takes about three minutes to finish.
ospf6d: introduce support for Graceful Restart (restarting mode)
RFC 5187 specifies the Graceful Restart enhancement to the OSPFv3
routing protocol. This commit implements support for the GR
restarting mode.
Here's a quick summary of how the GR restarting mode works:
* GR can be enabled on a per-instance basis using the `graceful-restart
[grace-period (1-1800)]` command;
* To perform a graceful shutdown, the `graceful-restart prepare ipv6
ospf` EXEC-level command needs to be issued before restarting the
ospf6d daemon (there's no specific requirement on how the daemon
should be restarted);
* `graceful-restart prepare ospf` will initiate the graceful restart
for all GR-enabled instances by taking the following actions:
o Flooding Grace-LSAs over all interfaces
o Freezing the OSPF routes in the RIB
o Saving the end of the grace period in non-volatile memory (a JSON
file stored in `$frr_statedir`)
* Once ospf6d is started again, it will follow the procedures
described in RFC 3623 until it detects it's time to exit the graceful
restart (either successfully or unsuccessfully).
Testing done:
* New topotest featuring a multi-area OSPF topology (including stub
and NSSA areas);
* Successful interop tests against IOS-XR routers acting as helpers.
introduced the idea of v6 LL using interface up/down events
instead of nexthop resolution to know when a peering should
happen or not. This above commit left a hole where if the remote
peer connected to this bgp, the bgp code would still believe
the peering is down. Modify the code to double check and
ensure that we have proper v6 LL resolution flags set.
Donald Sharp [Thu, 16 Sep 2021 01:10:24 +0000 (21:10 -0400)]
tests: Fix make check builds on some bsd variants
Compilation is warning that a memcpy is only copying
the first (sizeof pointer) into memory. This is not
what we really want. Although it does beg the question about
why this memcpy is needed( or what it is doing ). I'm going
to just fix the memcpy and call it a day.
Igor Ryzhov [Wed, 15 Sep 2021 19:45:23 +0000 (22:45 +0300)]
bgpd: fix memory leaks when using route-maps
There are places where we use route-maps using duplicated attributes and
neither intern nor flush them after the usage. If a route-map has set
rules for aspath/communities, they will be allocated and never freed.
We should always flush unneeded duplicated attributes.
Donald Sharp [Tue, 14 Sep 2021 17:28:00 +0000 (13:28 -0400)]
zebra: Fix case default usage w/ enum's
We should not be using `case default` with an enumerated type
This prevents the developer of new cases from knowing where
they need to fix by just compiling.
Donald Sharp [Fri, 13 Aug 2021 14:51:22 +0000 (10:51 -0400)]
vtysh: Allow us to gather a bit more data when extract.pl dies
When extract.pl dies, it was dieing in a manner that provided
absolutely no useful data as to what went wrong. Let's add
a tiny bit of debug code. So we can see what is going wrong.
bgpd: Extend EVPN next hop tracking to type-1 and type-4 routes
NH tracking is already in use for type-1, type-3 and type-5 routes.
This change extends that tracking to EAD and ESR to eliminate the 9s
delay (BGP holdtimer) with ES/L2-NHG update seen when all the uplinks
are shutdown on a remote EVPN PE.
zebra: Fix IPv4 routes with IPv6 link local next hops install in FPM
Description: Currently IPv4 routes with IPv6 link local next hops are
not properly installed in FPM.
Reason is the netlink decoding truncates the ipv6 LL address to 4 byte
ipv4 address.
Ex : fe80:: is directly converted to ipv4 and it results in 254.128.0.0
as next hop for below routes
show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
B>* 2.1.0.0/16 [200/0] via fe80::268a:7ff:fed0:d40, Ethernet0, weight 1,
02:22:26
B>* 5.1.0.0/16 [200/0] via fe80::268a:7ff:fed0:d40, Ethernet0, weight 1,
02:22:26
B>* 10.1.0.2/32 [200/0] via fe80::268a:7ff:fed0:d40, Ethernet0, weight
1, 02:22:26
Hence this fix converts the ipv6-LL address to ipv4-LL (169.254.0.1)
address before sending it to FPM. This is inline with how these types of
routes are currently programmed into kernel.
1. Optimized test: test_clear_pim_neighbors_and_mroute_p0 run time by clearing
mroute and verifying mroutes separately. Execution time is reduced from almots 10 mins
to ~220 sec.
bgpd: remove es_path VNI display from type-2 routes
EVPN paths are maintained in per-ES list for efficient updates
(es→macip_global_path_list, es→macip_evi_path_list). VNI is also maintained
in path_extra for easy lookups. This (path_extra) VNI (which is always 0 for
global paths) was being displayed against the path and was mis-interpreted
as the BD.
To avoid that confusion I have removed the display.
Igor Ryzhov [Tue, 7 Sep 2021 19:24:57 +0000 (22:24 +0300)]
bgpd: move rpki source after the server config
Currently the source IP parameter must be entered between destination IP
and destination port parameters. This is not obviously understandable
when you read such config so let's move the source parameter to the end
of the command line, after the whole list of destination parameters. We
can do this without any deprecation cycle as the parameter was introduced
just recently and isn't in any public release yet.
projects / mirror / frr.git / log