When bgp is using `bgp suppress-fib-pending` and the end
operator is using network statements, bgp was not sending
the network'ed prefix'es to it's peers. Fix this.
Also update the test cases for bgp_suppress_fib to test
this new corner case( I am sure that there are going to
be others that will need to be added ).
Fixes: #12112
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When an SRv6 locator is unset, all the SRv6 SIDs allocated from the
locator are removed. Before freeing the memory allocated for an SRv6
SID, we check if the pointer to the SID is `NULL`.
However, checking for `NULL` before freeing memory is useless.
This PR aims to improve the code's readability by removing the
useless `NULL` checks.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Currently, if `bgp max-med on-startup` is configured, after BGP session
is established for the first time, a timer for the specified time is
started. When the timer is expired, an UPDATE message should be sent to
reflect changes in the routes' MED value. The problem is that the routes
are being suppressed because based on the attributes they look like they
have not changed. However, in the case of max-med, the value is copied
to the packet directly from `bgp->maxmed_value`, not from the
attributes. Thus, changes in this case cannot be detected by comparing
attributes.
With this fix, avoid route suppressing when the `max-med on-startup`
timer expires and initiates an UPDATE.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
With this fix, make "no match rpki" in a route-map actually remove the
node in the candidate configuration instead of creating it.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
No mistake, just to unify style for the parameter of function address - remove
ampersand. In current code, only this one place of `hook_register()`s needs
to be made.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
There are lib debugs being set but never show up in
`show debug` commands because there was no way to show
that they were being used. Add a bit of infrastructure
to allow this and then use it for `debug route-map`
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In order to send correct SRv6 L3VPN advertisement, we need to save
srv6_locator_chunk in vpn_policy. With this information, we can
construct correct SRv6 L3VPN advertisement packets.
Signed-off-by: Ryoga Saito <ryoga.saito@linecorp.com>
There is code that sets the pi based upon matching it against
the same peer. In this code the type and sub-type are also
compared to the passed in type and sub-type. Let's just use
type and sub-type as that if we have a pi we know type and sub-type
are already correct. This should also make the first iteration
work correctly when the pi has not been created yet when we call
the martian_update function.bgpd: Remove unnecessary check for pi and setting type and sub-type
There is code that sets the pi based upon matching it against
the same peer. In this code the type and sub-type are also
compared to the passed in type and sub-type. Let's just use
type and sub-type as that if we have a pi we know type and sub-type
are already correct. This should also make the first iteration
work correctly when the pi has not been created yet when we call
the martian_update function.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
- for a given IP nexthop, dump all NH entries, including
colored entries, or entries with an ifindex.
- when a given IP nexthop is requested, the path is displayed.
For better readibility, remove the carriage return between
'Last update' and 'Paths', because ctime() function already
performs carriage return.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
```
donatas-pc# show ip bgp 100.100.100.0/24 longer-prefixes
BGP table version is 13, local router ID is 10.10.10.10, vrf id 0
Default local pref 100, local AS 65000
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
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
100.100.100.0/24 0.0.0.0 0 32768 i
Displayed 1 routes and 15 total paths
donatas-pc# show ip bgp 100.100.100.0/24
BGP routing table entry for 100.100.100.0/24, version 0
Paths: (1 available, no best path)
Not advertised to any peer
Local
0.0.0.0 (inaccessible, import-check enabled) from 0.0.0.0 (10.10.10.10)
Origin IGP, metric 0, weight 32768, invalid, sourced, local
Last update: Tue Oct 4 11:31:44 2022
donatas-pc# show ip bgp 100.100.100.0/24 json
{
"prefix":"100.100.100.0\/24",
"version":0,
"paths":[
{
"aspath":{
"string":"Local",
"segments":[
],
"length":0
},
"origin":"IGP",
"metric":0,
"weight":32768,
"valid":false,
"version":0,
"sourced":true,
"local":true,
"lastUpdate":{
"epoch":1664872304,
"string":"Tue Oct 4 11:31:44 2022\n"
},
"nexthops":[
{
"ip":"0.0.0.0",
"hostname":"donatas-pc",
"afi":"ipv4",
"accessible":false,
"importCheckEnabled":true,
"used":true
}
],
"peer":{
"peerId":"0.0.0.0",
"routerId":"10.10.10.10"
}
}
]
}
donatas-pc#
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The issuing of `show bgp nexthop A.B.C.D` fails even if that
nexthop exists:
eva# show bgp nexthop 192.168.119.120
specified nexthop does not have entry
Fixed:
eva# show bgp nexthop 192.168.119.120
192.168.119.120 valid [IGP metric 0], #paths 0, peer 192.168.119.120
if enp39s0
Last update: Fri Sep 30 14:55:13 2022
Paths:
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In bgp_open_option_parse the code is checking that the
stream has at least 2 bytes to read ( the opt_type and
the opt_length). However if BGP_OPEN_EXT_OPT_PARAMS_CAPABLE(peer)
is configured then FRR is reading 3 bytes. Which is not good
since the packet could be badly formateed. Ensure that
FRR has the appropriate data length to read the data.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In peek_for_as4_capability the code is checking that the
stream has at least 2 bytes to read ( the opt_type and the
opt_length ). However if BGP_OPEN_EXT_OPT_PARAMS_CAPABLE(peer)
is configured then FRR is reading 3 bytes. Which is not good
since the packet could be badly formated. Ensure that
FRR has the appropriate data length to read the data.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
