doc: Slightly touch on the vrf route lookup semantics

People keep asking about the default unreachable route
in the linux vrf table.  Add a bit of color about the
design choices and what is going on.

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

Merge pull request #6049 from sarav511/ovrdhold

pimd: SGRpt prune received during prune didn't override holdtime

Merge pull request #8013 from mjstapp/fix_topo_ospf6_topo1

tests: fix ospf6_topo1 missing ref files

tests: fix ospf6_topo1 missing ref files

Only one of the four reference files was present; add the missing
three. The test just silently passed if a ref file was missing:
change that to a failure.

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

Merge pull request #8004 from opensourcerouting/xref-cxx

lib/xref: fix C++ issues

lib/xref: fix initializer order for C++

[v2: drop designated initializer names]

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

Merge pull request #7449 from sudhanshukumar22/bgp-update-connect-timer

bgpd: config connect timer not applied immediately for non-established peers.

lib/xref: fix frrtrace() calls in thread code

This didn't exist yet when the xref code came around, and since
frrtrace() gets collapsed to nothing by the preprocessor when
tracepoints are disabled, it didn't cause any compiler errors...

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

lib/xref: work around GCC bug 41091

gcc fucks up global variables with section attributes when they're used
in templated C++ code.  The template instantiation "magic" kinda breaks
down (it's implemented through COMDAT in the linker, which clashes with
the section attribute.)

The workaround provides full runtime functionality, but the xref
extraction tool (xrelfo.py) won't work on C++ code compiled by GCC.

FWIW, clang gets this right.

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

lib/xref: restore lost extern "C" beginning

The `}` is still there, but the `extern "C" {` got lost somewhere,
probably in a rebase...

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

Merge pull request #8002 from idryzhov/fix-all-backets

*: fix all backets

Merge pull request #8001 from ton31337/fix/bgpd_replace_65535_with_const

bgpd: Replace 65535 with UINT16_MAX

*: fix all backets

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

Merge pull request #7314 from kuldeepkash/multicast-sm-topo1

Add multicast-pim-sm-topo1 test suite

bgpd: Replace 65535 with UINT16_MAX

Just consistent.

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

Merge pull request #6766 from opensourcerouting/xref

lib: xrefs - general cross-references & unique IDs

Merge pull request #7987 from donaldsharp/eigrp_mtu_correct

eigrpd: Correctly set the mtu for eigrp packets sent

Merge pull request #7991 from donaldsharp/valgrind_cleanups1

Valgrind cleanups

bgpd: config connect timer is not applied immediately for peers in non-established state.

Description:
When user is config connect timer, it doesn't reflect
immediately. It reflect when next time neighbor is tried to reconnect.

Problem Description/Summary :
When user is config connect timer, it doesn't reflect
The network connection was aborted by the local system.d to reconnect.
Fix is to update the connect timer immediately if BGP
    session is not in establish state.

Expected Behavior :
If neighbor is not yet established, we should immediately apply the config connect timer to the peer.

Signed-off-by: sudhanshukumar22 <sudhanshu.kumar@broadcom.com>

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

tools/checkpatch: downgrade string concat warning

This is the best I can make the asm blocks in lib/xref.h look, so just
mute the warning.  (It shouldn't come in relevant for other code.)

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

tests: add unit test for xrefs

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

doc/developer: xrefs

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

lib/xref: add xrefs for install_element()

Combined with the DEFUN xrefs, this means we can extract the full CLI
tree from a binary file.

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

lib/xref: add xrefs for DEFUNs

This allows grabbing a list of all DEFUNs and their help texts through
the xref extraction mechanics.

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

lib/xref: add xrefs on zlog_* calls

This allows extracting a list of all log messages including their ECs
and autogenerated unique IDs for them.

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

lib/xref: use to transport thread_* file/line/func

Just a better way of doing what was previously the "debugargdef" macro.

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

lib/xref: put setup calls in libraries

Our "true" libraries (i.e. not modules) don't invoke neither
FRR_DAEMON_INFO nor FRR_MODULE_SETUP, hence XREF_SETUP isn't invoked
either.  Invoke it directly to get things working.

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

lib: "xref" identifier infrastructure

This adds the machinery for cross reference points (hence "xref") for
things to be annotated with source code location or other metadata
and/or to be uniquely identified and found at runtime or by dissecting
executable files.

The extraction tool to walk down an ELF file is done and working but
needs some more cleanup and will be added in a separate commit.

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

lib: move frr_weak_random to header file

Makes more sense to have this as a static inline.  Also I don't want to
be forced to link network.o into clippy ;)

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>

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>

