一：什么是流表

流表類(lei)似于交換機的MAC地址表，路(lu)(lu)由器(qi)的路(lu)(lu)由表，是 OpenvSwitch 指揮流量轉(zhuan)發(fa)的表。

Openflow是有多個版本的 ovs-ofctl僅啟用(yong)OpenFlow 1.0.，當(dang)使用(yong)其(qi)他(ta)版本OpenFlow時(shi)

需要使用ovs-ofctl -O來指定詳細的(de)版本，在一體機項目中。我們使用的(de)openflow13 版本，因此(ci)查看(kan)流表的(de)命令為

ovs-ofctl -Oopenflow13 dump-flows br-int table=0

 cookie=0x0, duration=1541435.636s, table=0, n_packets=4337289, n_bytes=660210111, priority=100 actions=goto_table:10

二：常見的流表字段分類

從(cong)上面的輸出(chu)結(jie)果能看出(chu)一個常(chang)見(jian)的流表(biao)可(ke)以分為三類、統(tong)計類、標識類、行為類。

統計類：duration 表(biao)示該規則(ze)(ze)自創建以來已經生存(cun)的時間(jian)（單位為秒）。n_packets 和 n_bytes 分別表(biao)示匹(pi)配該規則(ze)(ze)的數據包數和總字節數。

標識(shi)類(lei)(lei)：cookie 用來標識(shi)一類(lei)(lei)規則，table 標識(shi)表的(de)編號。默認規則都是從table=0開始按priority 優先級逐條匹配的(de)，數字越大優先級越高(gao)。

行為類(lei)：actions對于(yu)匹配到的包，如何(he)進行處理。實際(ji)生產的流表中，我們可以看到有多個表項的動作(zuo)為goto_table和set_field。其(qi)中，

goto_table用于跳轉到指定的表中繼續匹配和執行，set_field用于設置指定字(zi)段的值

三： 詳細字段說明

3.1 虛擬機如何獲取IP地址。

 cookie=0x0, duration=1542867.268s, table=0, n_packets=4339798, n_bytes=660327009, priority=100 actions=goto_table:10

 cookie=0x0, duration=1542867.196s, table=10, n_packets=0, n_bytes=0, priority=300,udp6,tp_dst=547 actions=CONTROLLER:65535

 cookie=0x0, duration=1542867.172s, table=10, n_packets=137, n_bytes=47185, priority=300,udp,tp_dst=67 actions=CONTROLLER:65535

一(yi)個常見的流表項和(he)安全組和(he)防火墻類似，都是匹配(pei)到指(zhi)定規則的包，按指(zhi)定的行為（action）去處理.

上面第一(yi)條沒有任(ren)何匹配條件，標識所有的(de)包(bao)都匹配，go_to_table 表示繼(ji)續(xu)交給table=10的(de)表去處理(li)。（在實際(ji)應(ying)用中我(wo)們可以使(shi)用該命(ming)令來查(cha)看(kan)

指定table的(de)條(tiao)目，而不是(shi)一次將所有的(de)流表都輸出。）

ovs-ofctl -Oopenflow13 dump-flows br-int table=0  #此時就只看table=0的(de)表

上面條是(shi)table=10的表項有兩(liang)條，因為優先級都是(shi)300，則默認至上而下的匹配(pei)執行(xing)。具體含義表示匹配(pei)UDPv6協議的數據包，

目(mu)的(de)端(duan)口為547（DHCPv6協議的(de)默認端(duan)口），如果匹(pi)配(pei)成功(gong)，將數據包發送到控(kong)制器進行處理（controller：65535）。而第三條的(de)含義是

目標端(duan)口是udp 67的端(duan)口包(bao)，交給控(kong)制器來處(chu)理。dhcp服務默認端(duan)口就是udp 67.因此從(cong)該(gai)規則(ze)我們(men)看出，dhcp的請求包(bao)將發送給控(kong)制器去(qu)處(chu)理，

事實(shi)上也(ye)確實(shi)如此，下(xia)面我(wo)們來(lai)抓包來(lai)分析。

在(zai)物理機(ji)上(shang)抓目標端口為6633端口數據包（6633端口為控制(zhi)器監聽地址(zhi)），OFPT_PACKET_IN 為openflow向上(shang)發給控制(zhi)器的(de)請(qing)求報文。

詳細的報文格式如下

打(da)開Openflow 協議的(de)(de)Data 字段可以看(kan)(kan)到(dao)發(fa)送dhcp 請求的(de)(de)mac ，目標mac為廣播報文。下面(mian)我們查看(kan)(kan)虛擬機接口的(de)(de)mac

