From b5d52e2c26b6b707c1cdd500a87071409b3e6a64 Mon Sep 17 00:00:00 2001 From: Wei Bai Date: Sat, 13 Apr 2019 01:09:12 +0800 Subject: [PATCH 1/3] Fix a typo --- doc/sonic-vrf-hld-v0.4.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/sonic-vrf-hld-v0.4.md b/doc/sonic-vrf-hld-v0.4.md index 6b028f6fb3..53351531d8 100644 --- a/doc/sonic-vrf-hld-v0.4.md +++ b/doc/sonic-vrf-hld-v0.4.md @@ -185,7 +185,7 @@ key = VRF_TABLE:VRF_NAME ; fallback = "true"/"false" ``` -3. **3. Add 2-segment key entry** support in APP-intf-table +3. **Add 2-segment key entry** support in APP-intf-table There is two reason why add 2-segment key entry in interface table. 1. Multiple ip addresses can be configured on one interface. So we put interface common attribute From 321cef537581cae38b075748adb837cb9fc2fe55 Mon Sep 17 00:00:00 2001 From: Wei Bai Date: Sun, 21 Apr 2019 01:49:02 +0800 Subject: [PATCH 2/3] Create fpmsyncd_hld.md --- doc/vxlan/fpmsyncd_hld.md | 57 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 doc/vxlan/fpmsyncd_hld.md diff --git a/doc/vxlan/fpmsyncd_hld.md b/doc/vxlan/fpmsyncd_hld.md new file mode 100644 index 0000000000..3a34ff989f --- /dev/null +++ b/doc/vxlan/fpmsyncd_hld.md @@ -0,0 +1,57 @@ +# Vxlan SONiC +# fpmsyncd design +### Rev 0.1 + +# Table of Contents + * [List of Tables](#list-of-tables) + + * [Revision](#revision) + + * [Scope](#scope) + + * [1 Requirements](#1-requirements) + + * [2 Flows](#2-flows) + + * [3 Reference Tables](#3-reference-tables) + + * [4 Examples](#4-examples) + +###### Revision +| Rev | Date | Author | Change Description | +|:---:|:-----------:|:------------------:|-----------------------------------| +| 0.1 | 04/20/2019 | Wei Bai | Initial version | + +# Scope +This document describes the design of fpmsyncd to support VNet routes. + +# Definitions/Abbreviation +###### Table 1: Abbreviations +| | | +|--------------------------|--------------------------------| +| VRF | Virtual Routing and Forwarding | +| VNet | Virtual Network | +| Vxlan | Virtual Extensible Local Area Network | +| VTEP | Vxlan Tunnel End Point | + +# 1 Requirements +This section describes the SONiC requirements for fpmsyncd in the context of VNet. + +At a high level the following features should be supported: + +Phase #1 +- Should be able to identify VNet routes from all the receiving routes. +- Should be able to parse VNet routes and insert/delete the right entries into/from the App DB. + +Phase #2 +- Should be able to support warm restart for VNet routes. + +# 2 Flows + +# 3 Reference Tables + +# 4 Examples + + + + From 88222865f31c29a8d57a99060d621e2b6d58dc90 Mon Sep 17 00:00:00 2001 From: Wei Bai Date: Sun, 21 Apr 2019 23:05:13 +0800 Subject: [PATCH 3/3] Finish the first version --- doc/vxlan/fpmsyncd_hld.md | 53 ++++++++++++++++++++++++++++++++++----- 1 file changed, 47 insertions(+), 6 deletions(-) diff --git a/doc/vxlan/fpmsyncd_hld.md b/doc/vxlan/fpmsyncd_hld.md index 3a34ff989f..93f1df0958 100644 --- a/doc/vxlan/fpmsyncd_hld.md +++ b/doc/vxlan/fpmsyncd_hld.md @@ -12,7 +12,10 @@ * [1 Requirements](#1-requirements) * [2 Flows](#2-flows) - + * [2.1 Identify VNet routes](#21-identify-vnet-routes) + * [2.2 Parse VNet routes](#22-parse-vnet-routes) + * [2.2.1 Identify VNet regular and tunnel routes](#221-identify-vnet-regular-and-tunnel-routes) + * [2.2.2 Handle VNet regular and tunnel routes](#222-handle-vnet-regular-and-tunnel-routes) * [3 Reference Tables](#3-reference-tables) * [4 Examples](#4-examples) @@ -20,7 +23,7 @@ ###### Revision | Rev | Date | Author | Change Description | |:---:|:-----------:|:------------------:|-----------------------------------| -| 0.1 | 04/20/2019 | Wei Bai | Initial version | +| 0.1 | 04/21/2019 | Wei Bai | Initial version | # Scope This document describes the design of fpmsyncd to support VNet routes. @@ -40,18 +43,56 @@ This section describes the SONiC requirements for fpmsyncd in the context of VNe At a high level the following features should be supported: Phase #1 -- Should be able to identify VNet routes from all the receiving routes. -- Should be able to parse VNet routes and insert/delete the right entries into/from the App DB. +- Identify VNet routes from all the receiving routes. +- Parse VNet routes to insert/delete the right entries into/from the App DB. Phase #2 -- Should be able to support warm restart for VNet routes. +- Support warm restart for VNet routes. # 2 Flows +## 2.1 Identify VNet routes +Given a input route, fpmsyncd first uses rtnl_route_get_table to get the master device's interface ID. Then fpmsyncd uses this interface ID to derive the name of the master device. + +fpmsyncd identifies VNet routes based on the name of the master device. If the name of the master device starts with "Vnet", the route is a VNet route. + +## 2.2 Parse VNet routes +After identifying VNet routes, the next challenge is how to parse them correctly to insert/delete the right entries into/from the App DB. + +### 2.2.1 Identify VNet regular and tunnel routes +There are two types of VNet routes: regular routes and tunnel routes. Regular routes just forward packets to the outgoing interfaces as usual. In contrast, tunnel routes first encapsulate packets with Vxlan headers and then forwards packets based on the remote VTEP's IP address. The above two types of VNet routes are handled by different tables on the App DB. + +We leverage the route's outgoing interfaces' name to differentiate VNet regular routes and VNet tunnel routes. If the first interface name starts with "Brvxlan", the route is a VNet tunnel route. Otherwise, it is a regular VNet route. Note that "Brvxlan" is the prefix of SONiC Vxlan interface name. For more details, please refer to the implantation of Vxlanmgr in SONiC swss. + +### 2.2.2 Handle VNet regular and tunnel routes +For VNet regular routes, their information is inserted/deleted into/from VNET_ROUTE_TABLE of App DB. + +For VNet tunnel routes, their information is inserted/deleted into/from VNET_ROUTE_TUNNEL_TABLE of App DB. # 3 Reference Tables +``` +VNET_ROUTE_TABLE:{{vnet_name}}:{{prefix}} + "nexthop": {{ip_address}} (OPTIONAL) + "ifname": {{intf_name}} + +VNET_ROUTE_TUNNEL_TABLE:{{vnet_name}}:{{prefix}} + "endpoint": {{ip_address}} + "mac_address":{{mac_address}} (OPTIONAL) + "vni": {{vni}}(OPTIONAL) +``` # 4 Examples - +Assume that we have a VNet regular route. The VNet name is "Vnet1". The destination IP prefix is "192.168.1.0/24". The next hop IP address is "172.16.0.1". The interface name is "Ethernet0". The App DB object of this route is given as follows: +``` +"VNET_ROUTE_TABLE:Vnet1:192.168.1.0/24" + "nexthop": "172.16.0.1" + "ifname": "Ethernet0" +``` + +Assume that we have a VNet tunnel route. The VNet name is "Vnet1". The destination IP prefix is "192.168.1.0/24". The next hop IP address is "172.16.0.1". The interface name is "Brvxlan8000". Given the special inteface name "Brvxlan8000", we know that this is a VNet tunnel route. The App DB object of this route is given as follows: +``` +"VNET_ROUTE_TUNNEL_TABLE:Vnet1:192.168.1.0/24" + "endpoint": "172.16.0.1" +```