bgpd: add MPLSVPN SNMP boilerplate

Add infrastructure for mplsvpn MIB (RFC-4382) and the top level
ScalarGroup.

Signed-off-by: Pat Ruddy <pat@voltanet.io>

bgpd: add utility to check if a vrf is MPLS VPN

If a vrf is exporting to a vpn table and/or importing to a vpn
table then it is assumed t be a MPLS VPN vrf.

Signed-off-by: Pat Ruddy <pat@voltanet.io>

bgpd: add utility to check if a vrf is active

From RFC4382:
A VRF is
up(1) when there is at least one interface associated
with the VRF whose ifOperStatus is up(1).  A VRF is
down(2) when:
a. There does not exist at least one interface whose
   ifOperStatus is up(1).
b. There are no interfaces associated with the VRF.

Run through interfaces associated with a vrf and return
true if there is one in the up state.

Signed-off-by: Pat Ruddy <pat@voltanet.io>

lib: add utility to count interfaces connected to a vrf

Run through the vrf's interface list and return a count, skipping
the l3mdev which has a name which matches the vrf name.

Signed-off-by: Pat Ruddy <pat@voltanet.io>

Merge pull request #7985 from donaldsharp/eigrp_uninited

bunch of valgrind issues

Merge pull request #7992 from donaldsharp/bgp_locks

bgpd: Centralize the dest unlocking for adj_out data structure

Merge pull request #7402 from ranjanyash54/dev_2

ospf6d: Json support added for command "show ipv6 ospf6 route [json]"

Merge pull request #7994 from opensourcerouting/disable-printf-n

lib/printf: disable `%n` specifier

Merge pull request #7958 from sworleys/Fix-Nexthop-Infinite-Recurse

zebra: disallow resolution to duplicate nexthops

topotests: add test for infinite recursion

Add a test for the infinite recursion case fixed
with 0c4dbb5f8fe8fb188fa0e0aa8ce04764e893b79b

See that commit for details of the problem. This test uses a simpler
version of the repro found there as the test.

Signed-off-by: Stephen Worley <sworley@nvidia.com>

zebra: disallow resolution to duplicate nexthops

Disallow the resolution to nexthops that are marked duplicate.
When we are resolving to an ecmp group, it's possible this
group has duplicates.

I found this when I hit a bug where we can have groups resolving
to each other and cause the resolved->next->next pointer to increase
exponentially. Sufficiently large ecmp and zebra will grind to a hault.

Like so:

```
D>  4.4.4.14/32 [150/0] via 1.1.1.1 (recursive), weight 1, 00:00:02
  *                       via 1.1.1.1, dummy1 onlink, weight 1, 00:00:02
                        via 4.4.4.1 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.2 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.3 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.4 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.5 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.6 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.7 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.8 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.9 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.10 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.11 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.12 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.13 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.15 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1 onlink, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1 onlink, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                        via 4.4.4.16 (recursive), weight 1, 00:00:02
                          via 1.1.1.1, dummy1 onlink, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
                          via 1.1.1.1, dummy1, weight 1, 00:00:02
D>  4.4.4.15/32 [150/0] via 1.1.1.1 (recursive), weight 1, 00:00:09
  *                       via 1.1.1.1, dummy1 onlink, weight 1, 00:00:09
                        via 4.4.4.1 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.2 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.3 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.4 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.5 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.6 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.7 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.8 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.9 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.10 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.11 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.12 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.13 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.14 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                        via 4.4.4.16 (recursive), weight 1, 00:00:09
                          via 1.1.1.1, dummy1 onlink, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
                          via 1.1.1.1, dummy1, weight 1, 00:00:09
D>  4.4.4.16/32 [150/0] via 1.1.1.1 (recursive), weight 1, 00:00:19
  *                       via 1.1.1.1, dummy1 onlink, weight 1, 00:00:19
                        via 4.4.4.1 (recursive), weight 1, 00:00:19
                          via 1.1.1.1, dummy1, weight 1, 00:00:19
                        via 4.4.4.2 (recursive), weight 1, 00:00:19

...............
................

and on...

```