發現該mac 確實是虛擬機的(de)接口的(de)mac ,因此(ci)確定這個(ge)dhcp的(de)請求包為虛擬機發送(song)出來的(de)，其通過(guo)openflow協議發送(song)給(gei)了控制器。

下面是控制器回復(fu)的(de)響(xiang)應(ying)(ying)報(bao)文(wen) ，包括了dhcp 的(de)響(xiang)應(ying)(ying)包，該報(bao)文(wen)是發(fa)送給虛(xu)擬機(ji)(ji)(ji)所在的(de)物(wu)(wu)理(li)機(ji)(ji)(ji)節點(dian)上，到達物(wu)(wu)理(li)機(ji)(ji)(ji)后，由(you)物(wu)(wu)理(li)機(ji)(ji)(ji)轉發(fa)給對應(ying)(ying)的(de)虛(xu)擬機(ji)(ji)(ji)。

總結(jie)：從上述(shu)例子中(zhong)我們知道在(zai)一體機項目中(zhong)通過20號流(liu)表(biao)來把虛擬(ni)機的(de)dhcp的(de)請(qing)求包發送給了控(kong)制(zhi)(zhi)器，如果流(liu)表(biao)不正常、控(kong)制(zhi)(zhi)器不正常、控(kong)制(zhi)(zhi)器6633端口被防火墻規則所限制(zhi)(zhi)等都會造成虛擬(ni)機拿(na)不到IP地址(zhi)。

3.2 同網段的虛擬機相互之間通信

原(yuan)理：相同網絡的虛(xu)擬機(ji)要(yao)想通(tong)信需(xu)要(yao)通(tong)過arp 報文獲取對方的mac地址，接下來我們繼續分析流(liu)表，看虛(xu)擬機(ji)是如(ru)何發送arp請(qing)求和(he)響應(ying)的。

cookie=0x0, duration=8729580.116s, table=20, n_packets=25135358, n_bytes=4688159427, priority=200,ip,in_port="tap4432d19a-eb"

actions=load:0x7->NXM_NX_REG5[],load:0x7->NXM_NX_REG6[],set_field:0x23->tun_id,goto_table:21

cookie=0x0, duration=8729580.115s, table=20, n_packets=249587, n_bytes=10482654, priority=200,arp,in_port="tap4432d19a-eb" actions=load:0x7->NXM_NX_REG5[],load:0x7->NXM_NX_REG6[],set_field:0x23->tun_id,goto_table:21

cookie=0x0, duration=7607595.333s, table=20, n_packets=6775179, n_bytes=804658123, priority=200,ip,in_port="tap41e48bdc-5b" actions=load:0x8->NXM_NX_REG5[],load:0x11->NXM_NX_REG6[],set_field:0x47->tun_id,goto_table:21

cookie=0x0, duration=7607595.332s, table=20, n_packets=206073, n_bytes=8655066, priority=200,arp,in_port="tap41e48bdc-5b" actions=load:0x8->NXM_NX_REG5[],load:0x11->NXM_NX_REG6[],set_field:0x47->tun_id,goto_table:21

Ip,in_port=tap4432d19a-eb 表示(shi)其協議是(shi)IP協議，流量是(shi)從tap4432d19a-eb 發出來的(de)，將執行的(de)操作(zuo) load:0x7->MXM_NX_REG5[]，load:0x->MXM_NX_REG6

Set_field: 0x23->tun_id 。

上(shang)述的(de)操作看上(shang)去(qu)復(fu)雜，其實就做(zuo)了一件事(shi)打標(biao)(biao)(biao)記(ji)(ji)(ji)(ji)，只不過其標(biao)(biao)(biao)記(ji)(ji)(ji)(ji)是存放在對應的(de)寄存器中，reg5的(de)標(biao)(biao)(biao)記(ji)(ji)(ji)(ji)表(biao)示虛擬機port的(de)來源(yuan)的(de)標(biao)(biao)(biao)記(ji)(ji)(ji)(ji)，reg6標(biao)(biao)(biao)記(ji)(ji)(ji)(ji)則表(biao)示同一個subnet的(de)標(biao)(biao)(biao)記(ji)(ji)(ji)(ji)，而(er)tun_id 從字面意思(si)上(shang)可以看出是隧(sui)道標(biao)(biao)(biao)記(ji)(ji)(ji)(ji)。

因(yin)為上(shang)述環境為vxlan 網絡，因(yin)此每個不同(tong)的vpc 對應一(yi)個不同(tong)的tun_id,通過不同(tong)tun_id 來隔離不同(tong)vpc的租(zu)戶流量。

