The l2vpn afi was not being properly displayed
when a show run was being issued. Add a
afi2str_lower function and use it.
Fixes: #12867
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
According to the flowspec RFC 8955 a flowspec nlri is <length, <nlri data>>
Specifying 0 as a length makes BGP get all warm on the inside. Which
in this case is not a good thing at all. Prevent warmth, stay cold
on the inside.
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Before:
```
r1# sh ip bgp wide
BGP table version is 1, local router ID is 192.168.2.1, vrf id 0
Default local pref 100, local AS 65001
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
* 172.16.255.254/32 192.168.2.2 0 0 (65003) i
*> 192.168.1.2 0 0 (65002) i
Displayed 1 routes and 2 total paths
r1#
```
After:
```
r1# sh ip bgp wide
BGP table version is 1, local router ID is 192.168.2.1, vrf id 0
Default local pref 100, local AS 65001
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
* 172.16.255.254/32 192.168.2.2 0 0 (65003) i
*> 192.168.1.2 0 0 (65002) i
Displayed 1 routes and 2 total paths
r1#
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Sometimes bgp connections can be rejected for a variety of reasons. Give
a bit more context about what is going wrong so that the operator can
make better decisions about their network.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
An rfapi timer callback is responsible for the memory in a
context object, even in special-case exit paths. Always
free that object.
Signed-off-by: Mark Stapp <mjs@labn.net>
When we specify remote-as as external/internal, we need to set local_as to
bgp->as, instead of bgp->confed_id. Before this patch, (bgp->as != *as) is
always valid for such a case because *as is always 0.
Also, append peer->local_as as CONFED_SEQ to avoid other side withdrawing
the routes due to confederation own AS received and/or malformed as-path.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
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>
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>
"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>
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>
The call for all_digit is unnecessary as that the local preference
must be entered as a digit. In other words you cannot get to this
point without the string being all digits. This check is unnecessary.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Static Analysis caught a bug where we could be reading
garbage values for labels/num_lables. Fix that by
ensuring it's set to NULL/0 per loop of the mpath.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Add some bgp_path_info helper functions for getting the correct l3vni
label, getting the vni from the label stack, and determinging if
the mpath is D-VNI based.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Add functionality to always send the L3VNI to zebra as a label
on the route. It will be zebra's job to determine how to use it (i.e.
via Single Vxlan Device or not).
The l3VNI according to rfc should always be the second for a type2 route
and be the only one available for a type5. Hence, we can just grab the
last label in the stack here and add it onto the route.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Use the already existing mpls label code to store VNI
info for vxlan. VNI's are defined as labels just like mpls,
we should be using the same code for both.
This patch is the first part of that. Next we will need to
abstract the label code to not be so mpls specific. Currently
in this, we are just treating VXLAN as a label type and storing
it that way.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
When a routemap lookup of the prefix fails, add some useful data to
the end operator about what has just gone wrong when they are
using `debug routemap detail`
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Let's give the operator some inkling as to why a routemap is
not working the way they thing it should be when something
goes wrong using it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When using `match ip[v6] next-hop <Access-list>` warn
when creating the access-list that the access list does
not yet exist and nothing can be done with it yet.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The function vpn_leak_to_vrf_update_onevrf() has the RD parameter
set to NULL. Test the RD value before displaying it in the called
function.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The peer pointer theorically have a NULL bgp pointer. This triggers
a SA issue. So let us fix it.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
