Hi all,
This thread is a starting point to discuss about Ethernet VPN
implementation in Quagga BGP daemon. Currently, the RFC7432 is not
supported in quagga 1.1.0.
This email is a preparatory work to open discussion.
It is also a preparatory work to propose the following EVPN implementation.
Best Regards,
Philippe
*Overview*
This implementation is a response for the following use case.
On the datacenter, there are openflow switches. Behind those openflow
switches, one can find hosts/VMs, as well as gateway nodes which can
host a number of IP addresses.
There is also a Data-Center Gateway (DC-GW) behind which one can find
the same kind of host/VMS and gateway nodes. Those VMs can be on the
same Data Center, or be in a remote Data Center.
The goal is to implement a Layer 2 network across the hosts/VMs such
that we can establish a L2 connectivity between the hosts behind DC-GW
and the hosts behind OF switches.
Quagga BGP daemon is in charge of sending (and receiving) signaling
information to (from) DC-GW, by using EVPN BGP implementation. It acts
on behalf on SDN controller of the Data Center. EVPN has been
implemented in the ability to establish vxlan tunnels within a data
center.
This work relies on some IETF documents.
- rfc7432
- draft-ietf-bess-evpn-inter-subnet-forwarding-01
- draft-ietf-idr-tunnel-encaps-02
- draft-ietf-bess-evpn-prefix-advertisement-02
- draft-ietf-bess-evpn-overlay-05
*EVPN feature proposed*
Currently, the proposed implementation covers the following:
- EVPN route type 2 aka MAC/IP advertisement
- EVPN route type 5 aka Prefix IP advertisement.
It is possible to statically set abovementioned messages.
It also covers BGP extended community attributes:
- Router MAC extended community
- BGP encapsulation attribute for VXLAN
- Tunnel Encapsulation attribute VXLAN
It also covers VRF import processing.
By using exported RT set from BGP extended communities, EVPN
information is added in ADJ-RIB-IN per VRF per neighbor table. Some
associated vty show commands are available.
*EVPN changes proposed*
The changes occur in lib/ and bgpd folder.
The following is impacted:
- bgpd folder and lib/zebra.h. Two new defines are appended: AFI_L2VPN
(25) and SAFI_EVPN (70). In order to minimize RIB table sizing, 2 new
defines: AFI_INTENRNAL_L2VPN and SAFI_INTERNAL_EVPN values are chosen.
afi_safi_valid_indices() routine will be changed to take into account.
BGP core code is updated so as to take into account relevant changes
regarding to the new parameters.
- bgpd: support for overlay index information
Route type 5 messages carry overlay index information, which can
either be Ethernet Segment Identifier ( ESI) or gateway IP ( GWIP).
This information is carried in extra attr information. Some APIs are
designed in order to manipulate overlay index: update/add/remove/dup.
Extract structures implement the above.
struct eth_segment_id
{
u_char val[ESI_LEN];
};
#define MAC_LEN 6
union gw_addr {
struct in_addr ipv4;
#ifdef HAVE_IPV6
struct in6_addr ipv6;
#endif /* HAVE_IPV6 */
};
/* Overlay Index Info */
struct overlay_index
{
struct eth_segment_id eth_s_id;
union gw_addr gw_ip;
};
- prefix.[ch] : prefix extension to support MAC/IP prefixes. Extract
below indicates what the prefix looks like now:
struct macipaddr {
u_int32_t eth_tag_id;
u_int8_t mac_len;
struct ethaddr mac;
u_int8_t ip_len;
union
{
struct in_addr in4; /* AF_INET */
#ifdef HAVE_IPV6
struct in6_addr in6; /* AF_INET6 */
#endif /* HAVE_IPV6 */
} ip __attribute__ ((packed));
};
- EVPN processing in reception and in emission. Modifications mainly
done in bgp_attr.[ch] and bgp_evpn.[ch]. BGP EVPN format is translated
into internal structures and vice-versa. bgp_update() routine is
adapted and uses an extra parameter ( struct bgp_route_evpn), as
indicated below.
struct bgp_route_evpn
{
uint32_t eth_t_id;
struct eth_segment_id eth_s_id;
union gw_addr gw_ip;
};
int bgp_update (struct peer *peer, struct prefix *p, struct attr *attr,
afi_t afi, safi_t safi, int type, int sub_type,
struct prefix_rd *prd, uint32_t *labels, size_t nlabels,
int soft_reconfig, struct bgp_route_evpn* evpn);
- EVPN extra information.
As indicated in above features, BGP router target extended community
and BGP vxlan encapsulation attribute are handled. For that,
bgp_ecommunity.[ch] file is modified.
Also, MAC/IP contains 2 label fields, one for layer 2, one for layer
3. This label is mapped to the current label list. The following is
chosen. First label entry is layer2. Second is for layer3.
- EVPN configuration
Currently, an internal API is used and is not yet mapped on vty.
This API is relying on an internal structure named bgp_api_route.
This is the configuration structure.
struct bgp_api_route
{
struct prefix prefix;
struct in_addr nexthop;
uint32_t label;
uint32_t ethtag;
uint32_t l2label;
char *esi;
char *mac_router;
};
Calling this internal API by filling in appropriately the structure
will permit creating local entries in
bgp->rib[AFI_INTERNAL_L2VPN][SAFI_INTERNAL_L2VPN], and send BGP
updates with the information to remote BGP speaker.
- EVPN exploitation
All evpn vty commands are available under "show l2vpn evpn" subnode.
The vty commands are available under bgp_evpn.[ch] file. The vty
commands one can find under show bgp ipv4 vpn subnode are also
available under evpn subnode.
Below is the output of the show bgp l2vpn evpn command. Note that it
displays the new MAC /IP prefix, with also the ethernet tag ( [0] ).
bgpd# show bgp l2vpn evpn all
BGP table version is 0, local router ID is 10.125.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, =
multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.125.0.1:1111
*> [0][01:02:03:04:05:06/48][22.22.0.1/32]
0 100 0 i
Total number of prefixes 1
bgpd#
It is also possible to dump the tagging information related to L2/L3
tagging information. The former tag stands for L2 information (642),
while the latter tag stands for L3 information ( 235).
bgpd# show bgp l2vpn evpn all tags
Network Next Hop In tag/Out tag
Route Distinguisher: ip 10.125.0.1:1111
*>i[0][01:02:03:04:05:06/48][22.22.0.1/32]
:/642:235
- VRF import processing.
This feature is available if the following patchses have been applied.
Those patches are part of series. It is recommended to take the whole
series to benefit from it.
https://patchwork.quagga.net/patch/2108/ : bgpd: VRF vty
configuration, RIB table creation
https://patchwork.quagga.net/patch/2128/ : bgpd: VRF import processing
As mentioned on the feature list, with the RT set included in received
BGP update message, the L2 and L3 information from MAC/IP is added in
the associate VRF RIB entry.
Each VRF RIB is appended an attribute that mentions the layer of the
VRF. On this case, each VRF RIB is either L2 or L3. According to this
information, the information received in MAC/IP advertisment will be
put to the relevant VRF.
More information on
draft-ietf-bess-evpn-inter-subnet-forwarding-01#section-5.1.1
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
