Co-authored-by: Donald Sharp <sharpd@cumulusnetworks.com>
Co-authored-by: Quentin Young <qlyoung@cumulusnetworks.com>
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This command is added to provide detailed information. It will be
useful in troubleshooting as we will be able to dump all detailed info
using a single command.
"show bgp l2vpn evpn route [detail] ...". Additional filtering
can be done by providing type of the route.
Command will display the detailed content for all rd and macs-ip as
displayed by "show bgp l2vpn evpn route rd <> mac <>" for a single
rd, mac, ip from the global bgp routing table.
Ticket: CM-24397
Signed-off-by: Nitin Soni <nsoni@cumulusnetworks.com>
Reviewed-by:
Testing-Done:
This command is added to provide detailed information. It will be
useful in troubleshooting as we will be able to dump all detailed info
using a single command.
"net show bgp evpn route vni <all|id> [detail]". Additional filtering
can be done by providing vtep ip.
Command will display the detailed content for all vni and macs as
displayed by "net show bgp evpn route vni <> mac <> ip <>" for a single
vni, mac, ip.
Ticket: CM-24397
Signed-off-by: Nitin Soni <nsoni@cumulusnetworks.com>
Reviewed-by:
Testing-Done:
The bgp_path_info_new function whenever it was called
pretty much duplicated the info_make function call. So
convert over to using it and remove the bgp_path_info_new
function so people are not tempted.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The creation of a new `struct bgp_path_info` requires a legitimate
peer being passed in for creation. There exists no code paths
where this is not true. As such checking pi->peer for null convinces
SA that it might happen.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Move &rpki_cmd from VIEW to ENABLE. A non-enabled session could
enter into the rpki command node and exit into glocalb config mode
without having to enable.
Move &show_rpki* from ENABLE to VIEW. Allow non-enabled user to
view cache state and prefix table state.
Signed-off-by: David Teach <dteach@routeviews.org>
Avoid tracking 0.0.0.0/32 nexthop with RIB.
When routes are aggregated,
the originate of the route becomes self.
Do not track nexthop self (0.0.0.0) with rib.
Ticket: CM-24248
Testing Done:
Before fix-
tor-11# show ip nht vrf all
VRF blue:
0.0.0.0
unresolved
Client list: bgp(fd 16)
VRF default:
VRF green:
VRF magenta:
0.0.0.0
unresolved
Client list: bgp(fd 16)
After fix-
tor-11# show ip nht vrf all
VRF blue:
VRF default:
VRF green:
VRF magenta:
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
In order to iterate over MPLS VPN routes, it's necessary to use
two nested loops (the outer loop iterates over the MPLS VPN RDs,
and the inner loop iterates over the VPN routes from that RD).
The bgp_table_stats_walker() function wasn't giving this special
treatment to the MPLS VPN safi as it should, which was leading to
crashes and malfunctioning. Fix this.
Signed-off-by: Renato Westphal <renatowestphal@gmail.com>
pinum (renamed from rinum) was never used for anything useful since
the initial revision ~17 years ago. Get rid of it.
Signed-off-by: Renato Westphal <renatowestphal@gmail.com>
force allocation of entries in order to save memory and then save memory
for people that do not use flowspec.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
while labeled_unicast routes should be fetched in the
unicast table, we cannot set the safi to SAFI_UNICAST
else the peer afc checks and subgroup retrieval will fail
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
bgp entries in bgp_extra_path structure will be allocated as lists, only
when needed, that is to say when bgp fs entries will be received and
installed on the underlying system.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When using remove-private-AS together with local-as
aspath_remove_private_asns() is called before bgp_packet_attribute().
In this case, private AS will always appear in front of change_local_as.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Currently, as part of bgp clear soft inboud and outbound we don't handle
l2vpn evpn. Now clearing soft for all supported afi safi.
One of the examples where this was a problem -
On applying graceful-shutdown, bgp clear soft inboud and outbound don't
handle AFI L2VPN and SAFI EVPN. Gshut gets applied to EVPN Type 5 routes
by asking peer to refresh the routes (provided we have config - "advertise
ipv4/ipv6 unicast" as part of l2vpn evpn) but is not applied to type 2
and type 3 EVP routes. This fix takes care of l2vpn evpn type2 and type3
routes being readvertised with gshut community.
This fix also fixes similar issues related to following where bgp clear
soft is requred for l2vpn evpn -
-config bgp cluster-id
-config bgp client-to-client reflection
-config bgp default local-preference
-config bgp route-reflector allow-outbound-policy
-config bgp disable-ebgp-connected-route-check
Ticket: CM-22813
Signed-off-by: Nitin Soni <nsoni@cumulusnetworks.com>
Reviewed-by: CCR-8361
Testing-Done:
-With gshut configured on all BGP VRFs (operator has to know about the
auto-created BGP VRFs - we do show them in show commands - and turn on
graceful-shutdown in all of them.
-We announce all EVPN routes (type-2, type-3 and type-5) with GSHUT and
we mark IPv4/IPv6 routes in a VRF that are based on received EVPN type-2
or type-5 routes with local pref 0.
-On the receiver side, when EVPN routes are received with GSHUT, the
correct handling takes place (to treat them with local preference 0, and
hence not select them)
-When the gshut configuration is removed on all BGP VRFs, we re-announce
all of our EVPN routes without GSHUT and receiver does the appropriate
thing. Also, we no longer mark EVPN-based IPv4/IPv6 routes with local
pref 0.
-evpn-smoke
-bgp-smoke
We have the same warn message in 3 spots, which makes it extremely
hard to figure out which of the 3 has gone terribly wrong.
Add a bit of code to disambiguate the 3 situations.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This replaces manual checks of the flag with a wrapper macro to convey
the meaning "is evpn enabled on this vrf?"
Signed-off-by: Tuetuopay <tuetuopay@me.com>
Sponsored-by: Scaleway
During L3VNI add, non-default RD value is not replayed
correctly. Instead of picking non-default value it picks
up auto RD value which is derived based on router-id.
Indentation issue: Remove additional space from
L3VNI running config output.
Ticket:CM-24320
Reviewed By:CCR-8437
Testing Done:
Bring up evpn configuration with L3vni up with non-default
RD value, perform peerlink flap, l3vni flap which removes
all VNIS and readds with RD and RT values.
The configured RD and RTs are replayed.
Post L3VNI flap
router bgp 5546 vrf vrf2
!
address-family l2vpn evpn
rd 45.0.66.2:6
route-target import 20001:1
route-target export 20001:1
exit-address-family
TORC11# show bgp l2vpn evpn vni 4002
VNI: 4002 (known to the kernel)
Type: L3
Tenant VRF: vrf2
RD: 45.0.66.2:6
Originator IP: 36.0.0.11
Advertise-gw-macip : n/a
Import Route Target:
20001:1
Export Route Target:
20001:1
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
When a bgp-peer comes up prior to l3vnis are up in bgpd.
The EVPN routes (type-2/type-5) are learnt via peer.
The routes can have one of interface's MAC in rmac attribute.
The self rmac check would bypass as l3vni is not present.
Once l3vni has come up in bgpd, while installing evpn
routes in vrf table, perform rmac attribute check against self mac.
The routes with rmac of ours will be removed via re-scan
of routes during bgp_mac_rescan_all_evpn_tables when
interface mac is added to bgp.
Ticket:CM-24224
Reviewed By:CCR-8423
Testing Done:
Signed-off-by: Chirag Shah <chirag@cumulunetworks.com>
Rename {bgp,zvrf}_def{ault} to {bgp,zvrf}_evpn where it makes sense,
i.e. when they contain the EVPN instance.
Signed-off-by: Tuetuopay <tuetuopay@me.com>
Sponsored-by: Scaleway
For default RT, this uses the correct ASN to derive the RT (ASN of the
EVPN VRF).
It also stores them in the EVPN VRF's hash tables rather than in the
default's one.
Signed-off-by: Tuetuopay <tuetuopay@me.com>
Sponsored-by: Scaleway
This change stores the mapping in the hash table of the EVPN VRF rather
than the one of the default VRF.
Signed-off-by: Tuetuopay <tuetuopay@me.com>
Sponsored-by: Scaleway
This sends local routes in overlay VRFs to the EPVN VRF when
redistribute configurations are present, rather than to the default VRF.
Signed-off-by: Tuetuopay <tuetuopay@me.com>
Sponsored-by: Scaleway
If the EVPN VRF is not the default one (i.e. with advertise-all-vni),
this allows showing its information with `show bgp l2evpn evpn ...`
commands. They do not require adding `vrf VRFNAME` since we only
support a single EVPN VRF. The same is true for zebra-specific commands
(e.g. `show evpn ...`).
Configuration commands are not restricted to the default VRF but to
the EVPN one, that is to the one bearing `advertise-all-vni`.
Signed-off-by: Tuetuopay <tuetuopay@me.com>
Sponsored-by: Scaleway
This makes the instance bearing the advertise-all-vni config option
register to zebra as the EVPN one, forwarding it the option.
Signed-off-by: Tuetuopay <tuetuopay@me.com>
Sponsored-by: Scaleway
Found that previous fix for this issue caused collatoral damage and
reverted that fix. This fix clears the vrf_bitmaps when the vrf is
disabled/deleted and then re-applies the redist config when the vrf
is re-enabled.
Ticket: CM-24231
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
The evpn route prefix len was being hardcoded to 224 bits while the
length of a mac-ip addr is actually 288. Because of this many problems were
seen in the evpn-tests. The sample below is from a test that does a vm-move
to verify extended-evpn-mac-mobility - IP1-M1 => IP2->M1. You can see two
local neighs but only one was inserted into the per-vni route table.
root@TORC11:~# net show evpn arp vni 1001 |grep "2001:fee1:0:1::10\|2001:fee1:0:1::11"
2001:fee1:0:1::10 local active 00:54:6f:7c:74:64
2001:fee1:0:1::11 local active 00:54:6f:7c:74:64
root@TORC11:~# net show bgp l2vpn evpn route vni 1001 |grep "2001:fee1:0:1::10\|2001:fee1:0:1::11"
*> [2]:[0]:[48]:[00:54:6f:7c:74:64]:[128]:[2001:fee1:0:1::11]
root@TORC11:~#
Similarly other traffic loss problems were seen because of one prefix updating
another prefix's route.
I think the 224-bits came from the packet format definition of type-2 routes.
However the way FRR maintains the key is very different than the format in
the packet so it seems best to just sizeof the addr.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
