Mark Stapp [Thu, 5 Oct 2023 17:47:17 +0000 (13:47 -0400)]
tests: locate nhg id from json output in all_proto_startup
Don't hard-code a sharpd nhg id: those values aren't stable
if the daemons/protos/route-types change. Use json show output
to find the id in the 'resilient' nhg test case in
the all_protocol_startup suite.
Indicating the configured PIM Rendezvous Point (RP) in the MSDP SA
message
The RFC-3618, section 12.2.1, describes the fields included in the MSDP
SA message. The "RP address" field is "the address of the RP in the
domain the source has become active in".
In the most common case, we will establish an MSDP connection from RP to
RP. However, there are cases where we want to establish a MSDP
connection from an interface/address that is not the RP. Section 3 of
RFC-3618 describes that scenario as "intermediate MSDP peer". Moreover,
the RP could be another router in the PIM domain - not the one
establishing the MSDP connection.
The current implementation could be problematic even with a single
router per PIM domain. Consider the following scenario:
* There are two PIM domains, each one with a single router.
* The two routers are connected via two independent networks. Let's say
that is to provide redundancy.
* The routers are configured to establish two MSDP connections, one on
each network (redundancy again).
* A multicast source becomes active on the router 1. It will be
communicated to router 2 via two independent MSDP SA messages, one per
MSDP connection.
* Without these changes, each MSDP SA message will indicate a different
RP.
* Both RP addresses will pass the RPF check, and both MSDP sources will
be accepted.
* If the router has clients interested in that multicast group, it will
send PIM Join messages to both RPs and start receiving the multicast
traffic from both.
With the changes included in this commit, the multicast source available
in router 1 would still be communicated to router 2 twice. But both MSDP
SA messages would indicate the same RP, and one of them would be
discarded due to failure in the RPF-check failure. Also, the changes
allow us to define the RP that will be included in the MSDP SA message,
and it could be one of the interfaces used to establish the MSDP
connection, some other interface on the router, a loopback interface, or
another router in the PIM domain.
These changes should not create compatibility issues. As I mentioned, we
usually establish MSDP connections from RP to RP. In this case, the
result will be the same. We would still indicate the address used to
establish the MSDP connection if the RP is not set - I wonder if that
should even be a valid configuration.
Signed-off-by: Adriano Marto Reis <adrianomarto@gmail.com>
Philippe Guibert [Tue, 27 Jun 2023 19:36:01 +0000 (21:36 +0200)]
bgpd: add 'match community-list any' function
There is no match mechanism to match one community from the
incoming community-list. Add the 'any' keyword to the 'match
route-map' command of communit-list and large-community-list.
> match community-list AAA any
> match large-community-list AAA any
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
fmihoub6WIND [Fri, 25 Nov 2022 10:17:07 +0000 (11:17 +0100)]
zebra: delete label chunk upon release
In zebra/label_manager.c the releasing of the label chunk is done by
disowning the chunk to the system. The presence of this system label
chunk will cause label assignment to fail for this use case example:
Christian Hopps [Thu, 28 Sep 2023 16:10:31 +0000 (12:10 -0400)]
lib: use XREALLOC over realloc avoid coverity warning
I believe coverity is complaining that the current code does not handle the
realloc fail case, in which case the original pointer is not freed, but NULL is
returned. The code assert()s it's not failed but that is not strong enough it
needs to abort which XREALLOC does and is a better integration into FRR-inrfa
anyway.
Louis Scalbert [Thu, 28 Sep 2023 14:55:43 +0000 (16:55 +0200)]
bgpd: fix insecure data write with area addresses
Fix an issue where an attacker may inject a tainted length value to
corrupt the memory.
> CID 1568380 (#1 of 1): Untrusted value as argument (TAINTED_SCALAR)
> 9. tainted_data: Passing tainted expression length to bgp_linkstate_nlri_value_display, which uses it as an offset
Fixes: 8b531b1107 ("bgpd: store and send bgp link-state attributes") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Louis Scalbert [Thu, 28 Sep 2023 14:53:35 +0000 (16:53 +0200)]
bgpd: fix insecure data write with ip addresses
Fix issues where an attacker may inject a tainted length value to
corrupt the memory.
> CID 1568378 (#1-6 of 6): Untrusted value as argument (TAINTED_SCALAR)
> 16. tainted_data: Passing tainted expression length to bgp_linkstate_tlv_attribute_value_display, which uses it as an offset. [show details]
Quentin Young [Thu, 28 Sep 2023 14:49:37 +0000 (10:49 -0400)]
doc: unpin sphinx from 4.0.2
requirements.txt was pinning sphinx at a very old version. This version
doesn't work in recent versions of Python; the new RTD configuration
made RTD respect our requirements file, breaking the build.
Signed-off-by: Quentin Young <qlyoung@qlyoung.net>
Louis Scalbert [Thu, 28 Sep 2023 13:27:27 +0000 (15:27 +0200)]
bgpd: fix illegal memory access in bgp_ls_tlv_check_size()
Fix illegal memory access bgp_ls_tlv_check_size() if type is 1253.
> CID 1568377 (#4 of 4): Out-of-bounds read (OVERRUN)
> 5. overrun-local: Overrunning array bgp_linkstate_tlv_infos of 1253 16-byte elements at element index 1253 (byte offset 20063) using index type (which evaluates to 1253).
Louis Scalbert [Thu, 28 Sep 2023 13:08:23 +0000 (15:08 +0200)]
bgpd: do not check attr in bgp_packet_attribute
Fix the following coverity issue. attr cannot be NULL.
> CID 1568376 (#1 of 1): Dereference before null check (REVERSE_INULL)
> check_after_deref: Null-checking attr suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
Fixes: 8b531b1107 ("bgpd: store and send bgp link-state attributes") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Igor Ryzhov [Wed, 27 Sep 2023 23:45:05 +0000 (02:45 +0300)]
vtysh: fix entering configuration node in file-lock mode
When the config node is entered in file-lock mode, we should actually
remember it to correctly apply the workaround in `vtysh_exit`.
Otherwise, the file-lock mode is dropped once we exit any node one level
below the config node.
Igor Ryzhov [Wed, 27 Sep 2023 23:41:16 +0000 (02:41 +0300)]
vty: fix working in file-lock mode
When the configuration node is entered in file-lock mode, candidate
and running datastores are locked. Any configuration change is followed
by an implicit commit which leads to a crash of mgmtd, because double
lock is prohibited by an assert. When working in file-lock mode, we
shouldn't do implicit commits which is disabled by allowing pending
configuration changes.
When we accept a connection, we try to set TTL for the socket, but the socket
is not yet created/assigned and we are trying to set it on the wrong socket fd.
```
[Event] connection from 127.0.0.1 fd 25, active peer status 3 fd -1
can't set sockopt IP_TTL 255 to socket -1
bgp_set_socket_ttl: Can't set TxTTL on peer (rtrid 0.0.0.0) socket, err = 9
Unable to set min/max TTL on peer 127.0.0.1, Continuing
```
David Lamparter [Sun, 24 Sep 2023 18:12:42 +0000 (20:12 +0200)]
lib: assert for VTY_PASSFD expectations
Coverity is complaining that vty->state could be VTY_PASSFD here. It
can't, it really shouldn't, and if it actually is then something went
seriously wrong somewhere earlier so assert()ing out is the best thing
to do.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
In test_bgp_srv6l3vpn_sid.py we have a comment containing some '\'
characters. Python mistakenly tries to interpret such "\" characters
as escape sequences, which leads to the above warning.
Let's tell Python to treat the comment as a raw string,
so that it simply treats backslashes as literal characters rather than
escape sequences.
Rafael Zalamena [Fri, 22 Sep 2023 15:28:38 +0000 (12:28 -0300)]
lib: don't announce prefix delete for duplicates
When deleting a duplicated prefix list entry don't announce the change
to route map listeners, otherwise they will be removing rules that
shouldn't be removed causing the prefix that still exist in the
prefix-list to be not evaluated anymore.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
bgpd: Initialise timebuf arrays to zeros for dampening reuse timer
Avoid having something like this in outputs:
Before:
```
munet> r1 shi vtysh -c 'show bgp dampening damp'
BGP table version is 10, local router ID is 10.10.10.1, vrf id 0
Default local pref 100, local AS 65001
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
munet> r1 shi vtysh -c 'show bgp dampening flap'
BGP table version is 10, local router ID is 10.10.10.1, vrf id 0
Default local pref 100, local AS 65001
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
```
munet> r1 shi vtysh -c 'show bgp dampening damp '
BGP table version is 10, local router ID is 10.10.10.1, vrf id 0
Default local pref 100, local AS 65001
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
munet> r1 shi vtysh -c 'show bgp dampening flap'
BGP table version is 10, local router ID is 10.10.10.1, vrf id 0
Default local pref 100, local AS 65001
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Donald Sharp [Thu, 21 Sep 2023 19:30:08 +0000 (15:30 -0400)]
bgpd: Ensure send order is 100% consistent
When BGP is sending updates to peers on a neighbor up event
it was noticed that the bgp updates being sent were in reverse
order being sent to the first peer.
Imagine r1 -- r2 -- r3. r1 and r2 are ebgp peers and
r2 and r3 are ebgp peers. r1's interface to r2 is currently
shutdown. Prior to this fix the send order would look like this:
r1 -> r2 send of routes to r2 and then they would be installed in order
received:
10.0.0.12 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.11 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.10 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.9 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.8 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.7 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.6 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.5 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.4 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.3 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.2 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.1 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
r2 would then send these routes to r3 and then they would be installed
in order received:
10.0.0.1 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.2 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.3 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.4 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.5 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.6 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.7 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.8 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.9 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.10 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.11 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.12 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
Not that big of a deal right? Well imagine a situation where r1 is
originating several ten's of thousands of routes. It sends routes to r2
r2 is processing routes but in reverse order and at the same time it
is sending routes to r3, in the correct order of the bgp table.
r3 will have the early 10.0.0.1/32 routes installed and start forwarding
while r2 will not have those routes installed yet( since they were at the
end and zebra is slightly slower for processing routes than bgp is ).
Ensure that the order sent is a true FIFO. What is happening is that
there is an update fifo which stores all routes. And off that FIFO
is a bgp advertise attribute list which stores the list of prefixes
which share the same attribute that allow for more efficient packing
this list was being stored in reverse order causing the problem for
the initial send. When adding items to this list put them at the
end so we keep the fifo order that is traversed when we walk through
the bgp table.
After the fix:
r2 installation order:
10.0.0.0 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.1 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.2 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.3 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.4 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.5 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.6 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.7 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.8 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.9 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.10 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.11 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.12 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
r3 installation order:
10.0.0.0 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.1 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.2 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.3 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.4 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.5 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.6 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.7 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.8 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.9 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.10 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.11 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.12 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
projects / mirror / frr.git / log