Skip to content

Commit

Permalink
Finish the first version
Browse files Browse the repository at this point in the history
  • Loading branch information
baiwei0427 committed Apr 21, 2019
1 parent 321cef5 commit 8822286
Showing 1 changed file with 47 additions and 6 deletions.
53 changes: 47 additions & 6 deletions doc/vxlan/fpmsyncd_hld.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,15 +12,18 @@
* [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)

###### 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.
Expand All @@ -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 <code>rtnl_route_get_table</code> 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 <code>"Vnet"</code>, 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 <code>"Brvxlan"</code>, the route is a VNet tunnel route. Otherwise, it is a regular VNet route. Note that <code>"Brvxlan"</code> 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 <code>VNET_ROUTE_TABLE</code> of App DB.

For VNet tunnel routes, their information is inserted/deleted into/from <code>VNET_ROUTE_TUNNEL_TABLE</code> 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 <code>"Vnet1"</code>. The destination IP prefix is <code>"192.168.1.0/24"</code>. The next hop IP address is <code>"172.16.0.1"</code>. The interface name is <code>"Ethernet0"</code>. 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 <code>"Vnet1"</code>. The destination IP prefix is <code>"192.168.1.0/24"</code>. The next hop IP address is <code>"172.16.0.1"</code>. The interface name is <code>"Brvxlan8000"</code>. Given the special inteface name <code>"Brvxlan8000"</code>, 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"
```



0 comments on commit 8822286

Please sign in to comment.