同(tong)(tong)樣的第二條(tiao)也(ye)是打標(biao)記(ji)，只不過其標(biao)識(shi)的協議(yi)是來自arp協議(yi)的數據包。分別(bie)對比1 2條(tiao)數據和(he)3 4 條(tiao)數據可以(yi)確定tap4432d19a-eb 和(he)tap41e48bdc-5b的兩個port 分別(bie)輸入兩個完(wan)全不同(tong)(tong)的subnet 。因(yin)為reg6 標(biao)記(ji)不一樣，待會我們會驗證這一點。

 cookie=0x0, duration=8825531.760s, table=21, n_packets=92159712, n_bytes=12528380058, priority=100 actions=goto_table:22

 cookie=0x0, duration=8825531.760s, table=22, n_packets=92159712, n_bytes=12528380058, priority=100 actions=goto_table:30

上述這兩條規則只是做(zuo)跳(tiao)轉，將(jiang)流量(liang)引入(ru)了30號流表(biao)。

 cookie=0x0, duration=8729580.113s, table=30, n_packets=20, n_bytes=840, priority=300,arp,reg6=0x7,arp_tpa=10.100.255.5,arp_op=1 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:fa:16:3e:31:cc:e5->eth_src,set_field:2->arp_op,move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],set_field:fa:16:3e:31:cc:e5->arp_sha,move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],set_field:10.100.255.5->arp_spa,IN_PORT

上述流表要(yao)想看明白需要(yao)對(dui)arp 的報文有(you)一(yi)定的了解(jie)，因此(ci)我(wo)們(men)說下arp報文的格(ge)式

我們先(xian)看華為官網的(de)(de)例子中arp報文的(de)(de)部分(fen)格式(shi)如下

從上面看出一個arp 報文(wen)有發(fa)送mac地址 發(fa)送者IP地址 和(he)目標mac地址和(he)目標IP地址。 Opcode: 1 表(biao)示(shi)是arp 請求的報文(wen)， 2 則(ze)表(biao)示(shi)是arp 的響應的報文(wen)。

了解上述信息后我們(men)在看報文(wen)就豁然(ran)開朗了，arp_tpa=10.100.255.5,arp_op=1，表示如果是(shi)arp請求(qiu)的目標IP是(shi)10.100.255.5，則(ze)

move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[] set_field:fa:16:3e:31:cc:e5->eth_src  ，將源mac修改為目標(biao)mac ，而(er)將指定的fa:16:3e:31:cc:e5 ，寫進源mac, 而(er)set_field:2->arp_op，表(biao)示(shi)將arp 的請求包改為arp 的應答包。

上述是修(xiu)改了2層(ceng)以太網的(de)(de)封裝(zhuang)包(bao)，而下面則(ze)是將arp的(de)(de)封裝(zhuang)包(bao)也進(jin)行了修(xiu)改，ARP_SHA 表示 Ethernet Address of Sender，發送(song)方的(de)(de)以太網地(di)址，

ARP_THA 表示(shi) Ethernet Address of Destination 接受方的以太網地址(zhi)，ARP_SPA 表示(shi) 發送(song)方的IP地址(zhi) ARP_TPA 則(ze)表示(shi)接受方的IP 地址(zhi)。

move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],set_field:fa:16:3e:31:cc:e5->arp_sha,move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],set_field:10.100.255.5->arp_spa,IN_PORT

上述的(de)報(bao)文(wen)就(jiu)是將ARP的(de)發送(song)方(fang)的(de)以(yi)太網地址(zhi)和IP地址(zhi)，都修改為了(le)接(jie)收方(fang)的(de)以(yi)太網地址(zhi)和IP地址(zhi)。而將發送(song)方(fang)的(de)IP修改為 10.100.255.5

發送方的mac 修(xiu)改為fa:16:3e:31:cc:e5 。下(xia)面我(wo)們來查詢該mac對(dui)應(ying)的接口，則發現(xian)就是之前的tap4432d19a-eb 。

virsh domiflist 51

 Interface        Type     Source   Model    ;MAC

----------------------------------------------------------------

 tap4432d19a-eb   bridge   br-int   virtio   fa:16:3e:31:cc:e5

同時(shi)(shi)將(jiang)(jiang)2層(ceng)以太網封(feng)裝的(de)mac 和2層(ceng)arp報文(wen)的(de)封(feng)裝修改(gai)(gai)后，將(jiang)(jiang)目標改(gai)(gai)成源，其整體上就(jiu)做(zuo)了(le)一件事，arp 地(di)址代(dai)答，也就(jiu)是說 如果arp 請求查詢10.100.255.5的(de)IP對(dui)應(ying)(ying)的(de)mac 時(shi)(shi)，將(jiang)(jiang)tap4432d19a-eb對(dui)應(ying)(ying)接口mac 來作(zuo)為arp的(de)響應(ying)(ying)的(de)報文(wen)發(fa)送出去。此(ci)時(shi)(shi)也驗(yan)證(zheng)了(le)該mac地(di)址對(dui)應(ying)(ying)的(de)IP是10.100.255.5.

