一 GRE
1.1 概念
GRE全稱是Generic Routing Encapsulation，是一種協議封裝的格式，具體格式內容見：https://tools.ietf.org/html/rfc2784
協議封裝指的是用一種格式的協議封裝另一種格式的協議。如
1. TCP/IP協議可以看成是一種封裝：TCP傳輸層協議被網絡層的IP協議封裝，通過IP協議來進行傳輸。（這種封裝的目的主要是通過分層來嚴格的區分協議的設計，使得具體的協議設計的時候可以更加的清晰）
2. IP SAN，就是通過IP協議封裝scsi協議，使得我們可以直接通過IP網絡來進行磁盤數據的傳輸。（這種封裝主要是為了使用現有的設施，方便廠商推廣自己的產品，同時通過兩種協議的結合產生更多的功能。對於GRE來說，更趨向於這種封裝）
1.2 GRE封裝格式
GRE的目的是設計一種通用的封裝格式，所以如果將它與一些為特定目的進行設計的封裝協議比較，那么GRE是沒有太多優勢的。
A GRE encapsulated packet has the form:
---------------------------------
| |
| Delivery Header |
| |
---------------------------------
| |
| GRE Header |
| |
---------------------------------
| |
| Payload packet |
| |
---------------------------------
1. Delivery Header: 在GRE中，需要被傳輸和封裝的報文稱之為payload packet，而用於封裝和傳輸的協議則成為delivery protocol。
2. GRE header: GRE在封裝的時候，除了payload packet外，會生成一個GRE header。
3. payload packet: 我們真實要發送的數據包
GRE header + payload一起被delivery協議封裝用於傳輸，GRE header會包含payload的一些信息，包括checksum、version、payload的協議類型等。可以看到，通過這個GRE header的協議類型字段，我們可以做很多的事情。既然底層的delivery協議是用於傳輸的，那么A和B通信的時候delivery協議可以看成是個郵局送信火車，雖然很重要，但是對於業務理解來說沒有其運送的信重要。當脫取這一層delivery層后，我們怎么知道信的格式呢？通過GRE header中的協議類型我們就能知道協議類型了，既然知道了協議類型，那么就有能力解析了。
由於GRE是一種通用的格式，我們可以使用GRE進行很多不同種類的封裝。比如我們可以使用PPTP協議來進行VPN，可以使用IPv4來包裹IPv6。比較常見的delivery協議一般是IP協議。不過GRE在設計的時候有一個問題，那就是沒有考慮加密。因此現在常見的需要加密的封裝一般是用的IPsec協議。
例：A主機是在公司，B主機是在家，A網絡的地址為192.168.1.1，B網絡的地址為192.168.2.1，A如果要和B通信，則需要通過互聯網，所以在A連接的路由器RA上，會配置一個tunnel口，tunnel口的信息是（1.1.1.1 -> 2.2.2.2），在B連接的路由器RB上也會配置一個tunnel口，tunnel口的信息是（2.2.2.2 -> 1.1.1.1）。同時在設置好路由的情況下，A發送一個報文給B，報文會首先到RA，RA發現報文需要走互聯網，於是通過tunnel口封裝，封裝的delivery協議的目的地址寫的是配置的RB的地址2.2.2.2。報文到了RB后delivery協議被脫去，然后RB根據路由信息轉發給B。
（http://assafmuller.com/2013/10/10/gre-tunnels/）
當A（192.168.1.1） ping B（192.168.2.1）時，報文是如下形式的：
從A到RA
從RA到RB
1.2 Neutron中的GRE
（http://assafmuller.com/2013/10/14/gre-tunnels-in-openstack-neutron/）
- br-tun網橋信息：
[root@NextGen1 ~]# ovs-vsctl show
911ff1ca-590a-4efd-a066-568fbac8c6fb
[... Bridge br-int omitted ...]
Bridge br-tun
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port br-tun
Interface br-tun
type: internal
Port "gre-2"
Interface "gre-2"
type: gre
options: {in_key=flow, local_ip="192.168.1.100", out_key=flow, remote_ip="192.168.1.101"}
Port "gre-1"
Interface "gre-1"
type: gre
options: {in_key=flow, local_ip="192.168.1.100", out_key=flow, remote_ip="192.168.1.102"}
- VM1(10.0.0.1) pings VM2(10.0.0.2) in different nodes :
Before VM1 can create an ICMP echo request message, VM1 must send out an ARP request for VM2’s MAC address. A quick reminder about ARP encapsulation – It is encapsulated directly in an Ethernet frame – No IP involved (There exists a base assumption that states that ARP requests never leave a broadcast domain therefor IP packets are not needed). The Ethernet frame leaves VM1’s tap device into the host’s br-int. br-int, acting as a normal switch, sees that the destination MAC address in the Ethernet frame is FF:FF:FF:FF:FF:FF – The broadcast address. Because of that it floods it out all ports, including the patch cable linked to br-tun. br-tun receives the frame from the patch cable port and sees that the destination MAC address is the broadcast address. Because of that it will send the message out all GRE tunnels (Essentially flooding the message). But before that, it will encapsulate the message in a GRE header and an IP packet. In fact, two new packets are created: One from 192.168.1.100 to 192.168.1.101, and the other from 192.168.1.100 to 192.168.1.102. The encapsulation over the GRE tunnels looks like this:
To summarize, we can conclude that the flow logic on br-tun implements a learning switch but with a GRE twist. If the message is to a multicast, broadcast, or unknown unicast address it is forwarded out all GRE tunnels. Otherwise if it learned the destination MAC address via earlier messages (By observing the source MAC address, tunnel ID and incoming GRE port) then it forwards it to the correct GRE tunnel.
- br-tun流表：
[root@NextGen1 ~]# ovs-ofctl dump-flows br-tun NXST_FLOW reply (xid=0x4): cookie=0x0, duration=182369.287s, table=0, n_packets=5996, n_bytes=1481720, idle_age=52, hard_age=65534, priority=1,in_port=3 actions=resubmit(,2) cookie=0x0, duration=182374.574s, table=0, n_packets=14172, n_bytes=3908726, idle_age=5, hard_age=65534, priority=1,in_port=1 actions=resubmit(,1) cookie=0x0, duration=182370.094s, table=0, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=1,in_port=2 actions=resubmit(,2) cookie=0x0, duration=182374.078s, table=0, n_packets=3, n_bytes=230, idle_age=65534, hard_age=65534, priority=0 actions=drop cookie=0x0, duration=182373.435s, table=1, n_packets=3917, n_bytes=797884, idle_age=52, hard_age=65534, priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,20) cookie=0x0, duration=182372.888s, table=1, n_packets=10255, n_bytes=3110842, idle_age=5, hard_age=65534, priority=0,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,21) cookie=0x0, duration=182103.664s, table=2, n_packets=5982, n_bytes=1479916, idle_age=52, hard_age=65534, priority=1,tun_id=0x1388 actions=mod_vlan_vid:1,resubmit(,10) cookie=0x0, duration=182372.476s, table=2, n_packets=14, n_bytes=1804, idle_age=65534, hard_age=65534, priority=0 actions=drop cookie=0x0, duration=182372.099s, table=3, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=drop cookie=0x0, duration=182371.777s, table=10, n_packets=5982, n_bytes=1479916, idle_age=52, hard_age=65534, priority=1 actions=learn(table=20,hard_timeout=300,priority=1,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:NXM_OF_IN_PORT[]),output:1 cookie=0x0, duration=116255.067s, table=20, n_packets=3917, n_bytes=797884, hard_timeout=300, idle_age=52, hard_age=52, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:1f:19:55 actions=load:0->NXM_OF_VLAN_TCI[],load:0x1388->NXM_NX_TUN_ID[],output:3 cookie=0x0, duration=182371.623s, table=20, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=resubmit(,21) cookie=0x0, duration=182103.777s, table=21, n_packets=10235, n_bytes=3109310, idle_age=5, hard_age=65534, priority=1,dl_vlan=1 actions=strip_vlan,set_tunnel:0x1388,output:3,output:2 cookie=0x0, duration=182371.507s, table=21, n_packets=20, n_bytes=1532, idle_age=65534, hard_age=65534, priority=0 actions=drop
- table表流程
- 在openstack中主要是通過ovs，ovs支持GRE。通過GRE，VM之間的ARP、IP報文都能在GRE的封裝下通過IP網絡進行傳遞。不同的網絡通過GRE header中的tunnel id號區別。由於ovs支持openflow協議，為了效率和性能，mac和GRE的路由關系會存放在ovs的流表中。從鏈接中的文章可以看出，GRE有一個缺點，那就是每新增一個計算節點，都需要其和所有其他計算節點以及network控制器建立GRE鏈接。在計算節點很多的時候會有性能問題。
GRE 技術本身還是存在一些不足之處：
（1）Tunnel 的數量問題
GRE 是一種點對點（point to point）標准。Neutron 中，所有計算和網絡節點之間都會建立 GRE Tunnel。當節點不多的時候，這種組網方法沒什么問題。但是，當你在你的很大的數據中心中有 40000 個節點的時候，又會是怎樣一種情形呢？使用標准 GRE的話，將會有 780 millions 個 tunnels。
（2）擴大的廣播域
GRE 不支持組播，因此一個網絡（同一個 GRE Tunnel ID）中的一個虛機發出一個廣播幀后，GRE 會將其廣播到所有與該節點有隧道連接的節點。
（3）GRE 封裝的IP包的過濾和負載均衡問題
目前還是有很多的防火牆和三層網絡設備無法解析 GRE Header，因此它們無法對 GRE 封裝包做合適的過濾和負載均衡。
二 vxlan
2.1 概念
相比於GRE的通用性，VXLAN主要用於封裝、轉發2層報文。VXLAN全稱Virtual eXtensible Local Area Network，簡單的說就是擴充了的VLAN，其使得多個通過三層連接的網絡可以表現的和直接通過一台一台物理交換機連接配置而成的網絡一樣處在一個LAN中。其將二層報文加上個vxlan header，封裝在一個UDP包中進行傳輸。vxlan header會包括一個24位的ID（稱為VNI），含義類似於VLAN id或者上面提到的GRE的tunnel id。 在上面GRE的例子中，是通過路由器來進行GRE協議的封裝和解封的，在VXLAN中這類封裝和解封的組件有個專有的名字叫做VTEP。相比起VLAN來說，好處在於其突破了VLAN只有4094子網的限制，同時架設在UDP協議上后其擴展性提高了不少（因為UDP是高層協議，屏蔽了底層的差異，換句話說屏蔽了二層的差異）。
表面上看VXLAN和GRE區別不大，只是對delivery協議做了限定，使用UDP。但是實際上在協議的交互動作上面還是有區別的。和上面的例子一樣，假如主機A和主機B想通信，那么A的報文會的被VTEP封裝，然后發往連接B的VTEP。在上面的例子中類似於VTEP的角色是由路由器來充當的，而且路由器的兩端的地址是配置好的，所以RA知道RB的地址，直接將報文發給RB即可。但是在VXLAN中，A的VTEP並不知道B的VTEP在哪，所以需要一個發現的過程。如何發現呢？VXLAN要求每個VNI都關聯一個組播地址。所以對於一次ARP請求，A的VTEP會的發送一個組播IGMP報文給所有同在這個網絡組中的其他VTEP。所有的訂閱了這個組播地址的VTEP會的收到這個報文，學習發送端的A的MAC和VTEP地址用於以后使用，同時VTEP會將報文解析后比較VNI，發送給同VNI的主機。當某個主機B的IP和ARP中的一樣時，其會的發送ARP應答報文，應答報文通過B的VTEP按照類似的流程發送給A，但是由於B的VTEP已經學習到了A的MAC地址，因此B的VTEP直接就可以發送給A的VTEP，而不需要再走一遍通過IGMP的組播過程了。
從這個例子可以看出，VXLAN屏蔽了UDP的存在，上層基本上不感知這層封裝。同時VXLAN避免了GRE的點對點必須有連接的缺點。由於需要IGMP，對於物理交換機和路由器需要做一些配置，這點在GRE是不需要的。
vxlan報文格式：
（http://www.borgcube.com/blogs/2011/11/vxlan-primer-part-1/）
（http://www.borgcube.com/blogs/2012/03/vxlan-primer-part-2-lets-get-physical/）
含義：
- Outer MAC destination address (MAC address of the tunnel endpoint VTEP)
- Outer MAC source address (MAC address of the tunnel source VTEP)
- Outer IP destination address (IP address of the tunnel endpoint VTEP)
- Outer IP source address (IP address of the tunnel source VTEP)
- Outer UDP header：Src port 往往用於 load balancing，下文有提到；Dst port 即 VXLAN Port，默認值為 4789.
- VNID：表示該幀的來源虛機所在的 VXLAN 網段的 ID
特點：
- VNID： 24-bits，最大 16777216。每個不同的 24-bits VNI 代表一個 VXLAN 網段。只有同一個網段中的虛機才能互相通信。
- VXLAN Port：目的 UDP 端口，默認使用 4789 端口。用戶可以自己配置。
- 兩個 VTEP 之間的 VXLAN tunnels 是無狀態的。
- VTEP 可以在虛擬交換機上，物理交換機或者物理服務器上通過軟件或者硬件實現。
- 使用多播來傳送未知目的的、廣播或者多播幀。
- VTEP 不可以對 VXLAN 包分段。
2.2 VTEP 尋址
一個 VTEP 可以管理多個 VXLAN 隧道，每個隧道通向不同的目標。那 VTEP 接收到一個二層幀后，它怎么根據二層幀中的目的 MAC 地址找到對應的 VXLAN 隧道呢？VXLAN 利用了多播和 MAC 地址學習技術。如果它收到的幀是個廣播幀比如 ARP 幀，也會經過同樣的過程。
以下圖為例，每個 VTEP 包含兩個 VXLAN 隧道。VTEP-1 收到二層 ARP 幀1（A 要查找 B 的 MAC） 后，發出一個 Dst IP 地址為VTEP多播組 239.1.1.1 的 VXLAN 封裝 UDP 包。該包會達到 VTEP-2 和 VTEP-3。VTEP-3 收到后，因為目的 IP 地址不在它的范圍內，丟棄該包，但是學習到了一條路徑：MAC-A,VNI 10,VTEP-1-IP，它知道要到達 A 需要經過 VTEP-1 了。VTEP-2 收到后，發現目的 IP 地址是機器 B，交給 B，同時添加學習到的規則 MAC-A,VNI 10,VTEP-1-IP。B 發回響應幀后，VTEP-2 直接使用 VTEP-1 的 IP 直接將它封裝成三層包，通過物理網絡直接到達 VTEP-1，再由它交給 A。VTEP-1 也學習到了一條規則 MAC-B,VNI 10,VTEP-2-IP。
2.3 數據流向
發送端：
- 計算目的地址：Linux 內核在發送之前會檢查數據幀的目的MAC地址，需要選擇目的 VTEP。
- 如果是廣播或者多播地址，則使用其 VNI 對應的 VXLAN group 組播地址，該多播組內所有的 VTEP 將收到該多播包；
- 如果是單播地址，如果 Linux 的 MAC 表中包含該 MAC 地址對應的目的 VTEP 地址，則使用它；
- 如果是單播地址，但是 LInux 的 MAC 表中不包含該 MAC 地址對應的目的 VTEP IP，那么使用該 VNI 對應的組播地址。
- 添加Headers：依次添加 VXLAN header，UDP header，IP header。
接收端：
- UDP監聽：因為 VXLAN 利用了 UDP，所以它在接收的時候勢必須要有一個 UDP server 在監聽某個端口，這個是在 VXLAN 初始化的時候完成的。
- IP包剝離：一層一層剝離出原始的數據幀，交給 TCP/IP 棧，由它交給虛機。
2.2 Neutron中的vxlan
(http://www.opencloudblog.com/?p=300)
vxlan的br-tun流表與上面GRE類似。
三 GRE與VXLAN對比
| Feature | VXLAN | GRE |
|---|---|---|
| Segmentation | 24-bit VNI (VXLAN Network Identifier) | Uses different Tunnel IDs |
| Theoretical scale limit | 16 million unique IDs | 16 million unique IDs |
| Transport | UDP (default port 4789) | IP Protocol 47 |
| Filtering | VXLAN uses UDP with a well-known destination port; firewalls and switch/router ACLs can be tailored to block only VXLAN traffic. | Firewalls and layer 3 switches and routers with ACLs will typically not parse deeply enough into the GRE header to distinguish tunnel traffic types; all GRE would need to be blocked indiscriminately. |
| Protocol overhead | 50 bytes over IPv4 (8 bytes VXLAN header, 20 bytes IPv4 header, 8 bytes UDP header, 14 bytes Ethernet). | 42 bytes over IPv4 (8 bytes GRE header, 20 bytes IPv4 header, 14 bytes Ethernet). |
| Handling unknown destination packets, broadcasts, and multicast | VXLAN uses IP multicast to manage flooding from these traffic types. Ideally, one logical Layer 2 network (VNI) is associated with one multicast group address on the physical network. This requires end-to-end IP multicast support on the physical data center network. | GRE has no built-in protocol mechanism to address these. This type of traffic is simply replicated to all nodes. |
| IETF specification | http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-01 | http://tools.ietf.org/html/rfc2784.html |
對於GRE和VXLAN網絡模式而言，可以抽象地將每個br-tun看成隧道端點，有狀態的隧道點對點連接即為GRE；無狀態的隧道使用UDP協議連接則為VXLAN。
四 ：Neutron使用OVS支持GRE與VXLAN
因為 OVS 對兩種協議的實現機制，Neutron 對兩個協議的支持的代碼和配置幾乎是完全一致的，除了一些細小差別，比如名稱，以及個別配置比如VXLAN的UDP端口等。OVS 在計算或者網絡節點上的 br-tun 上建立多個 tunnel port，和別的節點上的 tunnel port 之間建立點對點的 GRE/VXLAN Tunnel。Neutron GRE/VXLAN network 使用 segmentation_id （VNI 或者 GRE tunnel id） 作為其網絡標識，類似於 VLAN ID，來實現不同網絡內網絡流量之間的隔離。
4.1 open vswitch實現的VXLAN VTEP
從上面的基礎知識部分，我們知道 VTEP 不只是實現包的封裝和解包，還包括：
（1）ARP 解析：需要盡量高效的方式響應本地虛機的 ARP 請求
（2）目的 VTEP 地址搜索：根據目的虛機的 MAC 地址，找到它所在機器的 VTEP 的 IP 地址
通常的實現方式包括：
（1）使用 L3 多播
（2）使用 SDN 控制器（controller）來提供集中式的 MAC/IP 對照表
（一個基於 Linuxbrige + VxLAN + Service Node 的集中式 Controller node 解決 VNI-VTEP_IPs 映射的提議，替代L3多播和廣播，來源： 20140520-dlapsley-openstack-summit-vancouver-vxlan-v0-150520174345-lva1-app6891.pptx）
（3）在VTEP本地運行一個代理（agent），接收（MAC, IP, VTEP IP）數據，並提供給 VTEP
那 Open vSwitch 是如何實現這些功能需求的呢？
（1）在沒有啟用 l2population 的情況下，配置了多播就使用多播，沒的話就使用廣播
（2）在啟用 l2population 的情況下，在虛機 boot 以后，通過 MQ 向用於同網絡虛機的節點上的 l2population driver 發送兩種數據，再將數據加入到 OVS 流表
（2.1）FDB (forwarding database): 目的地址-所在 VTEP IP 地址的對照表，用於查找目的虛機所在的 VTEP 的 IP 地址
（2.2）虛機 IP 地址 - MAC 地址的對照表，用於響應本地虛機的 ARP 請求
4.2 在不使用l2population時的隧道建立過程
https://wiki.openstack.org/wiki/L2population_blueprint
要使用 GRE 和 VXLAN，管理員需要在 ml2 配置文件中配置 local_ip（比如該物理服務器的公網 IP），並使用配置項 tunnel_types 指定要使用的隧道類型，即 GRE 或者 VXLAN。當 enable_tunneling = true 時，Neutorn ML2 Agent 在啟動時會建立 tunnel bridge，默認為 br-tun。接着，ML2 Agent 會在 br-tun 上建立 tunnel ports，作為 GRE/VXLAN tunnel 的一端。具體過程如圖所示：
OVS 默認使用 4789 作為 VXLAN port。下表中可以看出 Neutron 節點在該端口上監聽來自所有源的UDP包：
root@compute1:/home/s1# netstat -lnup Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name udp 3840 0 0.0.0.0:4789 0.0.0.0:*
l2pop 的原理也不復雜。Neutron 中保存每一個端口的狀態，而端口保存了網絡相關的數據。虛機啟動過程中，其端口狀態會從 down 到build 到 active。因此，在每次端口發生狀態變化時，函數 update_port_postcommit 都將會被調用，保證每個節點上的如下數據得到了實時更新，從而避免了不必要的隧道連接和廣播。
有和沒有 l2pop 的效果：
4.3 MTU 問題
VXLAN 模式下虛擬機中的 mtu 最大值為1450，也就是只能小於1450，大於這個值會導致 openvswitch 傳輸分片，進而導致虛擬機中數據包數據重傳，從而導致網絡性能下降。GRE 模式下虛擬機 mtu 最大為1462。
計算方法如下：
- vxlan mtu = 1450 = 1500 – 20(ip頭) – 8(udp頭) – 8(vxlan頭) – 14(以太網頭)
- gre mtu = 1458 = 1500 – 20(ip頭) – 8(gre頭) – 14(以太網頭)
可以配置 Neutron DHCP 組件，讓虛擬機自動配置 mtu，官方文檔鏈接 http://docs.openstack.org/juno/install-guide/install/yum/content/neutron-network-node.html
#/etc/neutron/dhcp_agent.ini [DEFAULT] dnsmasq_config_file = /etc/neutron/dnsmasq-neutron.conf #/etc/neutron/dnsmasq-neutron.conf dhcp-option-force=26,1450或1458 #26代表要設置的是mtu值
Tag Name Data Length Meaning Reference 0 Pad 0 None [RFC2132] 1 Subnet Mask 4 Subnet Mask Value [RFC2132] 2 Time Offset 4 Time Offset in Seconds from UTC (note: deprecated by 100 and 101) [RFC2132] 3 Router N N/4 Router addresses [RFC2132] 4 Time Server N N/4 Timeserver addresses [RFC2132] 5 Name Server N N/4 IEN-116 Server addresses [RFC2132] 6 Domain Server N N/4 DNS Server addresses [RFC2132] 7 Log Server N N/4 Logging Server addresses [RFC2132] 8 Quotes Server N N/4 Quotes Server addresses [RFC2132] 9 LPR Server N N/4 Printer Server addresses [RFC2132] 10 Impress Server N N/4 Impress Server addresses [RFC2132] 11 RLP Server N N/4 RLP Server addresses [RFC2132] 12 Hostname N Hostname string [RFC2132] 13 Boot File Size 2 Size of boot file in 512 byte chunks [RFC2132] 14 Merit Dump File N Client to dump and name the file to dump it to [RFC2132] 15 Domain Name N The DNS domain name of the client [RFC2132] 16 Swap Server N Swap Server address [RFC2132] 17 Root Path N Path name for root disk [RFC2132] 18 Extension File N Path name for more BOOTP info [RFC2132] 19 Forward On/Off 1 Enable/Disable IP Forwarding [RFC2132] 20 SrcRte On/Off 1 Enable/Disable Source Routing [RFC2132] 21 Policy Filter N Routing Policy Filters [RFC2132] 22 Max DG Assembly 2 Max Datagram Reassembly Size [RFC2132] 23 Default IP TTL 1 Default IP Time to Live [RFC2132] 24 MTU Timeout 4 Path MTU Aging Timeout [RFC2132] 25 MTU Plateau N Path MTU Plateau Table [RFC2132] 26 MTU Interface 2 Interface MTU Size [RFC2132] 27 MTU Subnet 1 All Subnets are Local [RFC2132] 28 Broadcast Address 4 Broadcast Address [RFC2132] 29 Mask Discovery 1 Perform Mask Discovery [RFC2132] 30 Mask Supplier 1 Provide Mask to Others [RFC2132] 31 Router Discovery 1 Perform Router Discovery [RFC2132] 32 Router Request 4 Router Solicitation Address [RFC2132] 33 Static Route N Static Routing Table [RFC2132] 34 Trailers 1 Trailer Encapsulation [RFC2132] 35 ARP Timeout 4 ARP Cache Timeout [RFC2132] 36 Ethernet 1 Ethernet Encapsulation [RFC2132] 37 Default TCP TTL 1 Default TCP Time to Live [RFC2132] 38 Keepalive Time 4 TCP Keepalive Interval [RFC2132] 39 Keepalive Data 1 TCP Keepalive Garbage [RFC2132] 40 NIS Domain N NIS Domain Name [RFC2132] 41 NIS Servers N NIS Server Addresses [RFC2132] 42 NTP Servers N NTP Server Addresses [RFC2132] 43 Vendor Specific N Vendor Specific Information [RFC2132] 44 NETBIOS Name Srv N NETBIOS Name Servers [RFC2132] 45 NETBIOS Dist Srv N NETBIOS Datagram Distribution [RFC2132] 46 NETBIOS Node Type 1 NETBIOS Node Type [RFC2132] 47 NETBIOS Scope N NETBIOS Scope [RFC2132] 48 X Window Font N X Window Font Server [RFC2132] 49 X Window Manager N X Window Display Manager [RFC2132] 50 Address Request 4 Requested IP Address [RFC2132] 51 Address Time 4 IP Address Lease Time [RFC2132] 52 Overload 1 Overload "sname" or "file" [RFC2132] 53 DHCP Msg Type 1 DHCP Message Type [RFC2132] 54 DHCP Server Id 4 DHCP Server Identification [RFC2132] 55 Parameter List N Parameter Request List [RFC2132] 56 DHCP Message N DHCP Error Message [RFC2132] 57 DHCP Max Msg Size 2 DHCP Maximum Message Size [RFC2132] 58 Renewal Time 4 DHCP Renewal (T1) Time [RFC2132] 59 Rebinding Time 4 DHCP Rebinding (T2) Time [RFC2132] 60 Class Id N Class Identifier [RFC2132] 61 Client Id N Client Identifier [RFC2132] 62 NetWare/IP Domain N NetWare/IP Domain Name [RFC2242] 63 NetWare/IP Option N NetWare/IP sub Options [RFC2242] 64 NIS-Domain-Name N NIS+ v3 Client Domain Name [RFC2132] 65 NIS-Server-Addr N NIS+ v3 Server Addresses [RFC2132] 66 Server-Name N TFTP Server Name [RFC2132] 67 Bootfile-Name N Boot File Name [RFC2132] 68 Home-Agent-Addrs N Home Agent Addresses [RFC2132] 69 SMTP-Server N Simple Mail Server Addresses [RFC2132] 70 POP3-Server N Post Office Server Addresses [RFC2132] 71 NNTP-Server N Network News Server Addresses [RFC2132] 72 WWW-Server N WWW Server Addresses [RFC2132] 73 Finger-Server N Finger Server Addresses [RFC2132] 74 IRC-Server N Chat Server Addresses [RFC2132] 75 StreetTalk-Server N StreetTalk Server Addresses [RFC2132] 76 STDA-Server N ST Directory Assist. Addresses [RFC2132] 77 User-Class N User Class Information [RFC3004] 78 Directory Agent N directory agent information [RFC2610] 79 Service Scope N service location agent scope [RFC2610] 80 Rapid Commit 0 Rapid Commit [RFC4039] 81 Client FQDN N Fully Qualified Domain Name [RFC4702] 82 Relay Agent Information N Relay Agent Information [RFC3046] 83 iSNS N Internet Storage Name Service [RFC4174] 84 REMOVED/Unassigned [RFC3679] 85 NDS Servers N Novell Directory Services [RFC2241] 86 NDS Tree Name N Novell Directory Services [RFC2241] 87 NDS Context N Novell Directory Services [RFC2241] 88 BCMCS Controller Domain Name list [RFC4280] 89 BCMCS Controller IPv4 address option [RFC4280] 90 Authentication N Authentication [RFC3118] 91 client-last-transaction-time option [RFC4388] 92 associated-ip option [RFC4388] 93 Client System N Client System Architecture [RFC4578] 94 Client NDI N Client Network Device Interface [RFC4578] 95 LDAP N Lightweight Directory Access Protocol [RFC3679] 96 REMOVED/Unassigned [RFC3679] 97 UUID/GUID N UUID/GUID-based Client Identifier [RFC4578] 98 User-Auth N Open Group's User Authentication [RFC2485] 99 GEOCONF_CIVIC [RFC4776] 100 PCode N IEEE 1003.1 TZ String [RFC4833] 101 TCode N Reference to the TZ Database [RFC4833] 102-107 REMOVED/Unassigned [RFC3679] 108 REMOVED/Unassigned [RFC3679] 109 Unassigned [RFC3679] 110 REMOVED/Unassigned [RFC3679] 111 Unassigned [RFC3679] 112 Netinfo Address N NetInfo Parent Server Address [RFC3679] 113 Netinfo Tag N NetInfo Parent Server Tag [RFC3679] 114 URL N URL [RFC3679] 115 REMOVED/Unassigned [RFC3679] 116 Auto-Config N DHCP Auto-Configuration [RFC2563] 117 Name Service Search N Name Service Search [RFC2937] 118 Subnet Selection Option 4 Subnet Selection Option [RFC3011] 119 Domain Search N DNS domain search list [RFC3397] 120 SIP Servers DHCP Option N SIP Servers DHCP Option [RFC3361] 121 Classless Static Route Option N Classless Static Route Option [RFC3442] 122 CCC N CableLabs Client Configuration [RFC3495] 123 GeoConf Option 16 GeoConf Option [RFC6225] 124 V-I Vendor Class Vendor-Identifying Vendor Class [RFC3925] 125 V-I Vendor-Specific Information Vendor-Identifying Vendor-Specific Information [RFC3925] 126 Removed/Unassigned [RFC3679] 127 Removed/Unassigned [RFC3679] 128 PXE - undefined (vendor specific) [RFC4578] 128 Etherboot signature. 6 bytes: E4:45:74:68:00:00 128 DOCSIS "full security" server IP address 128 TFTP Server IP address (for IP Phone software load) 129 PXE - undefined (vendor specific) [RFC4578] 129 Kernel options. Variable length string 129 Call Server IP address 130 PXE - undefined (vendor specific) [RFC4578] 130 Ethernet interface. Variable length string. 130 Discrimination string (to identify vendor) 131 PXE - undefined (vendor specific) [RFC4578] 131 Remote statistics server IP address 132 PXE - undefined (vendor specific) [RFC4578] 132 IEEE 802.1Q VLAN ID 133 PXE - undefined (vendor specific) [RFC4578] 133 IEEE 802.1D/p Layer 2 Priority 134 PXE - undefined (vendor specific) [RFC4578] 134 Diffserv Code Point (DSCP) for VoIP signalling and media streams 135 PXE - undefined (vendor specific) [RFC4578] 135 HTTP Proxy for phone-specific applications 136 OPTION_PANA_AGENT [RFC5192] 137 OPTION_V4_LOST [RFC5223] 138 OPTION_CAPWAP_AC_V4 N CAPWAP Access Controller addresses [RFC5417] 139 OPTION-IPv4_Address-MoS N a series of suboptions [RFC5678] 140 OPTION-IPv4_FQDN-MoS N a series of suboptions [RFC5678] 141 SIP UA Configuration Service Domains N List of domain names to search for SIP User Agent Configuration [RFC6011] 142 OPTION-IPv4_Address-ANDSF N ANDSF IPv4 Address Option for DHCPv4 [RFC6153] 143 OPTION-IPv6_Address-ANDSF N ANDSF IPv6 Address Option for DHCPv6 [RFC6153] 144 GeoLoc 16 Geospatial Location with Uncertainty [RFC6225] 145 FORCERENEW_NONCE_CAPABLE 1 Forcerenew Nonce Capable [RFC-ietf-dhc-forcerenew-nonce-07] 146-149 Unassigned [RFC3942] 150 TFTP server address [RFC5859] 150 Etherboot 150 GRUB configuration path name 151-174 Unassigned [RFC3942] 175 Etherboot (Tentatively Assigned - 2005-06-23) 176 IP Telephone (Tentatively Assigned - 2005-06-23) 177 Etherboot (Tentatively Assigned - 2005-06-23) 177 PacketCable and CableHome (replaced by 122) 178-207 Unassigned [RFC3942] 208 PXELINUX Magic 4 magic string = F1:00:74:7E [RFC5071][Deprecated] 209 Configuration File N Configuration file [RFC5071] 210 Path Prefix N Path Prefix Option [RFC5071] 211 Reboot Time 4 Reboot Time [RFC5071] 212 OPTION_6RD 18 + N OPTION_6RD with N/4 6rd BR addresses [RFC5969] 213 OPTION_V4_ACCESS_DOMAIN N Access Network Domain Name [RFC5986] 214-219 Unassigned 220 Subnet Allocation Option N Subnet Allocation Option [draft-ietf-dhc-subnet-alloc-13] 221 Virtual Subnet Selection (VSS) Option [RFC6607] 222-223 Unassigned [RFC3942] 224-254 Reserved (Private Use) 255 End 0 None [RFC2132]
重啟 DHCP Agent，讓虛擬機重新獲取 IP，然后使用 ifconfig 查看是否正確配置 mtu。
五 總結
- vxlan網絡指定的segment id 就是vxlan的tunnel id，local vlan號則由neutron代碼按序生成，tunnel id 與 local vlan 由br-tun流表來保證一一對應。
而由於br-tun的port與trunk0的tunnel-bearing子接口相連，tunnel-bearing子接口也帶vlan id，該vlan id放在Delivery Header的vlan id中，是為了與管理網絡隔離。
- local vlan 與 外部 vlan 區別
兩個VM所屬segment id 一樣，位於不同server上時，local vlan id 不一定一樣。local vlan只是作用於當前server上，用於隔離該server上的其他VM。
- br-tun中有關GRE/Vxlan的port是如何生成的？
ovs-agent啟動時，會上報自己的tunnel local ip 給neutron server ，然后neutron server 會發rpc消息給其他所有 ovs-agent ，在br-tun上建立相關聯的port。