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.
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit c37119df45)
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:
```
router bgp 65001
no bgp ebgp-requires-policy
neighbor 127.0.0.1 remote-as external
neighbor 127.0.0.1 passive
neighbor 127.0.0.1 ebgp-multihop
neighbor 127.0.0.1 disable-connected-check
neighbor 127.0.0.1 update-source 127.0.0.2
neighbor 127.0.0.1 timers 3 90
neighbor 127.0.0.1 timers connect 1
!
address-family ipv4 unicast
neighbor 127.0.0.1 addpath-tx-all-paths
neighbor 127.0.0.1 default-originate
neighbor 127.0.0.1 route-map RM_IN in
exit-address-family
exit
!
route-map RM_IN permit 10
set as-path prepend 200
exit
```
Send a malformed optional transitive attribute:
```
import socket
import time
OPEN = (b"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
b"\xff\xff\x00\x62\x01\x04\xfd\xea\x00\x5a\x0a\x00\x00\x01\x45\x02"
b"\x06\x01\x04\x00\x01\x00\x01\x02\x02\x02\x00\x02\x02\x46\x00\x02"
b"\x06\x41\x04\x00\x00\xfd\xea\x02\x02\x06\x00\x02\x06\x45\x04\x00"
b"\x01\x01\x03\x02\x0e\x49\x0c\x0a\x64\x6f\x6e\x61\x74\x61\x73\x2d"
b"\x70\x63\x00\x02\x04\x40\x02\x00\x78\x02\x09\x47\x07\x00\x01\x01"
b"\x80\x00\x00\x00")
KEEPALIVE = (b"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
b"\xff\xff\xff\xff\xff\xff\x00\x13\x04")
UPDATE = bytearray.fromhex("ffffffffffffffffffffffffffffffff002b0200000003c0ff00010100eb00ac100b0b001ad908ac100b0b")
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.2', 179))
s.send(OPEN)
data = s.recv(1024)
s.send(KEEPALIVE)
data = s.recv(1024)
s.send(UPDATE)
data = s.recv(1024)
time.sleep(100)
s.close()
```
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 6814f2e013)
Fix frr-reload script to only render 'no description'
rather than 'no description blah'
Ticket:#3650752
Testing:
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"
Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit 989991cf3c)
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.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 33025d97b2)
Add "no pcep" command in segment-routing/traffic-engineering context
to deconfigure the whole pcep configuration (pce-config, pce and pcc).
Signed-off-by: Farid Mihoub <farid.mihoub@6wind.com>
(cherry picked from commit 465130ac2a)
A few fixups to clean up some dev doc warnings, in the
northbound files especially.
Signed-off-by: Mark Stapp <mjs@labn.net>
(cherry picked from commit bb6d4cea60)
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.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 4ac659fcbe)
```
r1# sh ipv6 ospf6 summary-address
VRF Name: default
aggregation delay interval :5(in seconds)
```
Just hit this random and looks ugly, let's fix it.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit ed2b593720)
Display ptmStatus in correct order in show interface json
output.
Signed-off-by: Sindhu Parvathi Gopinathan's <sgopinathan@nvidia.com>
(cherry picked from commit aa6dab0369)
https://www.rfc-editor.org/rfc/rfc5340.html#page-37 states:
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.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 80dfa9e012)
Fix the documentation for the pbr map command with
correct syntax.
Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit df3d91f085)
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.
A crash:
```
bgpd[7834]: [TJ23Y-GY0RH] 127.0.0.1 Unknown attribute is received (type 31, length 16)
bgpd[7834]: [PCFFM-WMARW] 127.0.0.1(donatas-pc) rcvd UPDATE wlen 0 attrlen 20 alen 17
BGP[7834]: Received signal 11 at 1698089639 (si_addr 0x0, PC 0x55eefd375b4a); aborting...
BGP[7834]: /usr/local/lib/libfrr.so.0(zlog_backtrace_sigsafe+0x6d) [0x7f3205ca939d]
BGP[7834]: /usr/local/lib/libfrr.so.0(zlog_signal+0xf3) [0x7f3205ca9593]
BGP[7834]: /usr/local/lib/libfrr.so.0(+0xf5181) [0x7f3205cdd181]
BGP[7834]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980) [0x7f3204ff3980]
BGP[7834]: /usr/lib/frr/bgpd(+0x18ab4a) [0x55eefd375b4a]
BGP[7834]: /usr/local/lib/libfrr.so.0(route_map_apply_ext+0x310) [0x7f3205cd1290]
BGP[7834]: /usr/lib/frr/bgpd(+0x163610) [0x55eefd34e610]
BGP[7834]: /usr/lib/frr/bgpd(bgp_update+0x9a5) [0x55eefd35c1d5]
BGP[7834]: /usr/lib/frr/bgpd(bgp_nlri_parse_ip+0xb7) [0x55eefd35e867]
BGP[7834]: /usr/lib/frr/bgpd(+0x1555e6) [0x55eefd3405e6]
BGP[7834]: /usr/lib/frr/bgpd(bgp_process_packet+0x747) [0x55eefd345597]
BGP[7834]: /usr/local/lib/libfrr.so.0(event_call+0x83) [0x7f3205cef4a3]
BGP[7834]: /usr/local/lib/libfrr.so.0(frr_run+0xc0) [0x7f3205ca10a0]
BGP[7834]: /usr/lib/frr/bgpd(main+0x409) [0x55eefd2dc979]
```
Sending:
```
import socket
import time
OPEN = (b"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
b"\xff\xff\x00\x62\x01\x04\xfd\xea\x00\x5a\x0a\x00\x00\x01\x45\x02"
b"\x06\x01\x04\x00\x01\x00\x01\x02\x02\x02\x00\x02\x02\x46\x00\x02"
b"\x06\x41\x04\x00\x00\xfd\xea\x02\x02\x06\x00\x02\x06\x45\x04\x00"
b"\x01\x01\x03\x02\x0e\x49\x0c\x0a\x64\x6f\x6e\x61\x74\x61\x73\x2d"
b"\x70\x63\x00\x02\x04\x40\x02\x00\x78\x02\x09\x47\x07\x00\x01\x01"
b"\x80\x00\x00\x00")
KEEPALIVE = (b"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
b"\xff\xff\xff\xff\xff\xff\x00\x13\x04")
UPDATE = bytearray.fromhex("ffffffffffffffffffffffffffffffff003c0200000014ff1f001000040146464646460004464646464646664646f50d05800100010200ffff000000")
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.2', 179))
s.send(OPEN)
data = s.recv(1024)
s.send(KEEPALIVE)
data = s.recv(1024)
s.send(UPDATE)
data = s.recv(1024)
time.sleep(1000)
s.close()
```
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit d8482bf011)
If we modify the prefix-list that is used to define the routes to be
advertised, all of them MUST be advertised.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 3c94151258)
If we have a prefix-list with one entry, and after some time we append a prefix-list
with some more additional entries, conditional advertisement is triggered, and the
old entries are suppressed (because they look identical as sent before).
Hence, the old entries are sent as withdrawals and only new entries sent as updates.
Force re-sending all BGP updates for conditional advertisement. The same is done
for route-refresh, and/or soft clear operations.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 2d8e859585)
When testing GR features, it is desired to kill bgp
(or really any daemon )and not immediately have bgp start up again.
Modify the code to not attempt to restart the daemon
by hand to let us developers work when the `watchfrr ignore XXX`
command is issued.
Testing:
watchfrr ignore bgpd
kill -9 bgpd
start bgp by `/usr/lib/frr/watchfrr.sh start bgpd` at some point in time
in the future
leaf-1# show watchfrr
watchfrr global phase: Idle
Restart Command: "/usr/lib/frr/watchfrr.sh restart %s"
Start Command: "/usr/lib/frr/watchfrr.sh start %s"
Stop Command: "/usr/lib/frr/watchfrr.sh stop %s"
Min Restart Interval: 60
Max Restart Interval: 600
Restart Timeout: 90
zebra Up
bgpd Up/Ignoring Timeout
staticd Up
leaf-1#
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit c168244b99)
With the deprecation of the global "bgp enforce-first-as" command back
in https://github.com/FRRouting/frr/pull/2259 the newly introduced
option to enable that setting on a specific peer was not documented.
This commit adds the necessary documentation and states the command's
default.
Signed-off-by: Manuel Schweizer <manuel.schweizer@cloudscale.ch>
(cherry picked from commit 3acc6ae932)
Problem Statement:
===================
Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised byte(s)
at 0x4975157: sendmsg (sendmsg.c:28)
==2263111== by 0x1413BE: pim_msg_send_frame (pim_pim.c:629)
==2263111== by 0x1413BE: pim_msg_send (pim_pim.c:743)
==2263111== by 0x1425DC: pim_register_send (pim_register.c:332)
==2263111== by 0x1427EE: pim_null_register_send (pim_register.c:443)
==2263111== by 0x14D228: pim_upstream_register_stop_timer (pim_upstream.c:1608)
==2263111== by 0x48CE6DF: thread_call (thread.c:1693)
==2263111== by 0x4899EFF: frr_run (libfrr.c:1068)
==2263111== by 0x11D035: main (pim6_main.c:190)
==2263111== Address 0x1ffeffdcb1 is on thread 1's stack
==2263111== in frame #2, created by pim_register_send (pim_register.c:273)
==2263111== Uninitialised value was created by a stack allocation
==2263111== at 0x142690: pim_null_register_send (pim_register.c:389)
RCA:
====================
1. All members of struct pim_msg_header were not initiliased while sending
null register packet. Therefore when the pointers are assigned while
sending the msg via sendmsg, it complains the pointer points to
uninitialised byte.
2. struct ipv6_ph ph was also not initialised.
Fix:
====================
Initialised all the members using memset.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
(cherry picked from commit 1064818645)
When redistributing a local route, ensure the forwarding address field
of AS-External LSAs is only set when the associated nexthop interface
is OSPF-enabled. This is necessary because the OSPF RFC requires that
the AS-External LSA forwarding address should be resolvable using an
intra-area or inter-area path.
Fixes#14462.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
(cherry picked from commit 331ae6accc)
