2017-05-15 23:27:09 +02:00
|
|
|
/* BGP EVPN internal definitions
|
|
|
|
* Copyright (C) 2017 Cumulus Networks, Inc.
|
|
|
|
*
|
|
|
|
* This file is part of FRR.
|
|
|
|
*
|
|
|
|
* FRR is free software; you can redistribute it and/or modify it
|
|
|
|
* under the terms of the GNU General Public License as published by the
|
|
|
|
* Free Software Foundation; either version 2, or (at your option) any
|
|
|
|
* later version.
|
|
|
|
*
|
|
|
|
* FRR is distributed in the hope that it will be useful, but
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with FRR; see the file COPYING. If not, write to the Free
|
|
|
|
* Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
|
|
|
|
* 02111-1307, USA.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef _BGP_EVPN_PRIVATE_H
|
|
|
|
#define _BGP_EVPN_PRIVATE_H
|
|
|
|
|
|
|
|
#include "vxlan.h"
|
|
|
|
#include "zebra.h"
|
|
|
|
|
|
|
|
#include "bgpd/bgpd.h"
|
|
|
|
#include "bgpd/bgp_ecommunity.h"
|
|
|
|
|
2017-08-30 17:23:01 +02:00
|
|
|
#define RT_ADDRSTRLEN 28
|
2017-07-21 02:42:20 +02:00
|
|
|
|
2019-03-09 00:34:09 +01:00
|
|
|
/* EVPN prefix lengths. This represents the sizeof struct evpn_addr
|
|
|
|
* in bits */
|
|
|
|
#define EVPN_ROUTE_PREFIXLEN (sizeof(struct evpn_addr) * 8)
|
2017-05-15 23:27:09 +02:00
|
|
|
|
bgpd: support for Ethernet Segments and Type-1/EAD routes
This is the base patch that brings in support for Type-1 routes.
It includes support for -
- Ethernet Segment (ES) management
- EAD route handling
- MAC-IP (Type-2) routes with a non-zero ESI i.e. Aliasing for
active-active multihoming
- Initial infra for consistency checking. Consistency checking
is a fundamental feature for active-active solutions like MLAG.
We will try to levarage the info in the EAD-ES/EAD-EVI routes to
detect inconsitencies in access config across VTEPs attached to
the same Ethernet Segment.
Functionality Overview -
========================
1. Ethernet segments are created in zebra and associated with
access VLANs. zebra sends that info as ES and ES-EVI objects to BGP.
2. BGP advertises EAD-ES and EAD-EVI routes for the locally attached
ethernet segments.
3. Similarly BGP processes EAD-ES and EAD-EVI routes from peers
and translates them into ES-VTEP objects which are then sent to zebra
as remote ESs.
4. Each ES in zebra is associated with a list of active VTEPs which
is then translated into a L2-NHG (nexthop group). This is the ES
"Alias" entry
5. MAC-IP routes with a non-zero ESI use the alias entry created in
(4.) to forward traffic i.e. a MAC-ECMP is done to these remote-ES
destinations.
EAD route management (route table and key) -
============================================
1. Local EAD-ES routes
a. route-table: per-ES route-table
key: {RD=ES-RD, ESI, ET=0xffffffff, VTEP-IP)
b. route-table: per-VNI route-table
Not added
c. route-table: global route-table
key: {RD=ES-RD, ESI, ET=0xffffffff)
2. Remote EAD-ES routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=ES-RD, ESI, ET=0xffffffff, VTEP-IP)
c. route-table: global route-table
key: {RD=ES-RD, ESI, ET=0xffffffff)
3. Local EAD-EVI routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=0, ESI, ET=0, VTEP-IP)
c. route-table: global route-table
key: {RD=L2-VNI-RD, ESI, ET=0)
4. Remote EAD-EVI routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=0, ESI, ET=0, VTEP-IP)
c. route-table: global route-table
key: {RD=L2-VNI-RD, ESI, ET=0)
Please refer to bgp_evpn_mh.h for info on how the data-structures are
organized.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
2020-03-27 22:43:50 +01:00
|
|
|
/* EVPN route RD buffer length */
|
|
|
|
#define BGP_EVPN_PREFIX_RD_LEN 100
|
|
|
|
|
|
|
|
/* packet sizes for EVPN routes */
|
|
|
|
/* Type-1 route should be 25 bytes
|
|
|
|
* RD (8), ESI (10), eth-tag (4), vni (3)
|
|
|
|
*/
|
|
|
|
#define BGP_EVPN_TYPE1_PSIZE 25
|
|
|
|
/* Type-4 route should be either 23 or 35 bytes
|
|
|
|
* RD (8), ESI (10), ip-len (1), ip (4 or 16)
|
|
|
|
*/
|
|
|
|
#define BGP_EVPN_TYPE4_V4_PSIZE 23
|
|
|
|
#define BGP_EVPN_TYPE4_V6_PSIZE 34
|
|
|
|
|
|
|
|
RB_HEAD(bgp_es_evi_rb_head, bgp_evpn_es_evi);
|
|
|
|
RB_PROTOTYPE(bgp_es_evi_rb_head, bgp_evpn_es_evi, rb_node,
|
|
|
|
bgp_es_evi_rb_cmp);
|
2017-05-15 23:27:09 +02:00
|
|
|
/*
|
|
|
|
* Hash table of EVIs. Right now, the only type of EVI supported is with
|
|
|
|
* VxLAN encapsulation, hence each EVI corresponds to a L2 VNI.
|
|
|
|
* The VNIs are not "created" through BGP but through some other interface
|
|
|
|
* on the system. This table stores VNIs that BGP comes to know as present
|
|
|
|
* on the system (through interaction with zebra) as well as pre-configured
|
|
|
|
* VNIs (which need to be defined in the system to become "live").
|
|
|
|
*/
|
|
|
|
struct bgpevpn {
|
|
|
|
vni_t vni;
|
2017-10-08 05:26:16 +02:00
|
|
|
vrf_id_t tenant_vrf_id;
|
2018-03-27 21:13:34 +02:00
|
|
|
uint32_t flags;
|
2017-05-15 23:27:09 +02:00
|
|
|
#define VNI_FLAG_CFGD 0x1 /* VNI is user configured */
|
|
|
|
#define VNI_FLAG_LIVE 0x2 /* VNI is "live" */
|
|
|
|
#define VNI_FLAG_RD_CFGD 0x4 /* RD is user configured. */
|
|
|
|
#define VNI_FLAG_IMPRT_CFGD 0x8 /* Import RT is user configured */
|
|
|
|
#define VNI_FLAG_EXPRT_CFGD 0x10 /* Export RT is user configured */
|
2018-02-06 23:28:22 +01:00
|
|
|
#define VNI_FLAG_USE_TWO_LABELS 0x20 /* Attach both L2-VNI and L3-VNI if
|
|
|
|
needed for this VPN */
|
2017-05-15 23:27:09 +02:00
|
|
|
|
2018-02-23 10:16:32 +01:00
|
|
|
struct bgp *bgp_vrf; /* back pointer to the vrf instance */
|
|
|
|
|
2017-06-28 10:51:10 +02:00
|
|
|
/* Flag to indicate if we are
|
|
|
|
* advertising the g/w mac ip for
|
|
|
|
* this VNI*/
|
2018-03-27 21:13:34 +02:00
|
|
|
uint8_t advertise_gw_macip;
|
2017-06-28 10:51:10 +02:00
|
|
|
|
2018-03-27 21:13:34 +02:00
|
|
|
/* Flag to indicate if we are
|
|
|
|
* advertising subnet for this VNI */
|
|
|
|
uint8_t advertise_subnet;
|
2017-11-20 06:47:04 +01:00
|
|
|
|
2019-02-04 03:08:46 +01:00
|
|
|
/* Flag to indicate if we are advertising the svi mac ip for this VNI*/
|
|
|
|
uint8_t advertise_svi_macip;
|
|
|
|
|
2018-03-27 21:13:34 +02:00
|
|
|
/* Id for deriving the RD
|
|
|
|
* automatically for this VNI */
|
|
|
|
uint16_t rd_id;
|
2017-05-15 23:27:09 +02:00
|
|
|
|
2018-03-27 21:13:34 +02:00
|
|
|
/* RD for this VNI. */
|
|
|
|
struct prefix_rd prd;
|
2017-05-15 23:27:09 +02:00
|
|
|
|
2018-03-27 21:13:34 +02:00
|
|
|
/* Route type 3 field */
|
|
|
|
struct in_addr originator_ip;
|
2017-05-15 23:27:09 +02:00
|
|
|
|
2019-03-19 19:08:24 +01:00
|
|
|
/* PIM-SM MDT group for BUM flooding */
|
|
|
|
struct in_addr mcast_grp;
|
|
|
|
|
2018-03-27 21:13:34 +02:00
|
|
|
/* Import and Export RTs. */
|
|
|
|
struct list *import_rtl;
|
|
|
|
struct list *export_rtl;
|
2017-05-15 23:27:09 +02:00
|
|
|
|
2018-03-27 21:13:34 +02:00
|
|
|
/* Route table for EVPN routes for
|
|
|
|
* this VNI. */
|
|
|
|
struct bgp_table *route_table;
|
2017-05-15 23:27:09 +02:00
|
|
|
|
bgpd: support for Ethernet Segments and Type-1/EAD routes
This is the base patch that brings in support for Type-1 routes.
It includes support for -
- Ethernet Segment (ES) management
- EAD route handling
- MAC-IP (Type-2) routes with a non-zero ESI i.e. Aliasing for
active-active multihoming
- Initial infra for consistency checking. Consistency checking
is a fundamental feature for active-active solutions like MLAG.
We will try to levarage the info in the EAD-ES/EAD-EVI routes to
detect inconsitencies in access config across VTEPs attached to
the same Ethernet Segment.
Functionality Overview -
========================
1. Ethernet segments are created in zebra and associated with
access VLANs. zebra sends that info as ES and ES-EVI objects to BGP.
2. BGP advertises EAD-ES and EAD-EVI routes for the locally attached
ethernet segments.
3. Similarly BGP processes EAD-ES and EAD-EVI routes from peers
and translates them into ES-VTEP objects which are then sent to zebra
as remote ESs.
4. Each ES in zebra is associated with a list of active VTEPs which
is then translated into a L2-NHG (nexthop group). This is the ES
"Alias" entry
5. MAC-IP routes with a non-zero ESI use the alias entry created in
(4.) to forward traffic i.e. a MAC-ECMP is done to these remote-ES
destinations.
EAD route management (route table and key) -
============================================
1. Local EAD-ES routes
a. route-table: per-ES route-table
key: {RD=ES-RD, ESI, ET=0xffffffff, VTEP-IP)
b. route-table: per-VNI route-table
Not added
c. route-table: global route-table
key: {RD=ES-RD, ESI, ET=0xffffffff)
2. Remote EAD-ES routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=ES-RD, ESI, ET=0xffffffff, VTEP-IP)
c. route-table: global route-table
key: {RD=ES-RD, ESI, ET=0xffffffff)
3. Local EAD-EVI routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=0, ESI, ET=0, VTEP-IP)
c. route-table: global route-table
key: {RD=L2-VNI-RD, ESI, ET=0)
4. Remote EAD-EVI routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=0, ESI, ET=0, VTEP-IP)
c. route-table: global route-table
key: {RD=L2-VNI-RD, ESI, ET=0)
Please refer to bgp_evpn_mh.h for info on how the data-structures are
organized.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
2020-03-27 22:43:50 +01:00
|
|
|
/* RB tree of ES-EVIs */
|
|
|
|
struct bgp_es_evi_rb_head es_evi_rb_tree;
|
2018-04-14 00:01:12 +02:00
|
|
|
|
bgpd: support for Ethernet Segments and Type-1/EAD routes
This is the base patch that brings in support for Type-1 routes.
It includes support for -
- Ethernet Segment (ES) management
- EAD route handling
- MAC-IP (Type-2) routes with a non-zero ESI i.e. Aliasing for
active-active multihoming
- Initial infra for consistency checking. Consistency checking
is a fundamental feature for active-active solutions like MLAG.
We will try to levarage the info in the EAD-ES/EAD-EVI routes to
detect inconsitencies in access config across VTEPs attached to
the same Ethernet Segment.
Functionality Overview -
========================
1. Ethernet segments are created in zebra and associated with
access VLANs. zebra sends that info as ES and ES-EVI objects to BGP.
2. BGP advertises EAD-ES and EAD-EVI routes for the locally attached
ethernet segments.
3. Similarly BGP processes EAD-ES and EAD-EVI routes from peers
and translates them into ES-VTEP objects which are then sent to zebra
as remote ESs.
4. Each ES in zebra is associated with a list of active VTEPs which
is then translated into a L2-NHG (nexthop group). This is the ES
"Alias" entry
5. MAC-IP routes with a non-zero ESI use the alias entry created in
(4.) to forward traffic i.e. a MAC-ECMP is done to these remote-ES
destinations.
EAD route management (route table and key) -
============================================
1. Local EAD-ES routes
a. route-table: per-ES route-table
key: {RD=ES-RD, ESI, ET=0xffffffff, VTEP-IP)
b. route-table: per-VNI route-table
Not added
c. route-table: global route-table
key: {RD=ES-RD, ESI, ET=0xffffffff)
2. Remote EAD-ES routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=ES-RD, ESI, ET=0xffffffff, VTEP-IP)
c. route-table: global route-table
key: {RD=ES-RD, ESI, ET=0xffffffff)
3. Local EAD-EVI routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=0, ESI, ET=0, VTEP-IP)
c. route-table: global route-table
key: {RD=L2-VNI-RD, ESI, ET=0)
4. Remote EAD-EVI routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=0, ESI, ET=0, VTEP-IP)
c. route-table: global route-table
key: {RD=L2-VNI-RD, ESI, ET=0)
Please refer to bgp_evpn_mh.h for info on how the data-structures are
organized.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
2020-03-27 22:43:50 +01:00
|
|
|
/* List of local ESs */
|
|
|
|
struct list *local_es_evi_list;
|
2018-04-14 00:01:12 +02:00
|
|
|
|
|
|
|
QOBJ_FIELDS;
|
|
|
|
};
|
|
|
|
|
bgpd: support for Ethernet Segments and Type-1/EAD routes
This is the base patch that brings in support for Type-1 routes.
It includes support for -
- Ethernet Segment (ES) management
- EAD route handling
- MAC-IP (Type-2) routes with a non-zero ESI i.e. Aliasing for
active-active multihoming
- Initial infra for consistency checking. Consistency checking
is a fundamental feature for active-active solutions like MLAG.
We will try to levarage the info in the EAD-ES/EAD-EVI routes to
detect inconsitencies in access config across VTEPs attached to
the same Ethernet Segment.
Functionality Overview -
========================
1. Ethernet segments are created in zebra and associated with
access VLANs. zebra sends that info as ES and ES-EVI objects to BGP.
2. BGP advertises EAD-ES and EAD-EVI routes for the locally attached
ethernet segments.
3. Similarly BGP processes EAD-ES and EAD-EVI routes from peers
and translates them into ES-VTEP objects which are then sent to zebra
as remote ESs.
4. Each ES in zebra is associated with a list of active VTEPs which
is then translated into a L2-NHG (nexthop group). This is the ES
"Alias" entry
5. MAC-IP routes with a non-zero ESI use the alias entry created in
(4.) to forward traffic i.e. a MAC-ECMP is done to these remote-ES
destinations.
EAD route management (route table and key) -
============================================
1. Local EAD-ES routes
a. route-table: per-ES route-table
key: {RD=ES-RD, ESI, ET=0xffffffff, VTEP-IP)
b. route-table: per-VNI route-table
Not added
c. route-table: global route-table
key: {RD=ES-RD, ESI, ET=0xffffffff)
2. Remote EAD-ES routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=ES-RD, ESI, ET=0xffffffff, VTEP-IP)
c. route-table: global route-table
key: {RD=ES-RD, ESI, ET=0xffffffff)
3. Local EAD-EVI routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=0, ESI, ET=0, VTEP-IP)
c. route-table: global route-table
key: {RD=L2-VNI-RD, ESI, ET=0)
4. Remote EAD-EVI routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=0, ESI, ET=0, VTEP-IP)
c. route-table: global route-table
key: {RD=L2-VNI-RD, ESI, ET=0)
Please refer to bgp_evpn_mh.h for info on how the data-structures are
organized.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
2020-03-27 22:43:50 +01:00
|
|
|
DECLARE_QOBJ_TYPE(bgpevpn);
|
2018-04-14 00:01:12 +02:00
|
|
|
|
2017-05-15 23:27:09 +02:00
|
|
|
/* Mapping of Import RT to VNIs.
|
|
|
|
* The Import RTs of all VNIs are maintained in a hash table with each
|
|
|
|
* RT linking to all VNIs that will import routes matching this RT.
|
|
|
|
*/
|
|
|
|
struct irt_node {
|
|
|
|
/* RT */
|
|
|
|
struct ecommunity_val rt;
|
|
|
|
|
|
|
|
/* List of VNIs importing routes matching this RT. */
|
|
|
|
struct list *vnis;
|
|
|
|
};
|
|
|
|
|
2017-10-10 03:12:05 +02:00
|
|
|
/* Mapping of Import RT to VRFs.
|
|
|
|
* The Import RTs of all VRFss are maintained in a hash table with each
|
|
|
|
* RT linking to all VRFs that will import routes matching this RT.
|
|
|
|
*/
|
|
|
|
struct vrf_irt_node {
|
|
|
|
/* RT */
|
|
|
|
struct ecommunity_val rt;
|
|
|
|
|
|
|
|
/* List of VNIs importing routes matching this RT. */
|
|
|
|
struct list *vrfs;
|
|
|
|
};
|
|
|
|
|
|
|
|
|
2017-05-15 23:34:04 +02:00
|
|
|
#define RT_TYPE_IMPORT 1
|
|
|
|
#define RT_TYPE_EXPORT 2
|
|
|
|
#define RT_TYPE_BOTH 3
|
|
|
|
|
2018-11-01 00:53:28 +01:00
|
|
|
#define EVPN_DAD_DEFAULT_TIME 180 /* secs */
|
|
|
|
#define EVPN_DAD_DEFAULT_MAX_MOVES 5 /* default from RFC 7432 */
|
|
|
|
#define EVPN_DAD_DEFAULT_AUTO_RECOVERY_TIME 1800 /* secs */
|
|
|
|
|
|
|
|
struct bgp_evpn_info {
|
|
|
|
/* enable disable dup detect */
|
|
|
|
bool dup_addr_detect;
|
|
|
|
|
|
|
|
/* Detection time(M) */
|
|
|
|
int dad_time;
|
|
|
|
/* Detection max moves(N) */
|
|
|
|
uint32_t dad_max_moves;
|
|
|
|
/* Permanent freeze */
|
|
|
|
bool dad_freeze;
|
|
|
|
/* Recovery time */
|
|
|
|
uint32_t dad_freeze_time;
|
2019-02-04 03:08:46 +01:00
|
|
|
|
|
|
|
/* EVPN enable - advertise svi macip routes */
|
|
|
|
int advertise_svi_macip;
|
|
|
|
|
2019-04-18 09:17:57 +02:00
|
|
|
/* PIP feature knob */
|
|
|
|
bool advertise_pip;
|
|
|
|
/* PIP IP (sys ip) */
|
|
|
|
struct in_addr pip_ip;
|
|
|
|
struct in_addr pip_ip_static;
|
|
|
|
/* PIP MAC (sys MAC) */
|
|
|
|
struct ethaddr pip_rmac;
|
|
|
|
struct ethaddr pip_rmac_static;
|
|
|
|
struct ethaddr pip_rmac_zebra;
|
|
|
|
bool is_anycast_mac;
|
2018-11-01 00:53:28 +01:00
|
|
|
};
|
|
|
|
|
2017-10-26 01:49:18 +02:00
|
|
|
static inline int is_vrf_rd_configured(struct bgp *bgp_vrf)
|
|
|
|
{
|
|
|
|
return (CHECK_FLAG(bgp_vrf->vrf_flags, BGP_VRF_RD_CFGD));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int bgp_evpn_vrf_rd_matches_existing(struct bgp *bgp_vrf,
|
|
|
|
struct prefix_rd *prd)
|
|
|
|
{
|
|
|
|
return (memcmp(&bgp_vrf->vrf_prd.val, prd->val, ECOMMUNITY_SIZE) == 0);
|
|
|
|
}
|
|
|
|
|
2017-10-09 10:29:04 +02:00
|
|
|
static inline vni_t bgpevpn_get_l3vni(struct bgpevpn *vpn)
|
|
|
|
{
|
2018-02-23 10:16:32 +01:00
|
|
|
return vpn->bgp_vrf ? vpn->bgp_vrf->l3vni : 0;
|
2017-10-09 10:29:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void bgpevpn_get_rmac(struct bgpevpn *vpn, struct ethaddr *rmac)
|
|
|
|
{
|
|
|
|
memset(rmac, 0, sizeof(struct ethaddr));
|
2018-02-23 10:16:32 +01:00
|
|
|
if (!vpn->bgp_vrf)
|
2017-10-09 10:29:04 +02:00
|
|
|
return;
|
2018-02-23 10:16:32 +01:00
|
|
|
memcpy(rmac, &vpn->bgp_vrf->rmac, sizeof(struct ethaddr));
|
2017-10-09 10:29:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct list *bgpevpn_get_vrf_export_rtl(struct bgpevpn *vpn)
|
|
|
|
{
|
2018-02-23 10:16:32 +01:00
|
|
|
if (!vpn->bgp_vrf)
|
2017-10-09 10:29:04 +02:00
|
|
|
return NULL;
|
|
|
|
|
2018-02-23 10:16:32 +01:00
|
|
|
return vpn->bgp_vrf->vrf_export_rtl;
|
2017-10-09 10:29:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct list *bgpevpn_get_vrf_import_rtl(struct bgpevpn *vpn)
|
|
|
|
{
|
2018-02-23 10:16:32 +01:00
|
|
|
if (!vpn->bgp_vrf)
|
2017-10-09 10:29:04 +02:00
|
|
|
return NULL;
|
|
|
|
|
2018-02-23 10:16:32 +01:00
|
|
|
return vpn->bgp_vrf->vrf_import_rtl;
|
2017-10-09 10:29:04 +02:00
|
|
|
}
|
|
|
|
|
2020-05-09 04:24:56 +02:00
|
|
|
extern void bgp_evpn_es_evi_vrf_ref(struct bgpevpn *vpn);
|
|
|
|
extern void bgp_evpn_es_evi_vrf_deref(struct bgpevpn *vpn);
|
|
|
|
|
2017-10-09 05:43:14 +02:00
|
|
|
static inline void bgpevpn_unlink_from_l3vni(struct bgpevpn *vpn)
|
|
|
|
{
|
2018-02-23 10:16:32 +01:00
|
|
|
/* bail if vpn is not associated to bgp_vrf */
|
|
|
|
if (!vpn->bgp_vrf)
|
2017-10-09 05:43:14 +02:00
|
|
|
return;
|
2018-03-06 20:02:52 +01:00
|
|
|
|
2018-02-06 23:28:22 +01:00
|
|
|
UNSET_FLAG(vpn->flags, VNI_FLAG_USE_TWO_LABELS);
|
2018-02-23 10:16:32 +01:00
|
|
|
listnode_delete(vpn->bgp_vrf->l2vnis, vpn);
|
2018-03-06 20:02:52 +01:00
|
|
|
|
2020-05-09 04:24:56 +02:00
|
|
|
bgp_evpn_es_evi_vrf_deref(vpn);
|
|
|
|
|
2018-02-23 10:16:32 +01:00
|
|
|
/* remove the backpointer to the vrf instance */
|
2019-04-17 18:39:03 +02:00
|
|
|
bgp_unlock(vpn->bgp_vrf);
|
2018-02-23 10:16:32 +01:00
|
|
|
vpn->bgp_vrf = NULL;
|
2017-10-09 05:43:14 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void bgpevpn_link_to_l3vni(struct bgpevpn *vpn)
|
|
|
|
{
|
|
|
|
struct bgp *bgp_vrf = NULL;
|
|
|
|
|
2018-02-23 10:16:32 +01:00
|
|
|
/* bail if vpn is already associated to vrf */
|
|
|
|
if (vpn->bgp_vrf)
|
|
|
|
return;
|
|
|
|
|
2017-10-09 05:43:14 +02:00
|
|
|
bgp_vrf = bgp_lookup_by_vrf_id(vpn->tenant_vrf_id);
|
2018-02-06 23:28:22 +01:00
|
|
|
if (!bgp_vrf)
|
2017-10-09 05:43:14 +02:00
|
|
|
return;
|
2018-02-06 23:28:22 +01:00
|
|
|
|
2018-02-23 10:16:32 +01:00
|
|
|
/* associate the vpn to the bgp_vrf instance */
|
2019-04-17 18:39:03 +02:00
|
|
|
vpn->bgp_vrf = bgp_lock(bgp_vrf);
|
2017-10-09 05:43:14 +02:00
|
|
|
listnode_add_sort(bgp_vrf->l2vnis, vpn);
|
2018-02-27 11:00:10 +01:00
|
|
|
|
2020-05-07 22:33:02 +02:00
|
|
|
/*
|
|
|
|
* If L3VNI is configured,
|
|
|
|
* check if we are advertising two labels for this vpn
|
|
|
|
*/
|
|
|
|
if (bgp_vrf->l3vni &&
|
|
|
|
!CHECK_FLAG(bgp_vrf->vrf_flags, BGP_VRF_L3VNI_PREFIX_ROUTES_ONLY))
|
2018-02-06 23:28:22 +01:00
|
|
|
SET_FLAG(vpn->flags, VNI_FLAG_USE_TWO_LABELS);
|
2020-05-09 04:24:56 +02:00
|
|
|
|
|
|
|
bgp_evpn_es_evi_vrf_ref(vpn);
|
2017-10-09 05:43:14 +02:00
|
|
|
}
|
|
|
|
|
2017-05-15 23:34:04 +02:00
|
|
|
static inline int is_vni_configured(struct bgpevpn *vpn)
|
|
|
|
{
|
|
|
|
return (CHECK_FLAG(vpn->flags, VNI_FLAG_CFGD));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int is_vni_live(struct bgpevpn *vpn)
|
|
|
|
{
|
|
|
|
return (CHECK_FLAG(vpn->flags, VNI_FLAG_LIVE));
|
|
|
|
}
|
|
|
|
|
2019-08-19 08:07:59 +02:00
|
|
|
static inline int is_l3vni_live(struct bgp *bgp_vrf)
|
|
|
|
{
|
|
|
|
return (bgp_vrf->l3vni && bgp_vrf->l3vni_svi_ifindex);
|
|
|
|
}
|
|
|
|
|
2017-05-15 23:34:04 +02:00
|
|
|
static inline int is_rd_configured(struct bgpevpn *vpn)
|
|
|
|
{
|
|
|
|
return (CHECK_FLAG(vpn->flags, VNI_FLAG_RD_CFGD));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int bgp_evpn_rd_matches_existing(struct bgpevpn *vpn,
|
|
|
|
struct prefix_rd *prd)
|
|
|
|
{
|
|
|
|
return (memcmp(&vpn->prd.val, prd->val, ECOMMUNITY_SIZE) == 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int is_import_rt_configured(struct bgpevpn *vpn)
|
|
|
|
{
|
|
|
|
return (CHECK_FLAG(vpn->flags, VNI_FLAG_IMPRT_CFGD));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int is_export_rt_configured(struct bgpevpn *vpn)
|
|
|
|
{
|
|
|
|
return (CHECK_FLAG(vpn->flags, VNI_FLAG_EXPRT_CFGD));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int is_vni_param_configured(struct bgpevpn *vpn)
|
|
|
|
{
|
|
|
|
return (is_rd_configured(vpn) || is_import_rt_configured(vpn)
|
|
|
|
|| is_export_rt_configured(vpn));
|
|
|
|
}
|
|
|
|
|
2018-04-14 00:01:12 +02:00
|
|
|
static inline void encode_es_rt_extcomm(struct ecommunity_val *eval,
|
|
|
|
struct ethaddr *mac)
|
|
|
|
{
|
|
|
|
memset(eval, 0, sizeof(struct ecommunity_val));
|
|
|
|
eval->val[0] = ECOMMUNITY_ENCODE_EVPN;
|
|
|
|
eval->val[1] = ECOMMUNITY_EVPN_SUBTYPE_ES_IMPORT_RT;
|
|
|
|
memcpy(&eval->val[2], mac, ETH_ALEN);
|
|
|
|
}
|
|
|
|
|
2020-05-09 01:35:09 +02:00
|
|
|
static inline void encode_df_elect_extcomm(struct ecommunity_val *eval,
|
|
|
|
uint16_t pref)
|
|
|
|
{
|
|
|
|
memset(eval, 0, sizeof(*eval));
|
|
|
|
eval->val[0] = ECOMMUNITY_ENCODE_EVPN;
|
|
|
|
eval->val[1] = ECOMMUNITY_EVPN_SUBTYPE_DF_ELECTION;
|
|
|
|
eval->val[2] = EVPN_MH_DF_ALG_PREF;
|
|
|
|
eval->val[6] = (pref >> 8) & 0xff;
|
|
|
|
eval->val[7] = pref & 0xff;
|
|
|
|
}
|
|
|
|
|
bgpd: support for Ethernet Segments and Type-1/EAD routes
This is the base patch that brings in support for Type-1 routes.
It includes support for -
- Ethernet Segment (ES) management
- EAD route handling
- MAC-IP (Type-2) routes with a non-zero ESI i.e. Aliasing for
active-active multihoming
- Initial infra for consistency checking. Consistency checking
is a fundamental feature for active-active solutions like MLAG.
We will try to levarage the info in the EAD-ES/EAD-EVI routes to
detect inconsitencies in access config across VTEPs attached to
the same Ethernet Segment.
Functionality Overview -
========================
1. Ethernet segments are created in zebra and associated with
access VLANs. zebra sends that info as ES and ES-EVI objects to BGP.
2. BGP advertises EAD-ES and EAD-EVI routes for the locally attached
ethernet segments.
3. Similarly BGP processes EAD-ES and EAD-EVI routes from peers
and translates them into ES-VTEP objects which are then sent to zebra
as remote ESs.
4. Each ES in zebra is associated with a list of active VTEPs which
is then translated into a L2-NHG (nexthop group). This is the ES
"Alias" entry
5. MAC-IP routes with a non-zero ESI use the alias entry created in
(4.) to forward traffic i.e. a MAC-ECMP is done to these remote-ES
destinations.
EAD route management (route table and key) -
============================================
1. Local EAD-ES routes
a. route-table: per-ES route-table
key: {RD=ES-RD, ESI, ET=0xffffffff, VTEP-IP)
b. route-table: per-VNI route-table
Not added
c. route-table: global route-table
key: {RD=ES-RD, ESI, ET=0xffffffff)
2. Remote EAD-ES routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=ES-RD, ESI, ET=0xffffffff, VTEP-IP)
c. route-table: global route-table
key: {RD=ES-RD, ESI, ET=0xffffffff)
3. Local EAD-EVI routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=0, ESI, ET=0, VTEP-IP)
c. route-table: global route-table
key: {RD=L2-VNI-RD, ESI, ET=0)
4. Remote EAD-EVI routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=0, ESI, ET=0, VTEP-IP)
c. route-table: global route-table
key: {RD=L2-VNI-RD, ESI, ET=0)
Please refer to bgp_evpn_mh.h for info on how the data-structures are
organized.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
2020-03-27 22:43:50 +01:00
|
|
|
static inline void encode_esi_label_extcomm(struct ecommunity_val *eval,
|
|
|
|
bool single_active)
|
|
|
|
{
|
|
|
|
memset(eval, 0, sizeof(struct ecommunity_val));
|
|
|
|
eval->val[0] = ECOMMUNITY_ENCODE_EVPN;
|
|
|
|
eval->val[1] = ECOMMUNITY_EVPN_SUBTYPE_ESI_LABEL;
|
|
|
|
if (single_active)
|
|
|
|
eval->val[2] |= (1 << 0);
|
|
|
|
}
|
|
|
|
|
2017-10-09 13:55:57 +02:00
|
|
|
static inline void encode_rmac_extcomm(struct ecommunity_val *eval,
|
|
|
|
struct ethaddr *rmac)
|
|
|
|
{
|
|
|
|
memset(eval, 0, sizeof(*eval));
|
|
|
|
eval->val[0] = ECOMMUNITY_ENCODE_EVPN;
|
|
|
|
eval->val[1] = ECOMMUNITY_EVPN_SUBTYPE_ROUTERMAC;
|
|
|
|
memcpy(&eval->val[2], rmac, ETH_ALEN);
|
|
|
|
}
|
|
|
|
|
2017-11-13 12:19:52 +01:00
|
|
|
static inline void encode_default_gw_extcomm(struct ecommunity_val *eval)
|
|
|
|
{
|
|
|
|
memset(eval, 0, sizeof(*eval));
|
|
|
|
eval->val[0] = ECOMMUNITY_ENCODE_OPAQUE;
|
|
|
|
eval->val[1] = ECOMMUNITY_EVPN_SUBTYPE_DEF_GW;
|
|
|
|
}
|
|
|
|
|
2018-03-27 21:13:34 +02:00
|
|
|
static inline void encode_mac_mobility_extcomm(int static_mac, uint32_t seq,
|
2017-05-15 23:34:04 +02:00
|
|
|
struct ecommunity_val *eval)
|
|
|
|
{
|
|
|
|
memset(eval, 0, sizeof(*eval));
|
|
|
|
eval->val[0] = ECOMMUNITY_ENCODE_EVPN;
|
|
|
|
eval->val[1] = ECOMMUNITY_EVPN_SUBTYPE_MACMOBILITY;
|
|
|
|
if (static_mac)
|
|
|
|
eval->val[2] = ECOMMUNITY_EVPN_SUBTYPE_MACMOBILITY_FLAG_STICKY;
|
|
|
|
eval->val[4] = (seq >> 24) & 0xff;
|
|
|
|
eval->val[5] = (seq >> 16) & 0xff;
|
|
|
|
eval->val[6] = (seq >> 8) & 0xff;
|
|
|
|
eval->val[7] = seq & 0xff;
|
|
|
|
}
|
|
|
|
|
2018-07-07 06:46:46 +02:00
|
|
|
static inline void encode_na_flag_extcomm(struct ecommunity_val *eval,
|
2020-03-28 18:12:04 +01:00
|
|
|
uint8_t na_flag, bool proxy)
|
2018-07-07 06:46:46 +02:00
|
|
|
{
|
|
|
|
memset(eval, 0, sizeof(*eval));
|
|
|
|
eval->val[0] = ECOMMUNITY_ENCODE_EVPN;
|
|
|
|
eval->val[1] = ECOMMUNITY_EVPN_SUBTYPE_ND;
|
|
|
|
if (na_flag)
|
|
|
|
eval->val[2] |= ECOMMUNITY_EVPN_SUBTYPE_ND_ROUTER_FLAG;
|
2020-03-28 18:12:04 +01:00
|
|
|
if (proxy)
|
|
|
|
eval->val[2] |= ECOMMUNITY_EVPN_SUBTYPE_PROXY_FLAG;
|
2018-07-07 06:46:46 +02:00
|
|
|
}
|
|
|
|
|
2020-03-22 19:50:46 +01:00
|
|
|
static inline void ip_prefix_from_type5_prefix(const struct prefix_evpn *evp,
|
2017-11-07 10:52:23 +01:00
|
|
|
struct prefix *ip)
|
|
|
|
{
|
|
|
|
memset(ip, 0, sizeof(struct prefix));
|
2018-04-14 00:37:30 +02:00
|
|
|
if (is_evpn_prefix_ipaddr_v4(evp)) {
|
2017-11-07 10:52:23 +01:00
|
|
|
ip->family = AF_INET;
|
2018-04-14 00:37:30 +02:00
|
|
|
ip->prefixlen = evp->prefix.prefix_addr.ip_prefix_length;
|
|
|
|
memcpy(&(ip->u.prefix4), &(evp->prefix.prefix_addr.ip.ip),
|
2017-11-07 10:52:23 +01:00
|
|
|
IPV4_MAX_BYTELEN);
|
2018-04-14 00:37:30 +02:00
|
|
|
} else if (is_evpn_prefix_ipaddr_v6(evp)) {
|
2017-11-07 10:52:23 +01:00
|
|
|
ip->family = AF_INET6;
|
2018-04-14 00:37:30 +02:00
|
|
|
ip->prefixlen = evp->prefix.prefix_addr.ip_prefix_length;
|
|
|
|
memcpy(&(ip->u.prefix6), &(evp->prefix.prefix_addr.ip.ip),
|
2017-11-07 10:52:23 +01:00
|
|
|
IPV6_MAX_BYTELEN);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-07-12 22:05:19 +02:00
|
|
|
static inline int is_evpn_prefix_default(const struct prefix *evp)
|
2018-02-22 07:02:07 +01:00
|
|
|
{
|
|
|
|
if (evp->family != AF_EVPN)
|
|
|
|
return 0;
|
|
|
|
|
2018-04-14 00:37:30 +02:00
|
|
|
return ((evp->u.prefix_evpn.prefix_addr.ip_prefix_length == 0) ?
|
|
|
|
1 : 0);
|
2018-02-22 07:02:07 +01:00
|
|
|
}
|
|
|
|
|
2020-03-22 19:50:46 +01:00
|
|
|
static inline void ip_prefix_from_type2_prefix(const struct prefix_evpn *evp,
|
2017-10-11 10:32:54 +02:00
|
|
|
struct prefix *ip)
|
|
|
|
{
|
|
|
|
memset(ip, 0, sizeof(struct prefix));
|
2018-04-14 00:37:30 +02:00
|
|
|
if (is_evpn_prefix_ipaddr_v4(evp)) {
|
2017-10-11 10:32:54 +02:00
|
|
|
ip->family = AF_INET;
|
|
|
|
ip->prefixlen = IPV4_MAX_BITLEN;
|
2018-04-14 00:37:30 +02:00
|
|
|
memcpy(&(ip->u.prefix4), &(evp->prefix.macip_addr.ip.ip),
|
2017-10-11 10:32:54 +02:00
|
|
|
IPV4_MAX_BYTELEN);
|
2018-04-14 00:37:30 +02:00
|
|
|
} else if (is_evpn_prefix_ipaddr_v6(evp)) {
|
2017-10-11 10:32:54 +02:00
|
|
|
ip->family = AF_INET6;
|
|
|
|
ip->prefixlen = IPV6_MAX_BITLEN;
|
2018-04-14 00:37:30 +02:00
|
|
|
memcpy(&(ip->u.prefix6), &(evp->prefix.macip_addr.ip.ip),
|
2017-10-11 10:32:54 +02:00
|
|
|
IPV6_MAX_BYTELEN);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-03-22 19:50:46 +01:00
|
|
|
static inline void ip_prefix_from_evpn_prefix(const struct prefix_evpn *evp,
|
2018-04-14 00:37:30 +02:00
|
|
|
struct prefix *ip)
|
|
|
|
{
|
|
|
|
if (evp->prefix.route_type == BGP_EVPN_MAC_IP_ROUTE)
|
|
|
|
ip_prefix_from_type2_prefix(evp, ip);
|
|
|
|
else if (evp->prefix.route_type == BGP_EVPN_IP_PREFIX_ROUTE)
|
|
|
|
ip_prefix_from_type5_prefix(evp, ip);
|
|
|
|
}
|
|
|
|
|
2017-05-15 23:34:04 +02:00
|
|
|
static inline void build_evpn_type2_prefix(struct prefix_evpn *p,
|
|
|
|
struct ethaddr *mac,
|
|
|
|
struct ipaddr *ip)
|
|
|
|
{
|
|
|
|
memset(p, 0, sizeof(struct prefix_evpn));
|
2017-08-08 16:16:12 +02:00
|
|
|
p->family = AF_EVPN;
|
2018-04-14 00:01:12 +02:00
|
|
|
p->prefixlen = EVPN_ROUTE_PREFIXLEN;
|
2017-05-15 23:34:04 +02:00
|
|
|
p->prefix.route_type = BGP_EVPN_MAC_IP_ROUTE;
|
2018-04-14 00:37:30 +02:00
|
|
|
memcpy(&p->prefix.macip_addr.mac.octet, mac->octet, ETH_ALEN);
|
|
|
|
p->prefix.macip_addr.ip.ipa_type = IPADDR_NONE;
|
2017-05-15 23:34:04 +02:00
|
|
|
if (ip)
|
2018-04-14 00:37:30 +02:00
|
|
|
memcpy(&p->prefix.macip_addr.ip, ip, sizeof(*ip));
|
2017-05-15 23:34:04 +02:00
|
|
|
}
|
|
|
|
|
2020-03-22 19:50:46 +01:00
|
|
|
static inline void
|
|
|
|
build_type5_prefix_from_ip_prefix(struct prefix_evpn *evp,
|
|
|
|
const struct prefix *ip_prefix)
|
2017-10-27 23:15:45 +02:00
|
|
|
{
|
|
|
|
struct ipaddr ip;
|
|
|
|
|
|
|
|
memset(&ip, 0, sizeof(struct ipaddr));
|
|
|
|
if (ip_prefix->family == AF_INET) {
|
|
|
|
ip.ipa_type = IPADDR_V4;
|
|
|
|
memcpy(&ip.ipaddr_v4, &ip_prefix->u.prefix4,
|
|
|
|
sizeof(struct in_addr));
|
|
|
|
} else {
|
|
|
|
ip.ipa_type = IPADDR_V6;
|
|
|
|
memcpy(&ip.ipaddr_v6, &ip_prefix->u.prefix6,
|
|
|
|
sizeof(struct in6_addr));
|
|
|
|
}
|
|
|
|
|
|
|
|
memset(evp, 0, sizeof(struct prefix_evpn));
|
|
|
|
evp->family = AF_EVPN;
|
2018-04-14 00:01:12 +02:00
|
|
|
evp->prefixlen = EVPN_ROUTE_PREFIXLEN;
|
2017-10-27 23:15:45 +02:00
|
|
|
evp->prefix.route_type = BGP_EVPN_IP_PREFIX_ROUTE;
|
2018-04-14 00:37:30 +02:00
|
|
|
evp->prefix.prefix_addr.ip_prefix_length = ip_prefix->prefixlen;
|
|
|
|
evp->prefix.prefix_addr.ip.ipa_type = ip.ipa_type;
|
|
|
|
memcpy(&evp->prefix.prefix_addr.ip, &ip, sizeof(struct ipaddr));
|
2017-10-27 23:15:45 +02:00
|
|
|
}
|
|
|
|
|
2017-05-15 23:34:04 +02:00
|
|
|
static inline void build_evpn_type3_prefix(struct prefix_evpn *p,
|
|
|
|
struct in_addr originator_ip)
|
|
|
|
{
|
|
|
|
memset(p, 0, sizeof(struct prefix_evpn));
|
2017-08-08 16:16:12 +02:00
|
|
|
p->family = AF_EVPN;
|
2018-04-14 00:01:12 +02:00
|
|
|
p->prefixlen = EVPN_ROUTE_PREFIXLEN;
|
2017-05-15 23:34:04 +02:00
|
|
|
p->prefix.route_type = BGP_EVPN_IMET_ROUTE;
|
2018-04-14 00:37:30 +02:00
|
|
|
p->prefix.imet_addr.ip.ipa_type = IPADDR_V4;
|
|
|
|
p->prefix.imet_addr.ip.ipaddr_v4 = originator_ip;
|
2017-05-15 23:34:04 +02:00
|
|
|
}
|
|
|
|
|
2018-04-14 00:01:12 +02:00
|
|
|
static inline void build_evpn_type4_prefix(struct prefix_evpn *p,
|
|
|
|
esi_t *esi,
|
|
|
|
struct in_addr originator_ip)
|
|
|
|
{
|
|
|
|
memset(p, 0, sizeof(struct prefix_evpn));
|
|
|
|
p->family = AF_EVPN;
|
|
|
|
p->prefixlen = EVPN_ROUTE_PREFIXLEN;
|
|
|
|
p->prefix.route_type = BGP_EVPN_ES_ROUTE;
|
|
|
|
p->prefix.es_addr.ip_prefix_length = IPV4_MAX_BITLEN;
|
|
|
|
p->prefix.es_addr.ip.ipa_type = IPADDR_V4;
|
|
|
|
p->prefix.es_addr.ip.ipaddr_v4 = originator_ip;
|
|
|
|
memcpy(&p->prefix.es_addr.esi, esi, sizeof(esi_t));
|
|
|
|
}
|
|
|
|
|
bgpd: support for Ethernet Segments and Type-1/EAD routes
This is the base patch that brings in support for Type-1 routes.
It includes support for -
- Ethernet Segment (ES) management
- EAD route handling
- MAC-IP (Type-2) routes with a non-zero ESI i.e. Aliasing for
active-active multihoming
- Initial infra for consistency checking. Consistency checking
is a fundamental feature for active-active solutions like MLAG.
We will try to levarage the info in the EAD-ES/EAD-EVI routes to
detect inconsitencies in access config across VTEPs attached to
the same Ethernet Segment.
Functionality Overview -
========================
1. Ethernet segments are created in zebra and associated with
access VLANs. zebra sends that info as ES and ES-EVI objects to BGP.
2. BGP advertises EAD-ES and EAD-EVI routes for the locally attached
ethernet segments.
3. Similarly BGP processes EAD-ES and EAD-EVI routes from peers
and translates them into ES-VTEP objects which are then sent to zebra
as remote ESs.
4. Each ES in zebra is associated with a list of active VTEPs which
is then translated into a L2-NHG (nexthop group). This is the ES
"Alias" entry
5. MAC-IP routes with a non-zero ESI use the alias entry created in
(4.) to forward traffic i.e. a MAC-ECMP is done to these remote-ES
destinations.
EAD route management (route table and key) -
============================================
1. Local EAD-ES routes
a. route-table: per-ES route-table
key: {RD=ES-RD, ESI, ET=0xffffffff, VTEP-IP)
b. route-table: per-VNI route-table
Not added
c. route-table: global route-table
key: {RD=ES-RD, ESI, ET=0xffffffff)
2. Remote EAD-ES routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=ES-RD, ESI, ET=0xffffffff, VTEP-IP)
c. route-table: global route-table
key: {RD=ES-RD, ESI, ET=0xffffffff)
3. Local EAD-EVI routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=0, ESI, ET=0, VTEP-IP)
c. route-table: global route-table
key: {RD=L2-VNI-RD, ESI, ET=0)
4. Remote EAD-EVI routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=0, ESI, ET=0, VTEP-IP)
c. route-table: global route-table
key: {RD=L2-VNI-RD, ESI, ET=0)
Please refer to bgp_evpn_mh.h for info on how the data-structures are
organized.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
2020-03-27 22:43:50 +01:00
|
|
|
static inline void build_evpn_type1_prefix(struct prefix_evpn *p,
|
|
|
|
uint32_t eth_tag,
|
|
|
|
esi_t *esi,
|
|
|
|
struct in_addr originator_ip)
|
|
|
|
{
|
|
|
|
memset(p, 0, sizeof(struct prefix_evpn));
|
|
|
|
p->family = AF_EVPN;
|
|
|
|
p->prefixlen = EVPN_ROUTE_PREFIXLEN;
|
|
|
|
p->prefix.route_type = BGP_EVPN_AD_ROUTE;
|
|
|
|
p->prefix.ead_addr.eth_tag = eth_tag;
|
|
|
|
p->prefix.ead_addr.ip.ipa_type = IPADDR_V4;
|
|
|
|
p->prefix.ead_addr.ip.ipaddr_v4 = originator_ip;
|
|
|
|
memcpy(&p->prefix.ead_addr.esi, esi, sizeof(esi_t));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void evpn_type1_prefix_global_copy(struct prefix_evpn *global_p,
|
|
|
|
const struct prefix_evpn *vni_p)
|
|
|
|
{
|
|
|
|
memcpy(global_p, vni_p, sizeof(*global_p));
|
|
|
|
global_p->prefix.ead_addr.ip.ipa_type = 0;
|
2020-12-14 20:01:31 +01:00
|
|
|
global_p->prefix.ead_addr.ip.ipaddr_v4.s_addr = INADDR_ANY;
|
bgpd: support for Ethernet Segments and Type-1/EAD routes
This is the base patch that brings in support for Type-1 routes.
It includes support for -
- Ethernet Segment (ES) management
- EAD route handling
- MAC-IP (Type-2) routes with a non-zero ESI i.e. Aliasing for
active-active multihoming
- Initial infra for consistency checking. Consistency checking
is a fundamental feature for active-active solutions like MLAG.
We will try to levarage the info in the EAD-ES/EAD-EVI routes to
detect inconsitencies in access config across VTEPs attached to
the same Ethernet Segment.
Functionality Overview -
========================
1. Ethernet segments are created in zebra and associated with
access VLANs. zebra sends that info as ES and ES-EVI objects to BGP.
2. BGP advertises EAD-ES and EAD-EVI routes for the locally attached
ethernet segments.
3. Similarly BGP processes EAD-ES and EAD-EVI routes from peers
and translates them into ES-VTEP objects which are then sent to zebra
as remote ESs.
4. Each ES in zebra is associated with a list of active VTEPs which
is then translated into a L2-NHG (nexthop group). This is the ES
"Alias" entry
5. MAC-IP routes with a non-zero ESI use the alias entry created in
(4.) to forward traffic i.e. a MAC-ECMP is done to these remote-ES
destinations.
EAD route management (route table and key) -
============================================
1. Local EAD-ES routes
a. route-table: per-ES route-table
key: {RD=ES-RD, ESI, ET=0xffffffff, VTEP-IP)
b. route-table: per-VNI route-table
Not added
c. route-table: global route-table
key: {RD=ES-RD, ESI, ET=0xffffffff)
2. Remote EAD-ES routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=ES-RD, ESI, ET=0xffffffff, VTEP-IP)
c. route-table: global route-table
key: {RD=ES-RD, ESI, ET=0xffffffff)
3. Local EAD-EVI routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=0, ESI, ET=0, VTEP-IP)
c. route-table: global route-table
key: {RD=L2-VNI-RD, ESI, ET=0)
4. Remote EAD-EVI routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=0, ESI, ET=0, VTEP-IP)
c. route-table: global route-table
key: {RD=L2-VNI-RD, ESI, ET=0)
Please refer to bgp_evpn_mh.h for info on how the data-structures are
organized.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
2020-03-27 22:43:50 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* EAD prefix in the global table doesn't include the VTEP-IP so
|
|
|
|
* we need to create a different copy for the VNI
|
|
|
|
*/
|
|
|
|
static inline struct prefix_evpn *evpn_type1_prefix_vni_copy(
|
|
|
|
struct prefix_evpn *vni_p,
|
|
|
|
const struct prefix_evpn *global_p,
|
|
|
|
struct in_addr originator_ip)
|
|
|
|
{
|
|
|
|
memcpy(vni_p, global_p, sizeof(*vni_p));
|
|
|
|
vni_p->prefix.ead_addr.ip.ipa_type = IPADDR_V4;
|
|
|
|
vni_p->prefix.ead_addr.ip.ipaddr_v4 = originator_ip;
|
|
|
|
|
|
|
|
return vni_p;
|
|
|
|
}
|
|
|
|
|
2018-02-16 02:20:27 +01:00
|
|
|
static inline int evpn_default_originate_set(struct bgp *bgp, afi_t afi,
|
|
|
|
safi_t safi)
|
|
|
|
{
|
|
|
|
if (afi == AFI_IP &&
|
|
|
|
CHECK_FLAG(bgp->af_flags[AFI_L2VPN][SAFI_EVPN],
|
|
|
|
BGP_L2VPN_EVPN_DEFAULT_ORIGINATE_IPV4))
|
|
|
|
return 1;
|
|
|
|
else if (afi == AFI_IP6 &&
|
|
|
|
CHECK_FLAG(bgp->af_flags[AFI_L2VPN][SAFI_EVPN],
|
|
|
|
BGP_L2VPN_EVPN_DEFAULT_ORIGINATE_IPV6))
|
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-04-14 00:01:12 +02:00
|
|
|
static inline void es_get_system_mac(esi_t *esi,
|
|
|
|
struct ethaddr *mac)
|
|
|
|
{
|
2018-05-16 14:17:53 +02:00
|
|
|
/*
|
|
|
|
* for type-1 and type-3 ESIs,
|
|
|
|
* the system mac starts at val[1]
|
2018-04-14 00:01:12 +02:00
|
|
|
*/
|
|
|
|
memcpy(mac, &esi->val[1], ETH_ALEN);
|
|
|
|
}
|
|
|
|
|
2019-08-09 03:58:03 +02:00
|
|
|
static inline bool bgp_evpn_is_svi_macip_enabled(struct bgpevpn *vpn)
|
|
|
|
{
|
|
|
|
struct bgp *bgp_evpn = NULL;
|
|
|
|
|
|
|
|
bgp_evpn = bgp_get_evpn();
|
|
|
|
|
|
|
|
return (bgp_evpn->evpn_info->advertise_svi_macip ||
|
|
|
|
vpn->advertise_svi_macip);
|
|
|
|
}
|
|
|
|
|
2020-03-28 18:12:04 +01:00
|
|
|
static inline bool bgp_evpn_is_path_local(struct bgp *bgp,
|
|
|
|
struct bgp_path_info *pi)
|
|
|
|
{
|
|
|
|
return (pi->peer == bgp->peer_self
|
|
|
|
&& pi->type == ZEBRA_ROUTE_BGP
|
|
|
|
&& pi->sub_type == BGP_ROUTE_STATIC);
|
|
|
|
}
|
|
|
|
|
bgpd: support for Ethernet Segments and Type-1/EAD routes
This is the base patch that brings in support for Type-1 routes.
It includes support for -
- Ethernet Segment (ES) management
- EAD route handling
- MAC-IP (Type-2) routes with a non-zero ESI i.e. Aliasing for
active-active multihoming
- Initial infra for consistency checking. Consistency checking
is a fundamental feature for active-active solutions like MLAG.
We will try to levarage the info in the EAD-ES/EAD-EVI routes to
detect inconsitencies in access config across VTEPs attached to
the same Ethernet Segment.
Functionality Overview -
========================
1. Ethernet segments are created in zebra and associated with
access VLANs. zebra sends that info as ES and ES-EVI objects to BGP.
2. BGP advertises EAD-ES and EAD-EVI routes for the locally attached
ethernet segments.
3. Similarly BGP processes EAD-ES and EAD-EVI routes from peers
and translates them into ES-VTEP objects which are then sent to zebra
as remote ESs.
4. Each ES in zebra is associated with a list of active VTEPs which
is then translated into a L2-NHG (nexthop group). This is the ES
"Alias" entry
5. MAC-IP routes with a non-zero ESI use the alias entry created in
(4.) to forward traffic i.e. a MAC-ECMP is done to these remote-ES
destinations.
EAD route management (route table and key) -
============================================
1. Local EAD-ES routes
a. route-table: per-ES route-table
key: {RD=ES-RD, ESI, ET=0xffffffff, VTEP-IP)
b. route-table: per-VNI route-table
Not added
c. route-table: global route-table
key: {RD=ES-RD, ESI, ET=0xffffffff)
2. Remote EAD-ES routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=ES-RD, ESI, ET=0xffffffff, VTEP-IP)
c. route-table: global route-table
key: {RD=ES-RD, ESI, ET=0xffffffff)
3. Local EAD-EVI routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=0, ESI, ET=0, VTEP-IP)
c. route-table: global route-table
key: {RD=L2-VNI-RD, ESI, ET=0)
4. Remote EAD-EVI routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=0, ESI, ET=0, VTEP-IP)
c. route-table: global route-table
key: {RD=L2-VNI-RD, ESI, ET=0)
Please refer to bgp_evpn_mh.h for info on how the data-structures are
organized.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
2020-03-27 22:43:50 +01:00
|
|
|
extern struct zclient *zclient;
|
|
|
|
|
2018-11-29 04:18:08 +01:00
|
|
|
extern void bgp_evpn_install_uninstall_default_route(struct bgp *bgp_vrf,
|
|
|
|
afi_t afi, safi_t safi,
|
|
|
|
bool add);
|
2017-10-09 03:34:29 +02:00
|
|
|
extern void evpn_rt_delete_auto(struct bgp *, vni_t, struct list *);
|
2017-12-27 20:47:10 +01:00
|
|
|
extern void bgp_evpn_configure_export_rt_for_vrf(struct bgp *bgp_vrf,
|
|
|
|
struct ecommunity *ecomadd);
|
|
|
|
extern void bgp_evpn_unconfigure_export_rt_for_vrf(struct bgp *bgp_vrf,
|
|
|
|
struct ecommunity *ecomdel);
|
|
|
|
extern void bgp_evpn_configure_import_rt_for_vrf(struct bgp *bgp_vrf,
|
|
|
|
struct ecommunity *ecomadd);
|
|
|
|
extern void bgp_evpn_unconfigure_import_rt_for_vrf(struct bgp *bgp_vrf,
|
|
|
|
struct ecommunity *ecomdel);
|
2017-05-16 00:01:57 +02:00
|
|
|
extern int bgp_evpn_handle_export_rt_change(struct bgp *bgp,
|
|
|
|
struct bgpevpn *vpn);
|
2017-04-12 11:24:07 +02:00
|
|
|
extern void bgp_evpn_handle_autort_change(struct bgp *bgp);
|
2017-10-26 01:49:18 +02:00
|
|
|
extern void bgp_evpn_handle_vrf_rd_change(struct bgp *bgp_vrf, int withdraw);
|
2017-05-16 00:01:57 +02:00
|
|
|
extern void bgp_evpn_handle_rd_change(struct bgp *bgp, struct bgpevpn *vpn,
|
|
|
|
int withdraw);
|
|
|
|
extern int bgp_evpn_install_routes(struct bgp *bgp, struct bgpevpn *vpn);
|
|
|
|
extern int bgp_evpn_uninstall_routes(struct bgp *bgp, struct bgpevpn *vpn);
|
2017-12-27 20:47:10 +01:00
|
|
|
extern void bgp_evpn_map_vrf_to_its_rts(struct bgp *bgp_vrf);
|
|
|
|
extern void bgp_evpn_unmap_vrf_from_its_rts(struct bgp *bgp_vrf);
|
2017-05-15 23:34:04 +02:00
|
|
|
extern void bgp_evpn_map_vni_to_its_rts(struct bgp *bgp, struct bgpevpn *vpn);
|
|
|
|
extern void bgp_evpn_unmap_vni_from_its_rts(struct bgp *bgp,
|
|
|
|
struct bgpevpn *vpn);
|
|
|
|
extern void bgp_evpn_derive_auto_rt_import(struct bgp *bgp,
|
|
|
|
struct bgpevpn *vpn);
|
|
|
|
extern void bgp_evpn_derive_auto_rt_export(struct bgp *bgp,
|
|
|
|
struct bgpevpn *vpn);
|
|
|
|
extern void bgp_evpn_derive_auto_rd(struct bgp *bgp, struct bgpevpn *vpn);
|
2017-10-26 01:49:18 +02:00
|
|
|
extern void bgp_evpn_derive_auto_rd_for_vrf(struct bgp *bgp);
|
2017-05-15 23:34:04 +02:00
|
|
|
extern struct bgpevpn *bgp_evpn_lookup_vni(struct bgp *bgp, vni_t vni);
|
|
|
|
extern struct bgpevpn *bgp_evpn_new(struct bgp *bgp, vni_t vni,
|
2019-03-19 19:08:24 +01:00
|
|
|
struct in_addr originator_ip,
|
|
|
|
vrf_id_t tenant_vrf_id,
|
|
|
|
struct in_addr mcast_grp);
|
2017-05-15 23:34:04 +02:00
|
|
|
extern void bgp_evpn_free(struct bgp *bgp, struct bgpevpn *vpn);
|
2018-08-01 03:45:39 +02:00
|
|
|
extern bool bgp_evpn_lookup_l3vni_l2vni_table(vni_t vni);
|
2019-08-09 03:58:03 +02:00
|
|
|
extern int update_routes_for_vni(struct bgp *bgp, struct bgpevpn *vpn);
|
2020-03-27 14:39:51 +01:00
|
|
|
extern void delete_evpn_route_entry(struct bgp *bgp, afi_t afi, safi_t safi,
|
|
|
|
struct bgp_dest *dest,
|
|
|
|
struct bgp_path_info **pi);
|
bgpd: support for Ethernet Segments and Type-1/EAD routes
This is the base patch that brings in support for Type-1 routes.
It includes support for -
- Ethernet Segment (ES) management
- EAD route handling
- MAC-IP (Type-2) routes with a non-zero ESI i.e. Aliasing for
active-active multihoming
- Initial infra for consistency checking. Consistency checking
is a fundamental feature for active-active solutions like MLAG.
We will try to levarage the info in the EAD-ES/EAD-EVI routes to
detect inconsitencies in access config across VTEPs attached to
the same Ethernet Segment.
Functionality Overview -
========================
1. Ethernet segments are created in zebra and associated with
access VLANs. zebra sends that info as ES and ES-EVI objects to BGP.
2. BGP advertises EAD-ES and EAD-EVI routes for the locally attached
ethernet segments.
3. Similarly BGP processes EAD-ES and EAD-EVI routes from peers
and translates them into ES-VTEP objects which are then sent to zebra
as remote ESs.
4. Each ES in zebra is associated with a list of active VTEPs which
is then translated into a L2-NHG (nexthop group). This is the ES
"Alias" entry
5. MAC-IP routes with a non-zero ESI use the alias entry created in
(4.) to forward traffic i.e. a MAC-ECMP is done to these remote-ES
destinations.
EAD route management (route table and key) -
============================================
1. Local EAD-ES routes
a. route-table: per-ES route-table
key: {RD=ES-RD, ESI, ET=0xffffffff, VTEP-IP)
b. route-table: per-VNI route-table
Not added
c. route-table: global route-table
key: {RD=ES-RD, ESI, ET=0xffffffff)
2. Remote EAD-ES routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=ES-RD, ESI, ET=0xffffffff, VTEP-IP)
c. route-table: global route-table
key: {RD=ES-RD, ESI, ET=0xffffffff)
3. Local EAD-EVI routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=0, ESI, ET=0, VTEP-IP)
c. route-table: global route-table
key: {RD=L2-VNI-RD, ESI, ET=0)
4. Remote EAD-EVI routes
a. route-table: per-ES route-table
Not added
b. route-table: per-VNI route-table
key: {RD=0, ESI, ET=0, VTEP-IP)
c. route-table: global route-table
key: {RD=L2-VNI-RD, ESI, ET=0)
Please refer to bgp_evpn_mh.h for info on how the data-structures are
organized.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
2020-03-27 22:43:50 +01:00
|
|
|
int vni_list_cmp(void *p1, void *p2);
|
|
|
|
extern int evpn_route_select_install(struct bgp *bgp, struct bgpevpn *vpn,
|
2020-10-14 17:19:45 +02:00
|
|
|
struct bgp_dest *dest);
|
|
|
|
extern struct bgp_dest *bgp_global_evpn_node_get(struct bgp_table *table,
|
|
|
|
afi_t afi, safi_t safi,
|
|
|
|
const struct prefix_evpn *evp,
|
|
|
|
struct prefix_rd *prd);
|
|
|
|
extern struct bgp_dest *
|
2020-05-09 04:36:47 +02:00
|
|
|
bgp_global_evpn_node_lookup(struct bgp_table *table, afi_t afi, safi_t safi,
|
|
|
|
const struct prefix_evpn *evp,
|
|
|
|
struct prefix_rd *prd);
|
|
|
|
extern void bgp_evpn_import_route_in_vrfs(struct bgp_path_info *pi, int import);
|
2020-08-15 00:48:34 +02:00
|
|
|
extern void bgp_evpn_update_type2_route_entry(struct bgp *bgp,
|
|
|
|
struct bgpevpn *vpn,
|
|
|
|
struct bgp_node *rn,
|
|
|
|
struct bgp_path_info *local_pi,
|
|
|
|
const char *caller);
|
2020-08-18 01:24:50 +02:00
|
|
|
extern int bgp_evpn_route_entry_install_if_vrf_match(struct bgp *bgp_vrf,
|
|
|
|
struct bgp_path_info *pi,
|
|
|
|
int install);
|
2020-08-30 23:05:33 +02:00
|
|
|
extern void bgp_evpn_import_type2_route(struct bgp_path_info *pi, int import);
|
2017-05-15 23:27:09 +02:00
|
|
|
#endif /* _BGP_EVPN_PRIVATE_H */
|