簡介面向SDN初學者、網(wǎng)絡實驗課程學習者以及需要搭建控制器環(huán)境的Java開發(fā)者這份資料圍繞開源SDN控制器Floodlight的安裝部署展開重點幫助讀者理解Floodlight在SDN網(wǎng)絡中的定位并完成基礎(chǔ)實驗環(huán)境的準備。壓縮包約64.72MB下載頁暫未提供具體文件總數(shù)與類型明細使用前可結(jié)合資源說明確認內(nèi)容構(gòu)成。已有554人瀏覽學習說明其在SDN控制器入門與部署實踐方面具有一定參考價值。內(nèi)容圍繞安裝部署主題組織可幫助讀者在正式動手前建立環(huán)境準備、依賴檢查與運行驗證的整體框架減少盲目嘗試。對于希望在Ubuntu等Linux環(huán)境中熟悉Floodlight部署流程、梳理安裝要點與常見問題的人而言可將其作為搭建實驗平臺和后續(xù)配置練習的參考材料并為后續(xù)SDN實驗與二次開發(fā)打下基礎(chǔ)。1. Floodlight 是什么一條 PacketIn 消息能幫你驗證多少假設floodlight 進場的時機通常很樸素你已經(jīng)能用 Mininet 拉起一堆虛擬交換機但不知道控制平面在背后做了什么想找個能改源碼、能掛自己模塊、還能用一條 curl 就把內(nèi)部狀態(tài)看清楚的 OpenFlow 控制器。Floodlight 就是這類工具里上手成本偏低的那個——純 Java、單進程、自帶 REST 接口跑起來之后對外兩條主線一條面向交換機的 OpenFlow 通道一條面向人和腳本的 HTTP 接口。前者負責收 PacketIn、下 FlowMod后者負責讓你在不重啟進程的前提下查看拓撲、讀寫流表。它適合的讀者畫像很具體想把流表邏輯跑通一遍的網(wǎng)絡方向?qū)W生、要做控制器二次開發(fā)的工程師、需要給測試環(huán)境造一個可控控制平面的驗證人員。它不承諾生產(chǎn)級高可用也不打算替你做集群選主但能把“我寫的轉(zhuǎn)發(fā)邏輯到底對不對”這件事壓縮到幾分鐘內(nèi)看到結(jié)果。下面從跑通、寫模塊、下發(fā)流表一路寫到排查按我自己搭環(huán)境的順序來。2. 從源碼到 8080 端口Floodlight 本地跑通的最小路徑2.1 構(gòu)建前的依賴清單JDK、Maven 與三個容易漏的環(huán)境項Floodlight 是 Maven 工程構(gòu)建鏈路上翻車最多的地方不在代碼在工具鏈版本。它多數(shù)分支的pom.xml把maven.compiler.source/target鎖在 1.8用 JDK 8 構(gòu)建最省事如果你機器上只有 JDK 11 以上會在編譯期撞到package javax.annotation is not declared這類錯誤原因是高版本 JDK 移除了部分 Java EE 模塊而老代碼還在直接引用。解決辦法兩條裝一個 JDK 8 并讓JAVA_HOME指過去或者手動往 pom 里補javax.annotation-api依賴。我一般選前者省得后面還有別的模塊踩同一個雷。Maven 這邊3.6.x 是比較穩(wěn)的選擇。3.8.1 之后默認阻塞 HTTP 倉庫而一些老 pom 里的 repository 地址還寫著http://構(gòu)建時會直接報Blocked mirror for repositories。這不是網(wǎng)絡問題是 Maven 的策略變更。要么在settings.xml里給這個倉庫配一個放行規(guī)則要么把地址換成 HTTPS 鏡像。別急著重裝 Maven先看報錯里那行 URL 的協(xié)議頭。# 1. 確認 JDK 版本1.8 開頭最穩(wěn) java -version javac -version # 2. 確認 Maven 版本3.6.x 優(yōu)先 mvn -v # 3. 顯式指定 JDK 8避免 shell 里殘留的 JAVA_HOME 干擾 export JAVA_HOME/path/to/jdk8 export PATH$JAVA_HOME/bin:$PATH # 4. 跳過測試打包第一次構(gòu)建不建議跑全量單測 mvn clean package -DskipTests # 5. 產(chǎn)物確認正常會生成 target/floodlight.jar ls -lh target/*.jar這段命令的邏輯是“先鎖版本、再打包、最后確認產(chǎn)物”。第三步的JAVA_HOME覆蓋很關(guān)鍵很多人java -version看到的是 8但 Maven 用的是另一套 JDK因為mvn腳本會讀JAVA_HOME而不是PATH里的java。第五步如果只看到original-floodlight.jar而沒有floodlight.jar說明 shade 或 assembly 插件沒跑完通常是依賴下載中斷刪掉本地倉庫里對應的.lastUpdated文件重來。提示第一次構(gòu)建會拉大量依賴網(wǎng)絡不穩(wěn)時容易出現(xiàn)“編譯到一半缺包”的假成功。構(gòu)建完先看一眼 jar 體積幾百 KB 的量級基本意味著依賴沒打進去。2.2 啟動命令與配置文件-cf 改的是哪幾個值Floodlight 啟動時靠一個 properties 文件驅(qū)動默認讀 classpath 里的floodlightdefault.properties。想改端口、改加載模塊列表用-cf指定自己的配置文件別去改 jar 里的那份。啟動成功的標志是日志里出現(xiàn) OpenFlow 監(jiān)聽端口的行和 REST 服務的啟動行這兩行沒出現(xiàn)后面所有操作都免談。配置項作用什么時候必須改net.floodlightcontroller.core.FloodlightProvider.openFlowPort交換機接入端口端口被占用或要和 Mininet 的--controller對齊net.floodlightcontroller.restserver.RestApiServer.portREST 服務端口8080 被別的服務占了floodlight.modules啟動時加載的模塊列表加了自己寫的模塊必須顯式登記net.floodlightcontroller.core.FloodlightProvider.keyStoreTLS 證書路徑只做明文本地實驗時建議去掉相關(guān)配置# 用自定義配置啟動前臺運行方便看日志 java -jar target/floodlight.jar -cf ./my-floodlight.properties # 后臺跑并留日志排查時用這個 nohup java -jar target/floodlight.jar -cf ./my-floodlight.properties \ floodlight.log 21 # 起來了沒有返回 [] 說明控制器活著但還沒有交換機接入 curl -s http://127.0.0.1:8080/wm/core/controller/switches/json-cf后面的路徑建議用絕對路徑相對路徑在nohup場景下會因為工作目錄變化讀不到。第二條命令里21不能省Floodlight 的異常棧大多打在 stderr只重定向 stdout 會讓你在日志里看到一片空白卻查不出原因。第三條 curl 是最輕量的存活探針它不依賴任何模塊業(yè)務邏輯只要 REST 服務起來就有響應返回空數(shù)組是正常狀態(tài)返回連接拒絕才是真出問題。2.3 第一次握手Mininet 建拓撲后確認交換機真的上線了控制器空轉(zhuǎn)沒意義得讓它接上交換機。本地最省事的做法是用 Mininet 起一個線性拓撲把 controller 指到本機。這里有兩個參數(shù)必須對齊端口和 OpenFlow 版本。控制器監(jiān)聽 6653Mininet 就得連 6653控制器按 1.3 解析消息交換機就得用protocolsOpenFlow13起。這兩個對不上握手階段就會失敗日志里刷的是解析異常而不是連接拒絕容易被誤判成網(wǎng)絡不通。# 起一個 3 節(jié)點的線性拓撲交換機用 OpenFlow 1.3 sudo mn --controllerremote,ip127.0.0.1,port6653 \ --switchovsk,protocolsOpenFlow13 \ --topolinear,3 # 另一個終端里確認交換機是否上線正常會返回 DPID 列表 curl -s http://127.0.0.1:8080/wm/core/controller/switches/json | python -m json.tool # 看某個交換機的流表把 dpid 換成上一步返回的值 curl -s http://127.0.0.1:8080/wm/core/switch/dpid/flow/json | python -m json.tool--controllerremote表示不啟動 Mininet 自帶的控制器ip和port指向你剛起的那個進程。protocolsOpenFlow13是給ovsk交換機傳的不寫這個部分版本默認按 1.0 建鏈。第二條命令返回的數(shù)組長度應該等于拓撲里的交換機數(shù)量少一臺就去floodlight.log里搜那臺交換機的連接記錄。第三條命令是第一手調(diào)試手段流表里能看到priority、match、instructions三個字段后面所有下發(fā)動作的效果都要回到這里驗證不要只看 ping 通沒通。3. 模塊機制為什么你的自定義模塊收不到 PacketIn3.1 IFloodlightModule 六個方法的職責邊界Floodlight 的功能全部由模塊拼起來一個類要實現(xiàn)IFloodlightModule就得回答六個問題。這套接口設計的好處是加載順序由容器管你只需要聲明“我依賴誰”不用操心誰先 new。壞處是錯一個方法就可能靜默不生效——不報錯但你的代碼就是不會被調(diào)用。方法容器什么時候調(diào)常見寫錯的地方getModuleServices掃描階段登記本模塊對外提供的服務返回 null 和返回空集合語義不同前者表示不提供服務getServiceImpls同上返回接口到實例的映射提供了服務卻沒在這里注冊實現(xiàn)類getModuleDependencies加載排序前聲明依賴的服務接口只寫了接口類名忘了 import 或?qū)戝e泛型init依賴就緒后拿context.getServiceImpl取服務在構(gòu)造器里取服務此時容器還沒注入startUpinit之后注冊監(jiān)聽器、啟動線程監(jiān)聽器注冊在這里最穩(wěn)不要放 initshutdown進程退出前釋放資源起了線程池卻沒關(guān)熱重啟會殘留最容易出問題的是init和startUp的分工。init只做“取服務、存字段”不要在里面注冊消息監(jiān)聽器startUp才是注冊監(jiān)聽的正確時機因為此時依賴的模塊已經(jīng)完成初始化順序有保證。我見過把addOFMessageListener寫在init里的寫法表現(xiàn)是模塊時好時壞取決于哪個模塊先加載這種時序問題排查起來很麻煩。3.2 寫一個最小 PacketIn 記錄模塊并掛上去目標很小交換機發(fā)來的每個 PacketIn打印源 MAC、目的 MAC 和入端口。這段代碼不長但每一行都對應上面表格里的一個方法可以當作模板改。package net.floodlightcontroller.packetlogger; import java.util.Collection; import java.util.Collections; import java.util.Map; import net.floodlightcontroller.core.FloodlightContext; import net.floodlightcontroller.core.IFloodlightProviderService; import net.floodlightcontroller.core.IOFMessageListener; import net.floodlightcontroller.core.IOFSwitch; import net.floodlightcontroller.core.module.FloodlightModuleContext; import net.floodlightcontroller.core.module.FloodlightModuleException; import net.floodlightcontroller.core.module.IFloodlightModule; import net.floodlightcontroller.core.module.IFloodlightService; import net.floodlightcontroller.packet.Ethernet; import org.projectfloodlight.openflow.protocol.OFMessage; import org.projectfloodlight.openflow.protocol.OFPacketIn; import org.projectfloodlight.openflow.protocol.OFType; import org.projectfloodlight.openflow.types.OFPort; public class PacketLogger implements IFloodlightModule, IOFMessageListener { private IFloodlightProviderService provider; // 本模塊不對外提供服務返回 null 即可 Override public CollectionClass? extends IFloodlightService getModuleServices() { return null; } Override public MapClass? extends IFloodlightService, IFloodlightService getServiceImpls() { return null; } // 聲明依賴容器保證 init 之前 provider 已經(jīng)就緒 Override public CollectionClass? extends IFloodlightService getModuleDependencies() { return Collections.Class? extends IFloodlightServicesingletonList( IFloodlightProviderService.class); } Override public void init(FloodlightModuleContext context) throws FloodlightModuleException { this.provider context.getServiceImpl(IFloodlightProviderService.class); } Override public void startUp(FloodlightModuleContext context) { // 注冊監(jiān)聽放在 startUp依賴已完成初始化 this.provider.addOFMessageListener(OFType.PACKET_IN, this); } Override public void shutdown() { // 沒有線程池留空 } Override public String getName() { return PacketLogger; } Override public Command receive(IOFSwitch sw, OFMessage msg, FloodlightContext ctx) { OFPacketIn pi (OFPacketIn) msg; // 從上下文里取已解析的以太幀避免自己再解析一遍 Ethernet eth IFloodlightProviderService.bcStore.get( ctx, IFloodlightProviderService.CONTEXT_PI_PAYLOAD); OFPort inPort pi.getMatch().get(MatchField.IN_PORT); if (eth ! null) { System.out.println([PacketLogger] dpid sw.getId() in inPort src eth.getSourceMACAddress() dst eth.getDestinationMACAddress()); } // CONTINUE 表示交給后續(xù)監(jiān)聽器STOP 表示到此為止 return Command.CONTINUE; } Override public boolean isCallbackOrderingPrereq(OFType type, String name) { return false; } Override public boolean isCallbackOrderingPostreq(OFType type, String name) { return false; } }邏輯上有三處必須說清。第一receive里沒有自己去調(diào)parse解析字節(jié)流而是用bcStore取上下文里已經(jīng)解析好的Ethernet這樣性能和正確性都由框架保證第二返回值選Command.CONTINUE而不是STOP因為我還想讓默認的轉(zhuǎn)發(fā)模塊繼續(xù)處理這些包一旦返回STOP這個 PacketIn 就到此為止網(wǎng)絡會直接不通第三isCallbackOrderingPrereq和isCallbackOrderingPostreq都返回 false表示不干預和其他監(jiān)聽器的相對順序?qū)砣绻阋鶕?jù)流表判斷、必須跑在轉(zhuǎn)發(fā)模塊之前就要在這里對forwarding這個名字返回 true。注意pi.getMatch().get(MatchField.IN_PORT)需要 importorg.projectfloodlight.openflow.protocol.match.MatchField漏了這個 import 編譯期會報泛型推斷失敗報錯信息看著像類型問題實際只是少了一行。3.3 依賴聲明與加載順序模塊沒生效的三個原因代碼寫完了重啟控制器日志里一條[PacketLogger]都沒有。這是新手最?？ㄗ〉牡胤皆蚧咎硬怀鋈N。第一種模塊沒登記。Floodlight 不會自動掃描 classpath 下的所有IFloodlightModule實現(xiàn)必須把類名寫進配置文件的floodlight.modules列表用逗號分隔。加了新模塊卻沒改這行等于沒寫。第二種登記了但加載失敗。日志里會有一行加載異常但它往往被埋在幾千行 DEBUG 里。把日志級別臨時調(diào)高到 INFO或者直接grep -i PacketLogger floodlight.log能快速定位是構(gòu)造失敗還是依賴沒找到。第三種類沒打進 jar。這在自己加源碼、用mvn package重新構(gòu)建的場景下很常見——你改的是 IDE 里的源碼目錄跑的還是上一次構(gòu)建的 jar。判斷方式很簡單unzip -l target/floodlight.jar | grep PacketLogger看不到類文件就說明構(gòu)建沒帶上你。# 配置文件里顯式登記追加在原有模塊列表后面 # floodlight.modules ...,net.floodlightcontroller.packetlogger.PacketLogger # 構(gòu)建后確認類真的進了 jar unzip -l target/floodlight.jar | grep -i packetlogger # 啟動后確認模塊被加載 grep -i PacketLogger floodlight.log | head -20這三條命令的順序就是排查順序先確認配置登記再確認產(chǎn)物包含最后確認運行時加載。跳過任何一步都可能白折騰半小時。4. 流表下發(fā)從 PacketIn 到 FlowMod 的完整閉環(huán)4.1 PacketIn 到達后你有三種處理方式交換機遇到匹配不上的包默認動作是把它整個或頭部加一段發(fā)給控制器這就是 PacketIn?？刂破魇盏街笥腥齻€選擇選哪個決定了這條流量后面怎么走。第一種是泛洪也就是讓包從除入端口外的所有端口發(fā)出去適用于你還不知道目的端在哪的場景學習型交換機的初始行為就是這個。第二種是丟棄直接不回適合做策略阻斷。第三種是下發(fā)一條 FlowMod把“以后遇到同類型的包該怎么辦”寫進交換機后續(xù)同流量的包不再上送控制器。第三種是真正把控制平面用起來的方式前兩種更像是調(diào)試手段。這里有個容易忽略的細節(jié)PacketIn 可能攜帶 buffer_id表示交換機把原始包暫存在本地緩沖區(qū)了。如果你下發(fā)的 FlowMod 帶上了同一個 buffer_id交換機會直接把緩存里那個包按新流表轉(zhuǎn)發(fā)出去不需要你重發(fā)如果帶的是OFP_NO_BUFFER那個包就丟了得等重傳。首包丟失在 TCP 場景下表現(xiàn)為建連慢半拍很容易被誤認為“流表沒生效”。4.2 用 Java 構(gòu)造一條 FlowModMatch、Instructions、buffer_id下面這段代碼完成的事收到 PacketIn 后按“入端口 IPv4”匹配下發(fā)一條 30 秒空閑過期的流動作為從指定端口輸出。這是一個最小可用的轉(zhuǎn)發(fā)邏輯改匹配字段就能擴展成別的策略。// 在 receive 方法內(nèi)部拿到 pi 之后 private void installFlow(IOFSwitch sw, OFPacketIn pi, OFPort outPort) { // 用交換機自己的 OFFactory保證版本和協(xié)商結(jié)果一致 OFFactory factory sw.getOFFactory(); Match.Builder mb factory.buildMatch(); // 精確匹配入端口避免影響其他端口進來的同目的流量 mb.setExact(MatchField.IN_PORT, pi.getMatch().get(MatchField.IN_PORT)); // 只對 IPv4 生效ARP 等二層流量交給默認邏輯 mb.setExact(MatchField.ETH_TYPE, EthType.IPv4); // 動作從指定端口輸出 OFAction output factory.actions().buildOutput() .setPort(outPort) .setMaxLen(0) // 0 表示不截斷 .build(); // 指令立即執(zhí)行上面的動作 OFInstruction applyActions factory.instructions().buildActions() .setAction(output) .build(); OFFlowMod flowMod factory.buildFlowAdd() .setMatch(mb.build()) .setPriority(32768) // 高于 table-miss 的 0 .setIdleTimeout((short) 30) // 30 秒無流量即刪除 .setHardTimeout((short) 0) // 0 表示不設絕對過期 .setBufferId(pi.getBufferId()) // 復用交換機緩存的原始包 .setInstructions(Collections.singletonList(applyActions)) .build(); sw.write(flowMod); }關(guān)鍵在sw.getOFFactory()這一行。不要用全局靜態(tài)的 factory也不要用按 OpenFlow 1.0 構(gòu)造的 builder 去給 1.3 交換機下發(fā)版本字段對不上會導致交換機回一個錯誤消息而控制器側(cè)只看到流表沒增加很容易誤判。setBufferId(pi.getBufferId())是首包不丟的關(guān)鍵pi.getBufferId()在交換機不緩存時會返回OFP_NO_BUFFER這時行為等同于不指定屬于安全寫法。setMaxLen(0)表示輸出完整包如果你在做抓包分析、只關(guān)心頭部可以設成 128 之類的小值來降低帶寬。4.3 用靜態(tài)流表 REST 接口手工下發(fā)curl 與字段對照不想每次改邏輯都重啟控制器就用 REST 的靜態(tài)流表接口。它是排查和驗證流表字段的最快通道也是把“控制器邏輯”和“流表內(nèi)容”分開驗證的好辦法。注意接口路徑在不同分支之間變過/wm/staticflowpusher和/wm/staticentrypusher兩種前綴都出現(xiàn)過先探一下哪個有響應再發(fā)數(shù)據(jù)。# 先探測路徑返回 200 說明這個前綴可用 curl -s -o /dev/null -w %{http_code}\n \ http://127.0.0.1:8080/wm/staticflowpusher/json # 下發(fā)一條 IPv4 轉(zhuǎn)發(fā)流actions 里的 output2 表示從 2 號端口出去 curl -s -X POST \ -d { switch: 00:00:00:00:00:00:00:01, name: f-ipv4-01, eth_type: 0x0800, ipv4_src: 10.0.0.1, ipv4_dst: 10.0.0.2, priority: 32768, idle_timeout: 30, active: true, actions: output2 } \ http://127.0.0.1:8080/wm/staticflowpusher/json # 查已下發(fā)的靜態(tài)流確認字段沒被吞 curl -s http://127.0.0.1:8080/wm/staticflowpusher/list/00:00:00:00:00:00:00:01/json \ | python -m json.tool # 用完刪掉避免殘留影響后續(xù)實驗 curl -s -X DELETE \ -d {name:f-ipv4-01,switch:00:00:00:00:00:00:00:01} \ http://127.0.0.1:8080/wm/staticflowpusher/json字段對照關(guān)系要記牢switch是交換機的 DPID也就是dpid的十六進制形式name是這條流的唯一標識刪除時必須帶active是字符串true而不是布爾值寫成布爾會被靜默忽略actions是一段用逗號分隔的動作串outputN里的 N 是交換機端口號不是主機編號。返回體里如果是status:Entry pushed就說明成功如果是could not be pushed先檢查字段名拼寫——1.0 和 1.3 的匹配字段名不通用。4.4 優(yōu)先級、idle_timeout、buffer_id 三個必調(diào)參數(shù)參數(shù)取值范圍設錯的典型后果我一般怎么設priority0 到 32768比已有流低導致永不命中業(yè)務流 32768table-miss 固定 0idle_timeout秒0 表示永不過期設太短導致流反復重建、控制器 CPU 高實驗環(huán)境 30演示環(huán)境 300buffer_id交換機分配或OFP_NO_BUFFER用錯導致首包丟失、TCP 建連慢直接用 PacketIn 攜帶的值priority的坑在于它是全局比較而不是按表比較在單表場景下一條 priority 為 100 的寬匹配流會擋住后面所有 priority 更低的精確流。table-miss 那條流必須保持 priority 0、match 為空它決定的是“沒命中任何流轉(zhuǎn)發(fā)控制器”這個兜底行為刪了它交換機遇到未知包會直接丟表現(xiàn)為新連接全部失敗但已有連接正常非常具有迷惑性。idle_timeout的坑在于它是空閑計時不是生存計時。有人設 5 秒想“快速回收資源”結(jié)果低頻心跳流量每小時才來一次流表里那條記錄反復被刪了重建控制器側(cè)日志刷得飛快。實驗環(huán)境下 30 秒足夠演示環(huán)境建議 300 以上寧可多留一會也別讓它頻繁抖動。buffer_id的坑上面提過這里補一個排查技巧如果懷疑是首包丟失導致的建連慢先在receive里打印pi.getBufferId()和pi.getTotalLen()交換機不緩存時會明確給出OFP_NO_BUFFER這種情況你只能靠重傳不是代碼寫錯了。5. 排查交換機連不上、流表不生效的六個坑5.1 連接層的三個坑端口、版本與加密坑一交換機一直重連日志里是握手失敗?，F(xiàn)象是 Mininet 起來后pingall全丟控制器日志里反復出現(xiàn)連接建立又斷開的記錄但沒有任何業(yè)務日志。原因通常是 OpenFlow 版本不匹配Mininet 的交換機默認按 1.0 建鏈而控制器這邊按 1.3 解析雙方在 hello 階段商量不出共同版本直接斷開。解決是給 Mininet 顯式加protocolsOpenFlow13或者在控制器配置里允許 1.0。判斷依據(jù)很簡單看斷開前的最后一條日志里有沒有版本號字段?？佣丝趯戝e連的是沒人監(jiān)聽的地址?，F(xiàn)象比坑一更安靜Mininet 側(cè)沒有任何報錯控制器側(cè)連一條連接記錄都沒有。原因是--controllerremote,ip...,port...里的端口和配置文件里的openFlowPort不一致常見組合是 6633 和 6653 混用。老版本默認 6633新版本默認 6653Mininet 不同發(fā)行版的默認值也不一樣。解決是先ss -lntp | grep java確認進程真實監(jiān)聽的端口再把這個數(shù)字抄到 Mininet 參數(shù)里不要憑記憶。坑三控制器要加密連接交換機只會明文?，F(xiàn)象是 TCP 能連上但握手階段立刻斷開日志里出現(xiàn)證書或 TLS 相關(guān)字樣。原因是默認配置里帶了 keyStore 路徑控制器啟動時生成了自簽證書并要求加密通道而 Mininet 的交換機默認走明文。解決是在自己的配置文件里把 keyStore 相關(guān)項刪掉或置空重啟控制器。這個坑的隱蔽之處在于TLS 失敗和版本失敗的表面現(xiàn)象很像都是連上就斷只能靠日志里的關(guān)鍵字區(qū)分。5.2 轉(zhuǎn)發(fā)層的三個坑table-miss、ARP 與殘留流坑四流表查得到但 ping 就是不通?，F(xiàn)象是 REST 接口能查到剛下發(fā)的那條流match和instructions都正確但流量不命中。原因多半是 table-miss 那條兜底流被刪了或者 priority 被改過導致交換機遇到需要上送控制器的包直接丟棄ARP 請求根本到不了控制器自然也就沒有后續(xù)的流表下發(fā)。解決是確認 table-miss 存在且 priority 為 0或者干脆重啟控制器讓它重新下發(fā)默認流。排查時先看 ARP 通不通再看 IP順序反了會浪費很多時間?？游錓P 流表寫了但 ARP 沒人管主機學不到 MAC。現(xiàn)象是流表里 IPv4 轉(zhuǎn)發(fā)規(guī)則齊全但主機側(cè) ARP 表一直是 incompleteping 直接報“目的主機不可達”。原因是你的模塊只處理了 IPv4 的 PacketIn把 ARP 的包也一并STOP掉了或者沒有讓默認轉(zhuǎn)發(fā)模塊接手。解決是把receive的返回值按包類型區(qū)分非 IPv4 的包一律返回CONTINUE讓默認邏輯去泛洪。這個坑的典型特征是“流表看起來完美網(wǎng)絡就是不通”?？恿牧诉壿嬛貑⑴f流表還在新邏輯不生效?，F(xiàn)象是代碼改了、jar 換了、進程重啟了行為卻和改之前一模一樣。原因是流表存在交換機側(cè)控制器重啟不會清空它們舊的高優(yōu)先級流還在生效新下發(fā)的流因為優(yōu)先級相同或更低永遠不會被匹配到。解決是重啟后先對每臺交換機做一次全量清流再驗證新邏輯。清流之后建議先pingall跑一遍確認兜底路徑正常再去看具體策略。# 清空某臺交換機的全部流表謹慎使用會短暫中斷該交換機上的所有轉(zhuǎn)發(fā) curl -s -X GET http://127.0.0.1:8080/wm/core/switch/00:00:00:00:00:00:00:01/flow/clear/json # 確認流表已空 curl -s http://127.0.0.1:8080/wm/core/switch/00:00:00:00:00:00:00:01/flow/json \ | python -m json.tool清流這個動作要養(yǎng)成習慣它相當于給自己留了一顆后悔藥任何“改了不生效”的懷疑先用它排除交換機側(cè)殘留再去查代碼。跳過這一步直接讀代碼經(jīng)常是讀了兩小時發(fā)現(xiàn)邏輯沒錯只是舊流沒刪。6. 進階把 REST 接口串成回歸腳本驗證下發(fā)是否真的生效手工 curl 在驗證階段夠用但當你開始反復改模塊邏輯就需要一個能一鍵回答“這次改動有沒有破壞原有行為”的腳本。我的做法是用 Python 寫一個小回歸器只做三件事下發(fā)前清流、下發(fā)后輪詢流表確認條目存在、跑一次連通性檢查。它不追求覆蓋所有場景但能把“看起來成功了”和“真的成功了”區(qū)分開。import json import time import requests BASE http://127.0.0.1:8080 DPID 00:00:00:00:00:00:00:01 def clear_flows(): # 清空指定交換機的流表避免上一輪殘留干擾 requests.get(f{BASE}/wm/core/switch/{DPID}/flow/clear/json, timeout3) def flow_exists(cookie_prefix): # 輪詢交換機流表按 cookie 前綴匹配確認下發(fā)的流真的落地 for _ in range(10): resp requests.get(f{BASE}/wm/core/switch/{DPID}/flow/json, timeout3) flows json.loads(resp.text).get(DPID, {}).get(flows, []) for f in flows: if f.get(cookie, ).startswith(cookie_prefix): return True time.sleep(0.5) # 交換機寫入有延遲別只查一次 return False if __name__ __main__: clear_flows() time.sleep(1) # 這里換成你自己的下發(fā)邏輯或者直接走靜態(tài)流表接口 print(flow landed:, flow_exists(0x0))腳本里有兩個細節(jié)值得說。一是time.sleep(0.5)加輪詢而不是查一次就下結(jié)論交換機寫入流表到 REST 接口能查到之間有毫秒級延遲單次查詢會偶發(fā)誤判這種偶發(fā)失敗最消耗排查時間。二是按 cookie 前綴匹配而不是按名字因為靜態(tài)流表接口和模塊下發(fā)的流在字段上不完全一致cookie 是兩邊都能設且不參與匹配的字段適合當標記位。三種驗證手段的取舍可以對著下表選手段能看到什么開銷適合階段控制器日志打印模塊是否被調(diào)用、參數(shù)是什么低但需要改代碼開發(fā)期定位邏輯分支REST 查流表交換機側(cè)實際生效的條目低無需改代碼每次下發(fā)后的必查項端到端連通性測試數(shù)據(jù)面是否真的通中要起拓撲提交前的最終確認我踩過最貴的一次坑是只看了日志就認為功能正?！罩纠锬K確實被調(diào)用了參數(shù)也對但下發(fā)的那條流因為優(yōu)先級和已有的 table-miss 撞了交換機根本沒執(zhí)行。日志是控制器的視角流表是交換機的視角這兩個視角不一致的時候永遠以交換機為準。后來我給自己定了個規(guī)矩任何涉及流表的改動必須同時有日志、流表、連通性三樣證據(jù)缺一樣就先別提交。希望這些步驟能幫你在自己機器上把這套東西跑順少走幾段我走過的回頭路。本文還有配套的精品資源點擊獲取