You can repro the above via:

```
kernel routes:

1.1.1.1 dev dummy1 scope link

4.4.4.0/24 via 1.1.1.1 dev dummy1

==============================

config:

nexthop-group doof
 nexthop 1.1.1.1
 nexthop 4.4.4.1
 nexthop 4.4.4.10
 nexthop 4.4.4.11
 nexthop 4.4.4.12
 nexthop 4.4.4.13
 nexthop 4.4.4.14
 nexthop 4.4.4.15
 nexthop 4.4.4.16
 nexthop 4.4.4.2
 nexthop 4.4.4.3
 nexthop 4.4.4.4
 nexthop 4.4.4.5
 nexthop 4.4.4.6
 nexthop 4.4.4.7
 nexthop 4.4.4.8
 nexthop 4.4.4.9
!

===========================

Then use sharpd to install 4.4.4.16 -> 4.4.4.1 pointing to that nexthop
group in decending order.
```

With these changes it prevents the growing ecmp above by disallowing
duplicates to be in the resolution decision. These nexthops are not
installed anyways so why should we be resolving to them?

Signed-off-by: Stephen Worley <sworley@nvidia.com>

lib/printf: disable `%n` specifier

We don't use `%n` anywhere, so the only purpose it serves is enabling
exploits.

(I thought about this initially when adding printfrr, but I wasn't sure
we don't use `%n` anywhere, and thought I'll check later, and then just
forgot it...)

Signed-off-by: David Lamparter <equinox@diac24.net>

Merge pull request #7972 from donaldsharp/getrusage_data

lib: Line up `show thread cpu` output appropriately

Merge pull request #7948 from Jafaral/strongswan

doc: update the links to nhrp/strongswan patches

bgpd: Centralize the dest unlocking for adj_out data structure

When FRR creates a adj_out data structure we lock the `struct
bgp_dest` node associated with it.  On freeing of this data
structure and removing the lock it was not associated with
the actual free of the adjacency structure.  Let's clean up
the lock/unlock to be centralized to the alloc/free of the adj_out.

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

Merge pull request #7965 from opensourcerouting/netns-doc

doc: add information about network namespaces

lib: Line up `show thread cpu` output appropriately

The output from `show thread cpu` was not lined up appropriately
for the header line.  As well as the function name we were
calling in the output.  Fix it.

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

Merge pull request #7988 from ton31337/fix/initialize_raw_data

bgpd: Initialize bgp_notify.raw_data before passing to bgp_notify_rec…

Merge pull request #7969 from donaldsharp/more_flags

More flags

bgpd: Initialize bgp_notify.raw_data before passing to bgp_notify_receive()

```
2523558-==2523558==
2523558-==2523558== Conditional jump or move depends on uninitialised value(s)
2523558:==2523558==    at 0x47F242: bgp_notify_admin_message (bgp_debug.c:505)
2523558-==2523558==    by 0x47F242: bgp_notify_print (bgp_debug.c:534)
2523558-==2523558==    by 0x4BA9BC: bgp_notify_receive (bgp_packet.c:1905)
2523558-==2523558==    by 0x4BA9BC: bgp_process_packet (bgp_packet.c:2602)
2523558-==2523558==    by 0x4904B7E: thread_call (thread.c:1681)
2523558-==2523558==    by 0x48CAA27: frr_run (libfrr.c:1126)
2523558-==2523558==    by 0x474B1A: main (bgp_main.c:540)
2523558-==2523558==  Uninitialised value was created by a stack allocation
2523558:==2523558==    at 0x4BA33D: bgp_process_packet (bgp_packet.c:2529)
```

Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>

Merge pull request #7984 from donaldsharp/hidden_command

bgpd: Remove hidden `neighbor X route-map Y <in|out>` command

lib: Prevent unininted usage of data

Valgrind reports that some data being used in the
stack unwind of a crash is being used uninitailized.

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

