Docker image based on ubi8-minimal are smaller in size than previous
ones built with ubi8 as base. Also, due to proper cleanup of caches, the
final image is about 400MB in size (down from ~630MB using the older
ubi8 builder).
This Dockerfile also uses packages built for RHEL (instead of CentOS),
and updates dependencies so that it can compile latest FRR versions.
Signed-off-by: Juan Vidal Allende <juan.vidal1@ibm.com>
The builder for docker images based on ubi-8 images is broken, and it
generates docker images that are heavy and contain more artifacts than
they need to.
It also installs RPM packages from CentOS that, although seem to be
compatible with ubi-8, may diverge at some point (remember that CentOS
now does not track RHEL closely).
Signed-off-by: Juan Vidal Allende <juan.vidal1@ibm.com>
peer->af_flags got this correctly.
peer->flags were already converted a time ago, but these were missed...
Let's fix this.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Instead of hard coding so that if something ever changes
it will break. Let's use the #defines that FRR has
included for us.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Depending on ip_route and kernel, the output might include a nhid
which causes the test to fail with a strict text output check.
Change to json output to avoid the issue
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
When leaving the BGP shutdown state we must restart the peer timers
otherwise nothing will happen.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Quite a few well-known communities from IANA's list do
not receive special treatment in Cisco IOS XR, and at least one
community on Cisco IOS XR's special treatment list, internet == 0:0,
is not formally a well-known community as it is not in [IANA-WKC] (it
is taken from the Reserved range [0x00000000-0x0000FFFF]).
https://datatracker.ietf.org/doc/html/rfc8642
This is Cisco-specific command which is causing lots of questions when it
comes to debugging and/or configuring it properly, but overall, this behavior
is very odd and it's not clear how it should be treated between different
vendor implementations.
Let's deprecate it and let the operators use 0:0/0 communities as they want.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
There were a few tests using "show bgp ... json detail" that did json
comparisons against a predefined json structure. This updates those
predefined json structures to match the new format of the output.
(new output moves path array under "paths" key and adds header keys)
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
"show bgp <afi> <safi> json detail" was incorrectly displaying header
information from route_vty_out_detail_header() as an element of the
"paths" array. This corrects the behavior for 'json detail' so that a
route holds a dictionary with keys for "paths" and header info, which
aligns with how we structure the output for a specific prefix, e.g.
"show bgp <afi> <safi> <prefix> json".
Before:
```
ub20# show ip bgp json detail
{
"vrfId": 0,
"vrfName": "default",
"tableVersion": 3,
"routerId": "100.64.0.222",
"defaultLocPrf": 100,
"localAS": 1,
"routes": { "2.2.2.2/32": [
{ <<<<<<<<< should be outside the array
"prefix":"2.2.2.2/32",
"version":1,
"advertisedTo":{
"192.168.122.12":{
"hostname":"ub20-2"
}
}
},
{
"aspath":{
"string":"Local",
"segments":[
],
"length":0
},
<snip>
```
After:
```
ub20# show ip bgp json detail
{
"vrfId": 0,
"vrfName": "default",
"tableVersion": 3,
"routerId": "100.64.0.222",
"defaultLocPrf": 100,
"localAS": 1,
"routes": { "2.2.2.2/32": {
"prefix": "2.2.2.2/32",
"version": "1",
"advertisedTo": {
"192.168.122.12":{
"hostname":"ub20-2"
}
}
,"paths": [
{
"aspath":{
"string":"Local",
"segments":[
],
"length":0
},
```
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Coverity complains that MLAG_MSG_NONE cannot be reached in
the switch statement. Which is true so let's make it happy.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Coverity rightly points out that a call into zebra_l2_bridge_if_vlan_find
is NULL checked 4/5 times. Let's make it 5/5
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Commit d7c6467ba2 added the
ability to specify non pretty printing but unfortunately
forgot to use the option variable to make the whole
thing work.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
a) Consolidate v4 and v6 versions of rib_match_multicast
b) Improve debug to show what we matched against as well.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Ensure that a multipath set is fully comprised of EVPN paths (i.e.,
paths imported into the VRF from EVPN address-family) or non-EVPN
paths. This is actually a condition that existed already in the code
but was not properly enforced.
This change, as a side effect, eliminates the known trigger condition
for bad or missing RMAC programming in an EVPN deployment, described
in tickets CM-29043 and CM-31222. Routes (actually, paths) in a VRF
routing table that require VXLAN tunneling to the next hop currently
need some special handling in zebra to deal with the nexthop (neigh)
and RMAC programming, and this is implemented for the entire route
(prefix), not per-path. This can lead to the bad or missing RMAC
situation, which is now eliminated by ensuring all paths in the route
are 'similar'.
The longer-term solution in CL 5.x will be to deal with the special
programming by means of explicit communication between bgpd and zebra.
This is already implemented for EVPN-MH via CM-31398. These changes
will be extended to non-MH also and the special code in zebra removed
or refined.
Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
Acked-by: Trey Aspelund <taspelund@nvidia.com>
Acked-by: Anuradha Karuppiah <anuradhak@nvidia.com>
Acked-by: Chirag Shah <chirag@nvidia.com>
Ticket: CM-29043
Testing Done:
1. Manual testing
2. precommit on both MLX and BCM platforms
3. evpn-smoke - BCM and VX
Results described in the ticket
When performing deterministic MED processing, ensure that the peer
status is not checked when we encounter a stale path. Otherwise, this
path will be skipped from the DMED consideration leading to it potentially
not being installed.
Test scenario: Consider a prefix with 2 (multi)paths. The peer that
announces the path with the winning DMED undergoes a graceful-restart.
Before it comes back up, the other path goes away. Prior to the fix, a
third router that receives both these paths would have ended up not
having any path installed to the prefix after the above events.
Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
For internal use:
Ticket: CM-32032
Testing done: Multiple manual testing
Add a keyword self-originate" to extend current CLI commands to filter out self-originated routes only
a\) CLI to show ipv4/ipv6 self-originated routes
"show [ip] bgp [afi] [safi] [all] self-originate [wide|json]"
b\) CLI to show evpn self-originated routes
"show bgp l2vpn evpn route [detail] [type <ead|macip|multicast|es|prefix|1|2|3|4|5>] self-originate [json]"
Signed-off-by: Karl Quan <kquan@nvidia.com>
Implement: https://datatracker.ietf.org/doc/html/draft-abraitis-bgp-version-capability
Tested with GoBGP:
```
% ./gobgp neighbor 192.168.10.124
BGP neighbor is 192.168.10.124, remote AS 65001
BGP version 4, remote router ID 200.200.200.202
BGP state = ESTABLISHED, up for 00:01:49
BGP OutQ = 0, Flops = 0
Hold time is 3, keepalive interval is 1 seconds
Configured hold time is 90, keepalive interval is 30 seconds
Neighbor capabilities:
multiprotocol:
ipv4-unicast: advertised and received
ipv6-unicast: advertised
route-refresh: advertised and received
extended-nexthop: advertised
Local: nlri: ipv4-unicast, nexthop: ipv6
UnknownCapability(6): received
UnknownCapability(9): received
graceful-restart: advertised and received
Local: restart time 10 sec
ipv6-unicast
ipv4-unicast
Remote: restart time 120 sec, notification flag set
ipv4-unicast, forward flag set
4-octet-as: advertised and received
add-path: received
Remote:
ipv4-unicast: receive
enhanced-route-refresh: received
long-lived-graceful-restart: advertised and received
Local:
ipv6-unicast, restart time 10 sec
ipv4-unicast, restart time 20 sec
Remote:
ipv4-unicast, restart time 0 sec, forward flag set
fqdn: advertised and received
Local:
name: donatas-pc, domain:
Remote:
name: spine1-debian-11, domain:
software-version: advertised and received
Local:
GoBGP/3.10.0
Remote:
FRRouting/8.5-dev-MyOwnFRRVersion-gdc92f44a45-dirt
cisco-route-refresh: received
Message statistics:
```
FRR side:
```
root@spine1-debian-11:~# vtysh -c 'show bgp neighbor 192.168.10.17 json' | \
> jq '."192.168.10.17".neighborCapabilities.softwareVersion.receivedSoftwareVersion'
"GoBGP/3.10.0"
root@spine1-debian-11:~#
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Using a route-map to update the local ipv6 address has to be
better clarified. Actually, when a VPN SAFI is used, the nexthop
length must be changed to 48 bytes. Other cases, the length will
be 32 bytes.
Fixes: 9795e9f234 ("bgpd: fix when route-map changes the link local
nexthop for vpnv6")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Because mp_nexthop_len attribute value stands for the length
to encode in the stream, simplify the way the nexthop is
forged.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
