tests: Use igpMetric as 10 not 20, after OSPFv3 loopback cost changes

Fixes: fa3140f7927838c432a02ee4f1c1847387b7be6d ("ospf6d: Set loopback interface cost to 0")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit d7e97146439db054653c0fa12290a67c9bea3b80)

ospf6d: Set loopback interface cost to 0

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 80dfa9e012ebdb3e88cbd6de3101ae6dd9109ad2)

tests: Check if OSPFv3 loopback interface gets cost as 0

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit e8615867d08f0c79096c1270695fa5c52d689a87)

Merge pull request #14677 from FRRouting/mergify/bp/dev/9.1/pr-14665

pbrd: fix show pbr map detail json (backport #14665)

doc: fix pbr map detail json

Fix the documentation for the pbr map command with
correct syntax.

Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit df3d91f0851d551cc481599c1fa1a1dc5a29cd92)

pbrd: fix show pbr map detail json

'detail' and 'josn' keyword is given as an optional parameter
for cli arguments. Hence 'detail' keyword was consider as a
pbr 'name' for "show pbr map detail json" command.

Before Fix:

```
cumulus#
cumulus# show pbr map detail json
[
]
cumulus#
```

After Fix:
```
cumulus# show pbr map detail json
[
  {
    "name":"MAP1",
    "valid":false,
    "policies":[
      {
        "id":1,
        "sequenceNumber":10,
        "ruleNumber":309,
        "vrfUnchanged":false,
        "installed":false,
        "installedReason":"Invalid Src or Dst",
        "vrfName":"default"
      }
    ]
  }
]
cumulus#
```

Ticket:#3638600

Issue:3638600

Testing: UT done

Signed-off-by: Sindhu Parvathi Gopinathan's <sgopinathan@nvidia.com>
(cherry picked from commit d621c365a65f825adfbc00128360390d0b2bd5be)

Merge pull request #14667 from FRRouting/mergify/bp/dev/9.1/pr-14664

isisd: staticd: need to link directly against libyang (backport #14664)

Merge pull request #14672 from FRRouting/mergify/bp/dev/9.1/pr-14663

tests: have unit-test check more paths for the grpc.so module (backport #14663)

tests: have unit-test check more paths for the grpc.so module

Signed-off-by: Christian Hopps <chopps@labn.net>
(cherry picked from commit 8e630c29465a44761814f61b56c6d00878c4919e)

isisd: staticd: need to link directly against libyang

Signed-off-by: Christian Hopps <chopps@labn.net>
(cherry picked from commit 81d1d399521bb18f3fdd5353c9d58c4b3988f225)

Merge pull request #14653 from FRRouting/mergify/bp/dev/9.1/pr-14645

bgpd: A couple more bgpd crashes on malformed attributes (backport #14645)

bgpd: Check mandatory attributes more carefully for UPDATE message

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 d8482bf011cb2b173e85b65b4bf3d5061250cdb9)

bgpd: Handle MP_REACH_NLRI malformed packets with session reset

Avoid crashing bgpd.

```
(gdb)
bgp_mp_reach_parse (args=<optimized out>, mp_update=0x7fffffffe140) at bgpd/bgp_attr.c:2341
2341 stream_get(&attr->mp_nexthop_global, s, IPV6_MAX_BYTELEN);
(gdb)
stream_get (dst=0x7fffffffe1ac, s=0x7ffff0006e80, size=16) at lib/stream.c:320
320 {
(gdb)
321 STREAM_VERIFY_SANE(s);
(gdb)
323 if (STREAM_READABLE(s) < size) {
(gdb)
34   return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
(gdb)

Thread 1 "bgpd" received signal SIGSEGV, Segmentation fault.
0x00005555556e37be in route_set_aspath_prepend (rule=0x555555aac0d0, prefix=0x7fffffffe050,
    object=0x7fffffffdb00) at bgpd/bgp_routemap.c:2282
2282 if (path->attr->aspath->refcnt)
(gdb)
```

With the configuration:

```
 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
  redistribute connected
  neighbor 127.0.0.1 default-originate
  neighbor 127.0.0.1 route-map RM_IN in
 exit-address-family
!
route-map RM_IN permit 10
 set as-path prepend 200
exit
```

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit b08afc81c60607a4f736f418f2e3eb06087f1a35)

Merge pull request #14637 from FRRouting/mergify/bp/dev/9.1/pr-14628

bgpd: Do not suppress conditional advertisement updates if triggered (backport #14628)

tests: Check if BGP conditional advertisement works fine with static routes

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 3c9415125818b54416bd89b9f703f987ff91746c)

bgpd: Do not suppress conditional advertisement updates if triggered

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 2d8e85958526493f59e7cb9bf6dac829ed3d687f)

Merge pull request #14624 from FRRouting/mergify/bp/dev/9.1/pr-14618

watchfrr: Extend ignore option to daemon being killed (backport #14618)

Merge pull request #14621 from FRRouting/mergify/bp/dev/9.1/pr-14616

doc: add "enforce-first-as" to BGP documentation (backport #14616)

watchfrr: Extend ignore option to daemon being killed

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 c168244b9910bccafcb78bf1bb96a6fd569c6302)

doc: add "enforce-first-as" to BGP doc

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 3acc6ae932caf0e3c1eca3e2369230d300721a8b)

Merge pull request #14611 from FRRouting/mergify/bp/dev/9.1/pr-14607

pim6d: valgrind issue fixes (backport #14607)

pim6d: valgrind issue fixes

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 1064818645339d09ecfd79c95d4ff2ac330b1147)

Merge pull request #14601 from FRRouting/mergify/bp/dev/9.1/pr-14582