bfdd: Prevent storage of ifp pointer that has been deleted

On shutdown, interfaces are deleted but if the bfd session
is down we retain the interface pointer.  Remove the retained
pointer.

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

Merge pull request #7970 from volta-networks/fix_snmp_topotest_test_oid_walk

tests: update snmp topotest api test_oid_walk

bfdd: Prevent unininited data transmittal

Valgrind reports:

2052866-==2052866==
2052866-==2052866== Syscall param sendmsg(msg.msg_name) points to uninitialised byte(s)
2052866:==2052866==    at 0x49C8E13: sendmsg (sendmsg.c:28)
2052866-==2052866==    by 0x11DC08: bp_udp_send (bfd_packet.c:823)
2052866-==2052866==    by 0x11DD76: ptm_bfd_echo_snd (bfd_packet.c:179)
2052866-==2052866==    by 0x114C2D: ptm_bfd_echo_xmt_TO (bfd.c:469)
2052866-==2052866==    by 0x114C2D: ptm_bfd_echo_start (bfd.c:498)
2052866-==2052866==    by 0x114C2D: bs_echo_timer_handler (bfd.c:1199)
2052866-==2052866==    by 0x11E478: bfd_recv_cb (bfd_packet.c:702)
2052866-==2052866==    by 0x4904846: thread_call (thread.c:1681)
2052866-==2052866==    by 0x48CB4DF: frr_run (libfrr.c:1126)
2052866-==2052866==    by 0x113044: main (bfdd.c:403)
2052866-==2052866==  Address 0x1ffefff3e8 is on thread 1's stack

In ptm_bfd_echo_snd, for the v4 case we were memsetting the v6 memory
then setting the v4 memory.  Just fix it.

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

isisd: Prevent sending of uninited data to zebra

Valgrind reports:
2172861-==2172861==
2172861-==2172861== Syscall param write(buf) points to uninitialised byte(s)
2172861:==2172861==    at 0x49B4FB3: write (write.c:26)
2172861-==2172861==    by 0x48A4EA0: buffer_write (buffer.c:475)
2172861-==2172861==    by 0x4915AD9: zclient_send_message (zclient.c:298)
2172861-==2172861==    by 0x12AE08: isis_ldp_sync_state_req_msg (isis_ldp_sync.c:152)
2172861-==2172861==    by 0x12B74B: isis_ldp_sync_adj_state_change (isis_ldp_sync.c:305)
2172861-==2172861==    by 0x16DE04: hook_call_isis_adj_state_change_hook.isra.0 (isis_adjacency.c:141)
2172861-==2172861==    by 0x16EE27: isis_adj_state_change (isis_adjacency.c:371)
2172861-==2172861==    by 0x16F1F3: isis_adj_process_threeway (isis_adjacency.c:242)
2172861-==2172861==    by 0x13BCCA: process_p2p_hello (isis_pdu.c:283)
2172861-==2172861==    by 0x13BCCA: process_hello (isis_pdu.c:781)
2172861-==2172861==    by 0x13BCCA: isis_handle_pdu (isis_pdu.c:1700)

Sending of request includes uninited memory at the end of the interface
name string.  Fix

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

ospfd: Prevent sending of uninited data to zebra

Valgrind reports:
2174600-==2174600==
2174600-==2174600== Syscall param write(buf) points to uninitialised byte(s)
2174600:==2174600==    at 0x49C7FB3: write (write.c:26)
2174600-==2174600==    by 0x48A4EA0: buffer_write (buffer.c:475)
2174600-==2174600==    by 0x4915AD9: zclient_send_message (zclient.c:298)
2174600-==2174600==    by 0x12DB97: ospf_ldp_sync_state_req_msg (ospf_ldp_sync.c:114)
2174600-==2174600==    by 0x12E4F0: ospf_ldp_sync_if_start (ospf_ldp_sync.c:160)
2174600-==2174600==    by 0x12E4F0: ospf_ldp_sync_ism_change (ospf_ldp_sync.c:339)
2174600-==2174600==    by 0x12E4F0: ospf_ldp_sync_ism_change (ospf_ldp_sync.c:332)
2174600-==2174600==    by 0x12C6A2: hook_call_ospf_ism_change (ospf_ism.c:46)
2174600-==2174600==    by 0x12C6A2: ism_change_state (ospf_ism.c:540)
2174600-==2174600==    by 0x12C6A2: ospf_ism_event (ospf_ism.c:600)
2174600-==2174600==    by 0x4904846: thread_call (thread.c:1681)

