ALL Daemons
-N <namespace> to allow for config file locating when running FRR
inside of a namespace
Impoved Testing across all daemons
BFD
VRF Support
Conversion to Northbound interface
BGP
Aggregate-address add route-map support
BMP Support
Improved JSON output for many commands
`show bgp afi safi summary failed` command
`clear bop *` clears all peers
Show FQDN for `show bgp ipv4 uni` commands
Display BestPath selection reason as part of show commands
EIGRP
Infrastructure changes to allow VRF's
SIGHUP signals the config reload
Conversion to Northbound interface
ISIS
BFD Support
Support for circuits with MTU > 8192
PBRD
fwmark support as part of match criteria
autocompletion of PBRMAPS
Improved Nexthop Support
PIMD
PIM-BSM receive support
Improved debugging support
Store ECMP paths that are not currently legal for use
Disallow igmp query from a non-connected source
Many new cli improvements and changes
VRRPD
Add Support for RFC 3768 and RFC 5798
Route-Maps
Add sequence numbers to access-lists
Add `match ip next-hop type blackhole`
Improved ability to notice dependency changes
SHARPD
`sharp watch [import|nexthop]` you can now specify a prefix instead
of assuming a /32
STATICD
Significantly Improved NHT
ZEBRA
Many dataplane improvements for routes, neighbor table and EVPN
NHT cli can now be specified per VRF and improved ability to control
NHT data being shown
Removed duplicate processing of routes
Improved debugablility
RMAC and VxLan support for the FPM
LIB
RCU support
Nexthop Group Improvements
`log-filter WORD` added
Building
openssl support
libcap should be used as part of build or significant slowdowns will
be experienced
Lua builds have been fixed
Improved Cross building
Snapcraft
Add Fabricd
Add Libyan
Update rtrlib and rpki
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
commit ee8a72f315
broke the usage of ZEBRA_ROUTE_ALL as a valid redistribution
command. This commit puts it back in. LDP uses ZEBRA_ROUTE_ALL
as an option to say it is interested in all REDISTRIBUTION events.
Fixes: #5072
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The vrf_id in `zsend_interface_vrf_update()` is encoded as
a long via `stream_putl()`, we should decode it as such
as well.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
RFC 5303 states:
If the system ID and Extended Local Circuit ID of the neighboring
system are known (in adjacency three-way state Initializing or
Up), the neighbor's system ID SHALL be reported in the Neighbor
System ID field, and the neighbor's Extended Local Circuit ID
SHALL be reported in the Neighbor Extended Local Circuit ID field.
There is nothing written about only setting the Extended circuit ID of the
adjacency only when we bring the three-way adjacency up.
In fact, we should always update it, to avoid the problem described in #4783.
Fixes: #4783
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Current autocompletion works only for simple "vrf NAME" case.
This commit expands it also for the following cases:
- "nexthop-vrf NAME" in staticd
- usage of $varname in many daemons
All daemons are updated to use single varname "$vrf_name".
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Problem reported that when a "neighbor x.x.x.x route-map FOO in"
set a next-hop value, that modified next-hop value was also sent
to eBGP peers. This is incorrect since bgp is expected to set
next-hop to self when sending to eBGP peers unless third party
next-hop on a shared segment is true. This fix modifies the
behavior to stop sending the modified next-hop to eBGP peers
if the route-map was applied inbound on another peer.
Ticket: CM-26025
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
The newly added PEER_RMAP_TYPE_AGGREGATE flag is setup to
be the 9th bit:
But the flag we are putting it into:
uint8_t rmap_type;
is 8 bits. Adjust the size.
Found by Coverity SA Scan
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The "abort_if_not_found" parameter of nb_running_get_entry()
should be set to true only when this function is called during the
NB_EV_APPLY phase of a northbound callback. Failure to respect this
can lead to crashes when multiple configuration changes are being
committed at the same time.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
RFC 4271 sec 6.3 p33, In the case of a BGP_NEXTHOP attribute with an
incorrect value, FRR is supposed to send a notification
and include 'Corresponding type, length and value of the NEXT_HOP
attribute in the notification data.
Fixes: #4997
Signed-off-by: Nikos <ntriantafillis@gmail.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
[7.2 version]
When processing route updates from the dataplane, we were
terminating the checking of nexthops prematurely, and we could
miss meaningful changes.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
RFC4271 specifies behavior when the hold timer is sent to zero - we
should not send keepalives or run a hold timer. But FRR, and other
vendors, allow the keepalive timer to be set to zero with a nonzero hold
timer. In this case we were sending keepalives constantly and maxing out
a pthread to do so. Instead behave similarly to other vendors and do not
send keepalives.
Unsure what the utility of this is, but blasting keepalives is
definitely the wrong thing to do.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
When selecting a new best route, zebra sends a redist update
when the route is installed. There are cases where redist
clients may not see that redist add - clients who are not
subscribed to the new route type, e.g. In that case, attempt
to send a redist delete for the old/previous route type.
Revised the redist delete api to accomodate both cases;
also tightened up the const-ness of a few internal redist apis.
[7.2 version]
Signed-off-by: Mark Stapp <mjs@voltanet.io>
The lib/bgp.py test code is bringing up neighbors and clearing them
to test that things are working appropriately. The problem we have
is that we are only waiting 30 seconds for declaration of failure.
In a high load system packets can be lost and as such the initial
convergence may not happen. Modify the test to wait for 1 retry
window test period before declaring failure.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
