In current code, `build_evpn_type2_prefix()` doesn't distinguish ARP
according to the `ip` parameter. The `ip` parameter from caller is
always non-NULL.
Be consistent and not confused, just remove the unnecessary check.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
The "add" parameter of `bgp_evpn_mh_route_update()` makes no sense.
Just remove it to clarify this function, and remove the relevant check
with "add" as well.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
When `bgp_evpn_new()` is called, the `bgp` parameter MUST be non-NULL,
remove this unnecessary check and remove the NULL check for returned
`struct bgpevpn *`, which should be non-NULL.
And modify `import_rt_new()` in the same way.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Two changes for `delete_global_type2_routes()`:
1) Remove check of `bgp_dest_has_bgp_path_info_data(rddest)`.
It is unnecessary(`dest->info` should not be NULL) and misleading.
`if (rddest && bgp_dest_has_bgp_path_info_data(rddest))`
Use (locked) node with this check, but unlock with `if (rddest)`,
The mismatched condition is misleading, there seems to be a
mistake to extra unlock.
Just make it clear, immediately exit with `(!rddest)`.
2) Remove checking returned value for it, and use `void` as return type.
It is unnecessary and wrong. Even the check failed, it should continue
to delete other types of routes.
Just remove the check and go through.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
We will hit this soon because uint32_t will be not enough.
Two more flags gonna be added for rfc8538.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
N-bit flag should be exchanged in BGP OPEN messages, not only when the
bgpd is restarted/started.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Peer groups when various forms of `bgp capability extended-nexthop`
is entered on them are toggling the nexthop tracking status of peers
in their peer group. This is ok when the peer is not interface based.
But it is not ok when the peer is interface based as that it will turn
off the ability of FRR to properly work with that peer type.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Do not interface based peers change anything about when a
[no] neighbor <interface> capability extended-nexthop
is entered.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
FRR is displaying that the peer enhanced capability command is not
turned on when the interface is part of a peer group. Saving the
config and then reloading actually turns it off.
Fix the code so that FRR does not display the enhanced capability
for interface based peers.
Fixes: #11108
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Before we just showed always the first server which is wrong.
Now we have:
```
spine1-debian-11# show rpki cache-connection
Connected to group 1
rpki tcp cache 192.168.10.17 8283 pref 1
rpki tcp cache 192.168.10.17 8282 pref 2 (connected)
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
`rpki stop` and `rpki start` were already, let's add `rpki reset` as well.
Instead of going into configure mode.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Firstly, *keep no change* for `hash_get()` with NULL
`alloc_func`.
Only focus on cases with non-NULL `alloc_func` of
`hash_get()`.
Since `hash_get()` with non-NULL `alloc_func` parameter
shall not fail, just ignore the returned value of it.
The returned value must not be NULL.
So in this case, remove the unnecessary checking NULL
or not for the returned value and add `void` in front
of it.
Importantly, also *keep no change* for the two cases with
non-NULL `alloc_func` -
1) Use `assert(<returned_data> == <searching_data>)` to
ensure it is a created node, not a found node.
Refer to `isis_vertex_queue_insert()` of isisd, there
are many examples of this case in isid.
2) Use `<returned_data> != <searching_data>` to judge it
is a found node, then free <searching_data>.
Refer to `aspath_intern()` of bgpd, there are many
examples of this case in bgpd.
Here, <returned_data> is the returned value from `hash_get()`,
and <searching_data> is the data, which is to be put into
hash table.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
If `hash_get()` returns NULL, the list created with
`list_new()` is not be freed.
Since `hash_get()` should not fail, we don't need
`list_delete()` and other boring `XFREE()`s for its
failure case.
Just ignore returning value of `hash_get()` in these
cases.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
`stream_new` in `str2prefix_rd()` can be called after some
checkings are passed, so the last `if (s)` in this fuction will
make sense.
Additionally some changes for `str2prefix_rd()`:
1) Use `RD_BYTES` instead of hard number for `stream_new()`
2) Remove unnecessary `lret` variable
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Also, add N-Bit (Notification) flag for Graceful Restart.
This is a preparation for RFC8538.
More information: https://datatracker.ietf.org/doc/html/rfc8538
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The compiler is, rightly, pointing out that in some cases it is
possible that the pkt_afi and pkt_safi values are not properly
set and could result in a use before initialized. I do not
actually belive that this is possible, but let's make the compiler
happy.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The logic to unlock dest if iteration completed without iterating the
entire node was flawed. Specifically, if iteration terminated due to
`gr_deferred == 0` then the node would not get unlocked.
This change takes into account the fact that dest will be NULL only in
the case when the entire table was iterated and all nodes were already
unlocked. In any other case, it needs to be unlocked.
Signed-off-by: Carl Baldwin <carl@ecbaldwin.net>
Prior to this fix, the magic number (16) was used regardless of what value
the user specified for func-bits. With this fix, user-specified values are
handled appropriately.
Signed-off-by: Nobuhiro MIKI <nmiki@yahoo-corp.jp>
RT value will be unique across different VNIs but the
same across routers (in the same AS) for a particula
VNI.
It is unique, so add `break` for search procedure.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Fix: 06e4e90132
Modified BGP to pay more attention the prefix returned from
zebra to ensure that a LPM wasn't accidently causing BGP
import checks to think it had a match when it did not.
This unfortunately removed the check to handle the route
removal.
This sequence of config and events would leave BGP in a bad state:
ip route 100.100.100.0/24 Null0
router bgp 32932
bgp network import-check
address-family ipv4 uni
network 100.100.100.0/24
Then if you removed the static route the import check would
still think the route existed:
donatas-pc(config)# ip route 100.100.100.0/24 Null0
donatas-pc(config)# do sh ip bgp import-check-table
Current BGP import check cache:
100.100.100.0 valid [IGP metric 0], #paths 1
blackhole
Last update: Sat Apr 23 22:51:34 2022
donatas-pc(config)# do sh ip nht
100.100.100.0
resolved via static
is directly connected, Null0
Client list: bgp(fd 17)
donatas-pc(config)# do sh ip bgp neighbors 192.168.10.123 advertised-routes | include 100.100.100.0
*> 100.100.100.0/24 0.0.0.0 0 32768 i
donatas-pc(config)# no ip route 100.100.100.0/24 Null0
donatas-pc(config)# do sh ip nht
100.100.100.0
resolved via kernel
via 192.168.10.1, enp3s0
Client list: bgp(fd 17)
donatas-pc(config)# do sh ip bgp import-check-table
Current BGP import check cache:
100.100.100.0 valid [IGP metric 0], #paths 1
blackhole
Last update: Sat Apr 23 22:51:34 2022
donatas-pc(config)# do sh ip bgp neighbors 192.168.10.123 advertised-routes | include 100.100.100.0
*> 100.100.100.0/24 0.0.0.0 0 32768 i
donatas-pc(config)#
Fix this by moving the code to handle the prefix check to the
evaluation function and mark the bnc as not matching and actually
evaluate the bnc.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In some stress testing, we are seeing type-5 evpn routes being
left in a rejected state in zebra.
Sequence of events as I am seeing it:
a) Interface comes up that type5 routes nexthop depends on
b) zebra processes creates the connected and lets bgp know via nht
c) bgp installs the route to zebra
d) zebra processes and sends install to kernel
e) before route is installed, the interface the nexthop points at flaps
f) the route install is rejected, notify zebra
g) the interface comes up
h) zebra gets the notification about the route install rejection
i) zebra processes the down/up and turns it into a single up event
j) BGP never reinstalls the type 5 route
This up event does not translate into a nexthop tracking event
when the events happen quickly enough and/or zebra is extremelyh
busy and bgp would never see that the nexthops changed even very quickly.
This is the same thing that was going on with
https://github.com/FRRouting/frr/pull/7724
in PBR.
To fix this let's notice the interface up/down events for v4
in bgp now as well.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Fix NULL deference issue in log. And change one word - "vtep",
it should be with lowercase letters like other places.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Until now, it has been hard-coded that the position at which the label
is inserted is from the 64th bits. Therefore, when the Locator prefix
was not /64, incorrect SIDs were generated. Also, SIDs are generated
in duplicate on Lines 604 & 613 in bgpd/bgp_mplsvpn.c.
In this patch, the position where the label is inserted is calculated
based on the sum of block_bits_length and node_bits_length (i.e., the
user-specified Locator prefix length). In addition, SID generation is
performed at one location in alloc_new_sid.
Signed-off-by: Nobuhiro MIKI <nmiki@yahoo-corp.jp>
https://datatracker.ietf.org/doc/html/rfc7947#section-2.2
Optional recognized and unrecognized BGP attributes,
whether transitive or non-transitive, SHOULD NOT be updated by the
route server (unless enforced by local IXP operator configuration)
and SHOULD be passed on to other route server clients.
By default LB ext-community works with iBGP peers. When we receive a route
from eBGP peer, we can send LB ext-community to iBGP peers.
With this patch, allow sending LB ext-community to iBGP/eBGP peers if they
are set as RS clients.
FRR does not send non-transitive ext-communities to eBGP peers, but for
example GoBGP sends and if it's set as RS client, we should pass those attributes
towards another RS client.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Remove unnecessary `install_l3nhg` knob because it has already
been controlled by the command: "[no$no] use-es-l3nhg".
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Currently the warning is wrong:
```
root#show bgp vrf default vni
BGP instance for VRF default not foundACC1(config)#
```
Two changes for "show bgp vrf VRFNAME vni [json]":
- Correct the default VRF check
- Add newline for warning
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Description:
- When default route is originated using the
neighbor default-originate command, MED is
not set as part of the update message
attribute.
- Changes are done to set the MED value and MED
flag for default route.
Co-authored-by: Abhinay Ramesh <rabhinay@vmware.com>
Signed-off-by: Iqra Siddiqui <imujeebsiddi@vmware.com>
Correct flag name of `attr.es_flags` - ATTR_ES_L3_NHG_USE.
"bgp_path_info"s (Per "es-vrf") with this flag can use l3nhg.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