When we send the request structure we are sending the whole thing and the
interface name string has junk at the end.  Not a big deal, but cleans
up valgrind going wumple on us.

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

eigrpd: Prevent uninitialized value from being used

valgrind is finding:

2141982-==2141982== Conditional jump or move depends on uninitialised value(s)
2141982:==2141982==    at 0x11A7A6: eigrp_metrics_is_same (eigrp_metric.c:134)
2141982-==2141982==    by 0x120360: eigrp_topology_update_distance (eigrp_topology.c:374)
2141982-==2141982==    by 0x124F01: eigrp_get_fsm_event (eigrp_fsm.c:284)
2141982-==2141982==    by 0x12519E: eigrp_fsm_event (eigrp_fsm.c:419)
2141982-==2141982==    by 0x1206A1: eigrp_topology_neighbor_down (eigrp_topology.c:518)
2141982-==2141982==    by 0x11AB3A: eigrp_nbr_delete (eigrp_neighbor.c:178)
2141982-==2141982==    by 0x124494: eigrp_finish_final (eigrpd.c:271)
2141982-==2141982==    by 0x1245A8: eigrp_finish (eigrpd.c:247)
2141982-==2141982==    by 0x124630: eigrp_terminate (eigrpd.c:240)
2141982-==2141982==    by 0x11344B: sigint (eigrp_main.c:112)
2141982-==2141982==    by 0x48F5F32: quagga_sigevent_process (sigevent.c:130)

Prevent this from happening.

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

bgpd: Remove hidden `neighbor X route-map Y <in|out>` command

This command was put in place to allow upgrades for the
neighbor command from the BGP_NODE and have it put
into the ipv4 uni node instead.  Since this
utterly kills the yang conversion.  I believe we need
to remove this.  Since people upgrading will just loose
the route-map applicatoin( if they are using such an old
config ) and RFC 8212 will come into play.  They'll figure
it out pretty fast.

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

bgpd: Add `bgp_nexthop_dump_bnc_change_flags` function

Allow us to read what the change flags are instead of having
to look them up.

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

bgpd: Add bgp_nexthop_dump_bnc_flags

Add a function that allows us to see a string version of the
bnc->flags bit fields.

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

Merge pull request #7953 from mjstapp/fix_more_ntoa

libs, ospfd: remove inet_ntoa

Merge pull request #7960 from kishorekunal01/bgp_fix_allowas_in

BGP: "no neighbor <peer-group> allowas-in" is not resetting the peer-group member allowas_in[afi][safi].

Merge pull request #7974 from donaldsharp/more_if_zero

More if zero

tests: update snmp topotest api test_oid_walk

Update snmp topotest api test_oid_walk to validate a subset
of rows in a mib walk.

Signed-off-by: Karen Schoener <karen@voltanet.io>

Merge pull request #7955 from volta-networks/fix_isis_lsp_bit_topotest

tests: temporarily remove isis-lsp-bit-topo1 topotest

Merge pull request #7967 from ton31337/feature/show_bgp_summary_wide

bgpd: Add `show bgp summary wide` command

Merge pull request #7968 from ton31337/feature/doc_ebgp_reset_session

doc: ebgp-requires-policy requires manuall session clearing

ospfd: ospf_nbr_nbma_lookup_next always returns NULL

The calling function of ospf_nbr_nbma_lookup_next calls
this function and then immediately returns when it
gets the NULL.  Just cleanup a bit more code.

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

