Maxence Younsi [Mon, 6 Feb 2023 16:30:28 +0000 (17:30 +0100)]
bgpd: skip bmp messages when vrf id is unknown
changed result type of bmp_get_peer_distinguisher to int
added result pointer parameter to bmp_get_peer_distinguisher
bmp_get_peer_distinguisher returns 0 means the result is valid else
error occured do not use result
bgpd: loc-rib uptime moved to bgp_path_info_extra and set in header
moved loc-rib uptime field "bgp_rib_uptime" to struct bgp_path_info_extra for memory concerns
moved logic into bgp_route_update's callback bmp_route_update
written timestamp in per peer header
mxyns [Fri, 12 Aug 2022 16:00:38 +0000 (18:00 +0200)]
bgpd: applied styling and fixed warnings
frrbot found style &/| linter errors
fixed bmp_process_one return value warnings and added safety checks
fixed const modifier warning in bmp_put_vrftablename_info_tlv
added unused attribute to bmp_put_vrftablename_info_tlv
remove unused variables in bmp_process_one and bmp_route_update
Maxou [Mon, 8 Aug 2022 12:32:38 +0000 (14:32 +0200)]
bgpd: refactored bmp_route_update & cleanup TODOs
TODOs that are done/un-necessary now deleted
refactored bmp_route_update to use a modified bmp_process_one function call instead of duplicating similar code
bgpd: temporary set timestamp to 0 for loc rib monitoring messages
set timestamp to 0 for loc rib monitoring messages as path selection time is not available atm
this is temporary and tv is meant to be set to the path selection/install time at some point
vrf_id_to_name is used for display values only and returns "Unknown" when the vrf is not found
doing a manual lookup and not providing any tlv when the vrf is not found should be better
set field peer bgp id to the peer's remote id in every case except loc-rib (RFC9069 case) in which we put the bgp instance's router-id if available or 0-filled if not available
set field peer asn to local primary bgp asn in case of loc-rib instance (RFC9069) else it's set to the peer's asn
set field peer address to 0 in loc-rib instance (RFC9069 case) and to the peer's address in other cases
had to pass struct bgp reference to bmp_per_peer_hdr to access router-id and such, but it's always safely accessed when used
added afi/safi monitoring synchronisation for loc-rib
added peer_type_flag to bmp_eor signature, only set to BMP_PEER_TYPE_LOC_RIB and to 0 in other cases like it was before
updated tracelog to include peer_type_flag value
bgpd: peer flag set for loc-rib monitoring (left set to 0 in other cases)
set peer type flag to 3 for loc rib monitoring
leave to 0 in other cases like before, even though RFC7854 tells us to set it to 0 1 or 2 depending on the case global/rd/local instance
Farid Mihoub [Fri, 3 Nov 2023 12:53:43 +0000 (13:53 +0100)]
pathd: rework debug pathd pcep command
Rework "debug pathd pcep [...]" command to support the following
configurations:
- configure one debugging log type at a time.
- deconfigure one debugging log type at a time.
- configure all debugging logs in one shot.
- deconfigure all debugging logs in one shot.
route-map TEST permit 140
description rule for PFIX_IPV6_7
match ipv6 address prefix-list PFIX_IPV6_7
exit
!
end
torc-11# confi t
torc-11(config)# route-map TEST permit 140
torc-11(config-route-map)# no description rule for PFIX_IPV6_7
% Unknown command: no description rule for PFIX_IPV6_7
torc-11(config-route-map)# no description rule
% There is no matched command.
torc-11(config-route-map)# no description
<cr>
torc-11(config-route-map)# no description
torc-11(config-route-map)#
Using frr-reload failure log:
2023-10-31 00:30:31,972 INFO: Failed to execute route-map TEST permit 140 no description rule for PFIX_IPV6_7 exit
2023-10-31 00:30:31,972 ERROR: "route-map TEST permit 140 -- no description rule for PFIX_IPV6_7 -- exit" we failed to remove this command
2023-10-31 00:30:31,972 ERROR: % Unknown command: no description rule for PFIX_IPV6_7
With fix:
2023-11-02 06:10:30,024 INFO: Executed "route-map TEST permit 140 no description exit"
Donald Sharp [Tue, 31 Oct 2023 17:06:16 +0000 (13:06 -0400)]
pimd: Ensure upstream points at the correct rpf
In the scenario on an intermediate router where a *,G join has
been received and a S,G stream is being sent through that router
on the *,G stream, there exists a situation when the *,G in has been pruned
but the stream is still being received on on incoming interface towards
the RP for the *,G. In this situation PIM will see the S,G stream
initially as a NOCACHE from the dataplane, PIM will then do a RPF
for the S and notice that it is supposed to be coming in on adifferent
interface. In this case PIM the original PIM code would create
a blackhole mroute towards the RPF of the *,G( the interface the
stream is being received on ). The original reason for this is that
if there is a scenario where this particular S1,G stream is sending
at basically line rate, and there also happens to be a different
S2,G stream that is sending at a very low rate. With certain
dataplanes there is no way to really rate limit the S1 -vs- S2
stream and the S1 stream completely overwhelms the S2 stream
for sending up to the control plane for proper pim handling.
The problem then becomes that FRR never properly responds
to the situation where the *,G is rereceived and the S,G
stream switches back over to the SPT for itself and FRR ends
up with a dead mroute that stops everything from working properly.
This code change, installs the blackhole mroute with the RPF
towards the RP for the G and then resets the RPF to the correct
RPF for the Stream but does not modify the mroute. When the
*,G is rereceived and we attempt to transition to the S,G stream
this now works.
As a note: Both David L and myself do not necessarily believe
we fully understand the problem yet. What this does do is fix
all the inconsistent CI issues we are seeing in the topotests
at this time. Internally I am seeing other test failures
in PIM that I don't fully understand and we suspect that
there are other problems in the state machine. We plan to
revisit this problem as we are able to debug the issue better.
In the meantime both David and Myself agree that this gets
the CI working again and Streams end up in the right state.
Donatas Abraitis [Sun, 29 Oct 2023 20:44:45 +0000 (22:44 +0200)]
bgpd: Ignore handling NLRIs if we received MP_UNREACH_NLRI
If we receive MP_UNREACH_NLRI, we should stop handling remaining NLRIs if
no mandatory path attributes received.
In other words, if MP_UNREACH_NLRI received, the remaining NLRIs should be handled
as a new data, but without mandatory attributes, it's a malformed packet.
In normal case, this MUST not happen at all, but to avoid crashing bgpd, we MUST
handle that.
Donatas Abraitis [Fri, 27 Oct 2023 08:56:45 +0000 (11:56 +0300)]
bgpd: Treat EOR as withdrawn to avoid unwanted handling of malformed attrs
Treat-as-withdraw, otherwise if we just ignore it, we will pass it to be
processed as a normal UPDATE without mandatory attributes, that could lead
to harmful behavior. In this case, a crash for route-maps with the configuration
such as:
Christian Hopps [Mon, 30 Oct 2023 07:37:52 +0000 (03:37 -0400)]
tests: add gdb integration with valgrind
Allows you to run daemons under valgrind integrated with gdb. When daemons are
run with the ``--gdb-daemons/--gdb-routers`` options they will be wired up to
valgrind using vgdb (valgrind tool) so gdb will stop when valgrind errors are
encountered.
Donald Sharp [Sat, 28 Oct 2023 14:03:39 +0000 (10:03 -0400)]
zebra: Add encap type when building packet for FPM
Currently in the single nexthop case w/ evpn sending
down via the FPM the encap type is not being set
for the nexthop.
This looks like the result of some code reorg for the
nexthop happened but the fpm failed to be accounted for.
Let's just move the encap type encoding to where it
will happen.
'detail' and 'josn' keyword is given as an optional parameter
for cli arguments. Hence 'detail' keyword was consider as a
pbr 'name' for "show pbr map detail json" command.
Donatas Abraitis [Thu, 26 Oct 2023 11:56:52 +0000 (14:56 +0300)]
bgpd: Enable `enforce-first-as` by default
It's been for a while disabled by default, but this seems reasonable to flip it.
We had `bgp enforce-first-as` as a global BGP knob to enable/disable this
behavior globally, later we introduced `enforce-first-as` per neighbor, with disabled
by default. Now let's enable this by default by bringing a global `bgp enforce-first-as`
command back.
If the interface type is point-
to-multipoint or the interface is in the state Loopback, the
global scope IPv6 addresses associated with the interface (if any)
are copied into the intra-area-prefix-LSA with the PrefixOptions
LA-bit set, the PrefixLength set to 128, and the metric set to 0.
Donald Sharp [Tue, 24 Oct 2023 20:14:40 +0000 (16:14 -0400)]
bgpd: combine import_check_table and nexthop_check_table
In zebra, the import check table and the nexthop check tables
were combined. This leaves an issue where when bgp happens
to have a tracked address in both the import check table
and the nexthop track table that are the same address.
When the the item is removed from one table the call
to remove it from zebra removes tracking for the other
table.
Combine the two tables together and keep track where
they came from for processing in bgpd.
There is no command to choose to send or not the bgp4-mibv2 traps.
Since the MIB bgp4-mibv2 notification are redundant with MIB RFC4273
we added a command:
- [no] bgp snmp traps bgp4-mibv2
By default, the bgp4-mibv2 traps will be disabled, to prevent from
redundancy.
This commit add the support of traps for bgp4-mibv2.
It is conformant to draft-ietf-idr-bgp4-mibv2-11.
The following traps are supported:
- bgp4V2EstablishedNotification
- bgp4V2BackwardTransitionNotification
There is no cli command to prevent the router to send traps
implemented in the rfc4273. If not done, when introducing
the traps from bgp4v2mib, traps will be send for each of
the two mibs: there will be redundancy in the sent information.
Add a new command:
- [no] bgp snmp traps rfc4273
Using this command will allow or not the notification of
the following traps:
- bgpEstablishedNotification
- bgpBackwardTransNotification
Donatas Abraitis [Mon, 23 Oct 2023 20:34:10 +0000 (23:34 +0300)]
bgpd: Check mandatory attributes more carefully for UPDATE message
If we send a crafted BGP UPDATE message without mandatory attributes, we do
not check if the length of the path attributes is zero or not. We only check
if attr->flag is at least set or not. Imagine we send only unknown transit
attribute, then attr->flag is always 0. Also, this is true only if graceful-restart
capability is received.
Thread 1 "bgpd" received signal SIGSEGV, Segmentation fault.
0x00005555556e37be in route_set_aspath_prepend (rule=0x555555aac0d0, prefix=0x7fffffffe050,
object=0x7fffffffdb00) at bgpd/bgp_routemap.c:2282
2282 if (path->attr->aspath->refcnt)
(gdb)
```
projects / mirror / frr.git / log