anlan_cs [Wed, 28 Jun 2023 04:31:52 +0000 (12:31 +0800)]
pbrd: fix crash with match command
Crash with empty `ip-protocol`:
```
anlan(config-pbr-map)# match ip-protocol
vtysh: error reading from pbrd: Resource temporarily unavailable (11)Warning: closing connection to pbrd because of an I/O error!
```
add support of color extended community, conforming to RFC 9012.
This extended community will be added to the existing one, RT,SOO
and Node Target. The configuration will be made through the
route-map service.
Christian Hopps [Sun, 25 Jun 2023 12:13:25 +0000 (08:13 -0400)]
tools: less aggressive settings for clang-format
- Reports were that the current settings were choosing to extend beyond 80
columns too often. This change makes that more expensive but still tries
very hard to not break before first open parenthesis of function calls.
Mark Stapp [Wed, 31 May 2023 20:25:15 +0000 (16:25 -0400)]
zebra: support notifications for opaque ZAPI messages
Allow zapi clients to register to be notified when a server
for an opaque message type is present. Zebra maintains these
notification registrations in the same data structures that it
uses for opaque message handling.
Mark Stapp [Wed, 31 May 2023 20:22:16 +0000 (16:22 -0400)]
lib: add notifications for opaque zapi messages
Add a new notification zapi message type. A zapi client
that uses opaque messages can register to be notified
when a server for an opaque type is present.
Mark Stapp [Mon, 29 May 2023 17:04:24 +0000 (13:04 -0400)]
lib, zebra: include source client zapi info in opaque messages
Include the sending zapi client info (proto, instance, and
session id) in each opaque zapi message. Add opaque 'init'
apis for clients who want to encode their opaque data inline,
into the zclient's internal stream buffer. Use these init apis
in the TE/link-state lib code, instead of hand-coding the
zapi opaque header info.
Sai Gomathi N [Wed, 21 Jun 2023 09:53:09 +0000 (02:53 -0700)]
pim, pim6d: pimreg interface is not getting added in a certain scenario
Problem:
When ipv6 pim configuration is removed from the IIF on FHR node,
if we wait for RST timer to expire and then add the ipv6 pim configuration on the IIF again,
it is seen that pimreg is not getting added due to which null register wont be sent,
the register flag state also remains NO_INFO forever instead of RegPrune.
The reason for this is, when RST timer expires and IIF is unknown for the (S,G) upstream,
the FHR state is not reset due to which when the RP becomes reachable,
upstream state changes from NotJoined to Join but the register suppress timer could not be started
since we see there is no change in FHR state.
Fix:
When the Register Timer expires and the reg state is set to PIM_REG_NOINFO,reset the FHR flag,
so that when the RP becomes reachable can be because of config change or RP not reachable,
it is able to resume its duty.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Donatas Abraitis [Sun, 18 Jun 2023 19:07:54 +0000 (22:07 +0300)]
zebra: Show session id when printing an error when the client disconnects
Before:
```
2023/06/18 22:00:42 ZEBRA: [VXKFG-8SJRV][EC 4043309121] Client 'bgp' encountered an error and is shutting down.
2023/06/18 22:00:42 ZEBRA: [VXKFG-8SJRV][EC 4043309121] Client 'bgp' encountered an error and is shutting down.
```
After:
```
2023/06/18 22:06:44 ZEBRA: [N5M5Y-J5BPG][EC 4043309121] Client 'bgp' (session id 0) encountered an error and is shutting down.
2023/06/18 22:06:44 ZEBRA: [N5M5Y-J5BPG][EC 4043309121] Client 'bgp' (session id 1) encountered an error and is shutting down.
```
Donatas Abraitis [Mon, 12 Jun 2023 14:09:52 +0000 (17:09 +0300)]
bgpd: Use synchronous way to get labels from Zebra
Both the label manager and table manager zapi code send data requests via zapi
to zebra and then immediately listen for a response from zebra. The problem here
is of course that the listen part is throwing away any zapi command that is not
the one it is looking for.
ISIS/OSPF and PIM all have synchronous abilities via zapi, which they all
do through a special zapi connection to zebra. BGP needs to follow this model
as well. Additionally the new zclient_sync connection that should be created,
a once a second timer should wake up and read any data on the socket to
prevent problems too much data accumulating in the socket.
topotests: label per nexthop test adds add a while loop for mpls table
The bgp_vpnv4_per_nexthop_label tests only check to see if the mpls labels
are installed one time. Test runs show that all but one label is installed.
More than likely the test has asked for data while zebra is still installing
it. the mpls_label_check functions must check this result multiple times as
that system may be under heavy load.
A loop is introduced in order to let zebra check the mpls table.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
topotests: structural issues in bgp_local_as_dotplus_private_remove
This test has several issues:
A) The convergence function is spamming the show neighbor command until success,
if the neighbor never comes up the test will never finish. This adds unnecessary
load to an already loaded test system. Use run_and_expect to properly wait for
the neighbor relationship to come up.
B) The convergence function should not sleep for 1 second *After* the neighbor
is established
C) The _bgp_as_path() function fails if the prefix has not been received yet.
This looking for the prefix data should be within a run_and_expect() functionality.
Else a loaded test system will fail in this function because while we may be in
an established state, prefixes might not yet have been exchanged and there is no
point in failing the test without giving the system some time to actually converge.
Fix those points, similarly to what has been fixed in
bgp_local_as_private_remove test.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
David Ward [Mon, 19 Jun 2023 20:00:38 +0000 (16:00 -0400)]
ospf6d: Increment sequence number correctly in Authentication Trailer
According to RFC 7166, the sequence number should be treated as an
unsigned 64-bit value, although it is stored as two 32-bit values.
When incrementing it, the code caused the lower-order 32-bit value
to skip from 0xFFFFFFFE to 0. As a side effect, an error was never
produced if the full 64-bit sequence number wrapped.
Fixes: #13805 Signed-off-by: David Ward <david.ward@ll.mit.edu>
Christian Hopps [Sun, 18 Jun 2023 20:19:54 +0000 (16:19 -0400)]
mgmtd: KISS the locking code
Move away from things like "lock if not locked" type code, require the
user has locked prior to geting to that point.
For now we warn if we are taking a lock we already had; however, this
should really be a failure point.
New requirements:
SETCFG -
not implicit commit - requires user has locked candidate DS and they
must unlock after
implicit commit - requires user has locked candidate and running DS
both locks will be unlocked on reply to the SETCFG
COMMITCFG -
requires user has locked candidate and running DS and they must unlock
after
rollback - this code now get both locks and then does an unlock and
early return thing on the adapter side. It needs to be un-special
cased in follow up work that would also include tests for this
functionality.
Louis Scalbert [Thu, 8 Jun 2023 12:27:12 +0000 (14:27 +0200)]
topotests: do not import r1 vrf1 to itself bgp_vpnv4_noretain
Do not import r1 vrf1 to itself in order to check that r1 vrf1 prefixes
are only in VPN table because it is needed for advertising the prefixes
to other routers.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Do not output '{}' when bgp_show_table() returns a valid JSON.
Tested without rd in config, bgp_show_table() returns nothing and the
JSON output is only '{}'
Fixes: 0224b3296c ("bgpd: Print empty JSON `{}` if no entries under `show bgp ipv4 vpn json`") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Louis Scalbert [Tue, 6 Jun 2023 10:46:21 +0000 (12:46 +0200)]
bgpd: fix memory usage of vpn no retain
By default, bgpd stores all MPLS VPN SAFI prefixes unless the "no bgp
retain route-target all" option is used to store only prefixes that are
imported into local VRFs. The "no retain" option temporarily uses too
much memory, as all prefixes are stored in memory before the deletion of
non-imported prefixes is done.
Filter out non-imported prefixes before they are set into the BGP adj
RIB out.
Fixes: a486300b26 ("bgpd: implement retain route-target all behaviour") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
bgpd: fix static analysis issue in subgroup_announce_check()
Remove the check about pi->peer value different from null.
Introducing this check introduces a SA warning on the value
of the from value (derived from pi->peer).
Actually, peer is set when bgp_path_info_make() call is
performed; peer is never null.
Fixes: 23bb4a9b5c64 ("bgpd: advertise mpls vpn routes with appropriate label") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
bgpd: fix accept-own routes received by a route reflector
When using the bgp-accept-own community, with the
'attribute-unchanged next-hop' command, the advertised
mpls vpn updates that are reflected by a route reflector
are received, but are not selected.
Once the accept-own community is detected, a new bgp_path
is created, in addition of the original one; then the
next-hop of the NLRI is checked, but fails for two reasons:
- the next-hop tracking returns the real IP reachability
status for prefixes that have the BGP_ROUTE_IMPORTED subtype.
This is what happens with bgp updates with the accept-own
community.
- as the next-hop was unchanged and was the peer IP in the VRF.
Consequently, the new bgp_path is considered inactive in the
default VRF, and is not selected.
The incoming bgp updates with the accept-own community should
not be checked against the next-hop tracking. As the bgp_path
subtype has been changed to BGP_ROUTE_IMPORTED, let us check
the bgp subtype before calling the 'bgp_find_or_add_nexthop()'
function in the 'bgp_update()' call.
Fixes: 46dbf9d0c0b9 bgpd: ("Implement ACCEPT_OWN extended community") Fixes: 376797711f4d - bgpd: track mpls vpn nexthops Fixes: e6110f755718 bgpd: ("fix use nexthop tracking for exported vpn paths") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
bgpd: fix use nexthop tracking for exported vpn paths
When exporting redistributed prefixes from a given VRF
to an MPLS VPN network, the paths are always considered
as valid whereas it should not always be the case.
At exportation, a new MPLS VPN path is built in. Then
nexthop tracking is applied to the new path, and the
SAFI_MPLS_VPN parameter is used to tell the NHT code
to just check for the next-hop reachability. The previous
commit was wrongly considering that nexthop tracking was
never applied to mpls vpn networks. Ensure that nexthop
tracking for exported paths behaves as usual.
Fix this by not returning always 1 in the 'bgp_find_or_add_nexthop()'
function if the passed 'pi' parameter is a 'BGP_IMPORTED_ROUTE'
sub-type entry.
Philippe Guibert [Fri, 21 Apr 2023 10:25:30 +0000 (12:25 +0200)]
topotests: mpls vpn routes redistribution, add asbr test
This setup demonstrates the redistribution and the proper
switching operations in an asbr device.
The setup interconnects an internal AS with an external
connected AS.
- the iBGP AS uses BGP-LU as MPLS transport
- the eBGP peering is directly connected and does use the
'mpls bgp forwarding' configuration to accept exterior
updates.
The setup performs the following tests:
- it checks for end to end connectivity from one interior
host h1 to two external hosts h2, and h3.
- it checks that the proper label values are advertised
by the ASBR to the iBGP peer, and the eBGP peer.
- it checks that the 'show mpls table' has additional
MPLS entries that permit transit mpls traffic to transit
across the ASBR. That behaviour is possible with the
'mpls bgp allocate-label-on-nexthop-change' command.
- it checks that withdraw of routes will remve the MPLS
entries.
- it checks that by unconfiguring the 'next-hop-self' option,
the external routes advertised to the internal maintain the
next-hop.
- it checks that a second prefix advertised by r3 with the
same RD, but different label value is using a new label on r2,
and that this new label value is used.
- it checks that when filtering out prefixes from r1, on r2,
then the MPLS label is deallocated, and the MPLS entry is not
present.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
There is no 'show command' to use for troubleshooting
purposes.
Add a new show command to dump the cache entry of the
MPLS VPN nexthop label bind cache table.
> show bgp [vrf NAME] mplsvpn-nh-label-bind [detail]
The below command illustrates its output:
> dut# show bgp mplsvpn-nh-label-bind detail
> Current BGP mpls-vpn nexthop label bind cache, VRF default
> 192.168.1.3, label 102, local label 18 #paths 3
> interface r2-eth1
> Last update: Mon May 22 14:39:42 2023
> Paths:
> 1/3 172.31.3.0/24 VRF default flags 0x418
> 1/3 172.31.2.0/24 VRF default flags 0x418
> 1/3 172.31.1.0/24 VRF default flags 0x418
> 192.0.2.1, label 101, local label 19 #paths 1
> interface r2-eth0
> Last update: Mon May 22 14:39:43 2023
> Paths:
> 1/3 172.31.0.0/24 VRF default flags 0x418
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Thu, 11 May 2023 13:42:08 +0000 (15:42 +0200)]
bgpd: update the mpls entry to handle return traffic
When advertising an mpls vpn entry with a new label,
the return traffic is redirected to the local machine,
but the MPLS traffic is dropped.
Add an MPLS entry to handle MPLS packets which have
the new label value. Traffic is swapped to the original
label value from the mpls vpn next-hop entry; then it is
sent to the resolved next-hop of the original next-hop
from the mpls vpn next-hop entry.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Thu, 11 May 2023 13:26:50 +0000 (15:26 +0200)]
bgpd: advertise mpls vpn routes with appropriate label
The advertised label value from mpls vpn routes is not modified
when the advertised next-hop is modified to next-hop-self.
Actually, the original label value received is redistributed as
is, whereas the new_label value bound in the nexthop label
bind entry should be used.
Only the VPN entries that contain MPLS information, and that
are redistributed between distinct peers, will have a label
value to advertise.
- no SRv6 attribute
- no local prefix
- no exported VPN prefixes from a VRF
If the advertisement to a given peer has the next-hop modified,
then the new label value will be picked up. The considered cases
are peers configured with 'next-hop-self' option, or ebgp peerings
without the 'next-hop-unchanged' option.
Note that the the NLRI format will follow the rfc3107 format, as
multiple label values for MPLS VPN NLRIs are not supported (the
rfc8277 is not supported).
Note also that the case where an outgoing route-map is applied to
the outgoing neighbor is not considered in this commit.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
projects / mirror / frr.git / log