pbrd: Remove #if 0 code

I am not even sure what the goal of this code was in any
way shape fashion or form.  But since it's pbr_nht.c
I as the original author should know... But I don't.

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

lib: Remove #if 0 code

Just some more dead code that has been sitting unused for
a very long time.

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

eigrpd: Remove #if 0 dead code

There is some dead code in eigrpd

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

bfdd: Remove #if 0

We do have a bunch of old code that is never used.

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

zebra: Remove #if 0 code

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

bgpd: Remove #if 0 code

Remove all dead #if 0 code from bgpd.

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

isisd: Remove #if 0 code

Looks like the #if 0 code in this place was for ESI support
on solaris.  We do not support solaris anymore.  So let's
remove with prejudice.

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

ripngd: Remove #if 0 code

Remove some more dead code.

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

ripd: #if 0 we know what you are up to.

rip, ripped out the #if 0 code.

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

pimd: Remove #if 0 code from system

Old dead code.
Like a log
jamming your build system

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

tests: temporarily remove isis-lsp-bits-topo1 topotest

Signed-off-by: Lynne Morrison <lynne@voltanet.io>

ospf6d: Remove #if 0 code that has not been used in a long time

The earliest that some of this code is 2018.  There is not
much point in keeping this code around.

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

ospfd: Remove #if 0 code

The #if 0 code in ospfd, has not been compiled since at least
2012.  If we are at least 9 years old at this point with no effort
to use or save, we should just get rid of it.

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

bgpd: Removing "neighbor <peer-group> allowas-in"

Unconfig not resetting the peer-group member allowas_in[afi][safi]
This is causing remote route to be accept.

Signed-off-by: Kishore Kunal <kishorekunal01@broadcom.com>

doc: ebgp-requires-policy requires manuall session clearing

Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>

Merge pull request #7933 from deastoe/show-route-header-sep

lib: restore blank line after show route header

bgpd: Show NoNeg instead of bad parsing `show bgp summary` if disabled

Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>

doc: Add `show bgp summary wide` short description

Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>

bgpd: Include local AS for JSON output in `show bgp summary json` cmd

Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>

bgpd: Add `show bgp summary wide` command

Add LocalAS into wide output and extend Desc to 64 chars instead of 20.

Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>

doc: add information about network namespaces

Let user know that there are standardized ways to use network namespaces.

Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>

Merge pull request #7952 from kuldeepkash/documentation

doc: topotests-markers typo error

Merge pull request #7433 from sudhanshukumar22/bgp-aggregate-member-issue

bgpd:'bgpd' core generated on Leaf device with system-test config

*: Update version string

Update the version string to reflect work towards next release

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

libs, ospfd: remove inet_ntoa

inet_ntoa not permitted - replace instances.

Signed-off-by: Mark Stapp <mjs@voltanet.io>

doc: topotests-markers typo error

Fixed topotests-markers typo error

Signed-off-by: kuldeepkash <kashyapk@vmware.com>

Merge pull request #7936 from pjdruddy/l3vpn-lableled-nh-check

bgpd: make sure nh is valid for MPLS vpn routes

doc: update the links to nhrp/strongswan patches

Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>

bgpd: make sure nh is valid for MPLS vpn routes

If we are using a nexthop for a MPLS VPN route make sure the
nexthop is over a labeled path. This new check mirrors the one
in validate_paths (where routes are enabled when a nexthop
becomes reachable). The check is introduced to the code path
where routes are added and the nexthop is looked up.

Signed-off-by: Pat Ruddy <pat@voltanet.io>

lib: restore blank line after show route header

In 5a3cf85391b3665b5344d577e98aaa29a1927818 the trailing empty line
following the "show ip(v6) route" header was removed. Restore it for
consistency.

Signed-off-by: Duncan Eastoe <duncan.eastoe@att.com>

tests: more robust show route header stripping

In test_converge_protocols() use sed to match the "show ip(v6) route"
header and strip it, rather than using tail which requires hardcoding
the expected length of the header (which is subject to change).

