zebra: fix FPM abort for unreach/prohibit routes

b0e9567ed162da708f8d0b3a3caf87cd03b62e96 fixed an issue whereby
zebra would abort while building an update for a blackhole route.

The same issue, `assert(data_len)` failing in
`zfpm_build_route_updates()`, can be observed when building updates
for unreachable and prohibit routes.

To address this `netlink_route_info_fill()` is updated to not
indicate failure, due to lack of nexthops, for any blackhole routes.

Signed-off-by: Duncan Eastoe <duncan.eastoe@att.com>
(cherry picked from commit 94f7786375030e08063cdae5b4577edf26adb456)

Merge pull request #7190 from ton31337/feature/bgpd_cherry_picks

bgpd: [7.5] timers, static routes, router-id backports

bgpd: allow derived router-id update if previously 0x0

Problem found that if a router-id was not defined or derived
initially, the bgp->router_id would be set to 0x0 and used
for determining auto-rd values. When bgp received a subsequent
router-id update from zebra, bgp would not completely process
the update since it was treated as updating an already derived
router-id with a new value, which is not desired.  This also
could leave the auto rd/rt inforamation missing or invalid in
some cases.  This fix allows updating the derived router-id if
the previous value was 0/0.

Ticket: CM-31441
Signed-off-by: Don Slice <dslice@nvidia.com>

bgpd: Use bgp instance's default keepalive interval if < (holdtime/3)

bgp->default_keepalive was not considered when setting
peer->v_keepalive, causing the effective keepalive interval to
always be (holdtime/3), even when default_keepalive < (holdtime/3).
This ensures that the default_keepalive is used when it's set and
is < (holdtime/3).

Signed-off-by: Trey Aspelund <taspelund@cumulusnetworks.com>
(cherry picked from commit d8bf8c6128f2e493d473148213bd663a500c7f73)

bgpd: Allow bgp static routes to use /32's

If you are including a network statement of a /32
then the current bgp martian checks will match the /32
together.

Problem:
!
router bgp 3235
 neighbor 192.168.161.2 remote-as external
 neighbor 192.168.161.131 remote-as external
 !
 address-family ipv4 unicast
  network 10.10.3.11/32
  network 192.168.161.0/24
  no neighbor 192.168.161.2 activate
  neighbor 192.168.161.2 route-map BLUE in
 exit-address-family
!
eva# show bgp ipv4 uni
BGP table version is 1, local router ID is 10.10.3.11, vrf id 0
Default local pref 100, local AS 3235
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
   10.10.3.11/32    0.0.0.0(eva)             0         32768 i
*> 192.168.161.0/24 0.0.0.0(eva)             0         32768 i
Displayed  2 routes and 2 total paths
eva# show bgp import-check-table
Current BGP import check cache:
 192.168.161.0 valid [IGP metric 0], #paths 1
  if enp39s0
  Last update: Fri Sep 25 08:00:42 2020
 10.10.3.11 valid [IGP metric 0], #paths 1
  if lo
  Last update: Fri Sep 25 08:00:42 2020
eva# show bgp ipv4 uni summ
BGP router identifier 10.10.3.11, local AS number 3235 vrf-id 0
BGP table version 1
RIB entries 3, using 576 bytes of memory
Peers 1, using 21 KiB of memory
Neighbor                 V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt
janelle(192.168.161.131) 4      60000        69        70        0    0    0 00:03:21            0        1
Total number of neighbors 1

When we are deciding that a nexthop is valid there is not much point in checking
that a static route has a martian nexthop or not, since we self derived it already.

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

Merge pull request #7140 from pguibert6WIND/netns_refactor_v75

Netns refactor v75

Merge pull request #7161 from mjstapp/fix_topo_daemons_list_7_5

[7.5] tests: fix bug in handling of daemons to start

tests: fix bug in handling of daemons to start

Ensure the list of daemons to start is either the one specified
by a caller or the default one from the router configuration.

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

zebra: fix fd going out of scope leaks the handle

the file descriptor is closed if it has been locally created.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

Merge pull request #7151 from donaldsharp/7.5_bsd_address

zebra: Allow FreeBSD to set and delete addresses from an interface

zebra: Allow FreeBSD to set and delete addresses from an interface

This series of events:

$ sudo ifconfig lo0 add 4.4.4.4/32
$ sudo ifconfig lo0 inet 4.4.4.4/32 delete