tests: Add OSPF test for issue 14488 (backport #14582)

tests: Add OSPF test for issue 14488

OSPF on IPv4/IPv6 removes the wrong routes in certain cases, causing
issues when removing and re-enabling interfaces. This test proofs that.

These tests all pass with https://github.com/FRRouting/frr/pull/13340
and the latest master (d2324b7b4a02e9ef6a219578567932addeb7f593).

See https://github.com/FRRouting/frr/issues/14488

Signed-off-by: Denis Krienbühl <denis.krienbuehl@cloudscale.ch>
(cherry picked from commit 616e1fa9df13cf2f269fdfb70b9bae7cd592fc4e)

Merge pull request #14595 from FRRouting/mergify/bp/dev/9.1/pr-14590

ospf6d: fix setting of the forwarding address in AS-External LSAs (backport #14590)

ospf6d: fix setting of the forwarding address in AS-External LSAs

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 331ae6accc9737324e7a050033971c2f402c8933)

Merge pull request #14591 from FRRouting/mergify/bp/dev/9.1/pr-14583

bgpd: ecommunity_dup memory leak fix (backport #14583)

Merge pull request #14581 from FRRouting/mergify/bp/dev/9.1/pr-14577

zebra: add xxxCHAIN netlink messages to handler, ignore (backport #14577)

Merge pull request #14593 from FRRouting/mergify/bp/dev/9.1/pr-14584

zebra: add label chunk range in log when label manager request fails (backport #14584)

Merge pull request #14589 from FRRouting/mergify/bp/dev/9.1/pr-13340

zebra: Fix connected route deletion when multiple entry exists (backport #13340)

zebra: add label chunk range in log when label manager request fails

When the label manager is unable to provide a label chunk to
a routing service, an error message is displayed:

> Oct 11 11:47:27 vsr zebra[163745]: [YMY6E-K9JYD][EC 4043309085] Unable to assign Label Chunk to bgp instance 0

There is missing information on the range that was requested.
Add this information in the log message.

> Oct 11 11:47:27 vsr zebra[163745]: [YMY6E-K9JYD][EC 4043309085] Unable to assign Label Chunk 60 - 60 to bgp instance 0

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit 1cedcf7b15ee72fe859189bf772081a141fb50e6)

zebra: merge lm_get_chunk_response() function

This function lm_get_chunk_response() is only called
by label_manager_get_chunk(). Let us move the code of
the function in the caller.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit 69886228326443941a65f87e7ee6fb42323f825b)

bgpd: Ecommunity_dup memory leak fix

The shallow copy of attr wasn't freed when there was no valid label for the momentand the function return therefore creating leaks. The leak below are solved by flushing the shallow copy of attr.

Address Sanitizer Error detected in bgp_vpnv6_per_nexthop_label.test_bgp_vpnv6_per_nexthop_label/r1.asan.bgpd.13409
=================================================================
==13409==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 280 byte(s) in 7 object(s) allocated from:
    #0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
    #1 0x7f62ccac21c3 in qcalloc lib/memory.c:105
    #2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
    #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x5623b88c13b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005
    #5 0x5623b89beabc in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287
    #6 0x5623b89beabc in af_label_vpn_export_allocation_mode_magic bgpd/bgp_vty.c:9464
    #7 0x5623b89beabc in af_label_vpn_export_allocation_mode bgpd/bgp_vty_clippy.c:2809
    #8 0x7f62cca45511 in cmd_execute_command_real lib/command.c:978
    #9 0x7f62cca459d5 in cmd_execute_command lib/command.c:1036
    #10 0x7f62cca45e54 in cmd_execute lib/command.c:1203
    #11 0x7f62ccb6ee20 in vty_command lib/vty.c:591
    #12 0x7f62ccb6f2cb in vty_execute lib/vty.c:1354
    #13 0x7f62ccb77b95 in vtysh_read lib/vty.c:2362
    #14 0x7f62ccb62b8f in event_call lib/event.c:1969
    #15 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
    #16 0x5623b87e054b in main bgpd/bgp_main.c:510
    #17 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Direct leak of 280 byte(s) in 7 object(s) allocated from:
    #0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
    #1 0x7f62ccac21c3 in qcalloc lib/memory.c:105
    #2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
    #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x5623b892e86d in bgp_update bgpd/bgp_route.c:4969
    #5 0x5623b893134d in bgp_nlri_parse_ip bgpd/bgp_route.c:6213
    #6 0x5623b88e2a0e in bgp_nlri_parse bgpd/bgp_packet.c:341
    #7 0x5623b88e4f7c in bgp_update_receive bgpd/bgp_packet.c:2220
    #8 0x5623b88f0474 in bgp_process_packet bgpd/bgp_packet.c:3386
    #9 0x7f62ccb62b8f in event_call lib/event.c:1969
    #10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
    #11 0x5623b87e054b in main bgpd/bgp_main.c:510
    #12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Direct leak of 280 byte(s) in 7 object(s) allocated from:
    #0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
    #1 0x7f62ccac21c3 in qcalloc lib/memory.c:105
    #2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
    #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x5623b88c13b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005
    #5 0x5623b89bdebb in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287
    #6 0x5623b89bdebb in af_label_vpn_export_magic bgpd/bgp_vty.c:9547
    #7 0x5623b89bdebb in af_label_vpn_export bgpd/bgp_vty_clippy.c:2868
    #8 0x7f62cca45511 in cmd_execute_command_real lib/command.c:978
    #9 0x7f62cca459d5 in cmd_execute_command lib/command.c:1036
    #10 0x7f62cca45e54 in cmd_execute lib/command.c:1203
    #11 0x7f62ccb6ee20 in vty_command lib/vty.c:591
    #12 0x7f62ccb6f2cb in vty_execute lib/vty.c:1354
    #13 0x7f62ccb77b95 in vtysh_read lib/vty.c:2362
    #14 0x7f62ccb62b8f in event_call lib/event.c:1969
    #15 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
    #16 0x5623b87e054b in main bgpd/bgp_main.c:510
    #17 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Direct leak of 240 byte(s) in 6 object(s) allocated from:
    #0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
    #1 0x7f62ccac21c3 in qcalloc lib/memory.c:105
    #2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
    #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x5623b88dc289 in evaluate_paths bgpd/bgp_nht.c:1384
    #5 0x5623b88ddb0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733
    #6 0x5623b88de027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934
    #7 0x5623b8a03163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104
    #8 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425
    #9 0x7f62ccb62b8f in event_call lib/event.c:1969
    #10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
    #11 0x5623b87e054b in main bgpd/bgp_main.c:510
    #12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Direct leak of 120 byte(s) in 3 object(s) allocated from:
    #0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
    #1 0x7f62ccac21c3 in qcalloc lib/memory.c:105
    #2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
    #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x5623b893a406 in bgp_redistribute_add bgpd/bgp_route.c:8692
    #5 0x5623b8a02b3b in zebra_read_route bgpd/bgp_zebra.c:595
    #6 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425
    #7 0x7f62ccb62b8f in event_call lib/event.c:1969
    #8 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
    #9 0x5623b87e054b in main bgpd/bgp_main.c:510
    #10 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Direct leak of 80 byte(s) in 2 object(s) allocated from:
    #0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
    #1 0x7f62ccac21c3 in qcalloc lib/memory.c:105
    #2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
    #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x5623b88dc188 in evaluate_paths bgpd/bgp_nht.c:1348
    #5 0x5623b88ddb0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733
    #6 0x5623b88de027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934
    #7 0x5623b8a03163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104
    #8 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425
    #9 0x7f62ccb62b8f in event_call lib/event.c:1969
    #10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
    #11 0x5623b87e054b in main bgpd/bgp_main.c:510
    #12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Indirect leak of 56 byte(s) in 7 object(s) allocated from:
    #0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
    #1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100
    #2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
    #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x5623b88c13b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005
    #5 0x5623b89beabc in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287
    #6 0x5623b89beabc in af_label_vpn_export_allocation_mode_magic bgpd/bgp_vty.c:9464
    #7 0x5623b89beabc in af_label_vpn_export_allocation_mode bgpd/bgp_vty_clippy.c:2809
    #8 0x7f62cca45511 in cmd_execute_command_real lib/command.c:978
    #9 0x7f62cca459d5 in cmd_execute_command lib/command.c:1036
    #10 0x7f62cca45e54 in cmd_execute lib/command.c:1203
    #11 0x7f62ccb6ee20 in vty_command lib/vty.c:591
    #12 0x7f62ccb6f2cb in vty_execute lib/vty.c:1354
    #13 0x7f62ccb77b95 in vtysh_read lib/vty.c:2362
    #14 0x7f62ccb62b8f in event_call lib/event.c:1969
    #15 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
    #16 0x5623b87e054b in main bgpd/bgp_main.c:510
    #17 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Indirect leak of 56 byte(s) in 7 object(s) allocated from:
    #0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
    #1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100
    #2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
    #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x5623b892e86d in bgp_update bgpd/bgp_route.c:4969
    #5 0x5623b893134d in bgp_nlri_parse_ip bgpd/bgp_route.c:6213
    #6 0x5623b88e2a0e in bgp_nlri_parse bgpd/bgp_packet.c:341
    #7 0x5623b88e4f7c in bgp_update_receive bgpd/bgp_packet.c:2220
    #8 0x5623b88f0474 in bgp_process_packet bgpd/bgp_packet.c:3386
    #9 0x7f62ccb62b8f in event_call lib/event.c:1969
    #10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
    #11 0x5623b87e054b in main bgpd/bgp_main.c:510
    #12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Indirect leak of 56 byte(s) in 7 object(s) allocated from:
    #0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
    #1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100
    #2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
    #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x5623b88c13b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005
    #5 0x5623b89bdebb in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287
    #6 0x5623b89bdebb in af_label_vpn_export_magic bgpd/bgp_vty.c:9547
    #7 0x5623b89bdebb in af_label_vpn_export bgpd/bgp_vty_clippy.c:2868
    #8 0x7f62cca45511 in cmd_execute_command_real lib/command.c:978
    #9 0x7f62cca459d5 in cmd_execute_command lib/command.c:1036
    #10 0x7f62cca45e54 in cmd_execute lib/command.c:1203
    #11 0x7f62ccb6ee20 in vty_command lib/vty.c:591
    #12 0x7f62ccb6f2cb in vty_execute lib/vty.c:1354
    #13 0x7f62ccb77b95 in vtysh_read lib/vty.c:2362
    #14 0x7f62ccb62b8f in event_call lib/event.c:1969
    #15 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
    #16 0x5623b87e054b in main bgpd/bgp_main.c:510
    #17 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Indirect leak of 48 byte(s) in 6 object(s) allocated from:
    #0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
    #1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100
    #2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
    #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x5623b88dc289 in evaluate_paths bgpd/bgp_nht.c:1384
    #5 0x5623b88ddb0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733
    #6 0x5623b88de027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934
    #7 0x5623b8a03163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104
    #8 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425
    #9 0x7f62ccb62b8f in event_call lib/event.c:1969
    #10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
    #11 0x5623b87e054b in main bgpd/bgp_main.c:510
    #12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Indirect leak of 24 byte(s) in 3 object(s) allocated from:
    #0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
    #1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100
    #2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
    #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x5623b893a406 in bgp_redistribute_add bgpd/bgp_route.c:8692
    #5 0x5623b8a02b3b in zebra_read_route bgpd/bgp_zebra.c:595
    #6 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425
    #7 0x7f62ccb62b8f in event_call lib/event.c:1969
    #8 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
    #9 0x5623b87e054b in main bgpd/bgp_main.c:510
    #10 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Indirect leak of 16 byte(s) in 2 object(s) allocated from:
    #0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
    #1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100
    #2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
    #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x5623b88dc188 in evaluate_paths bgpd/bgp_nht.c:1348
    #5 0x5623b88ddb0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733
    #6 0x5623b88de027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934
    #7 0x5623b8a03163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104
    #8 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425
    #9 0x7f62ccb62b8f in event_call lib/event.c:1969
    #10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
    #11 0x5623b87e054b in main bgpd/bgp_main.c:510
    #12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

SUMMARY: AddressSanitizer: 1536 byte(s) leaked in 64 allocation(s).
***********************************************************************************

Address Sanitizer Error detected in bgp_vpnv4_per_nexthop_label.test_bgp_vpnv4_per_nexthop_label/r1.asan.bgpd.10610

=================================================================
==10610==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 280 byte(s) in 7 object(s) allocated from:
    #0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
    #1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105
    #2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
    #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x55cdc9c4686d in bgp_update bgpd/bgp_route.c:4969
    #5 0x55cdc9c4934d in bgp_nlri_parse_ip bgpd/bgp_route.c:6213
    #6 0x55cdc9bfaa0e in bgp_nlri_parse bgpd/bgp_packet.c:341
    #7 0x55cdc9bfcf7c in bgp_update_receive bgpd/bgp_packet.c:2220
    #8 0x55cdc9c08474 in bgp_process_packet bgpd/bgp_packet.c:3386
    #9 0x7f81fbffbb8f in event_call lib/event.c:1969
    #10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
    #11 0x55cdc9af854b in main bgpd/bgp_main.c:510
    #12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Direct leak of 280 byte(s) in 7 object(s) allocated from:
    #0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
    #1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105
    #2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
    #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005
    #5 0x55cdc9cd6abc in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287
    #6 0x55cdc9cd6abc in af_label_vpn_export_allocation_mode_magic bgpd/bgp_vty.c:9464
    #7 0x55cdc9cd6abc in af_label_vpn_export_allocation_mode bgpd/bgp_vty_clippy.c:2809
    #8 0x7f81fbede511 in cmd_execute_command_real lib/command.c:978
    #9 0x7f81fbede9d5 in cmd_execute_command lib/command.c:1036
    #10 0x7f81fbedee54 in cmd_execute lib/command.c:1203
    #11 0x7f81fc007e20 in vty_command lib/vty.c:591
    #12 0x7f81fc0082cb in vty_execute lib/vty.c:1354
    #13 0x7f81fc010b95 in vtysh_read lib/vty.c:2362
    #14 0x7f81fbffbb8f in event_call lib/event.c:1969
    #15 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
    #16 0x55cdc9af854b in main bgpd/bgp_main.c:510
    #17 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Direct leak of 280 byte(s) in 7 object(s) allocated from:
    #0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
    #1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105
    #2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
    #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005
    #5 0x55cdc9cd5ebb in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287
    #6 0x55cdc9cd5ebb in af_label_vpn_export_magic bgpd/bgp_vty.c:9547
    #7 0x55cdc9cd5ebb in af_label_vpn_export bgpd/bgp_vty_clippy.c:2868
    #8 0x7f81fbede511 in cmd_execute_command_real lib/command.c:978
    #9 0x7f81fbede9d5 in cmd_execute_command lib/command.c:1036
    #10 0x7f81fbedee54 in cmd_execute lib/command.c:1203
    #11 0x7f81fc007e20 in vty_command lib/vty.c:591
    #12 0x7f81fc0082cb in vty_execute lib/vty.c:1354
    #13 0x7f81fc010b95 in vtysh_read lib/vty.c:2362
    #14 0x7f81fbffbb8f in event_call lib/event.c:1969
    #15 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
    #16 0x55cdc9af854b in main bgpd/bgp_main.c:510
    #17 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Direct leak of 240 byte(s) in 6 object(s) allocated from:
    #0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
    #1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105
    #2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
    #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x55cdc9bf4289 in evaluate_paths bgpd/bgp_nht.c:1384
    #5 0x55cdc9bf5b0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733
    #6 0x55cdc9bf6027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934
    #7 0x55cdc9d1b163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104
    #8 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425
    #9 0x7f81fbffbb8f in event_call lib/event.c:1969
    #10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
    #11 0x55cdc9af854b in main bgpd/bgp_main.c:510
    #12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Direct leak of 80 byte(s) in 2 object(s) allocated from:
    #0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
    #1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105
    #2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
    #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x55cdc9bf4188 in evaluate_paths bgpd/bgp_nht.c:1348
    #5 0x55cdc9bf5b0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733
    #6 0x55cdc9bf6027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934
    #7 0x55cdc9d1b163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104
    #8 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425
    #9 0x7f81fbffbb8f in event_call lib/event.c:1969
    #10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
    #11 0x55cdc9af854b in main bgpd/bgp_main.c:510
    #12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Direct leak of 80 byte(s) in 2 object(s) allocated from:
    #0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
    #1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105
    #2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
    #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005
    #5 0x55cdc9bdafd5 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287
    #6 0x55cdc9bdafd5 in vpn_leak_label_callback bgpd/bgp_mplsvpn.c:581
    #7 0x55cdc9bb2606 in lp_cbq_docallback bgpd/bgp_labelpool.c:118
    #8 0x7f81fc0164b5 in work_queue_run lib/workqueue.c:266
    #9 0x7f81fbffbb8f in event_call lib/event.c:1969
    #10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
    #11 0x55cdc9af854b in main bgpd/bgp_main.c:510
    #12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Direct leak of 40 byte(s) in 1 object(s) allocated from:
    #0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
    #1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105
    #2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
    #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x55cdc9c52406 in bgp_redistribute_add bgpd/bgp_route.c:8692
    #5 0x55cdc9d1ab3b in zebra_read_route bgpd/bgp_zebra.c:595
    #6 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425
    #7 0x7f81fbffbb8f in event_call lib/event.c:1969
    #8 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
    #9 0x55cdc9af854b in main bgpd/bgp_main.c:510
    #10 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Indirect leak of 56 byte(s) in 7 object(s) allocated from:
    #0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
    #1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100
    #2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
    #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005
    #5 0x55cdc9cd6abc in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287
    #6 0x55cdc9cd6abc in af_label_vpn_export_allocation_mode_magic bgpd/bgp_vty.c:9464
    #7 0x55cdc9cd6abc in af_label_vpn_export_allocation_mode bgpd/bgp_vty_clippy.c:2809
    #8 0x7f81fbede511 in cmd_execute_command_real lib/command.c:978
    #9 0x7f81fbede9d5 in cmd_execute_command lib/command.c:1036
    #10 0x7f81fbedee54 in cmd_execute lib/command.c:1203
    #11 0x7f81fc007e20 in vty_command lib/vty.c:591
    #12 0x7f81fc0082cb in vty_execute lib/vty.c:1354
    #13 0x7f81fc010b95 in vtysh_read lib/vty.c:2362
    #14 0x7f81fbffbb8f in event_call lib/event.c:1969
    #15 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
    #16 0x55cdc9af854b in main bgpd/bgp_main.c:510
    #17 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Indirect leak of 56 byte(s) in 7 object(s) allocated from:
    #0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
    #1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100
    #2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
    #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005
    #5 0x55cdc9cd5ebb in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287
    #6 0x55cdc9cd5ebb in af_label_vpn_export_magic bgpd/bgp_vty.c:9547
    #7 0x55cdc9cd5ebb in af_label_vpn_export bgpd/bgp_vty_clippy.c:2868
    #8 0x7f81fbede511 in cmd_execute_command_real lib/command.c:978
    #9 0x7f81fbede9d5 in cmd_execute_command lib/command.c:1036
    #10 0x7f81fbedee54 in cmd_execute lib/command.c:1203
    #11 0x7f81fc007e20 in vty_command lib/vty.c:591
    #12 0x7f81fc0082cb in vty_execute lib/vty.c:1354
    #13 0x7f81fc010b95 in vtysh_read lib/vty.c:2362
    #14 0x7f81fbffbb8f in event_call lib/event.c:1969
    #15 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
    #16 0x55cdc9af854b in main bgpd/bgp_main.c:510
    #17 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Indirect leak of 56 byte(s) in 7 object(s) allocated from:
    #0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
    #1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100
    #2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
    #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x55cdc9c4686d in bgp_update bgpd/bgp_route.c:4969
    #5 0x55cdc9c4934d in bgp_nlri_parse_ip bgpd/bgp_route.c:6213
    #6 0x55cdc9bfaa0e in bgp_nlri_parse bgpd/bgp_packet.c:341
    #7 0x55cdc9bfcf7c in bgp_update_receive bgpd/bgp_packet.c:2220
    #8 0x55cdc9c08474 in bgp_process_packet bgpd/bgp_packet.c:3386
    #9 0x7f81fbffbb8f in event_call lib/event.c:1969
    #10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
    #11 0x55cdc9af854b in main bgpd/bgp_main.c:510
    #12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Indirect leak of 48 byte(s) in 6 object(s) allocated from:
    #0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
    #1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100
    #2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
    #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x55cdc9bf4289 in evaluate_paths bgpd/bgp_nht.c:1384
    #5 0x55cdc9bf5b0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733
    #6 0x55cdc9bf6027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934
    #7 0x55cdc9d1b163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104
    #8 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425
    #9 0x7f81fbffbb8f in event_call lib/event.c:1969
    #10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
    #11 0x55cdc9af854b in main bgpd/bgp_main.c:510
    #12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Indirect leak of 16 byte(s) in 2 object(s) allocated from:
    #0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
    #1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100
    #2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
    #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x55cdc9bf4188 in evaluate_paths bgpd/bgp_nht.c:1348
    #5 0x55cdc9bf5b0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733
    #6 0x55cdc9bf6027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934
    #7 0x55cdc9d1b163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104
    #8 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425
    #9 0x7f81fbffbb8f in event_call lib/event.c:1969
    #10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
    #11 0x55cdc9af854b in main bgpd/bgp_main.c:510
    #12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Indirect leak of 16 byte(s) in 2 object(s) allocated from:
    #0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
    #1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100
    #2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
    #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005
    #5 0x55cdc9bdafd5 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287
    #6 0x55cdc9bdafd5 in vpn_leak_label_callback bgpd/bgp_mplsvpn.c:581
    #7 0x55cdc9bb2606 in lp_cbq_docallback bgpd/bgp_labelpool.c:118
    #8 0x7f81fc0164b5 in work_queue_run lib/workqueue.c:266
    #9 0x7f81fbffbb8f in event_call lib/event.c:1969
    #10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
    #11 0x55cdc9af854b in main bgpd/bgp_main.c:510
    #12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Indirect leak of 8 byte(s) in 1 object(s) allocated from:
    #0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
    #1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100
    #2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
    #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
    #4 0x55cdc9c52406 in bgp_redistribute_add bgpd/bgp_route.c:8692
    #5 0x55cdc9d1ab3b in zebra_read_route bgpd/bgp_zebra.c:595
    #6 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425
    #7 0x7f81fbffbb8f in event_call lib/event.c:1969
    #8 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
    #9 0x55cdc9af854b in main bgpd/bgp_main.c:510
    #10 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

SUMMARY: AddressSanitizer: 1536 byte(s) leaked in 64 allocation(s).
***********************************************************************************

Signed-off-by: ryndia <dindyalsarvesh@gmail.com>
(cherry picked from commit 78b6cadc16f75cc7411bb535beed6703a150d38a)

zebra: Fix connected route deletion when multiple entry exists

When multiple interfaces have addresses in the same network, deleting
one of them may cause the wrong connected route being deleted.
For example:

    ip link add veth1 type veth peer veth2
    ip link set veth1 up
    ip link set veth2 up
    ip addr add dev veth1 192.168.0.1/24
    ip addr add dev veth2 192.168.0.2/24
    ip addr flush dev veth1

Zebra deletes the route of interface veth2 rather than veth1.

Should match nexthop against ere->re_nhe instead of ere->re->nhe.

Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
(cherry picked from commit a35ba7ba602f87390cc9cbce3f0ceb61977f0949)

zebra: add RTM_xxxCHAIN message codes, ignore

We may receive some xxxCHAIN netlink messages, but we ignore
them (currently). Add them to the basic handler callback so
that we don't log errors about them.

Signed-off-by: Mark Stapp <mjs@labn.net>
(cherry picked from commit 620daa36c5a757a96b6d0ed97e350d00b721cc48)

Merge pull request #14567 from FRRouting/mergify/bp/dev/9.1/pr-14557

eigrp: use correct memory pool on interface deletion (backport #14557)

Merge pull request #14568 from FRRouting/mergify/bp/dev/9.1/pr-14437

vtysh freezed on ospf 'no network' command when there are multiple networks and interfaces (backport #14437)

Merge pull request #14571 from FRRouting/mergify/bp/dev/9.1/pr-14563

lib: Suppress HOB/STARVATION warnings when running in vtysh (backport #14563)

Merge pull request #14573 from FRRouting/mergify/bp/dev/9.1/pr-14564

mgmtd: Change MGMTD_VTY_PORT to 2623 (backport #14564)

mgmtd: Change MGMTD_VTY_PORT to 2623

This is clashing with PIMv6 (2622).

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit eeda9b8ae82e888c107bdbfd2d3f81c4fe5d0bba)

lib: Suppress HOB/STARVATION warnings when running in vtysh

Running ping/traceroute/etc. (any kind of commands that use execute_command()
suffer with this kind of warnings.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 3ff671b830698abbf39586c6677f3142dcfa72f1)

ospfd: Fixing infinite loop when listing OSPF interfaces

The problem was happening because the ospf->oiflist has this behaviour, each interface was removed and added at the end of the list in each ospf_network_run_subnet call, generation an infinite loop.
As a solution, a copy of the list was generated and we interacted with a fixed list.

Signed-off-by: Rodrigo Nardi <rnardi@netdef.org>
(cherry picked from commit e0dbeff5bc599be0dfade8256b53dcfef4435bc8)

eigrp: use correct memory pool on interface deletion

Trying to delete an interface during the test test_eigrp_topo1.py triggers a crash.
```
EIGRP: abort+0x12b
EIGRP: _zlog_assert_failed+0x18c
EIGRP: mt_count_free+0x56
EIGRP: qfree+0x2e
EIGRP: eigrp_if_delete_hook+0x8c
EIGRP: hook_call_if_del+0x5f
EIGRP: if_delete_retain+0x1c
EIGRP: if_delete+0xfb
EIGRP: if_destroy_via_zapi+0x69
EIGRP: zclient_interface_delete+0x57
EIGRP: zclient_read+0x3d0
EIGRP: event_call+0xd8
EIGRP: frr_run+0x271
EIGRP: main+0x14b
EIGRP: __libc_start_main+0xf3
EIGRP: _start+0x2e
EIGRP: in thread zclient_read scheduled from lib/zclient.c:4514 zclient_event()
```

Signed-off-by: Volodymyr Huti <v.huti@vyos.io>
(cherry picked from commit 8ddf6a713f2003ccccb884a8c436ffeb2fe34c62)

Merge pull request #14562 from FRRouting/mergify/bp/dev/9.1/pr-14560

Linkstate reversal (backport #14560)

Revert "lib: register bgp link-state afi/safi"

This reverts commit 1642a68d60cfade4b2fce72aaef58dea700c65c3.

(cherry picked from commit 0dc12c9003a865c7ee829543d40e8c285863abe8)

Revert "yang: add bgp link-state"

This reverts commit 3cf5ff27155138ad7b7bafd2e815ca1bba5744ea.

(cherry picked from commit 9c44816398d5a4710e06f0d7597538bf77aa94b1)

Revert "bgpd: add bgp link-state address-family configuration context"

This reverts commit ae2f3bb5b4eed01df1f7a69c7710c9be519390f6.

(cherry picked from commit ddd96b51b06e7cd5ff5471aa6f8ddb390708b858)

Revert "bgpd: accept bgp link-state capability"

This reverts commit 67fe40676eb4e2ca78a41ddd70887af09b29fd9d.

(cherry picked from commit a4fcdc4e48460dc067b0ff8f4dab20bf18fe9694)

Revert "lib: add link-state prefixes"

This reverts commit c8172af6825ad4b10e68b33b8edc22e6e2dc1524.

(cherry picked from commit bbe3163a1b4573c76aedb2b766dc1563f2e488fa)

Revert "bgpd: store bgp link-state prefixes"

This reverts commit 39a8d354c11f6f063fa5154f5807e7a0c9b04b46.

(cherry picked from commit 59c3a491667d8022f996af65612d476ec964049c)

Revert "bgpd: send bgp link-state prefixes"

This reverts commit 0c94fb9cc853b3bcc98e8acca9fd03a036d33c92.

(cherry picked from commit f75d9050fc16469b519630abe7ed61de725e64a5)

Revert "bgpd, lib: extend the size of the prefix string buffer"

This reverts commit bdb3fa3b9216aede64c5b982011fb04ef25c67f7.

(cherry picked from commit 8b3e765d19158e3be146304d40d0563bf945310d)

Revert "bgpd: do not display vty output headers for link-state prefixes"

This reverts commit 3098772467ad8a46a8f35cdd4e502806740b2064.

(cherry picked from commit 85a63731dc8231923796345ba8bb1843ba48d59b)

Revert "bgpd: display link-state prefixes detail"

This reverts commit 7e0d9ff8ba984966689562553afe2734b04c8539.

(cherry picked from commit 8a6b65f7fde9c3bc5fce6a18f8e1d04db9fcf937)

Revert "bgpd: do not announce link-state routes to zebra"

This reverts commit 39fb34275f827b3e1134549ed1731d74e72e6c79.

(cherry picked from commit 4ab7fa86b0360fb79cbe4905a167e8ac25f7f6bf)

Revert "bgpd: add bgp default link-state command"

This reverts commit 38a7e20fc98ed750d9b2cdae1c79d1e19ceadcd3.

(cherry picked from commit 7679d6056b96f707c01157fe5cefab06a7a6392b)

Revert "bgpd: add show bgp link-state link-state commands"

This reverts commit f11f67033fe20f0b4aeb6c885949abb060324749.

(cherry picked from commit d3261fd83f921cb2defd17fd93ab5099d48c952d)

Revert "bgpd: add linkstate debug"

This reverts commit de38eada9c0527758bca34984d2f018670d74c9a.

(cherry picked from commit 68bae363762894d6703e405d2cb1b60d7381be3a)

Revert "tests: add bgp_linkstate_topo1"

This reverts commit a0e6cd4c8fb954f66546b056b0016b4ca7a0a430.

(cherry picked from commit c4edb3a453b524fa5e4f81706f997a6667287f2c)

Revert "doc: move bgp references at the right place"

This reverts commit 709fe971fdd998687fdb9d1e36eca3fb9c8b3265.

(cherry picked from commit c27409358717ccf07076eb01a1c133c5802b6404)

Revert "doc: add the bgp link-state user documentation"

This reverts commit 115f4f1dddb47a05c3e9454cc0fc88f34ebeb281.

(cherry picked from commit da622a28e6faa35cd8992c27e3c818d43ff164a9)

Revert "bgpd: store and send bgp link-state attributes"

This reverts commit 8b531b110756bf8627b5716f433190a0748b5e76.

(cherry picked from commit 166e52d6a31c517861be316af6c5737e43c2f48f)

Revert "tests: add link-state attribute display in bgp_linkstate_topo1"

This reverts commit 5727195cbf7d4c5ea63e307d553e039fa1f9e96f.

(cherry picked from commit 547a0d02aa1a5919662ddf380d401d02490ff854)

Revert "doc: add information to display bgp-ls attributes"

This reverts commit 8074d6f438bfb6c0cc98626b54919ce10f190125.

(cherry picked from commit 63d2016da8383d07e90ee6c210df2b657a99f8d5)

Revert "bgpd: do not check attr in bgp_packet_attribute"

This reverts commit eb9e2865116777661c44963769c1a5fed764b7f9.

(cherry picked from commit e7c0191e820d7a57370ed11434a79f3a65e49b57)

Revert "bgpd: fix illegal memory access in bgp_ls_tlv_check_size()"

This reverts commit dae5791c446cd18d8cda93a1e578fff2cd27be10.

(cherry picked from commit 73a4891ab39bf22f5d0120b378fb7d6cd4b75dd5)

Revert "bgpd: fix link_state_hash_cmp()"

This reverts commit 25408c8dbf7d9e0149ceb2dcbd2058860ce4f6c5.

(cherry picked from commit 2263d1163074f24cc20d75156ee9efe1042b0c6a)

Revert "bgpd: fix insecure data write with ip addresses"

This reverts commit 54222f921305edbce74e81996e9303c0c6b03823.

(cherry picked from commit 298d53401344d2832bf462d143d0c32057f13139)

Revert "bgpd: fix insecure data write with area addresses"

This reverts commit 57d0dc565f6a99c3d61b9b67a40ad88a83773eb6.

(cherry picked from commit c0d3acb0a0813e8d56bf890183bf71fba7f53b2c)

Revert "bgpd: fix printing link state ospf opaque data"

This reverts commit e1333d12e0d3ba8a9a0ca914dc72d0908dea494e.

(cherry picked from commit 28dab7387770f33cbf0f726708ebd085ad93b3f6)

Merge pull request #13617 from anlancs/fix/pimd-remove-pimreg-vrf

pimd: Fix missing pimreg interface

Merge pull request #14535 from opensourcerouting/fix/bgp_aggregate_stuff

bgpd: Drop redundant assignment for aspath segment type and length

Merge pull request #14515 from mjstapp/fix_nhg_intf_uninstall

zebra: be more careful removing 'installed' flag from nhgs

Merge pull request #14548 from raja-rajasekar/frr_dev1

zebra: Prevent leaking ctx memory in err condition

Merge pull request #14550 from Keelan10/fix-nexthop_group-leak

zebra: Free nexthop_group

zebra: Free nexthop_group

`ng` was not properly freed, leading to a memory leak.
The commit calls `nexthop_group_delete` to free memory associated with `ng`.

The ASan leak log for reference:

```
***********************************************************************************
Address Sanitizer Error detected in isis_topo1.test_isis_topo1/r5.asan.zebra.24308

=================================================================
==24308==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 32 byte(s) in 1 object(s) allocated from:
    #0 0x7f4f47b43d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
    #1 0x7f4f4753c0a8 in qcalloc lib/memory.c:105
    #2 0x7f4f47559526 in nexthop_group_new lib/nexthop_group.c:270
    #3 0x562ded6a39d4 in zebra_add_import_table_entry zebra/redistribute.c:681
    #4 0x562ded787c35 in rib_link zebra/zebra_rib.c:3972
    #5 0x562ded787c35 in rib_addnode zebra/zebra_rib.c:3993
    #6 0x562ded787c35 in process_subq_early_route_add zebra/zebra_rib.c:2860
    #7 0x562ded787c35 in process_subq_early_route zebra/zebra_rib.c:3138
    #8 0x562ded787c35 in process_subq zebra/zebra_rib.c:3178
    #9 0x562ded787c35 in meta_queue_process zebra/zebra_rib.c:3228
    #10 0x7f4f475f7118 in work_queue_run lib/workqueue.c:266
    #11 0x7f4f475dc7f2 in event_call lib/event.c:1969
    #12 0x7f4f4751f347 in frr_run lib/libfrr.c:1213
    #13 0x562ded69e818 in main zebra/main.c:486
    #14 0x7f4f468ffc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Indirect leak of 152 byte(s) in 1 object(s) allocated from:
    #0 0x7f4f47b43d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
    #1 0x7f4f4753c0a8 in qcalloc lib/memory.c:105
    #2 0x7f4f475510ad in nexthop_new lib/nexthop.c:376
    #3 0x7f4f475539c5 in nexthop_dup lib/nexthop.c:914
    #4 0x7f4f4755b27a in copy_nexthops lib/nexthop_group.c:444
    #5 0x562ded6a3a1c in zebra_add_import_table_entry zebra/redistribute.c:682
    #6 0x562ded787c35 in rib_link zebra/zebra_rib.c:3972
    #7 0x562ded787c35 in rib_addnode zebra/zebra_rib.c:3993
    #8 0x562ded787c35 in process_subq_early_route_add zebra/zebra_rib.c:2860
    #9 0x562ded787c35 in process_subq_early_route zebra/zebra_rib.c:3138
    #10 0x562ded787c35 in process_subq zebra/zebra_rib.c:3178
    #11 0x562ded787c35 in meta_queue_process zebra/zebra_rib.c:3228
    #12 0x7f4f475f7118 in work_queue_run lib/workqueue.c:266
    #13 0x7f4f475dc7f2 in event_call lib/event.c:1969
    #14 0x7f4f4751f347 in frr_run lib/libfrr.c:1213
    #15 0x562ded69e818 in main zebra/main.c:486
    #16 0x7f4f468ffc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

SUMMARY: AddressSanitizer: 184 byte(s) leaked in 2 allocation(s).
***********************************************************************************
```

Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>

Merge pull request #14451 from m-varasteh/ospf-coverity-issues

ospfd: a possible fix for TAINTED_SCALAR coverity issues

Merge pull request #14533 from mjstapp/fix_rule_notify_vrf

lib,*: add vrf id to pbr rule results zapi message

zebra: Prevent leaking ctx memory in err condition

When netlink_link_change() errors out for a new link for
interface without MTU set, the allocated ctx is not freed..
Adding code for correctness

Ticket# 3628313

Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>

Merge pull request #14543 from mjstapp/fix_pbr_rule_unique

zebra: add zclient to iprules key

Merge pull request #10733 from anlancs/zebra-remove-update

zebra: remove ZEBRA_INTERFACE_VRF_UPDATE

Merge pull request #14541 from idryzhov/isis-fix-cb-destroy

isisd: remove redundant northbound destroy callbacks

doc: replace commands list with header file

Signed-off-by: anlan_cs <anlan_cs@tom.com>

*: remove ZEBRA_INTERFACE_VRF_UPDATE

Currently when one interface changes its VRF, zebra will send these messages to
all daemons in *order*:
    1) `ZEBRA_INTERFACE_DELETE` ( notify them delete from old VRF )
    2) `ZEBRA_INTERFACE_VRF_UPDATE` ( notify them move from old to new VRF )
    3) `ZEBRA_INTERFACE_ADD` ( notify them added into new VRF )

When daemons deal with `VRF_UPDATE`, they use
`zebra_interface_vrf_update_read()->if_lookup_by_name()`
to check the interface exist or not in old VRF. This check will always return
*NULL* because `DELETE` ( deleted from old VRF ) is already done, so can't
find this interface in old VRF.

Send `VRF_UPDATE` is redundant and unuseful. `DELETE` and `ADD` are enough,
they will deal with RB tree, so don't send this `VRF_UPDATE` message when
vrf changes.

Since all daemons have good mechanism to deal with changing vrf, and don't
use this `VRF_UPDATE` mechanism.  So, it is safe to completely remove
all the code with `VRF_UPDATE`.

Signed-off-by: anlan_cs <anlan_cs@tom.com>

zebra: add zclient to iprules key

Include a zclient value in the hash and tree key computations
for iprules in zebra: clients may collide without this.

Signed-off-by: Mark Stapp <mjs@labn.net>

isisd: remove redundant northbound destroy callbacks

Fixes startup warnings:
```
ISIS: [ZKB8W-3S2Q4][EC 100663330] unneeded 'destroy' callback for '/frr-isisd:isis/instance/segment-routing-srv6/msd/node-msd/max-segs-left'
ISIS: [ZKB8W-3S2Q4][EC 100663330] unneeded 'destroy' callback for '/frr-isisd:isis/instance/segment-routing-srv6/msd/node-msd/max-end-pop'
ISIS: [ZKB8W-3S2Q4][EC 100663330] unneeded 'destroy' callback for '/frr-isisd:isis/instance/segment-routing-srv6/msd/node-msd/max-h-encaps'
ISIS: [ZKB8W-3S2Q4][EC 100663330] unneeded 'destroy' callback for '/frr-isisd:isis/instance/segment-routing-srv6/msd/node-msd/max-end-d'
```

Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>

lib,*: add vrf id to pbr rule results zapi message

The iprule/pbr rule object has a vrf id, and zebra uses
that internally, but the vrf id isn't returned to clients
who install rules and are waiting for results. Include the
vrf_id sent by the client in the zapi result notification
message; update the existing clients so they decode the id.

Signed-off-by: Mark Stapp <mjs@labn.net>

bgpd: Drop redundant assignment for aspath segment type and length

They are already initialized via assegment_new().

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

Merge pull request #14534 from mjstapp/fix_topo_nhgid

tests: locate nhg id from json output in all_proto_startup

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.

Signed-off-by: Mark Stapp <mjs@labn.net>

Merge pull request #14517 from adrianomarto/pim-msdp-sa-rp

pimd: Indicating the configured PIM Rendezvous Point (RP) in the MSDP SA message

Merge pull request #14474 from donaldsharp/strsep_fixup

staticd: Memory leak of string in staticd

staticd: Memory leak of string in staticd

XSTRDUP and then calling strsep mangles the
pointer returned by XSTRDUP.  Keep a copy
of the orig and when we are done, free that instead.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>

Merge pull request #14527 from opensourcerouting/fix/guard_debug_messages_for_ttl

bgpd: Add guards for zlog_debug when setting GTSM for the peer

pimd: Indicating the rp in the msdp sa message

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>

bgpd: Add guards for zlog_debug when setting GTSM for the peer

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

Merge pull request #14511 from opensourcerouting/fix/bgpd_software_version_capability

bgpd: Validate maximum length of software version when handling via dynamic caps

Merge pull request #14472 from opensourcerouting/plist-dup

lib: fix route map duplicated prefix removal evaluation

Merge pull request #13814 from pguibert6WIND/comm_list_expanded_match_no_exact

bgpd: add match community "any" to match any incoming community

Merge pull request #14508 from LabNConsulting/chopps/darr-use-frrmemfunc

lib: use XREALLOC over realloc avoid coverity warning