摘要:需要修改數據包的二層源目地址以及三層包頭的因為路由是逐跳轉發的,每一跳都需要做這些工作,即使是現在通過流表轉發,中間的轉發器直接轉發報文,到達倒數第一跳的時候還是需要把數據包的目的地址修改為接受端的地址。
前言
熟悉這款設備的同學,應該也快到不惑之年了吧!這應該是Cisco最古老的路由器了。上個世紀80年代至今,路由交換技術不斷發展,但是在這波瀾壯闊的變化之中,總有一些東西在嘈雜的機房內閃閃發光,像極了工程師的頭頂,充滿了智慧!
Cisco“古董”路由器
本文主要描述了一種將三層路由變成二層交換轉發(以及二層轉發變成三層路由)的實現方式,以應對OVS(OpenFlow)跨網段路由復雜的問題;當然技術本身是客觀的,具體應用還要看場景。
隨著SDN技術不斷“發展”,玩路由器交換機的變成了“傳統網工”,搞控制器、轉發器的才算是正常工作,當然任何新技術的掌握都離開對“歷史”了解或者反芻;也許幾年以后當有人聽到一條一條的配置ACL、配置路由表是一件很不可思議的事情,因為那時所有的配置都是控制器做好模型生成配置自動下發的,點點鼠標或者寫個py腳本就可以了
傳統的路由交換機
OK,言歸正傳,我們先來了解一下傳統路由、交換的區別:
交換: 一般指的是同網段內分組包的轉發,轉發依據:MAC地址
PC視角:當兩臺主機在同一個網段,PC1需要訪問PC2時,PC1首先會發送arp請求報文,請求PC2的的MAC地址;收到響應后,PC1會把PC2的MAC地址封裝在分組包的目的MAC的位置,然后將分組報文扔給交換機;PC2也會做類似的動作。
交換機視角:交換機會接收網段上的所有數據幀;利用接收數據幀中的源MAC地址來建立MAC地址表(源地址自學習),使用地址老化機制進行地址表維護。MAC地址表中查找數據幀中的目的MAC地址,如果找到就將該數據幀發送到相應的端口,如果找不到,就向除入端口以外的所有的端口發送;向所有端口轉發廣播幀和多播幀。
路由:一般指不同網段的數據包的轉發,轉發依據:IP路由
PC視角:當兩臺主機在不同的網段,PC1需要訪問PC2時,PC1首先會在自己的路由表內查詢PC2的IP地址對應的下一跳(一般默認是網關)地址,然后再去發送ARP報文,請求該下一跳對應的MAC地址;收到響應后,PC1會把該MAC地址封裝在數據包的目的MAC的位置(注意此時的目的IP仍是PC2的IP地址,而不是下一跳IP),然后將數據報文扔給路由器;PC2也會做類似的動作。
路由器視角:當路由器收到一個IP數據包,路由器就會找出數據包的三層包頭中的目的IP地址,然后拿著目的IP地址到自己的路由表中進行查詢,找到“最匹配”的路由條目后,將數據包根據路由條目所指示的出接口或者下一跳IP轉發出去,這就是IP路由(當然路由器還會做一些額外的工作:將數據包的三層包頭的TTL減一,修改數據包的二層源MAC地址為自己出接口的MAC,修改數據包的二層目的MAC地址為下一跳的MAC);而每一臺路由器都會在本地維護一個路由表(Routing Table),路由表中裝在著路由器獲知的路由條目,路由條目由路由前綴(路由所關聯的目的地址)、路由信息的來源、出接口或者下一跳IP等元素構成;路由器通過靜態配置或者動態的方式獲取路由條目并維護自己的路由表。
OpenFlow的出現
當OpenFlow出現以后,路由器、交換機統一變成了轉發器,轉發依據:流表
OK,我們先看一下流表長啥樣:
root@ubuntu:~# ovs-ofctl dump-flows br2
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=16080.313s, table=0, n_packets=1, n_bytes=42, idle_age=15691, priority=200,arp,arp_tpa=2.2.2.0/24 actions=output:100
cookie=0x0, duration=15964.186s, table=0, n_packets=1, n_bytes=42, idle_age=15691, priority=100,arp,arp_tpa=1.1.1.0/24 actions=output:1
cookie=0x0, duration=15985.113s, table=0, n_packets=5, n_bytes=490, idle_age=15692, priority=200,icmp,nw_dst=2.2.2.0/24 actions=output:100
cookie=0x0, duration=15802.910s, table=0, n_packets=5, n_bytes=490, idle_age=15692, priority=100,icmp,nw_dst=1.1.1.0/24 actions=output:1
當然有人稱流表為ACL,這也可以理解,都有著強大的匹配域以及Action,流表的Pipeline可以算是其特色(性能暫時先不care);到此為止,MAC表、路由表在轉發器上面已經統統看不到了,你能看到只有上面的流表。
就OVS來說,如果把Bridge配置成Secure模式,默認是沒有什么流表的;如果現在我們把OVS配置成一臺普通的傳統二層交換機,只需要增加幾條關于ARP、ICMP的流表,就可以Ping通了(可以參考以上示例),這還是比較簡單的。
當然可能有些人說還有更簡單的:只需把Bridge配置Standalone模式或者增加一條默認action=NORMAL的流表就可以了。但是如果這樣的話,所有的流量又回到傳統的二層三層轉發去了,作為新時代的OVS,這符合我的個性啊,如果這樣的話,這活還是交給Linux Bridge來干吧。
但是問題來了,如果把OVS配置成一臺有路由器功能的轉發器,這就比較困難了;因為通過上文分析路由轉發過程相對來說還是比較復雜的,需要做的工作如下:
需要一個類似網關的設備(Device),來響應ARP請求:當然可以在新增OVS時自動生成的設備上配置網關地址,也可以增加多帶帶的設備專門作為網關。
需要修改數據包的二層源目MAC地址以及三層包頭的TTL:因為路由是逐跳轉發的,每一跳都需要做這些工作,即使是現在通過流表轉發,中間的轉發器直接轉發報文,到達倒數第一跳的時候還是需要把數據包的目的MAC地址修改為接受端的MAC地址。
一切皆交換的世界
在OpenFlow的世界所有的網絡設備都是轉發器或者稱為交換機,執行簡單的轉發轉發動作; OK,那我們能不能將跨網段訪問的路由轉發變換成普通的二層轉發呢?答案是YES!
下面我們通過一個示例來實現這個想法:
首先我們要解決的第一個問題就是網關的問題:如何取消對網關的ARP請求?這個在Linux平臺下并不是一件難事,只需一條命令:
root@ubuntu:~# ip route add 0.0.0.0/0 dev eth0 scope link
(同時注意arp_ignore需要是0或1)
Link路由是可以直接arp目標地址的,而不是arp下一跳地址。意思就是說,目標地址是屬于跟本地直連的二層鏈路上,不跨三層。既然是不跨三層的鏈路,arp就可以暢行無阻,而標準中又沒有規定arp協議包的請求源和請求目標必須是同一個網段的地址(甚至都沒有掩碼約束),所以說,一個以下的arp請求是有效的:
驗證得到了響應:
細心的童鞋可以發現上面的命令實際上解決了我們的兩個問題,網關的問題解決了,另外由于源主機直接請求目的主機的MAC地址,所以封裝的時候也直接封裝了目的主機的MAC,省去了我們在倒數第一跳修改數據包的目的MAC為目的主機的工作。
最后剩下一個問題就是防環的TTL的問題,這個處理起來也比較簡單一些,我們可以在流表中加入actions=dec_ttl(1), output:100,在每一跳中自動減小TTL。
然后在接收端的PC上面做類似的操作,中間的OVS添加相關ARP以及業務流的流表,就實現了跨網段的“交換”。
Little Tips
通過以上描述,已經實現了跨網段的路由向交換的轉換,另外也可以實現所謂二層交換向路由的轉換,比如10.0.0.100/24 訪問10.0.0.200/24,按照我們的想當然是應該走二層轉發的,也就是直接請求目的主機的MAC地址,然后封裝、發送;
但是由于種種原因,目的主機10.0.0.200/24可能跟源主機是跨三層網絡的,那現在怎么辦呢?OK,可以在源主機上面增加一條明細路由把10.0.0.200/24指向默認網關,在目的主機上面增加一條明細路由把10.0.0.100/24指向默認網關,然后再ping一下,有木有看到自己的嘴角上揚呢!
交換機本就應該做二層轉發的事情,其他的分布式出去吧!
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/76911.html
摘要:需要修改數據包的二層源目地址以及三層包頭的因為路由是逐跳轉發的,每一跳都需要做這些工作,即使是現在通過流表轉發,中間的轉發器直接轉發報文,到達倒數第一跳的時候還是需要把數據包的目的地址修改為接受端的地址。 前言 熟悉這款設備的同學,應該也快到不惑之年了吧!這應該是Cisco最古老的路由器了。上個世紀80年代至今,路由交換技術不斷發展,但是在這波瀾壯闊的變化之中,總有一些東西在嘈雜的機房...
摘要:需要修改數據包的二層源目地址以及三層包頭的因為路由是逐跳轉發的,每一跳都需要做這些工作,即使是現在通過流表轉發,中間的轉發器直接轉發報文,到達倒數第一跳的時候還是需要把數據包的目的地址修改為接受端的地址。 前言 熟悉這款設備的同學,應該也快到不惑之年了吧!這應該是Cisco最古老的路由器了。上個世紀80年代至今,路由交換技術不斷發展,但是在這波瀾壯闊的變化之中,總有一些東西在嘈雜的機房...
摘要:它最基本的功能是實現了虛擬交換機,可以把虛擬網卡和虛擬交換機的端口連接,這樣一個交換機下的多個網卡網絡就打通了,類似的功能。最基礎的分布式虛擬交換機,這樣可以將多臺機器上的容器組織在一個二層網絡下,看上去就好像所有容器接在一臺交換機上。 【編者的話】Kubernetes經過了幾年的發展,存在著很多的網絡方案。然而網絡虛擬化在Kubernetes出現前就一直在發展,其中基于OpenVsw...
摘要:在實踐中,我們開發并上線了網關和負載均衡網關。而負載均衡網關則支持無縫替換傳統交換機實現網關集群,支持一致性,并支持根據任意字段,內存和端口來計算哈希,支持協議。網絡作為信息時代的重要載體,在云服務的快速發展下形成了獨具特色的虛擬網絡服務架構和模式。12月19日,2020中國云網絡峰會于北京順利召開,會上UCloud虛擬網絡VPC負責人陳煌棟給大家帶來了演講《UCloud VPC技術演進之路...
摘要:支持協議,所以可以很方便的通過編程實現大規模網絡的自動化,被大量運用于網絡中。流表中,優先級高的優先匹配,并執行匹配規則的。 sdn (software defines network) 看了些相關的資料,這里記錄一下自己對sdn的理解,能力有限,如有錯誤歡迎指正。 sdn軟件定義網絡,目的是想要利用軟件來模擬網絡設備,如交換機,路由器之類的。 為什么需要這么做? 一個主要原因是云計算...
閱讀 1028·2023-04-26 02:26
閱讀 2134·2021-09-26 10:16
閱讀 1544·2019-08-30 12:57
閱讀 3461·2019-08-29 16:10
閱讀 3213·2019-08-29 13:47
閱讀 1182·2019-08-29 13:12
閱讀 2135·2019-08-29 11:11
閱讀 1330·2019-08-26 13:28