A redistribute cmd can have a route-map attached to it and adding the
match source-protocol to that route-map means BGP to filter which
protocol routes to accept among the bunch of routes zebra is sending.
Fixing this since this wasnt implemented earlier.
Ticket :#4119692
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
(cherry picked from commit 68358c0f92)
Without this patch we set only the first path for the route (if multiple exist)
as LLGR stale and stop doing that for the rest of the paths, which is wrong.
Fixes: 1479ed2fb3 ("bgpd: Implement LLGR helper mode")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 895d586a5f)
We iterated over all bgp_path_info's, but once we remove the path, we didn't
check for other paths under the same bgp_dest.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 7de464b00f)
The test verifies that a kernel blackhole route is not affected by
interface's link change.
Signed-off-by: anlan_cs <anlan_cs@126.com>
(cherry picked from commit 0073a870d1)
The `rib_update_handle_kernel_route_down_possibility()` didn't consider
the kernel routes ( blackhole ) without interface. When some other
interfaces are down, these kernel routes will be wrongly removed.
Signed-off-by: anlan_cs <anlan_cs@126.com>
(cherry picked from commit 44a82da405)
If we set router-id, e.g. `router-id x.x.x.x`, then we have:
```
pc.donatas.net# show ip ospf | include Router ID
OSPF Routing Process, Router ID: x.x.x.x
```
But once we remove it (`no router-id x.x.x.x`), the old router-id remains.
This is kinda OK, but to be consistent with OSPFv3 we should use what Zebra
already has, instead of retaining the old one.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 1073e0f9b3)
A new command is `ospf router-id ...`, but the old one is also valid. Just a no
form was missed.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 80bfe6784f)
Before this patch, if we set something like:
```
bgp extcommunity-list expanded 1234 permit admin
```
In running config we have:
```
bgp extcommunity-list 1234 seq 5 permit admin
```
That leads to incorrect rendering, even more the line can't be deleted.
With this fix we treat numbered community-list only if it's inside the range
1-500, otherwise it's a non-numbered clist.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 4c1ee29116)
Modified nhrp_connection_authorized(). Initially, when writing debug
information about incoming NHRP packets with authentication enabled,
the nhrp_connection_authorized() function would print the
passphrase of the incoming packet as if it were a null terminated
string. This meant that if the passphrase on the incoming packet
had non ASCII-complient bytes in it, it would attempt to print those
bytes anyway. There was also no check that the size of the passphrase in
the incoming packet matched the size of the passphrase on the interface.
The changes in this commit log the passphrase on the incoming packet as
well as the passphrase on interface in HEX to avoid issues with ASCII.
It also performs a check that accounts for the sizes of the two different
passphrases
Moved CISCO_PASS_LENGTH_LEN from nhrp_vty.c to nhrp_protocol.h
for easier access to the macro in other files
Signed-off-by: Joshua Muthii <jmuthii@labn.net>
(cherry picked from commit 5718ee37c7)
Modified nhrp_topo topotest to test for newly added resolution
request retry feature. Changes to the topotest include adding a spoke to the
existing nhrp_topo topotest so that a topology with two spokes and hub
can be used to create shortcuts and test the sending/resending of
resolution requests and responses between spoke and hub. The resolution
request retry feature was tested by blocking incoming resolution requests on a
receiving nodes to stop the creation of a successful shortcut - which
then triggered the sending spoke to retry sending resolution requests
Signed-off-by: Joshua Muthii <jmuthii@labn.net>
(cherry picked from commit d599aa1da6)
Traceback (most recent call last):
File "/home/docs/checkouts/readthedocs.org/user_builds/frrouting/envs/latest/lib/python3.11/site-packages/sphinx/config.py", line 529, in eval_config_file
exec(code, namespace) # NoQA: S102
^^^^^^^^^^^^^^^^^^^^^
File "/home/docs/checkouts/readthedocs.org/user_builds/frrouting/checkouts/latest/doc/user/conf.py", line 77, in <module>
html_context["READTHEDOCS"] = True
^^^^^^^^^^^^
NameError: name 'html_context' is not defined
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit ef9f698e04)
Currently the mroute code was not allowing the mroute
to be sent to the dataplane. This leaves us with a
situation where the routes being installed where never
being set as installed and additionally nht against
the mrib would not work if the route came into existence
after the nexthop tracking was asked for.
Turns out all the pieces where there to let this work.
Modify the code to pass it to the dplane and to send
it back up as having worked.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Trying to figure out what safi we are talking about is fun when
it is not put into the debugs.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 811168ecc3)
Nothing special here, just allow sharpd to ask to watch
nexthops in the mrib.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit aff8eaa4a2)
The algorithm number is encoded on 8 bits and does not require
an unsigned 32 bit value to store the value.
Fixes: cc4926c128 ("isisd,yang: add algorithm-prefix-sid configuration tree")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit 8e861a75e8)
we have
(gdb) p *path->attr->aspath
$1 = {refcnt = 3, segments = 0x0, json = 0x0, str = 0x55723d0b7470 "", str_len = 0, asnotation = ASNOTATION_PLAIN}
It looks like this aspath is empty, resulting in a size 0 and NULL pointer for path->attr->aspath->segments which leads to the SIGSEGV
fixe: return 0 when segments is null.
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
(cherry picked from commit ee2f1b85cf)
a local logger masks the global logger and prevents errors from being
gracefully handled within topotest.py
Signed-off-by: Liam Brady <lbrady@labn.net>
(cherry picked from commit 1b38f33041)
Fix the display of the local label in show bgp.
> r1# show bgp ipv4 labeled-unicast 172.16.2.2/32
> BGP routing table entry for 172.16.2.2/32, version 2
> Local label: 16 <---- MISSING
> Paths: (1 available, best #1, table default, vrf (null))
> Advertised to non peer-group peers:
> 192.168.1.2
> 65501
> 192.168.1.2 from 192.168.1.2 (172.16.2.2)
> Origin IGP, metric 0, valid, external, best (First path received)
> Remote label: 3
> Last update: Fri Oct 25 17:55:45 2024
Fixes: 67f67ba481 ("bgpd: Drop label_ntop/label_pton functions")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit e7b3276ace)
Introduce a command to stop bgpd from enabling IPv6 router advertisement
messages sending on interfaces.
Signed-off-by: Mikhail Sokolovskiy <sokolmish@gmail.com>
(cherry picked from commit 7b1c0c23fc)
This only matters to single hop nodes that are adjacent to the bsr. More common
with IPv6 where LL address is used in PIM as the primary address. If the BSR IP
happens to be an address on the same interface, the receiving pim router
rejects the BSR address because it expects the BSR IP to resolve via the LL address
even if we have a connected route for the same BSR IP subnet. Effectively, we want to
allow rpf to be resolved via secondary IPs with connected routes on the same interface,
and not limit them to primary addresses.
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
(cherry picked from commit 8fbd88c5a7)