cookie=0x0, duration=8729580.113s, table=30, n_packets=6292, n_bytes=264264,

priority=200,arp,tun_id=0x23,in_port=vxlan1,arp_tpa=10.100.255.5 actions=output:"tap4432d19a-eb"

此流(liu)表表示如(ru)果(guo)tun_id是(shi) 0x23 流(liu)量(liang)是(shi)從vxlan1 進入來的(de)(de)(de)(de) 且arp 的(de)(de)(de)(de)接(jie)收的(de)(de)(de)(de)方(fang)IP是(shi)10.100.255.5 從 tap4432d19a-eb 發送出去。經過(guo)上述(shu)幾(ji)天(tian)流(liu)表，無論是(shi)相(xiang)同網段(duan)（相(xiang)同tun_id ）的(de)(de)(de)(de)虛擬機都可以通(tong)(tong)過(guo)arp的(de)(de)(de)(de)報文(wen)來拿到(dao)通(tong)(tong)信(xin)雙方(fang)的(de)(de)(de)(de)mac 地(di)址了。

解決了mac地(di)址(zhi)的問題，則同subnet的虛(xu)擬機(ji)既可以完(wan)成2層(ceng)封(feng)裝，如果(guo)想要進行(xing)IP通信(xin)，還(huan)需要將IP流量引入指定虛(xu)擬機(ji)的tap口(kou)，接下(xia)來我們具(ju)體分析(xi)。

cookie=0x0, duration=8729580.112s, table=40, n_packets=23418345, n_bytes=3836008358, priority=200,ip,in_port=vxlan1,dl_dst=fa:16:3e:31:cc:e5 actions=load:0x7->NXM_NX_REG5[],load:0x7->NXM_NX_REG6[],goto_table:81

根據前面的理解，這條報文的意(yi)思是(shi) 如果(guo)是(shi)IP協議，從vxlan1 進來的 目(mu)標mac地址是(shi) fa:16:3e:31:cc:e5也就是(shi)10.100.255.5 其tap口(kou)為 tap4432d19a-eb的流量包，跳轉到81號流表。

cookie=0x0, duration=8728669.421s, table=81, n_packets=158, n_bytes=13828, priority=200,icmp,reg5=0x7 actions=ct(commit,table=83)

cookie=0x0, duration=8728268.791s, table=81, n_packets=3567, n_bytes=499779, priority=200,tcp,reg5=0x7,tp_dst=3389 actions=ct(commit,table=83)

cookie=0x0, duration=7976525.032s, table=81, n_packets=55623, n_bytes=5723897, priority=200,tcp,reg5=0x7,tp_dst=9098 actions=ct(commit,table=83)

上(shang)述(shu)三條(tiao)的(de)意思是(shi)如(ru)果其reg5=0x7 ，上(shang)述(shu)曾說明過其就代(dai)表的(de)tap4432d19a-eb 的(de)tap口(kou)，并且協(xie)(xie)議是(shi)icmp 或(huo) tcp協(xie)(xie)議目標端(duan)口(kou)是(shi)3389 或(huo)目標端(duan)口(kou)是(shi)9098的(de)流量，其追蹤后重新(xin)提交到(dao)83號流表。

 cookie=0x0, duration=8825531.759s, table=83, n_packets=38664553, n_bytes=5163764381, priority=100 actions=goto_table:84

 cookie=0x0, duration=8825531.758s, table=84, n_packets=38664553, n_bytes=5163764381, priority=100 actions=goto_table:85

 cookie=0x0, duration=8729580.111s, table=85, n_packets=23415882, n_bytes=3835853296, priority=200,reg5=0x7 actions=output:"tap4432d19a-eb"

標記為0x7的(de)tap4432d19a-eb ，經過84 85好流(liu)(liu)表都發(fa)送到(dao)了(le)tap4432d19a-eb的(de)接口，這樣(yang)就完(wan)成(cheng)了(le)與tap4432d19a-eb的(de)流(liu)(liu)量的(de)引導。

總結：從arp地址應(ying)到、到流(liu)(liu)量引(yin)導，可以(yi)看到整個(ge)流(liu)(liu)量的過(guo)程都是在(zai)流(liu)(liu)表中(zhong)進行的，而流(liu)(liu)表的下發和更(geng)新(xin)都是由控制(zhi)器來(lai)動態更(geng)新(xin)和生成的。