Those commands are using northbound api, add YANG attr to them. This
will allow them to use with pending commit, else the validation will
failed as they are detected as non YANG cmd.
Signed-off-by: Loïc Sang <loic.sang@6wind.com>
Those commands are using northbound api, add YANG attr to them. This
will allow them to use with pending commit, else the validation will
failed as they are detected as non YANG cmd.
Signed-off-by: Loïc Sang <loic.sang@6wind.com>
Those commands are using northbound api, add YANG attr to them. This
will allow them to use with pending commit, else the validation will
failed as they are detected as non YANG cmd.
Signed-off-by: Loïc Sang <loic.sang@6wind.com>
Say you have 2 mgmtd frontend sessions (2 vtysh's) the first one is long
running and is actively changing the global candidate datastore (DS),
the second one starts and exits, this code would then copy running
back over the candidate, blowing away any changes made by the first
session.
(the long running session could technically be any user)
Instead we need to trust the various cleanup code that already exits.
For example in the commit_cfg_reply on success candidate is copied to
running, and on failure *for implicit commit* running is copied back to
candidate clearing the change. This leaves the non-implicit
configuration changes in this case we actually want candidate to keep
it's changes in transactional cases, in the other case of pending commit
during a file read the code restores candidate (if needed) on exit from
"config terminal", with this call stack:
vty_config_node_exit()
nb_cli_pending_commit_check()
nb_cli_classic_commit()
nb_candidate_commit_prepare() [fail] -> copy running -> candidate
nb_candidate_commit_apply() -> copy candidate -> running
fixes#18541
Signed-off-by: Christian Hopps <chopps@labn.net>
According to [RFC 2332, Section 5.1], if an NHS receives a packet that it would normally forward and the hop count is zero, it must send an error indication back to the source and drop the packet.
Signed-off-by: zmw12306 <zmw12306@gmail.com>
Currently, when the locator block and sid block differs, staticd would
still go ahead and request zebra to allocate the SID which it does if
there is atleast one match (from any locators).
Only when staticd tries to install the route, it sees that the locator
block and sid block are different and avoids installing the route.
Fix:
Check if the locator block and sid block match before even requesting
Zebra to allocate one.
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
According to RFC 5880 Section 6.3, once the remote peer reflects back the local discriminator, the receiver MUST demultiplex subsequent BFD packets based solely on the Your Discriminator field. The source IP or interface MUST NOT be used in demultiplexing once the session is established.
Signed-off-by: zmw12306 <zmw12306@gmail.com>
A router-id MUST NOT consist of either all binary zeroes (0000000000000000 hexadecimal) or all binary ones (FFFFFFFFFFFFFFFF hexadecimal).
Signed-off-by: zmw12306 <zmw12306@gmail.com>
When all feasible routes to a destination are lost, but unexpired unfeasible routes exist, the node MUST send a seqno request to prevent starvation.
Signed-off-by: zmw12306 <zmw12306@gmail.com>
Modify route selection to check feasibility first, then fall back to non-feasible routes as per SHOULD requirement.
Signed-off-by: zmw12306 <zmw12306@gmail.com>
Section 4.1 of RFC8955 defines how the length field of flowspec NLRIs is encoded.
The method use implies a maximum length of 4095 for a single flowspec NLRI.
However, in bgp_flowspec.c, we check the length attribute of the bgp_nlri structure against this maximum value, which actually is the *total* length of all NLRI included in the considered MP_REACH_NLRI path attribute.
Due to this confusion, frr would reject valid announces that contain many flowspec NLRIs, when their cummulative length exceeds 4095, and close the session.
The proposed change removes that check entirely. Indeed, there is no need to check the length field of each invidual NLRI because the method employed make it impossible to encode a length greater than 4095.
Signed-off-by: Stephane Poignant <stephane.poignant@proton.ch>
`"` was accidentally added, and random tests failures happening.
Fixes: a4f61b78dd ("tests: Check if routes are marked as stale and retained with N-bit for GR")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Issue:
"Processing EVPN MAC interface change on peer" log message is printed
even when the peer didnt have EVPN address family.
Fix:
Process only if the peer is in EVPN address family
Ticket: #17890
Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
If we have `neighbor X bfd` and BFD status is DOWN and/or ADMIN_DOWN, and BGP
session is not yet established, we never allow the session to establish.
Let's fix this regression that was in 10.2.
Fixes: 1fb48f5 ("bgpd: Do not start BGP session if BFD profile is in shutdown state")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
With bgpd no longer sending withdraws for EVPN prefix routes
zebra needs to track the path/ref count of prefixes for an EVPN
nexthop. When a route is updated the count is first increased
with the new paths and then decreased with the paths of the
existing/"same" route entry.
However the same evpn route methods are used for EVPN MH as well,
where bgpd already tracks the references. It is expected that an
ADD operation for the respective A-D routes is handled as an
upsert, a DEL operation should really remove the respective A-D
reference on a next-hop. For this the old behaviour (no path/ref
counting in zebra) is preserved.
Signed-off-by: Christopher Dziomba <christopher.dziomba@telekom.de>
Previously bgpd needed to send a withdraw followed by an install
to update an EVPN prefix route. With refcount tracking in zebra
this is no longer needed
Signed-off-by: Christopher Dziomba <christopher.dziomba@telekom.de>
While here, also make "VPN SAFI clear" test wait for clear result
(tests/topotests/bgp_rfapi_basic_sanity{,_config2})
Original RFAPI code relied on the frr timer system to remember
various allocations that were supposed to be freed at future times
rather than manage a parallel database. However, if bgpd is terminated
before the times expire, those pending allocations are marked as
memory leaks, even though they wouldn't be leaks under normal operation.
This change adds some hash tables to track these outstanding
allocations that are associated with pending timers, and uses
those tables to free the allocations when bgpd exits.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