would end up leaving the 4.4.4.4/32 address on the interface under
freebsd.

This all boils down to the fact that the interface is not
considered connected yet we have a destination.  If the
destination is the same and we are not connected ignore
it on freebsd.

I am sure there are other fun scenarios that someone
will have to squirrel out.

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

bgp: remove duplicate command installs

[no_]neighbor_nexthop_self_cmd & [no_]neighbor_nexthop_self_force_cmd
have duplicate install_element actions on the EVPN_NODE. This causes
duplicate command log errors which are caught by topotests. Remove
these.

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

test: topotest bgp_evpn_rt5 runs on kernel > 4.18

if kernel is less than 4.18, then test will not run.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

topotests: bgp_evpn_rt5 test uses ip link instead of bridge-utils

bridge-utils package is not available on tested distributions.
use ip link instead.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

topotests: add bgp_evpn_rt5 test with vrf netns backend

this test checks connectivity between a vrf-lite device and a vrf-netns
device. this ensures that evpn serice is importing appropriate evpn rt5
entries in the correct vrf.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

zebra: support for macvlan interfaces

mac vlan interfaces are supported in different network namespaces.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

doc: add some documentation about bgp evpn netns support

a linux configuration gives some explanation on how to set up an evpn
overlay in network namespaces.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

zebra: dynamically detect vxlan link interfaces in other netns

this is used when parsing the newly network namespaces. actually, to
track the link of some interfaces like vxlan interfaces, both link index
and link nsid are necessary. if a vxlan interface is moved to a new
netns, the link information is in the default network namespace, then
LINK_NSID is the value of the netns by default in the new netns. That
value of the default netns in the new netns is not known, because the
system does not automatically assign an NSID of default network
namespace in the new netns. Now a new NSID of default netns, seen from
that new netns, is created. This permits to store at netns creation the
default netns relative value for further usage.
Because the default netns value is set from the new netns perspective,
it is not needed anymore to use the NETNSA_TARGET_NSID attribute only
available in recent kernels.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

bgpd: sanity check when updating nexthop from bgp to zebra

nexthop may sometimes not be passed through zebra, like for onlink
messages.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

lib, zebra: reuse and adapt ns_list walk functionality

the walk routine is used by vxlan service to identify some contexts in
each specific network namespace, when vrf netns backend is used. that
walk mechanism is extended with some additional paramters to the walk
routine.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

zebra: local mac entries populated in correct netnamespace

MAC address neighbours are read on the same netnamespace where the vxlan
interface is.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

zebra: when parsing local entry against dad, retrieve config

when duplicate address detection is observed, some incrementation,
some timing mechanisms need to be done. For that the main evpn
configuration is retrieved. Until now, the VRF that was storing the dad
config parameters was the same VRF that hosted the VXLAN interface. With
netns backend, this is not true, as the VXLAN interface is in the
same VRF as the bridge interface. The modification takes same definition
as in BGP, that is to say that there is a single bgp evpn instance, and
this is that instance that will give the correct config settings.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

bgpd: evpn nexthop can be changed by default

There can be cases where evpn traffic is not meshed across various
endpoints, but sent to a central pe. For this situation, add the
configuration knobs to force nexthop attribute. Upon that change,
nexthop unchanged attribute is automatically disabled.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

zebra: zvni_map_to_vlan() adaptation for all namespaces

this change is needed when a MAC/IP entry is learned by zebra, and the
entry happens to be in a different namespace. So that the entry be
active, the correct vni match has to be found.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

zebra: fdb and neighbor table are read for all zns

all network namespaces are read so as to collect interesting fdb and
neighbor tables for EVPN.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

zebra: add ns_id attribute to mac structure

this information is necessary for local information, because the
interface associated to the mac address is stored with its ifindex, and
the ifindex may not be enough to get to the right interface when it
comes with multiple network namespaces.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

zebra: bridge layer2 information records ns_id where bridge is

when working with vrf netns backend, two bridges interfaces may have the
same bridge interface index, but not the same namespace. because in vrf
netns backend mode, a bridge slave always belong to the same network
namespace, then a check with the namespace id and the ns id of the
bridge interface permits to resolve correctly the interface pointer.
The problem could occur if a same index of two bridge interfaces can be
found on two different namespaces.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

zebra, lib: new API to get absolute netns val from relative netns val