Signed-off-by: Duncan Eastoe <duncan.eastoe@att.com>

ospf6d: Json support added for command "show ipv6 ospf6 interface prefix [json]"

Modify code to add JSON format output in show command
"show ipv6 ospf6 interface prefix" with proper formating

Signed-off-by: Yash Ranjan <ranjany@vmware.com>

ospf6d: Json support added for command "show ipv6 ospf6 route [json]"

Modify code to add JSON format output in show command
"show ipv6 ospf6 route [<intra-area|inter-area|external-1|
external-2|X:X::X:X|X:X::X:X/M|detail|summary>]"
with proper formating

Signed-off-by: Yash Ranjan <ranjany@vmware.com>

Merge pull request #7935 from donaldsharp/ospf6_use_after_free

ospf6d: Track wait_timer and disable when needed

Merge pull request #7925 from opensourcerouting/watchfrr-netns

watchfrr: fix crash on missing optional argument

Merge pull request #7938 from mjstapp/fix_netlink_debugs

zebra: debug messages go under conditionals

Merge pull request #7368 from eololab/add-pidfile-in-frr.service

tools: add PIDFile option in frr.service

zebra: debug messages go under conditionals

Move a couple of unprotected debug calls in the netlink code
under DEBUG_KERNEL.

Signed-off-by: Mark Stapp <mjs@voltanet.io>

Merge pull request #7635 from AnuradhaKaruppiah/ead-evi-knobs

bgpd: add config knobs to disable rx and tx of ead-per-evi routes

watchfrr: fix SA warning

`valid_command` now causes static analyzer complaints since it no
longer assumes `optarg` is non-NULL. If this was the case then
`valid_command` would return `false` (or 0) because it would mean the
string is empty and doesn't contain the '%s' it expects.

Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>

Merge pull request #7934 from donaldsharp/valgrind_cleanups

pimd: Prevent use after free

ospf6d: Track wait_timer and disable when needed

When removing ospfv3 from an interface that has been previously
put into wait state, there is a possible use after free of the
oi because the wait_timer could have been started for the interface.
This is because the wait_timer was not tracked by the interface
and we just created a thread for it without storing the thread
pointer.

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

pimd: Prevent use after free

Valgrind is reporting this:
==22220== Invalid read of size 4
==22220==    at 0x11DC2B: pim_if_delete (pim_iface.c:215)
==22220==    by 0x11DD71: pim_if_terminate (pim_iface.c:76)
==22220==    by 0x128E03: pim_instance_terminate (pim_instance.c:66)
==22220==    by 0x128E03: pim_vrf_delete (pim_instance.c:159)
==22220==    by 0x48E0010: vrf_delete (vrf.c:251)
==22220==    by 0x48E0010: vrf_delete (vrf.c:225)
==22220==    by 0x48E02FE: vrf_terminate (vrf.c:551)
==22220==    by 0x149495: pim_terminate (pimd.c:142)
==22220==    by 0x13C61B: pim_sigint (pim_signals.c:44)
==22220==    by 0x48CF862: quagga_sigevent_process (sigevent.c:103)
==22220==    by 0x48DD324: thread_fetch (thread.c:1404)
==22220==    by 0x48A926A: frr_run (libfrr.c:1122)
==22220==    by 0x11B85E: main (pim_main.c:167)
==22220==  Address 0x5912160 is 1,200 bytes inside a block of size 1,624 free'd
==22220==    at 0x48369AB: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==22220==    by 0x128E52: pim_instance_terminate (pim_instance.c:74)
==22220==    by 0x128E52: pim_vrf_delete (pim_instance.c:159)
==22220==    by 0x48E0010: vrf_delete (vrf.c:251)
==22220==    by 0x48E0010: vrf_delete (vrf.c:225)
==22220==    by 0x48F1353: zclient_vrf_delete (zclient.c:1896)
==22220==    by 0x48F1353: zclient_read (zclient.c:3511)
==22220==    by 0x48DD826: thread_call (thread.c:1585)
==22220==    by 0x48A925F: frr_run (libfrr.c:1123)
==22220==    by 0x11B85E: main (pim_main.c:167)
==22220==  Block was alloc'd at
==22220==    at 0x4837B65: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==22220==    by 0x48ADA4F: qcalloc (memory.c:110)
==22220==    by 0x128B9B: pim_instance_init (pim_instance.c:82)
==22220==    by 0x128B9B: pim_vrf_new (pim_instance.c:142)
==22220==    by 0x48E0C5A: vrf_get (vrf.c:217)
==22220==    by 0x48F13C9: zclient_vrf_add (zclient.c:1863)
==22220==    by 0x48F13C9: zclient_read (zclient.c:3508)
==22220==    by 0x48DD826: thread_call (thread.c:1585)
==22220==    by 0x48A925F: frr_run (libfrr.c:1123)
==22220==    by 0x11B85E: main (pim_main.c:167)

