The remote spoke always sends a 32 prefix length to a shortcut request.
In the example, the remote spoke as the IP address 192.168.2.1/24.
spoke1# sh ip nhrp shortcut
Type Prefix Via Identity
dynamic 192.168.2.1/32 10.255.255.2
Do not deal with local routes in nhrpd. Now:
spoke1# sh ip nhrp shortcut
Type Prefix Via Identity
dynamic 192.168.2.0/24 10.255.255.2
Fixes: d4aa24ba7d ("*: Introduce Local Host Routes to FRR")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit af54901405)
This test checks the bgp crash on rt2 when 2 commands
launched consequently:
T0: rr, config -> router bgp 65004 -> neighbor 192.168.12.2 password 8888
T1: rt2, snmpwalk -v 2c -c public 127.0.0.1 .1.3.6.1.4.1.7336.4.2.1
T2: test if rt2 bgp is crashed.
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
(cherry picked from commit e23005f407)
When 'no rpki' is requested and the rtrlib RPKI object was freed, bgpd
is crashing.
RPKI is configured in VRF red.
> ip l set red down
> ip l del red
> printf 'conf\n vrf red\n no rpki' | vtysh
> Core was generated by `/usr/bin/bgpd -A 127.0.0.1 -M snmp -M rpki -M bmp'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 __pthread_kill_implementation (no_tid=0, signo=11, threadid=140411103615424) at ./nptl/pthread_kill.c:44
> 44 ./nptl/pthread_kill.c: No such file or directory.
> [Current thread is 1 (Thread 0x7fb401f419c0 (LWP 190226))]
> (gdb) bt
> #0 __pthread_kill_implementation (no_tid=0, signo=11, threadid=140411103615424) at ./nptl/pthread_kill.c:44
> #1 __pthread_kill_internal (signo=11, threadid=140411103615424) at ./nptl/pthread_kill.c:78
> #2 __GI___pthread_kill (threadid=140411103615424, signo=signo@entry=11) at ./nptl/pthread_kill.c:89
> #3 0x00007fb4021ad476 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
> #4 0x00007fb4025ce22b in core_handler (signo=11, siginfo=0x7fff831b2d70, context=0x7fff831b2c40) at lib/sigevent.c:248
> #5 <signal handler called>
> #6 rtr_mgr_remove_group (config=0x55fe8789f750, preference=11) at /build/make-pkg/output/source/DIST_RTRLIB/rtrlib/rtrlib/rtr_mgr.c:607
> #7 0x00007fb40145f518 in rpki_delete_all_cache_nodes (rpki_vrf=0x55fe8789f4f0) at bgpd/bgp_rpki.c:442
> #8 0x00007fb401463098 in no_rpki_magic (self=0x7fb40146bba0 <no_rpki_cmd>, vty=0x55fe877f5130, argc=2, argv=0x55fe877fccd0) at bgpd/bgp_rpki.c:1732
> #9 0x00007fb40145c09a in no_rpki (self=0x7fb40146bba0 <no_rpki_cmd>, vty=0x55fe877f5130, argc=2, argv=0x55fe877fccd0) at ./bgpd/bgp_rpki_clippy.c:37
> #10 0x00007fb402527abc in cmd_execute_command_real (vline=0x55fe877fd150, vty=0x55fe877f5130, cmd=0x0, up_level=0) at lib/command.c:984
> #11 0x00007fb402527c35 in cmd_execute_command (vline=0x55fe877fd150, vty=0x55fe877f5130, cmd=0x0, vtysh=0) at lib/command.c:1043
> #12 0x00007fb4025281e5 in cmd_execute (vty=0x55fe877f5130, cmd=0x55fe877fb8c0 "no rpki\n", matched=0x0, vtysh=0) at lib/command.c:1209
> #13 0x00007fb4025f0aed in vty_command (vty=0x55fe877f5130, buf=0x55fe877fb8c0 "no rpki\n") at lib/vty.c:615
> #14 0x00007fb4025f2a11 in vty_execute (vty=0x55fe877f5130) at lib/vty.c:1378
> #15 0x00007fb4025f513d in vtysh_read (thread=0x7fff831b5fa0) at lib/vty.c:2373
> #16 0x00007fb4025e9611 in event_call (thread=0x7fff831b5fa0) at lib/event.c:2011
> #17 0x00007fb402566976 in frr_run (master=0x55fe871a14a0) at lib/libfrr.c:1212
> #18 0x000055fe857829fa in main (argc=9, argv=0x7fff831b6218) at bgpd/bgp_main.c:549
Fixes: 8156765abe ("bgpd: Add `no rpki` command")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit 4e053d65f1)
A crash happens when executing the following command:
> ubuntu2204hwe# conf
> ubuntu2204hwe(config)# router bgp 65500
> ubuntu2204hwe(config-router)# !
> ubuntu2204hwe(config-router)# address-family ipv4 unicast
> ubuntu2204hwe(config-router-af)# sid vpn export auto
> ubuntu2204hwe(config-router-af)# exit-address-family
> ubuntu2204hwe(config-router)# !
> ubuntu2204hwe(config-router)# address-family ipv4 vpn
> ubuntu2204hwe(config-router-af)# network 4.4.4.4/32 rd 55:55 label 556
> ubuntu2204hwe(config-router-af)# network 5.5.5.5/32 rd 662:33 label 232
> ubuntu2204hwe(config-router-af)# exit-address-family
> ubuntu2204hwe(config-router)# exit
> ubuntu2204hwe(config)# !
> ubuntu2204hwe(config)# no router bgp
The crash analysis indicates a memory item has been freed.
> #6 0x000076066a629c15 in mt_count_free (mt=0x56b57be85e00 <MTYPE_BGP_NAME>, ptr=0x60200038b4f0)
> at lib/memory.c:73
> #7 mt_count_free (ptr=0x60200038b4f0, mt=0x56b57be85e00 <MTYPE_BGP_NAME>) at lib/memory.c:69
> #8 qfree (mt=mt@entry=0x56b57be85e00 <MTYPE_BGP_NAME>, ptr=0x60200038b4f0) at lib/memory.c:129
> #9 0x000056b57bb09ce9 in bgp_free (bgp=<optimized out>) at bgpd/bgpd.c:4120
> #10 0x000056b57bb0aa73 in bgp_unlock (bgp=<optimized out>) at ./bgpd/bgpd.h:2513
> #11 peer_free (peer=0x62a000000200) at bgpd/bgpd.c:1313
> #12 0x000056b57bb0aca8 in peer_unlock_with_caller (name=<optimized out>, peer=<optimized out>)
> at bgpd/bgpd.c:1344
> #13 0x000076066a6dbb2c in event_call (thread=thread@entry=0x7ffc8cae1d60) at lib/event.c:2011
> #14 0x000076066a60aa88 in frr_run (master=0x613000000040) at lib/libfrr.c:1214
> #15 0x000056b57b8b2c44 in main (argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_main.c:543
Actually, the BGP_NAME item has not been used at allocation for
static->prd_pretty, and this results in reaching 0 quicker at bgp
deletion.
Fix this by reassigning MTYPE_BGP_NAME to prd_pretty.
Fixes: 16600df2c4 ("bgpd: fix show run of network route-distinguisher")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit 64594f8a68)
When a whole distribute-list is deleted (can be done only using API),
all its children must be cleaned up manually.
Fixes#16538
Signed-off-by: Igor Ryzhov <idryzhov@gmail.com>
(cherry picked from commit 8fad4f317e)
The adj_process_threeway() api may call the adj_state_change()
api, which may delete the adj struct being examined. Change the
signature so that callers pass a ptr-to-ptr so that they will
see that deletion.
Signed-off-by: Mark Stapp <mjs@cisco.com>
(cherry picked from commit 3eb7d16411)
The function zebra_nhg_hash_equal is only used
as a hash function for storage of NHG's and retrieval.
If you have say two nhg's:
31 (25/26)
32 (25/26)
This function would return them as being equal. Which
of course leads to the problem when you attempt to
hash_release 32 but release 31 from the hash. Then later
when you attempt to do hash comparisons 32 has actually
been freed leaving to use after free situations and shit
goes down hill fast.
This hash is only used as part of the hash comparison
function for nexthop group storage. Since this is so
let's always return the 31/32 nhg's are not equal at all.
We possibly have a different problem where we are creating
31 and 32 ( when 31 should have just been used instead of 32 )
but we need to prevent any type of hash release problem at all.
This supercedes any other issue( that should be tracked down
on it's own ). Since you can have use after free situation
that leads to a crash -vs- some possible nexthop group duplication
which is very minor in comparison.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 5a1b61aeba)
When mgmt reads configuration from file, it shouldn't add implicit state
data to the candidate datastore. Configuration datastores like candidate
should never store state, otherwise they fail validation.
Fixes#15814
Signed-off-by: Igor Ryzhov <idryzhov@gmail.com>
(cherry picked from commit 61e8d5e0b9)
CLI show callbacks should be defined in frr_ripd_cli_info instead of
frr_ripd_info, because only the former is loaded by mgmtd and only its
callbacks are getting called for config output.
Signed-off-by: Igor Ryzhov <idryzhov@gmail.com>
(cherry picked from commit 25d94ec3ee)
The destroy callback must be executed only once on APPLY stage.
Fixes#16528
Signed-off-by: Igor Ryzhov <idryzhov@gmail.com>
(cherry picked from commit 2b12d62e38)
Release Overview:
* Breaking changes
- Enable BGP dynamic capability by default for datacenter profile
- Split BGP `rpki cache` command into separate per SSH/TCP
- Add deprecation cycle for OSPF `router-info X [A.B.C.D]` command
* Features
- BGP dampening per-neighbor support
- BMP send-experimental stats
- Implement extended link-bandwidth for BGP
- Paths Limit for Multiple Paths in BGP
- New command for OSPFv2 `ip ospf neighbor-filter NAME [A.B.C.D]`
- Implement non-broadcast support for point-to-multipoint networks
* Other significant changes
bgpd
- Fix route leaking from the default l3vrf
- Fix `match peer` when switching between IPv4/IPv6/interface
- Fix dynamic peer graceful restart race condition
- Fix colored routes not installed after a switchover
- Fix crash when deleting the SRv6 locator
- Fix `no set as-path prepend ASNUM...`
- Fix negative commands for Graceful-Restart operations
- Fix ipv4-mapped ipv6 on non 6pe
- Fix show run of network route-distinguisher
- Fix display when using `missing-as-worst`
- Fix `show bgp neighbors` output
- Fix error handling for MP/GR capabilities as a dynamic capability
- Fix error handling when receiving BGP Prefix-SID attribute
- Fix route-target display with a dotted format
- Fix `no bgp as-path access-list`
- Fix `no` form for `neighbor X capability software-version`
- Check against extended community unit size for link bandwidth
- Make sure we have enough data to handle extended link bandwidth
- Check if FQDN capability length is in valid ranges
- Allow using different ASNs per VRF instances
- Send End-of-RIB not only if Graceful-Restart capability is received
- Implement backpressure to avoid CPU hog
- Ignore validating the attribute flags if path-attribute is configured
- Prevent deletion of BGP peer groups associated with `bgp listen range`
- Inherit some peer flags from the peer-group
- Allow specification of AS 0 for RPKI commands
- Allow using `maximum-prefix` for EVPN
- Increase install/uninstall speed of EVPN VNIs
- Update default-originate route-map actual map structure
- Include `unsuppress-map` as a valid outgoing eBGP policy
- Allow dynamically disable graceful-restart/long-lived graceful-restart
- Unset advertised capabilities if the capability is disabled
- Aggregated summary-only remove suppressed from EVPN
isisd
- Fix crash when deactivating ISIS adjacency on the interface
- Fix `show isis database [detail] json`
- Fix `show isis algorithm`
- Fix crash when configuring the circuit type for the interface
- Fix IP/IPv6 reachability TLVs
- When the metric-type is configured as "wide", the IS-IS generates
incorrect metric values for IPv4 directly connected routes
- Add link state support for SRv6 adjacencies
- The hold time of hello packets on a P2P link does not match the
sending interval
mgmtd
- Implement YANG RPC/action support
ospfd
- Fix crash in OSPF TE parsing
- Fix the bug where ip_ospf_dead-interval_minimal_hello-multiplier did
not reset the hello timer
- Fix `no write-multiplier` command
- Fix `no maximum-paths` command
- Solved crash in RI parsing with OSPF TE
- Assure OSPF AS External routes are installed after the link flap
- Send LS Updates in response to LS Request as unicast
ospf6d
- Handle topo change in Graceful-Restart Helper mode for max-age LSAs
- Prevent heap-buffer-overflow with an unknown type
- Redistribute metric for AS-external route
- Fix next-hop computation for inter-area multi-ABR ECMP
- Fix interface type vs. connected routes updates
pathd
- Retry synchronous label-manager ZAPI connection
pimd
- Fix null register before aging out reg-stop
- Fix dr-priority range
- Fix crash unconfiguring rp keepalive timer
lib
- Fix keychain NB crash
- Do not convert EVPN prefixes into IPv4/IPv6 if not needed
ripd
- Fix `clear ip rip` command
ripngd
- Fix `clear ipv6 ripng` command
tools
- Handle seq num for BGP as-path in frr-reload.py
vtysh
- Fix 'show ip[v6] prefix-list ... json' formatting by moving it to vtysh
- Fix `show route-map` command when calling via `do`
- Show `ip ospf network ...` even if it's not the same as the interface type
zebra
- Fix `mpls label bind` command
- Fix excessive `exit` commands
- Fix static SRv6 segment-list SID order
- Fix JSON output for `show route summary json`
- Fix malformed json output for multiple vrfs in command
`show ip route vrf all json`
- Fix crash if MAC-VLAN link in another netns
- Fix crash on MAC-VLAN link down/up
- Deny the routes if ip protocol CLI refers to an undefined route-map
- Bridge flap handle VLAN membership update
- Add `show fpm status [json]` command
Fixes the crash:
```
(gdb) bt
0 __pthread_kill_implementation (no_tid=0, signo=11, threadid=124583315603008) at ./nptl/pthread_kill.c:44
1 __pthread_kill_internal (signo=11, threadid=124583315603008) at ./nptl/pthread_kill.c:78
2 __GI___pthread_kill (threadid=124583315603008, signo=signo@entry=11) at ./nptl/pthread_kill.c:89
3 0x0000714ed0242476 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
4 0x0000714ed074cfb7 in core_handler (signo=11, siginfo=0x7ffe6d9792b0, context=0x7ffe6d979180) at lib/sigevent.c:258
5 <signal handler called>
6 0x000060f55e33ffdd in route_table_get_info (table=0x0) at ./lib/table.h:177
7 0x000060f55e340053 in bgp_dest_table (dest=0x60f56dabb840) at ./bgpd/bgp_table.h:156
8 0x000060f55e340c9f in is_route_injectable_into_vpn (pi=0x60f56dbc4a60) at ./bgpd/bgp_mplsvpn.h:331
9 0x000060f55e34507c in vpn_leak_from_vrf_update (to_bgp=0x60f56da52070, from_bgp=0x60f56da75af0, path_vrf=0x60f56dbc4a60) at bgpd/bgp_mplsvpn.c:1575
10 0x000060f55e346657 in vpn_leak_from_vrf_update_all (to_bgp=0x60f56da52070, from_bgp=0x60f56da75af0, afi=AFI_IP) at bgpd/bgp_mplsvpn.c:2028
11 0x000060f55e340c10 in vpn_leak_postchange (direction=BGP_VPN_POLICY_DIR_TOVPN, afi=AFI_IP, bgp_vpn=0x60f56da52070, bgp_vrf=0x60f56da75af0) at ./bgpd/bgp_mplsvpn.h:310
12 0x000060f55e34a692 in vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:3737
13 0x000060f55e3d91fc in router_bgp (self=0x60f55e5cbc20 <router_bgp_cmd>, vty=0x60f56e2d7660, argc=3, argv=0x60f56da19830) at bgpd/bgp_vty.c:1601
14 0x0000714ed069ddf5 in cmd_execute_command_real (vline=0x60f56da32a80, vty=0x60f56e2d7660, cmd=0x0, up_level=0) at lib/command.c:1002
15 0x0000714ed069df6e in cmd_execute_command (vline=0x60f56da32a80, vty=0x60f56e2d7660, cmd=0x0, vtysh=0) at lib/command.c:1061
16 0x0000714ed069e51e in cmd_execute (vty=0x60f56e2d7660, cmd=0x60f56dbf07d0 "router bgp 100\n", matched=0x0, vtysh=0) at lib/command.c:1227
17 0x0000714ed076faa0 in vty_command (vty=0x60f56e2d7660, buf=0x60f56dbf07d0 "router bgp 100\n") at lib/vty.c:616
18 0x0000714ed07719c4 in vty_execute (vty=0x60f56e2d7660) at lib/vty.c:1379
19 0x0000714ed07740f0 in vtysh_read (thread=0x7ffe6d97c700) at lib/vty.c:2374
20 0x0000714ed07685c4 in event_call (thread=0x7ffe6d97c700) at lib/event.c:1995
21 0x0000714ed06e3351 in frr_run (master=0x60f56d1d2e40) at lib/libfrr.c:1232
22 0x000060f55e2c4b44 in main (argc=7, argv=0x7ffe6d97c978) at bgpd/bgp_main.c:555
(gdb)
```
Fixes https://github.com/FRRouting/frr/issues/16484
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 04f9372409)
In scaled EVPN + ipv4/ipv6 uni route sync to zebra,
some of the ipv4/ipv6 routes skipped reinstallation
due to incorrect local variable's stale value.
Once the local variable value reset in each loop
iteration all skipped routes synced to zebra properly.
Ticket: #3948828
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
Signed-off-by: Chirag Shah <chirag@nvidia.com>
The return value of evpn_route_select_install is ignored in all cases
except during vni route table install/uninstall and based on the
returned value, an error is logged. Fixing this.
Ticket :#3992392
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
The code is clearly incorrect. After consultation with
the original author this is the decided change.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit c4b4c242ec)
Correct FRR startup counts on a daemon's vty socket to be open when the
parent process exits. The parent process waits for `frr_check_detach()`
to be called by the child before exiting. The problem is when the
`FRR_MANUAL_VTY_START` flag is set the vty socket was not opened but
`frr_check_detach()` was called anyway.
Instead add a bool option for `frr_check_detach()` to be called when the
socket is opened with `frr_vty_serv_start()`, and do so when "manually"
calling said function (i.e., when FRR_MANUAL_VTY_START is set).
The `FRR_MANUAL_VTY_START` flag is only set by mgmtd. The reason we
wait to open the vty socket is so that mgmtd can parse the various
daemon specific config files it has taken over, after the event loop has
started, but before we receive any possible new config from `vtysh`.
fixes#16362
Signed-off-by: Christian Hopps <chopps@labn.net>
(cherry picked from commit be9a6fc0ea)