when receiving a netlink API for an interface in a namespace, this
interface may come with LINK_NSID value, which means that the interface
has its link in an other namespace. Unfortunately, the link_nsid value
is self to that namespace, and there is a need to know what is its
associated nsid value from the default namespace point of view.
The information collected previously on each namespace, can then be
compared with that value to check if the link belongs to the default
namespace or not.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

zebra, lib: store relative default ns id in each namespace

to be able to retrieve the network namespace identifier for each
namespace, the ns id is stored in each ns context. For default
namespace, the netns id is the same as that value.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

zebra, lib: add an internal API to get relative default nsid in other ns

as remind, the netns identifiers are local to a namespace. that is to
say that for instance, a vrf <vrfx> will have a netns id value in one
netns, and have an other netns id value in one other netns.
There is a need for zebra daemon to collect some cross information, like
the LINK_NETNSID information from interfaces having link layer in an
other network namespace. For that, it is needed to have a global
overview instead of a relative overview per namespace.
The first brick of this change is an API that sticks to netlink API,
that uses NETNSA_TARGET_NSID. from a given vrf vrfX, and a new vrf
created vrfY, the API returns the value of nsID from vrfX, inside the
new vrf vrfY.
The brick also gets the ns id value of default namespace in each other
namespace. An additional value in ns.h is offered, that permits to
retrieve the default namespace context.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

zebra: map vxlan interface to bridge interface with correct ns id

an incoming bridge index has been found, that is linked with vxlan
interface, and the search for that bridge interface is done. In
vrf-lite, the search is done across the same default namespace, because
bridge and vxlan may not be in the same vrf. But this behaviour is wrong
when using vrf netns backend, as the bridge and the vxlan have to be in
the same vrf ( hence in the same network namespace). To comply with
that, use the netnamespace of the vxlan interface. Like that, the
appropriate nsid is passed as parameter, and consequently, the search is
correct, and the mac address passed to BGP will be ok too.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

zebra: display interface slave type

interface slave type is displayed.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

zebra: zvni_map_to_svi() adaptation for other network namespaces

the function is called with all the network namespaces.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

zebra: zvni_from_svi() adaptation for other network namespaces

other network namespaces are parsed because bridge interface can be
bridged with vxlan interfaces with a link in the default vrf that hosts
l2vpn.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

zebra: importation of bgp evpn rt5 from vni with other netns

With vrf-lite mechanisms, it is possible to create layer 3 vnis by
creating a bridge interface in default vr, by creating a vxlan interface
that is attached to that bridge interface, then by moving the vxlan
interface to the wished vrf.
With vrf-netns mechanism, it is slightly different since bridged
interfaces can not be separated in different network namespaces. To make
it work, the setup consists in :
- creating a vxlan interface on default vrf.
- move the vxlan interface to the wished vrf ( with an other netns)
- create a bridge interface in the wished vrf
- attach the vxlan interface to that bridged interface

from that point, if BGP is enabled to advertise vnis in default vrf,
then vxlan interfaces are discovered appropriately in other vrfs,
provided that the link interface still resides in the vrf where l2vpn is
advertised.
to import ipv4 entries from a separate vrf, into the l2vpn, the
configuration of vni in the dedicated vrf + the advertisement of ipv4
entries in bgp vrf will import the entries in the bgp l2vpn.

the modification consists in parsing the vxlan interfaces in all network
namespaces, where the link resides in the same network namespace as the
bgp core instance where bgp l2vpn is enabled.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

Merge pull request #7134 from ton31337/fix/do_not_allow_setting_maximum-prefix-out_global_7.5

bgpd: [7.5] Create separate udpate-group when using `maximum-prefix-out` command

doc: Say that maximum-prefix-out requires it's own update-group

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

bgpd: Create separate udpate-group when using `maximum-prefix-out` command

This is needed to avoid mangling update-group which is used for many peers.

Sent prefix count is managed by update-groups.

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

Merge pull request #7121 from AnuradhaKaruppiah/7.5-mh-macip-fixes

zebra: fixup a neigh del bug introduced by a previous commit for MAC-IP sync

zebra: fixup a neigh del bug introduced by a previous commit for MAC-IP sync

Problem commit -
[
b169fd6fd59ed zebra: support for MAC-IP sync routes
]

That commit had accidentally replaced a mac-ip del to bgp with a mac
del (consequence of a bad cut-paste).

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
(cherry picked from commit fb8f609d486f132c7fab41d6bb67372d829137aa)