On pim vrf deletion, ensure that the vrf->info pointers are NULL as well
as the free'd pim pointer for ->vrf is NULL as well.

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

Merge pull request #7676 from ton31337/fix/show_ip_bgp_summary_description_truncate

bgpd: Strip neighbors's description to 20 chars in show bgp summary

Merge pull request #7898 from donaldsharp/pim_igmp_crash

pimd: Prevent crash with igmp only config

Merge pull request #7901 from donaldsharp/pim_marking

tests: Fix to use global variable for pim marking

Merge pull request #7928 from volta-networks/fix_simple_snmp_add_checks

tests: update simple_snmp_test to check for memory leaks, router failure

Merge pull request #7127 from opensourcerouting/ospf_ti-lfa

ospfd: add support for Topology Independent LFA (TI-LFA)

Merge pull request #7843 from volta-networks/feat_isis_attach_bit

isisd: Fix Attach-bit processing

Merge pull request #7923 from donaldsharp/gcc10-cleanups

Gcc10 cleanups

Merge pull request #7905 from mjstapp/fix_zapi_nhg

zebra, sharpd: async results for NHGs

tests: update simple_snmp_test to check for memory leaks, router failure

Signed-off-by: Karen Schoener <karen@voltanet.io>

lib: Wrapper a function to make gcc-10 happy

gcc-10 is complaining:

lib/frrscript.c:42:14: error: cast between incompatible function types from ‘const char * (*)(lua_State *, const char *)’ to ‘void (*)(lua_State *, const void *)’ [-Werror=cast-function-type]
   42 |   .encoder = (encoder_func)lua_pushstring,
      |              ^

Wrapper it to make it happy.  Not sure what else to do.

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

lib: Prevent possible memory overwrite

fname is MAXPATHLEN and scriptdir and fs->name are less then
MAXPATHLEN but the combination of those two + the `.lua` are
greater than the MAXPATHLEN.  Just give us more room to prevent
a coding boo boo.

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

ospf6d: use a new json_object per loop iteration

When redistributing multiple route types into ospfv3
the code must create a new array per route type into
the the json code.

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

Merge pull request #7922 from ton31337/fix/bgpd_blackhole_community_ibgp

bgpd: Advertise BLACKHOLE community tagged prefixes to iBGP peers

watchfrr: fix crash on missing optional argument

Fix `netns` command line handling for missing argument (it's optional).

Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>

bgpd: Assert that community_str2com("no-export") always returns non-NULL

community_str2com("no-export"); returns ALWAYS non-NULL.

If NULL returned here, we really have a bigger problems in the call path.

Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>

tests: Check if BLACKHOLE community prefixes are visible inside local AS

Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>

bgpd: Set no-export community for blackhole tagged prefixes

RFC says to prevent propagation of the prefix outside the local AS.

So, let's use NO_EXPORT.

Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>

bgpd: Log prefix when community filter fails

This is needed when NO_ADVERTISE or NO_EXPORT is handled for outgoing
updates.

Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>