zebra: Prevent sending of unininted data

valgrind is reporting:
2448137-==2448137== Thread 5 zebra_apic:
2448137-==2448137== Syscall param writev(vector[...]) points to uninitialised byte(s)
2448137:==2448137==    at 0x4D6FDDD: __writev (writev.c:26)
2448137-==2448137==    by 0x4D6FDDD: writev (writev.c:24)
2448137-==2448137==    by 0x48A35F5: buffer_flush_available (buffer.c:431)
2448137-==2448137==    by 0x48A3504: buffer_flush_all (buffer.c:237)
2448137-==2448137==    by 0x495948: zserv_write (zserv.c:263)
2448137-==2448137==    by 0x4904B7E: thread_call (thread.c:1681)
2448137-==2448137==    by 0x48BD3E5: fpt_run (frr_pthread.c:308)
2448137-==2448137==    by 0x4C61EA6: start_thread (pthread_create.c:477)
2448137-==2448137==    by 0x4D78DEE: clone (clone.S:95)
2448137-==2448137==  Address 0x720c3ce is 62 bytes inside a block of size 4,120 alloc'd
2448137:==2448137==    at 0x483877F: malloc (vg_replace_malloc.c:307)
2448137-==2448137==    by 0x48D2977: qmalloc (memory.c:110)
2448137-==2448137==    by 0x48A30E3: buffer_add (buffer.c:135)
2448137-==2448137==    by 0x48A30E3: buffer_put (buffer.c:161)
2448137-==2448137==    by 0x49591B: zserv_write (zserv.c:256)
2448137-==2448137==    by 0x4904B7E: thread_call (thread.c:1681)
2448137-==2448137==    by 0x48BD3E5: fpt_run (frr_pthread.c:308)
2448137-==2448137==    by 0x4C61EA6: start_thread (pthread_create.c:477)
2448137-==2448137==    by 0x4D78DEE: clone (clone.S:95)
2448137-==2448137==  Uninitialised value was created by a stack allocation
2448137:==2448137==    at 0x43E490: zserv_encode_vrf (zapi_msg.c:103)

Effectively we are sending `struct vrf_data` without ensuring
data has been properly initialized.

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

ospf6d: prevent use after free

Valgrind reports:

2437395-==2437395== Invalid read of size 8
2437395:==2437395==    at 0x40B610: ospf6_asbr_update_route_ecmp_path (ospf6_asbr.c:327)
2437395-==2437395==    by 0x40BC7C: ospf6_asbr_lsa_add (ospf6_asbr.c:544)
2437395-==2437395==    by 0x40C5DF: ospf6_asbr_lsentry_add (ospf6_asbr.c:829)
2437395-==2437395==    by 0x42D88D: ospf6_top_brouter_hook_add (ospf6_top.c:185)
2437395-==2437395==    by 0x4188E3: ospf6_intra_brouter_calculation (ospf6_intra.c:2320)
2437395-==2437395==    by 0x42C624: ospf6_spf_calculation_thread (ospf6_spf.c:638)
2437395-==2437395==    by 0x4904B7E: thread_call (thread.c:1681)
2437395-==2437395==    by 0x48CAA27: frr_run (libfrr.c:1126)
2437395-==2437395==    by 0x40AF43: main (ospf6_main.c:232)
2437395-==2437395==  Address 0x5c668a8 is 24 bytes inside a block of size 256 free'd
2437395:==2437395==    at 0x48399AB: free (vg_replace_malloc.c:538)
2437395-==2437395==    by 0x429027: ospf6_route_delete (ospf6_route.c:419)
2437395-==2437395==    by 0x429027: ospf6_route_unlock (ospf6_route.c:460)
2437395-==2437395==    by 0x429027: ospf6_route_remove (ospf6_route.c:887)
2437395-==2437395==    by 0x40B343: ospf6_asbr_update_route_ecmp_path (ospf6_asbr.c:318)
2437395-==2437395==    by 0x40BC7C: ospf6_asbr_lsa_add (ospf6_asbr.c:544)
2437395-==2437395==    by 0x40C5DF: ospf6_asbr_lsentry_add (ospf6_asbr.c:829)
2437395-==2437395==    by 0x42D88D: ospf6_top_brouter_hook_add (ospf6_top.c:185)
2437395-==2437395==    by 0x4188E3: ospf6_intra_brouter_calculation (ospf6_intra.c:2320)
2437395-==2437395==    by 0x42C624: ospf6_spf_calculation_thread (ospf6_spf.c:638)
2437395-==2437395==    by 0x4904B7E: thread_call (thread.c:1681)
2437395-==2437395==    by 0x48CAA27: frr_run (libfrr.c:1126)
2437395-==2437395==    by 0x40AF43: main (ospf6_main.c:232)
2437395-==2437395==  Block was alloc'd at
2437395:==2437395==    at 0x483AB65: calloc (vg_replace_malloc.c:760)
2437395-==2437395==    by 0x48D2A32: qcalloc (memory.c:115)
2437395-==2437395==    by 0x427CE4: ospf6_route_create (ospf6_route.c:402)
2437395-==2437395==    by 0x40BA8A: ospf6_asbr_lsa_add (ospf6_asbr.c:490)
2437395-==2437395==    by 0x40C5DF: ospf6_asbr_lsentry_add (ospf6_asbr.c:829)
2437395-==2437395==    by 0x42D88D: ospf6_top_brouter_hook_add (ospf6_top.c:185)
2437395-==2437395==    by 0x4188E3: ospf6_intra_brouter_calculation (ospf6_intra.c:2320)
2437395-==2437395==    by 0x42C624: ospf6_spf_calculation_thread (ospf6_spf.c:638)
2437395-==2437395==    by 0x4904B7E: thread_call (thread.c:1681)
2437395-==2437395==    by 0x48CAA27: frr_run (libfrr.c:1126)
2437395-==2437395==    by 0x40AF43: main (ospf6_main.c:232)

ospfv3 loops through the ecmp routes to decide what to clean up.  In some
situations the code free's up an existing route at the head of the list.
Cleaning the pointers in the list but never touching the original pointer.
In that case notice and update the old pointer.

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>

eigrpd: Correctly set the mtu for eigrp packets sent

This version of eigrp pre-calculated the eigrp metric
to be a default of 1500 bytes, but unfortunately it
had entered the byte order wrong.

Modify the code to properly set the byte order
according to the eigrp rfc as well as actually
read in and transmit the mtu of the interface
instead of hard coding it to 1500 bytes.

Fixes: #7986
Signed-off-by: Donald Sharp <sharpd@nvidia.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>

doc: Updated topotest.rst doc with iperf

1. We are using iperf to send IGMP join and traffic for multicast suites. Iperf must be
   used to run all multicast suite

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

tests: Add multicast-pim-sm-topo2 test suite

1. Added 8 test cases to verify multicast PIM SM functionality

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

tests: Add multicast-pim-sm-topo1 test suite

1. Added 10 test cases to verify multicast PIM SM functionality

Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.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

pimd: SGRpt prune received during prune didn't override holdtime

RCA: There were 2 problems.
1. SGRpt prune expiry didn't create S,G entry with none oil when no other
interfaces were part of the oil.
2. When restarting the timer with new hold value, comparision was missing and
old timer was not stopping.

Fix:
SGRpt Prune pending expiry will put SG entry with none oil if no other

Signed-off-by: Saravanan K <saravanank@vmware.com>
interfaces present. If present we will be deleting the inherited oif from oil.
Deleting the oif in that scenario will take care of changing mroute.
When alone interface expires in SGRpt prune pending state, we shall detect by
checking installed flag. if not installed, install mroute.

*: 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>