Merge pull request #7115 from chiragshah6/evpn_7_5

zebra: dup detected mac avoid update to bgpd

Merge pull request #7118 from AnuradhaKaruppiah/7.5-l3vni_ecom_leak

bgpd: fix ecom leak handling l3vni update

bgpd: fix ecom leak handling l3vni update

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
(cherry picked from commit 84f22ecc05b08d7266605fbd9f6089d6d61e9f03)

zebra: dup detected mac avoid update to bgpd

When a MAC is detected duplicate on a local
learn event (with freeze action),
do not send update to bgp to advertise into
evpn control plane.

With evpn mh, inform_client flag is set and
sends notification to bgp albeit dup detect
is set.

Check mac are detected as duplicate before
setting inform_client to true.

Ticket:CM-29817
Reviewed By:CCR-10329
Testing Done:

Enable DAD with freeze action
Upon local learn MAC detected as duplica

Signed-off-by: Chirag Shah <chirag@nvidia.com>

Merge pull request #7087 from donaldsharp/nhrp_leafref_7.5

nhrpd: add frr-vrf to the list of implemented yang modules

nhrpd: add frr-vrf to the list of implemented yang modules

PR #6376 introduced a VRF leafref in the frr-interface YANG module.
That change exposed a bug in the northbound layer that is causing
nhrpd to crash under certain circumstances. Even though nhrpd wasn't
converted to the new northbound model yet, make it implement the
frr-vrf module in order to work around this problem. This is a
temporary fix until a better solution is available.

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

Merge pull request #7076 from donaldsharp/snap_fix_7.5

snapcraft: Update libyang version

snapcraft: Update libyang version

Update the snapcraft build of libyang to the version we
actually want to be using v1.0.184

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

Merge pull request #7071 from opensourcerouting/pbrd-leafref-workaround-7.5

[7.5] pbrd: add frr-vrf to the list of implemented yang modules

pbrd: add frr-vrf to the list of implemented yang modules

PR #6376 introduced a VRF leafref in the frr-interface YANG module.
That change exposed a bug in the northbound layer that is causing
pbrd to crash under certain circumstances. Even though pbrd wasn't
converted to the new northbound model yet, make it implement the
frr-vrf module in order to work around this problem. This is a
temporary fix until a better solution is available.

Signed-off-by: Renato Westphal <renato@opensourcerouting.org>

Merge pull request #7047 from qlyoung/fix-zlog-target-null-deref

lib: fix possible null dereference in zlog

Merge pull request #7031 from dslicenc/global-bgp-update-delay

Global bgp update delay

Merge pull request #7032 from qlyoung/devdocs-libyang-hashtable

Dev docs update for libyang, hash table invariants

doc: update libyang blurb for 1.x

Signed-off-by: Quentin Young <qlyoung@nvidia.com>

doc: add notes about hash table invariants

Signed-off-by: Quentin Young <qlyoung@nvidia.com>

Merge pull request #6376 from opensourcerouting/bump-libyang-req-version-1.x

build, yang: bump libyang minimum required version to 1.0.184

lib: fix possible null dereference in zlog

In some cases one or both of the zlog targets in use here can be null,
we need to check for that.

Interestingly it appears we don't crash even when this is the case.
Undefined behavior ftw

Signed-off-by: Quentin Young <qlyoung@nvidia.com>

Merge pull request #6969 from ton31337/feature/autoshutdown_if_rtt_higher_than_specified

bgpd: Add `neighbor <neigh> shutdown rtt` command

topotests: Add test for bgp update-delay configuration

Signed-off-by: Don Slice <dslice@nvidia.com>

bgpd: add global config for update-delay

Enhancement to update-delay configuration to allow setting globally
rather than per-instance.  Setting the update-delay is allowed either
per-vrf or globally, but not both at the same time.

Ticket: CM-31096
Signed-off-by: Don Slice <dslice@nvidia.com>

doc: Add `neighbor <x.x.x.x.> shutdown rtt <milliseconds>`

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

bgpd: Add `neighbor <neigh> shutdown rtt` command

This would be useful in cases with lots of peers and shutdown them
automatically if RTT goes above the specified limit.

A host with 512 or more IPv6 addresses has a higher latency due to
ipv6_addr_label(). This method tries to pick the best candidate address
fo outgoing connection and literally increases processing latency.

