1. Increasing BGP convergence wait time to overcome Ubuntu 16.04 arm8 box, as
bgp neighorship is taking more time in this particular testbed.
2. Debugged bgp-ecmp-topo2 failures and here also it seems to be bgp convergence
issue, doing some enhancement in scripts to handle it
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
constants are int-typed, so adding something to an uint8_t yields an
int. Nevermind the fact that varargs calling conventions require
upcasting everything smaller than an int to an int anyways...
Signed-off-by: David Lamparter <equinox@diac24.net>
Remove mid-string line breaks, cf. workflow doc:
.. [#tool_style_conflicts] For example, lines over 80 characters are allowed
for text strings to make it possible to search the code for them: please
see `Linux kernel style (breaking long lines and strings)
<https://www.kernel.org/doc/html/v4.10/process/coding-style.html#breaking-long-lines-and-strings>`_
and `Issue #1794 <https://github.com/FRRouting/frr/issues/1794>`_.
Scripted commit, idempotent to running:
```
python3 tools/stringmangle.py --unwrap `git ls-files | egrep '\.[ch]$'`
```
Signed-off-by: David Lamparter <equinox@diac24.net>
It's hard to cope with cases when next-hop is changed/unchanged or
peers are non-direct.
It would be better to show the hostname and nexthop IP address (both)
under `show bgp` to quickly identify the source and the real next-hop
of the route.
If `bgp default show-nexthop-hostname` is toggled the output looks like:
```
spine1-debian-9# show bgp
BGP table version is 1, local router ID is 2.2.2.2, vrf id 0
Default local pref 100, local AS 65002
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
* 2a02:4780::/64 fe80::a00:27ff:fe09:f8a3(exit1-debian-9)
0 0 65001 ?
spine1-debian-9# show ip bgp
BGP table version is 5, local router ID is 2.2.2.2, vrf id 0
Default local pref 100, local AS 65002
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.255.255.0/24 192.168.0.1(exit1-debian-9)
0 0 65001 ?
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
If we are asked to check if a nexthop is active and it matches a
connected route but the ifindex on it does not match the interface
with the connected route, mark as inactive. This is a bad nexthop.
Before, we would skip this check and just assume any nexthop that matches
on a connected route is valid and return here then fail during
installation. This adds a check for the IPV*_ifindex nexthop case where the
ifindex we have been sent doesn't match.
Old:
F>r 0.0.0.0/0 [200/0] via 20.0.0.2, test, weight 1, 00:00:27
r via 40.4.4.4, lo, weight 1, 00:00:27
New:
F>* 0.0.0.0/0 [200/0] via 20.0.0.2, test, weight 1, 00:00:06
* via 40.4.4.4, lo inactive, weight 1, 00:00:06
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
`force_nhg` is only settable when calling from `fpm`, so if the kernel
was using next hop groups it would override our knob.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
no need to check cicuit->area, as all code paths leading there
had already dereferenced it.
Fixes CID 1496314
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
Cleanup the marking of a nhc as installed/removed based on table
route installation.
We were not even handling the removal state at all.
We saw some timing issues with the routes being installed/removed
multiple times and then never resending the pbr map due to bad states
on the nhgc.
Dont worry about checking if its already marked installed before
scheduling the policy walk. We have a check in `pbr_send_map()`
to ensure we dont try to resend a map sequence already installed.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Withdraw route from RIB if we detect the NHG is not valid
anymore. We were seeing an issue where we would leave a route
in zebra's RIB if it was recursive despite it being removed
from the kernel due to an interface going down.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Block signals in child/additional pthreads; frr daemons generally
expect that only the main thread will handle signals.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Stop printing hard-coded 30 seconds in a couple of places in
bgp.py in the topojson infra - print the actual time
spent waiting.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
```
exit1-debian-9# show bgp summary
IPv4 Unicast Summary:
BGP router identifier 192.168.0.1, local AS number 100 vrf-id 0
BGP table version 8
RIB entries 15, using 2880 bytes of memory
Peers 2, using 43 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt
192.168.0.2 4 200 10 6 0 0 0 00:00:35 8 8
2a02:4780::2 4 0 0 1 0 0 0 never Active 0
Total number of neighbors 2
exit1-debian-9# show bgp summary established
IPv4 Unicast Summary:
BGP router identifier 192.168.0.1, local AS number 100 vrf-id 0
BGP table version 8
RIB entries 15, using 2880 bytes of memory
Peers 2, using 43 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt
192.168.0.2 4 200 10 6 0 0 0 00:00:39 8 8
Total number of neighbors 2
exit1-debian-9# show bgp summary failed
IPv4 Unicast Summary:
BGP router identifier 192.168.0.1, local AS number 100 vrf-id 0
BGP table version 8
RIB entries 15, using 2880 bytes of memory
Peers 2, using 43 KiB of memory
Neighbor EstdCnt DropCnt ResetTime Reason
2a02:4780::2 0 0 never Waiting for peer OPEN
Total number of neighbors 2
exit1-debian-9#
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
On startup of both zebra and ospfd. If ospfd has not
received a valid router-id *but* has received interface
data, interfaces will not be turned on in the state
machine. When ospf finally receives a valid router-id
it would never actually kick the state machine into
action for those interfaces it has been configured for.
Modify ospf on router id changes, *if* the old
router id was INADDR_ANY *and* the interface is
operative *and* the oi->state is ISM_Down, give
it the old kick in the patooeys
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
