| Age | Commit message (Collapse) | Author |
|---|
|
Related-to: 94e2aadf7187d7d695babce21033b5bc8e454f25 ("bgpd: Set the label for MP_UNREACH_NLRI 0x800000 instead of 0x000000")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit e69459c7144568381c05bbaf962adecd914975d5)
|
|
RFC8277 says:
The procedures in [RFC3107] for withdrawing the binding of a label
or sequence of labels to a prefix are not specified clearly and correctly.
=> How to Explicitly Withdraw the Binding of a Label to a Prefix
Suppose a BGP speaker has announced, on a given BGP session, the
binding of a given label or sequence of labels to a given prefix.
Suppose it now wishes to withdraw that binding. To do so, it may
send a BGP UPDATE message with an MP_UNREACH_NLRI attribute. The
NLRI field of this attribute is encoded as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Compatibility |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: NLRI for Withdrawal
Upon transmission, the Compatibility field SHOULD be set to 0x800000.
Upon reception, the value of the Compatibility field MUST be ignored.
[RFC3107] also made it possible to withdraw a binding without
specifying the label explicitly, by setting the Compatibility field
to 0x800000. However, some implementations set it to 0x000000. In
order to ensure backwards compatibility, it is RECOMMENDED by this
document that the Compatibility field be set to 0x800000, but it is
REQUIRED that it be ignored upon reception.
In FRR case where a single label is used per-prefix, we should send 0x800000,
and not 0x000000.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 94e2aadf7187d7d695babce21033b5bc8e454f25)
|
|
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 42b9d985ccced6ee4ccc70b139c78cd47867b2ba)
|
|
Revert backport for crash when modifying SRv6 SID for stable/10.3 branch
|
|
This reverts commit c80c2b2a4226640464a38f8ee9f8b2b4be8bd094.
|
|
This reverts commit 8f1313392f70ff2e7e8f924e238564879d5e3aeb.
|
|
staticd: Fix a crash that occurs when modifying an SRv6 SID (backport #18467)
|
|
bgpd: Fix holdtime not working properly when busy (backport #18483)
|
|
Commit: cc9f21da2218d95567eff1501482ce58e6600f54
Modified the bgp_fsm code to dissallow the extension
of the hold time when the system is under extremely
heavy load. This was a attempt to remove the return
code but it was too aggressive and messed up this bit
of code.
Put the behavior back that was introduced in:
d0874d195d0127009a7d9c06920c52c95319eff9
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 9a26a56c5188fd1c95e244932bc17f97b9051935)
|
|
This commit adds a test case that modifies a SID and verifies that the
RIB is as expected.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
(cherry picked from commit 23403e01a3ece0b206bc8acf36c08b4bb538cb79)
|
|
When the user modifies an SRv6 SID and then removes all SIDs, staticd
crashes:
```
2025/03/23 08:37:22.691860 STATIC: lib/memory.c:74: mt_count_free(): assertion (mt->n_alloc) failed
STATIC: Received signal 6 at 1742715442 (si_addr 0x8200007cf0); aborting...
STATIC: zlog_signal+0x390 fcc704a844b8 ffffd7450390 /usr/lib/frr/libfrr.so.0 (mapped at 0xfcc704800000)
STATIC: core_handler+0x1f8 fcc704b79990 ffffd7450590 /usr/lib/frr/libfrr.so.0 (mapped at 0xfcc704800000)
STATIC: ---- signal ----
STATIC: ? fcc705c008f8 ffffd74507a0 linux-vdso.so.1 (mapped at 0xfcc705c00000)
STATIC: pthread_key_delete+0x1a0 fcc70458f1f0 ffffd7451a00 /lib/aarch64-linux-gnu/libc.so.6 (mapped at 0xfcc704510000)
STATIC: raise+0x1c fcc70454a67c ffffd7451ad0 /lib/aarch64-linux-gnu/libc.so.6 (mapped at 0xfcc704510000)
STATIC: abort+0xe4 fcc704537130 ffffd7451af0 /lib/aarch64-linux-gnu/libc.so.6 (mapped at 0xfcc704510000)
STATIC: _zlog_assert_failed+0x3c4 fcc704c407c8 ffffd7451c40 /usr/lib/frr/libfrr.so.0 (mapped at 0xfcc704800000)
STATIC: mt_count_free+0x12c fcc704a93c74 ffffd7451dc0 /usr/lib/frr/libfrr.so.0 (mapped at 0xfcc704800000)
STATIC: qfree+0x28 fcc704a93fa0 ffffd7451e70 /usr/lib/frr/libfrr.so.0 (mapped at 0xfcc704800000)
STATIC: static_srv6_sid_free+0x1c adc1df8fa544 ffffd7451e90 /usr/lib/frr/staticd (mapped at 0xadc1df8a0000)
STATIC: delete_static_srv6_sid+0x14 adc1df8faafc ffffd7451eb0 /usr/lib/frr/staticd (mapped at 0xadc1df8a0000)
STATIC: list_delete_all_node+0x104 fcc704a60eec ffffd7451ed0 /usr/lib/frr/libfrr.so.0 (mapped at 0xfcc704800000)
STATIC: list_delete+0x8c fcc704a61054 ffffd7451f00 /usr/lib/frr/libfrr.so.0 (mapped at 0xfcc704800000)
STATIC: static_srv6_cleanup+0x20 adc1df8fabdc ffffd7451f20 /usr/lib/frr/staticd (mapped at 0xadc1df8a0000)
STATIC: sigint+0x40 adc1df8be544 ffffd7451f30 /usr/lib/frr/staticd (mapped at 0xadc1df8a0000)
STATIC: frr_sigevent_process+0x148 fcc704b79460 ffffd7451f40 /usr/lib/frr/libfrr.so.0 (mapped at 0xfcc704800000)
STATIC: event_fetch+0x1c4 fcc704bc0834 ffffd7451f60 /usr/lib/frr/libfrr.so.0 (mapped at 0xfcc704800000)
STATIC: frr_run+0x650 fcc704a5d230 ffffd7452080 /usr/lib/frr/libfrr.so.0 (mapped at 0xfcc704800000)
STATIC: main+0x1d0 adc1df8be75c ffffd7452270 /usr/lib/frr/staticd (mapped at 0xadc1df8a0000)
STATIC: __libc_init_first+0x7c fcc7045373fc ffffd74522b0 /lib/aarch64-linux-gnu/libc.so.6 (mapped at 0xfcc704510000)
STATIC: __libc_start_main+0x98 fcc7045374cc ffffd74523c0 /lib/aarch64-linux-gnu/libc.so.6 (mapped at 0xfcc704510000)
STATIC: _start+0x30 adc1df8be0f0 ffffd7452420 /usr/lib/frr/staticd (mapped at 0xadc1df8a0000)
```
Tracking this down, the crash occurs because every time we modify a
SID, staticd executes some callbacks to modify the SID and finally it
calls `apply_finish`, which re-adds the SID to the list `srv6_sids`.
This leads to having the same SID multiple times in the `srv6_sids`
list. When we delete all SIDs, staticd attempts to deallocate the same
SID multiple times, which leads to the crash.
This commit fixes the issue by moving the code that adds the SID to the
list from the `apply_finish` callback to the `create` callback.
This ensures that the SID is inserted into the list only once, when it
is created. For all subsequent modifications, the SID is modified but
not added to the list.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
(cherry picked from commit 6037ea350c98fbce60d0a287720cd4e60f7a21ec)
|
|
bgpd: fix `set evpn gateway-ip ipv[46]` route-map (backport #18378)
|
|
All assignments of the EVPN attributes (ESI and Gateway IP) are gated
behind the peer being set up for inbound soft-reconfiguration.
There are no actual reasons for this limitation, so let's perform the
EVPN attribute assignment no matter what when soft reconfiguration is
not enabled.
Fixes: 6e076ba5231 ("bgpd: Fix for ain->attr corruption during path update")
Signed-off-by: Tuetuopay <tuetuopay@me.com>
(cherry picked from commit 7320659f78cbe86dd983d5101831120fc14583d7)
|
|
This test does not actually look at the route since the gateway-ip is
not exposed in vtysh output. However, this ensures such a route-map does
not crash bgpd.
Signed-off-by: Tuetuopay <tuetuopay@me.com>
(cherry picked from commit 05a74323b9d440590074f22be11c34a605da69ad)
|
|
The `route_set_evpn_gateway_ip` function copies `gw_ip->ip.addr` in the
route's gateway ip. In a nutshell, this skips the `ipa_type` field,
writing the actual IP in the IP type. This later rightfully trips
asserts about unknown IP types.
The following route-map...
```
route-map test permit 10
set evpn gateway-ip ipv4 1.1.1.1
```
...will make the following gateway IP in the route:
```
(gdb) p/x a1->evpn_overlay->gw_ip
$11 = {ipa_type = 0x1010101, ip = {addr = 0x0, addrbytes = {
0x0 <repeats 16 times>}, _v4_addr = {s_addr = 0x0}, _v6_addr = {
__in6_u = {__u6_addr8 = {0x0 <repeats 16 times>}, __u6_addr16 = {0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, __u6_addr32 = {0x0, 0x0, 0x0,
0x0}}}}}
```
We do indeed see the IP Address in the `ipa_type` field.
Fix by starting the memcpy at the root of `struct ipaddr` instead of
skipping the `ipa_type` field.
Fixes: d0a4ee6010a ("bgpd: Add "set evpn gateway-ip" clause for route-map")
Signed-off-by: Tuetuopay <tuetuopay@me.com>
(cherry picked from commit 0b0e7015971a788c14dd1dc9b5bac8cb66175c29)
|
|
zebra: Do not flush an existing vni configuration trying to remove wrong vni (backport #18108)
|
|
Before:
```
pc.donatas.net(config)# do sh run | include vni
vni 1
pc.donatas.net(config)# no vni 2
pc.donatas.net(config)# do sh run | include vni
pc.donatas.net(config)#
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 44fe3981ee388f7c60ab2635309bce34774116e1)
|
|
bgpd: Fix leaked memory when showing some bgp routes (backport #18435)
|
|
Fix rpm packaging for 10.3 (manual backport #18426)
|
|
Fix issue where zeromq is getting enabled if build system has the libs
installed. For RPMs, we want it always based on intended config options.
(and currently the zeromq is not part of the packages)
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
|
|
Adding options to disable docs and rpki during the build. By
default they are always built. RPKI sub-package will not be built
(and not available) if built without the RPKI support.
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
|
|
for different system environments by including all built .so files"
This reverts commit d89f21fc0602761f5adb0dd82b8c6e24a5636a20.
Reverting original change from PR 17793. This commit breaks RPKI
and SNMP sub-packages
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
|
|
The two memory leaks:
==387155== 744 (48 direct, 696 indirect) bytes in 1 blocks are definitely lost in loss record 222 of 262
==387155== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==387155== by 0x4C1B982: json_object_new_object (in /usr/lib/x86_64-linux-gnu/libjson-c.so.5.1.0)
==387155== by 0x2E4146: peer_adj_routes (bgp_route.c:15245)
==387155== by 0x2E4F1A: show_ip_bgp_instance_neighbor_advertised_route_magic (bgp_route.c:15549)
==387155== by 0x2B982B: show_ip_bgp_instance_neighbor_advertised_route (bgp_route_clippy.c:722)
==387155== by 0x4915E6F: cmd_execute_command_real (command.c:1003)
==387155== by 0x4915FE8: cmd_execute_command (command.c:1062)
==387155== by 0x4916598: cmd_execute (command.c:1228)
==387155== by 0x49EB858: vty_command (vty.c:626)
==387155== by 0x49ED77C: vty_execute (vty.c:1389)
==387155== by 0x49EFFA7: vtysh_read (vty.c:2408)
==387155== by 0x49E4156: event_call (event.c:2019)
==387155== by 0x4958ABD: frr_run (libfrr.c:1247)
==387155== by 0x206A68: main (bgp_main.c:557)
==387155==
==387155== 2,976 (192 direct, 2,784 indirect) bytes in 4 blocks are definitely lost in loss record 240 of 262
==387155== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==387155== by 0x4C1B982: json_object_new_object (in /usr/lib/x86_64-linux-gnu/libjson-c.so.5.1.0)
==387155== by 0x2E45CA: peer_adj_routes (bgp_route.c:15325)
==387155== by 0x2E4F1A: show_ip_bgp_instance_neighbor_advertised_route_magic (bgp_route.c:15549)
==387155== by 0x2B982B: show_ip_bgp_instance_neighbor_advertised_route (bgp_route_clippy.c:722)
==387155== by 0x4915E6F: cmd_execute_command_real (command.c:1003)
==387155== by 0x4915FE8: cmd_execute_command (command.c:1062)
==387155== by 0x4916598: cmd_execute (command.c:1228)
==387155== by 0x49EB858: vty_command (vty.c:626)
==387155== by 0x49ED77C: vty_execute (vty.c:1389)
==387155== by 0x49EFFA7: vtysh_read (vty.c:2408)
==387155== by 0x49E4156: event_call (event.c:2019)
==387155== by 0x4958ABD: frr_run (libfrr.c:1247)
==387155== by 0x206A68: main (bgp_main.c:557)
For the 1st one, if the operator issues a advertised-routes command, the
json_ar variable was never being freed.
For the 2nd one, if the operator issued a command where the
output_count_per_rd is 0, we need to free the json_routes value.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 9651b159ccd18c81450251dbd3bae9c493b7a866)
|
|
lib: Create VRF if needed (backport #18430)
|
|
When creating a control plane protocol through NB, create the vrf
if needed instead of only looking up and asserting if it doesn't
exist yet.
Fixes 18429.
Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
(cherry picked from commit b6ae01f907c071be6cd197df0f3ca6fe9baa631a)
|
|
ospf6d: Disable and delete OSPFv3 areas that no longer have interfaces or configuration. (backport #18393)
|
|
configuration.
This fix will delete an OSPFv3 area when all the interfaces and
configuration (ranges, NSSA ranges, stub area, NSSA area, filter-list,
import-list and export-list) have been removed. The changes provides
a general solution to https://github.com/FRRouting/frr/issues/18324.
Signed-off-by: Acee Lindem <acee@lindem.com>
(cherry picked from commit 04994891fe164b4d5a2819d3bc90e5346f94dc53)
|
|
bgpd: Fixed crash upon bgp network import-check command (backport #18387)
|
|
BT:
```
3 <signal handler called>
4 0x00005616837546fc in bgp_static_update (bgp=bgp@entry=0x5616865eac50, p=0x561686639e40,
bgp_static=0x561686639f50, afi=afi@entry=AFI_IP6, safi=safi@entry=SAFI_UNICAST) at ../bgpd/bgp_route.c:7232
5 0x0000561683754ad0 in bgp_static_add (bgp=0x5616865eac50) at ../bgpd/bgp_table.h:413
6 0x0000561683785e2e in no_bgp_network_import_check (self=<optimized out>, vty=0x5616865e04c0,
argc=<optimized out>, argv=<optimized out>) at ../bgpd/bgp_vty.c:4609
7 0x00007fdbcc294820 in cmd_execute_command_real (vline=vline@entry=0x561686663000,
```
The program encountered a SEG FAULT when attempting to access pi->extra->vrfleak->bgp_orig because
pi->extra->vrfleak was NULL.
```
(gdb) p pi->extra->vrfleak
$1 = (struct bgp_path_info_extra_vrfleak *) 0x0
(gdb) p pi->extra->vrfleak->bgp_orig
Cannot access memory at address 0x8
```
Added NOT NULL check on pi->extra->vrfleak before accessing pi->extra->vrfleak->bgp_orig
to prevent the segmentation fault.
Signed-off-by: Manpreet Kaur <manpreetk@nvidia.com>
(cherry picked from commit bc1008b970541c090e36fc1d50c720df822fcb99)
|
|
zebra: ensure proper return for failure for Sid allocation (backport #18360)
|
|
The functions alloc_srv6_sid_func_explicit/dynamic expect to return bool
but we have places where we return a -1 or NULL which the caller is
assuming as a True/Valid and ending up allocating Sid
Without Fix:
2025/03/10 21:44:04.295350 ZEBRA: [XWV20-TGK70] alloc_srv6_sid_func_explicit: trying to allocate explicit SID function 65088 from block fcbb:bbbb::/32
2025/03/10 21:44:04.295351 ZEBRA: [MM61M-TQZNP] alloc_srv6_sid_func_explicit: elib s 10000 e 20000 wlib s 1000 ewlib s 30000 e 1000 SID_FUNC 65088
2025/03/10 21:44:04.295352 ZEBRA: [QGHMB-SWNFW] alloc_srv6_sid_func_explicit: function 65088 is outside ELIB [10000/20000] and EWLIB alloc ranges [30000/1000]
2025/03/10 21:44:04.295367 ZEBRA: [H0GZA-NNSWJ] get_srv6_sid_explicit: allocated explicit SRv6 SID fcbb:bbbb:1:fe40:: for context End.X nh6 2001::2
2025/03/10 21:44:04.295368 ZEBRA: [XBBYD-T1Q7P] srv6_manager_get_sid_internal: got new SRv6 SID for ctx End.X nh6 2001::2: sid_value=fcbb:bbbb:1:fe40:: (func=65088) (proto=4, instance=0, sessionId=0), notifying all clients
With Fix:
2025/03/10 22:04:25.052235 ZEBRA: [MM61M-TQZNP] alloc_srv6_sid_func_explicit: elib s 30000 e 31000 wlib s 31000 ewlib s 30000 e 31000 SID_FUNC 65056
2025/03/10 22:04:25.052236 ZEBRA: [YHMRC-EMYNX] alloc_srv6_sid_func_explicit: function 65056 is outside ELIB [30000/31000] and EWLIB alloc ranges [30000/31000]
2025/03/10 22:04:25.052254 ZEBRA: [XSG8X-Q2XJX] get_srv6_sid_explicit: invalid SM request arguments: failed to allocate SID function 65056 from block fcbb:bbbb::/32
2025/03/10 22:04:25.052257 ZEBRA: [YC52T-427SJ] srv6_manager_get_sid_internal: not got SRv6 SID for ctx End.DT6 vrf_id 4, sid_value=fcbb:bbbb:1:fe20::, locator_name=MAIN
root@rajasekarr:/tmp/topotests/static_srv6_sids.test_static_srv6_sids/r1#
Ticket :#
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
(cherry picked from commit 5a63cf4c0d1e7b84f59003877599c6575ba08a25)
|
|
- Major highlights:
- Lua 5.4 support
- Fixed CVE-2024-55553
- New match community-count BGP command to limit communities count
- New set metric igp|aigp BGP command to inject IGP metric as MED into BGP
- New bgp ipv6-auto-ra BGP command
- Optimize BGP EVPN L2VNI/L3VIN remote routes processing
- Respect non-transitive BGP extended communities between direct peers
- Drop deprecated bgp network import-check exact command
- Handle BGP ENHE (Extended Next Hop Encoding) capability via dynamic capability
- Implement BGP connect backoff retry
- Implement an ability to import BMP information from a separate BGP instance
- Add support of BGP color extended community color-only types
- Implement SBFD
- Add support for SRv6 static SIDs
- Implement embedded-rp for PIMv6
- Implement AutoRP mapping-agent for PIM
- Implement MSDP peer SA limiting
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
|
|
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
|
|
Topotest startup order (backport #18348)
|
|
Documentation typesafe (backport #18338)
|
|
Ensure that the zserv.api socket is actually up and running
before moving onto other daemons after zebra.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 009f42dd5bd02eb5ee0bd9852704357c6bc7aaa1)
|
|
Currently the topotest infrastructure is starting up daemons
in mgmtd,zebra, staticd then everything else.
The problem that is happening, under heavy load, is that
zebra may not be fully started and when a daemon attempts
to connect to it, it will not be able to connect.
Some of the daemons do not have great retry mechanisms at all.
In addition our normal systemctl startup scripts actually
wait a small amount of time for zebra to be ready before
moving onto the other daemons.
Let's make topotests startup a tiny bit more nuanced
and have mgmtd fully up before starting up zebra.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit dd609bc069857a38ff3577b76d0b9ef708b8d2aa)
|
|
Add the sbfd documentation, such as it is, to the
developer documentation so that it can be read
by people.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit f1c75deb8e6581b0c3eb2129a61c017ca1d9be99)
|
|
The building-frr-for-ubuntu2404 and building-doc were missing
from the compilation of developer documents.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 4738cb51d2019e8852887e97e9a0363ec29728a4)
|
|
Try to give some good examples of various lists being
converted over to the typesafe way of doing things.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 39909f9fb9459ce210cb44a10291a053d4fbb272)
|
|
zebra: Bring up 514 BGP neighbor sessions (backport #18214)
|
|
pimd: Fix PIM6 MLD VRF support (use recvmsg() pktinfo) (backport #18315)
|
|
When receiving MLD messages, prefer pktinfo over msghdr.msg_name for
determining the source interface. The latter is just the VRF master
interface in case of VRF and we need the true interface the packet was
received on instead.
Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
(cherry picked from commit 374c8dc4dbc8a560036fecdfb3213f690099b869)
|
|
Signed-off-by: Soumya Roy <souroy@nvidia.com>
(cherry picked from commit 10ff0d5e4cf08dacf2bf82b2350dac403633e380)
|
|
Signed-off-by: Soumya Roy <souroy@nvidia.com>
(cherry picked from commit fd80124ccab4afed32c09437986ad1347440fc81)
|
|
Issue:
When 514 inerfaces/neighbors are configured, it creates socket error,
"Cannot allocate memory", when back to back V6 RA messages are tried
to be sent over the socket. This prevents interface, to know its peer's
link local address. Socket error comes when 1) try to join ICMPv6 all
router multicast group, back to back for all interfaces 2)send back to
back RA for all interfaces
Fix:
1)For ICMPv6 join case, we check if the interface has already joined
all router group, if not try to join. On failure, retry joining after
random amount of time determined 1 ms to ICMPV6_JOIN_TIMER_EXP_MS(100 ms)
2) For RA issue case, batch sending of RA mesages using wheel timer
Testing:
Monitor BGP session running sh bgp summary command
Before fix:
r1# sh bgp summary
IPv4 Unicast Summary:
BGP router identifier 192.168.1.1, local AS number 1001 VRF default vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 515, using 12 MiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
r1-eth0 4 1002 89 90 0 0 0 00:07:10 0 0 N/A
r1-eth1 4 1002 89 90 0 0 0 00:07:10 0 0 N/A
r1-eth2 4 1002 89 90 0 0 0 00:07:10 0 0 N/A
r1-eth3 4 1002 89 90 0 0 0 00:07:10 0 0 N/A
r1-eth4 4 1002 89 90 0 0 0 00:07:10 0 0 N/A
r1-eth5 4 1002 89 90 0 0 0 00:07:10 0 0 N/A
…..<snip>...
r1-eth252 4 1002 31 29 0 0 0 00:02:08 0 0 N/A
r1-eth253 4 1002 31 29 0 0 0 00:02:08 0 0 N/A
r1-eth254 4 1002 31 29 0 0 0 00:02:08 0 0 N/A
r1-eth255 4 1002 31 29 0 0 0 00:02:08 0 0 N/A
r1-eth256 4 0 0 0 0 0 0 never Idle 0 N/A
r1-eth257 4 0 0 0 0 0 0 never Idle 0 N/A
r1-eth258 4 0 0 0 0 0 0 never Idle 0 N/A
r1-eth259 4 0 0 0 0 0 0 never Idle 0 N/A
r1-eth260 4 0 0 0 0 0 0 never Idle 0 N/A
……..<snip>…..
r1-eth511 4 0 0 0 0 0 0 never Idle 0 N/A
r1-eth512 4 0 0 0 0 0 0 never Idle 0 N/A
r1-eth513 4 0 0 0 0 0 0 never Idle 0 N/A
r1-eth514 4 0 0 0 0 0 0 never Idle 0 N/A
After fix:
r1# show bgp summary
IPv4 Unicast Summary:
BGP router identifier 192.168.1.1, local AS number 1001 VRF default vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 515, using 12 MiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
r1-eth0 4 1002 87 87 0 0 0 00:07:04 0 0 N/A
r1-eth1 4 1002 87 87 0 0 0 00:07:04 0 0 N/A
r1-eth2 4 1002 87 87 0 0 0 00:07:04 0 0 N/A
r1-eth3 4 1002 64 67 0 0 0 00:05:09 0 0 N/A
r1-eth4 4 1002 87 87 0 0 0 00:07:04 0 0 N/A
r1-eth5 4 1002 87 87 0 0 0 00:07:04 0 0 N/A
r1-eth6 4 1002 67 70 0 0 0 00:05:22 0 0 N/A
r1-eth7 4 1002 87 87 0 0 0 00:07:04 0 0 N/A
r1-eth8 4 1002 87 87 0 0 0 00:07:04 0 0 N/A
....
r1-eth499 4 1002 43 43 0 0 0 00:03:22 0 0 N/A
r1-eth500 4 1002 43 43 0 0 0 00:03:22 0 0 N/A
r1-eth501 4 1002 19 22 0 0 0 00:01:21 0 0 N/A
r1-eth502 4 1002 43 43 0 0 0 00:03:22 0 0 N/A
r1-eth503 4 1002 43 43 0 0 0 00:03:22 0 0 N/A
r1-eth504 4 1002 20 23 0 0 0 00:01:30 0 0 N/A
r1-eth505 4 1002 43 43 0 0 0 00:03:22 0 0 N/A
r1-eth506 4 1002 43 43 0 0 0 00:03:22 0 0 N/A
r1-eth507 4 1002 22 25 0 0 0 00:01:39 0 0 N/A
r1-eth508 4 1002 43 43 0 0 0 00:03:22 0 0 N/A
r1-eth509 4 1002 17 20 0 0 0 00:01:13 0 0 N/A
r1-eth510 4 1002 43 43 0 0 0 00:03:22 0 0 N/A
r1-eth511 4 1002 43 43 0 0 0 00:03:22 0 0 N/A
r1-eth512 4 1002 19 22 0 0 0 00:01:22 0 0 N/A
r1-eth513 4 1002 43 43 0 0 0 00:03:22 0 0 N/A
r1-eth514 4 1002 43 43 0 0 0 00:03:22 0 0 N/A
Signed-off-by: Soumya Roy <souroy@nvidia.com>
(cherry picked from commit 6a75d33b5cb9f5a87d71d169e24c1ae15e1bd896)
|
|
Bring in 2 northbound bug-fixes from master to 10.3
|
|
The capacity of the xpath string was not guaranteed to be sufficient to hold all
the key predicates and so would truncate. Calculate the required space and
guarantee that it is available.
Signed-off-by: Christian Hopps <chopps@labn.net>
|
|
Signed-off-by: Christian Hopps <chopps@labn.net>
|
|
tools: Fix `frr-reload.py` error related to `static-sids` (backport #18290)
|