```
Samples: 28  of event 'cycles', Event count (approx.): 22131542
  Children      Self  Command  Shared Object      Symbol
  +  100.00%     0.00%  ping6    [kernel.kallsyms]  [k] entry_SYSCALL_64_fastpath
  +  100.00%     0.00%  ping6    [unknown]          [.] 0x0df0ad0b8047022a
  +  100.00%     0.00%  ping6    libc-2.17.so       [.] __sendto_nocancel
  +  100.00%     0.00%  ping6    [kernel.kallsyms]  [k] sys_sendto
  +  100.00%     0.00%  ping6    [kernel.kallsyms]  [k] SYSC_sendto
  +  100.00%     0.00%  ping6    [kernel.kallsyms]  [k] sock_sendmsg
  +  100.00%     0.00%  ping6    [kernel.kallsyms]  [k] inet_sendmsg
  +  100.00%     0.00%  ping6    [kernel.kallsyms]  [k] rawv6_sendmsg
  +  100.00%     0.00%  ping6    [kernel.kallsyms]  [k] ip6_dst_lookup_flow
  +  100.00%     0.00%  ping6    [kernel.kallsyms]  [k] ip6_dst_lookup_tail
  +  100.00%     0.00%  ping6    [kernel.kallsyms]  [k] ip6_route_get_saddr
  +  100.00%     0.00%  ping6    [kernel.kallsyms]  [k] ipv6_dev_get_saddr
  +  100.00%     0.00%  ping6    [kernel.kallsyms]  [k] __ipv6_dev_get_saddr
  +  100.00%     0.00%  ping6    [kernel.kallsyms]  [k] ipv6_get_saddr_eval
  +  100.00%     0.00%  ping6    [kernel.kallsyms]  [k] ipv6_addr_label
  +  100.00%   100.00%  ping6    [kernel.kallsyms]  [k] __ipv6_addr_label
  +    0.00%     0.00%  ping6    [kernel.kallsyms]  [k] schedule
```

This is how it works:

```
~# vtysh -c 'show bgp neigh 192.168.0.2 json' | jq '."192.168.0.2".estimatedRttInMsecs'
9
~# tc qdisc add dev eth1 root netem delay 120ms
~# vtysh -c 'show bgp neigh 192.168.0.2 json' | jq '."192.168.0.2".estimatedRttInMsecs'
89
~# vtysh -c 'show bgp neigh 192.168.0.2 json' | jq '."192.168.0.2".estimatedRttInMsecs'
null
~# vtysh -c 'show bgp neigh 192.168.0.2 json' | jq '."192.168.0.2".lastResetDueTo'
"Admin. shutdown"
```

Warning message:
bgpd[14807]: 192.168.0.2 shutdown due to high round-trip-time (200ms > 150ms)

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

bgpd: Update RTT on KEEPALIVE message

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

Merge pull request #6982 from achernavin22/ospf_nssa_after_redist

ospfd: install Type-7 when NSSA enabled after redistribution

Merge pull request #7040 from qlyoung/fix-evpn-attribute-hash-error

bgpd: modify attr fields before hash insert

Merge pull request #7037 from volta-networks/fix_traps_bgp

Fix bgpBackwardTransition traps

Merge pull request #7051 from donaldsharp/ospf_test_speedup

Ospf test speedup

Merge pull request #7054 from qlyoung/fix-bgp-mplsvpn-nlri-missing-length-checks

bgpd: fix mplsvpn nlri garbage heap read

Merge pull request #7046 from qlyoung/fix-various-integer-issues

Fix various integer signedness / overflow issues

Merge pull request #7055 from qlyoung/fix-bgp-localpref-overflow

bgpd: fix asserting read of localpref

Merge pull request #6934 from Niral-Networks/niral_dev_vrf_isis_core_pr4

isisd, yang, doc : Support for different VRF in ISIS.

Merge pull request #6971 from volta-networks/fix_ldp_no_config

ldpd: Fix issue when starting up LDP with no configuration.

Merge pull request #6589 from NaveenThanikachalam/gr_fixes

bgpd: GR fixes

ldpd: Fix issue when starting up LDP with no configuration.

LDP would mark all routes as learned on a non-ldp interface.  Then
when LDP was configured the labels were not updated correctly.  This
commit fixes issues 6841 and 6842.

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

Merge pull request #6826 from pjdruddy/bgp-auth-vrf-frr

Bgp auth vrf frr

Merge pull request #7053 from mjstapp/fix_ospf6_intf_sa

ospf6d: fix SA warning

Merge pull request #7052 from mjstapp/fix_stream_get_data

lib: remove unused stream_get_data api

Merge pull request #6891 from opensourcerouting/feature/sr-te-bgpd

bgpd: Add support for SR-TE Policies in route-maps

bgpd: use stream_rewind_getp() to remove overflow

Passing a negative argument to a size_t parameter creates an overflow
condition

Signed-off-by: Quentin Young <qlyoung@nvidia.com>

lib: add stream_rewind_getp()

stream_forward_getp() cannot be used with negative numbers due to the
size_t argument, we'll end up doing overflow arithmetic.

Signed-off-by: Quentin Young <qlyoung@nvidia.com>

bgpd: fix asserting read of localpref

Attribute may not be long enough to contain a localpref value, resulting
in an assert on stream size. Gracefully handle this case instead.

Signed-off-by: Quentin Young <qlyoung@nvidia.com>

bgpd: fix mplsvpn nlri garbage heap read

NLRI parsing for mpls vpn was missing several length checks that could
easily result in garbage heap reads past the end of nlri->packet.

Convert the whole function to use stream APIs for automatic bounds
checking...

Signed-off-by: Quentin Young <qlyoung@nvidia.com>

Merge pull request #6926 from kuldeepkash/dynamic_route_leak

tests: Add bgp_vrf_dynamic_route_leak test suite

ospf6d: fix SA warning

Fix an SA issue in ospf6_interface.c.

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

lib: remove unused stream_get_data api

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

tests: Reduce run time of bgp_l3vpn_to_bgp_vrf

Reduces run time of the bgp_l3vpn_to_bgp_vrf topotests
from ~118 seconds to ~87 seconds by reducing hello timers
in bgp and ospf

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

tests: Reduce bfd-topo2 run time

Reduce run time of bfd-topo2 from ~62 seconds to ~33 seconds
by modifying the hello/dead intervals for both ospf and ospfv3

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

tests: Reduce ldp-oc-acl-topo1 run time

Reduce the ldp-oc-acl-topo1 test run time from ~69 seconds
to ~39 seconds.

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

tests: Reduce bgp-evpn-vxlan-topo1 run time

Reduce the runtime from ~82 seconds to ~51 seconds by
reducing hello/hold timers for both bgp and ospf.

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

tests: Reduce ospf-topo1 run time

Reduce run time from ~114 seconds to ~55 seconds by
configuring hello/dead interval timers for ospf and ospfv3

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

tests: Reduce bgp_l3vpn_to_bgp_direct run time

Reduce run time from ~76 seconds to ~47 seconds by modifying
both bgp and ospf timers to be more aggressive

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

tests: Reduce ldp-vpls-topo1 run time

Reduce this tests run time from ~76 seconds to ~49 seconds
by decreasing the hello/dead interval timers in ospf

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

tests: Speedup bgp_rfapi_basic_sanity run

Decrease run time from ~70 seconds to ~41 seconds by
reducing hello/dead interval timers in ospf

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

tests: Speedup bfd-profiles-topo1 runtime

Decrease run time from ~70 seconds to ~60 seconds
by modifying the hello/dead interval interface timers
in ospf

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

tests: Decrease ospf-sr-topo1 run time

Reduce ospf-sr-topo1 run time from ~60 seconds to ~30 seconds
by shortening the hello and dead timers.

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

tests: ospf-topo2 speed up

Modify ospf hello/dead timers to speed up run time from ~25 seconds to
~17 seconds.

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

tests: Modify ldp-oc-topo1 to run faster

Convert run times by lowering hello/dead interval timers to
smaller values from ~66 seconds to ~36 seconds.

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

tests: Speedup ldp-topo1 tests

These ospf timer changes, speed up convergence from ~85 seconds to
~40 seconds.

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

Merge pull request #7043 from donaldsharp/bgp_features_speedup

tests: Speed up bgp_features topotests by a lot

ospfd: install Type-7 when NSSA enabled after redistribution

If NSSA is enabled before redistribution is configured, Type-7 LSA's
are installed. But if NSSA is enabled after redistribution is
configured, Type-7 LSAs are missing.

With this change, when NSSA is enabled, scan for external LSA's and
if they exist, install Type-7.

Signed-off-by: Alexander Chernavin <achernavin@netgate.com>