色哟哟视频在线观看-色哟哟视频在线-色哟哟欧美15最新在线-色哟哟免费在线观看-国产l精品国产亚洲区在线观看-国产l精品国产亚洲区久久

0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
會員中心
創作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

UCloud基于Linux內核新特性的下一代外網網關設計及相關開源工作

Linux閱碼場 ? 來源:lq ? 2019-05-01 11:33 ? 次閱讀

UCloud外網網關是為了承載外網IP、負載均衡等產品的外網出入向流量,當前基于Linux內核的OVS/GRE tunnel/netns/iptables等實現,很好地支撐了現有業務。同時,我們也在不斷跟蹤開源社區的新技術發展,并將之用于下一代外網網關的設計。這些新特性可將系統性能和管理能力再提上一檔,滿足未來幾年的需求。在方案設計研發過程中發現,新特性存在不少缺陷和Bug,為此我們向開源社區回饋了10多個patch,并融入到kernel 5.0版本中,幫助完善kernel功能并提升穩定性。

當前業界的多租戶外網網關很多都是基于OpenFlow的OpenvSwitch(OVS)方案,然而隨著內核路由轉發功能的不斷完善,利用內核原生路由轉發方式進行設計多租戶外網網關系統成為一種可能。在這種方式下能有效的使用傳統iproute2路由工具以及iptables、nftables等Firewall工具,并且隨著SwitchDev技術的興起,未來將網關系統遷移到Linux Switch上也成為一種可能。

現有kernel 3.x的不足

當前廣泛使用的內核版本為3.x系列,例如CentOS 7全系列標準支持的內核為3.10版本,Fedora/Ubuntu等Linux發行版也有大量使用。在3.x系列內核下存在著IP tunnel管理復雜、租戶隔離性能損耗等問題。

1. IP tunnel管理復雜

Linux內核創建IP tunnel設備來建立點對點的隧道連接,創建時需指定tunnel dst和 tunnel key。因為宿主機之間兩兩建立連接,面向宿主機的目的地址眾多,這樣就會導致網關節點上需要創建成千上萬的tunnel設備,在大規模業務環境下,tunnel的管理將變得及其復雜。

2. 多租戶隔離導致的性能下降

a. 公有云需要實現多租戶隔離以確保用戶間的安全和隱私。由于VPC網絡下不同租戶的內網地址可以重合,導致路由也有重合的可能性,此時需要通過大量的策略路由去隔離租戶的路由規則,由于策略路由的鏈表屬性,性能會隨著鏈表長度的增加而急劇下降。

b. 由于Firewall和NAT的實現基于同樣鏈式的iptables,性能損耗同樣可觀。

3. netns帶來性能開銷

通過netns實現租戶路由和Firewall規則的隔離,但是netns會引入虛擬網卡和協議棧重入開銷,使整體性能下降20%左右。

三項內核新技術

為了解決原有方案存在的困擾,我們調研了大量行業主流方案和內核上游的新動向,發現Lightweight tunneling(輕量級隧道,簡稱lwtunnel)、Virtual Routing Forwarding(虛擬路由轉發,簡稱VRF)以及nftable & netfilter flow offload(流卸載)三項內核新技術的特性,可以幫助規避原方案存在的缺陷。

1. Lightweight tunneling

Linux內核在4.3版本中引入了輕量級隧道Lightweight tunneling,它提供了通過route方式設置tunnel屬性的方法,這樣可以避免管理大量的tunnel設備。

創建隧道設備時指定external模式,利用路由設置的輕量級隧道通過tun設備發送報文。

2. Virtual Routing Forwarding

Linux內核在4.3版本中引入了VRF的初步支持,并在4.8版本形成完備版本。Virtual Routing Forwarding虛擬路由轉發,可以將一臺Linux Box的物理路由器當多臺虛擬路由器使用,能很好的解決租戶路由隔離問題,避免直接使用策略路由。因此,可以將不同租戶的網卡加入租戶所屬的虛擬路由器中來實現多租戶的虛擬路由。

3. flow offload

Nftables是一種新的數據包分類框架,旨在替代現存的{ip,ip6,arp,eb}_tables。在nftables中,大部分工作是在用戶態完成的,內核只知道一些基本指令(過濾是用偽狀態機實現的)。nftables的一個高級特性就是映射,可以使用不同類型的數據并映射它們。例如,我們可以映射iif device到專用的規則集合(之前創建的存儲在一個鏈中)。由于是hash映射的方式,可以完美的避免鏈式規則跳轉的性能開銷。

Linux內核在版本4.16引入了flow offload功能,它為IP forward提供了基于流的卸載功能。當一條新建連接完成首回合原方向和反方向的報文時,完成路由,Firewall和NAT工作后,在處理反方向首報文的forward hook,根據報文路由、NAT等信息創建可卸載flow到接收網卡ingress hook上。后續的報文可以在接收ingress hook上直接轉發,不需要再進入IP stack處理。此外,將來flow offload還將支持hardware offload模式,這將極大提高系統轉發性能。

方案設計與優化實踐

通過對上述三項新技術的研究,我們發現可以嘗試設計一套基于路由的方式,實現多租戶overlay網絡的外網網關。在方案設計過程中,我們也碰到了諸如lwtunnel和flow offload功能不足,以及VRF和flow offload不能一起有效的工作等問題。最終我們都設法解決了,并針對這些內核的不足提交patch給Linux開源社區。

1. lwtunnel發送報文tunnel_key丟失

問題描述:我們利用lwtunnel路由方式發送報文時,創建了一個external類型的gretap tunnel,我們將命令設置了id為1000,但是發送成功報文中沒有tunnel_key字段。

問題定位:我們研究iproute2代碼,發現由于TUNNEL_KEY flag并沒有開放給用戶態,所以iproute2工具并沒有對lwtunnel路由設置TUNNEL_KEY,導致報文不會創建tunnel_key字段。

提交patch:我們給內核和用戶態iproute2分別提交patch來解決這一問題:

iptunnel: make TUNNEL_FLAGS available in uapi

https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?

id=1875a9ab01dfa96b06cb6649cb1ce56efa86c7cb

iproute: Set ip/ip6 lwtunnel flags

https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=3d65cefbefc86a53877f1e6461a9461e5b8fd7b3

提交patch后,可以通過以下方式設置路由。

ip r r 2.2.2.11 via 1.1.1.11 dev tun encap ip id 1000 dst 172.168.0.1 key

2. lwtunnel對指定key的IP tunnel無效

問題發現:為了能有效隔離租戶路由,我們給每個租戶創建一個基于tunnel_key的gretap tunnel設備。如下圖,創建一個tunnel_key 1000的gretap tunnel設備,把tunnel設備加入租戶所屬VRF,tunnel設備能有效地接收報文,但并不能發送報文。

問題定位:研究內核發現,IP tunnel在非external模式下即使指定了輕量級隧道路由,發送報文也沒有使用它,導致報文路由錯誤被丟棄。

提交patch:

ip_tunnel: Make none-tunnel-dst tunnel port work with lwtunnel

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d71b57532d70c03f4671dd04e84157ac6bf021b0

提交patch后,在未指定tunnel_dst的非external模式IP tunnel下,能使用輕量級隧道路由進行發送報文。

3. external IP tunnel ARP無法正常運行

問題描述:鄰居IP tunnel進行了ARP請求,但是本端的ARP回應報文的隧道頭中并沒帶tunnel_key字段。

問題定位:研究代碼發現,tunnel收到了對端的ARP 請求,在發送報文ARP回復的時候會復制請求報文的tunnel信息,但是遺漏了所有tun_flags。

提交patch:

iptunnel: Set tun_flags in the iptunnel_metadata_reply from src

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7bdca378b2301b1fc6a95c60d6d428408ae4e39e

4. Flow offload不能與DNAT有效工作

問題描述:Firewall創建規則從eth0收到目的地址2.2.2.11的報文,DNAT為10.0.0.7, flow offload無法工作。

問題定位:分析發現,客戶端1.1.1.7 ---> 2.2.2.7 DNAT到server 10.0.0.7,第一個reply反向報文(syc+ack)使用了錯的目的地址獲取反向路由

daddr = ct->tuplehash[!dir].tuple.dst.u3.ip

此時dir為反方向,所以daddr獲取為原方向的目的地址,這個值是2.2.2.7, 但是由于被DNAT過,真正的路由不應該通過2.2.2.7去獲取,而是應該根據10.0.0.7這個值去獲取

addr = ct->tuplehash[dir].tuple.src.u3.ip

提交patch:

netfilter: nft_flow_offload: Fix reverse route lookup

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a799aea0988ea0d1b1f263e996fdad2f6133c680

5. Flow offload不能與VRF有效工作

問題描述:將網卡eth0和eth1加入VFR后,flow offload不起作用。

問題定位:查看代碼發現,原方向和反方向首報文進入協議堆棧后skb->dev會設置為vrf device user1,創建flow offload規則的iif就是user1。但是offload規則下發在eth0和eth1的ingress hook上,所以后續報文在eth0和eth1的ingress hook上不能匹配flow規則。

提交patch:

netfilter: nft_flow_offload: fix interaction with vrf slave device

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=10f4e765879e514e1ce7f52ed26603047af196e2

最終,我們根據兩個方向查找路由的結果,設置flow offload規則的iif和oif信息來解決此問題。

6. VRF PREROUTING hook重入問題

問題描述:配置網卡加入VRF,firewall ingress方向規則為接收目的地址2.2.2.11 、TCP 目的端口22的報文,egress方向規則為丟棄TCP 目的端口 22的報文。出現異常結果: 收到目的地址2.2.2.11 TCP 22目的端口的報文卻被丟棄。

問題定位:研究發現網卡加入VRF后收到的報文會兩次進入PREROUTING hook,因為在進入IP stack時會進第一次PREROUTING hook,然后被VRF設備接管后會再次進入PREROUTING hook。上述規則第一次在rule-1000-ingress chain中dst nat為10.0.0.7,第二次由于報文被DNAT后會錯誤的進入rule-1000-egress,導致報文被丟棄。

提交patch:我們給內核加了一個支持判斷網卡類型的match項目,讓用戶態避免可知的第二次無效重入,內核態和用戶態nftables分別提交了如下的patch:

netfilter: nft_meta: Add NFT_META_I/OIFKIND meta type

https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=0fb4d21956f4a9af225594a46857ccf29bd747bc

meta: add iifkind and oifkind support

http://git.netfilter.org/nftables/commit/?id=512795a673f999fb04b84dbbbe41174e9c581430

使用方法:

nft add rule firewall rules-all meta iifkind "vrf" counter accept原型驗證

最終,我們成功地利用lwtunnel、VRF和flow offload實現多租戶外網網關的原型驗證。驗證過程如下:

1. 首先創建原型環境。

a. netns cl模擬外網client, 地址為1.1.1.7,tunnel src 172.168.0.7,配置發送路由;

b. netns ns1模擬租戶1,內網地址為10.0.0.7,外網地址為 2.2.2.11,tunnel src 172.168.0.11 tunnel_key 1000,配置發送路由;

c. netns ns2模擬租戶2,內網地址為10.0.0.7,外網地址為 2.2.2.12,tunnel src 172.168.0.12 tunnel_key 2000,配置發送路由;

d. Host模擬外網網關,tunnel src 172.168.0.1,創建租戶VRF user1和use2,創建租戶IP tunnel tun1和tun2,配置轉發路由。

原型環境圖如下:

2. 創建firewall規則:

a. 租戶1入向允許TCP目的端口22和ICMP訪問,出向禁止訪問外部TCP 22目的端口;

b. 租戶2入向允許TCP端口23和ICMP訪問,出向禁止訪問外部TCP 23目的端口;

c. 在租戶tun1和tun2設備上支持flow offload。

最終,client可以通過2.2.2.11成功訪問user1 tcp 22端口服務,user1不能訪問client tcp 22端口服務;client可以通過2.2.2.12成功訪問user2 tcp 23端口服務,user1不能訪問client tcp 23端口服務。

待后續hardware offload功能完善以及網卡廠商支持后,我們會做進一步的開發驗證。

寫在最后

以上是本項目涉及的部分核心問題,這些patch特性都可以在Linux kernel 5.0版本里獲取。我們把這期間為Linux kernel社區貢獻的patch整理成了一份列表,希望能為開發者提供幫助,讀者可以點擊“閱讀原文”閱覽完整patch list。

Linux作為成熟的開源套件,一直是云廠商使用的主流操作系統,但在技術的更新迭代過程中,一些新特性在實際應用上也會存在穩定性、兼容性等方面的問題。我們在研究使用上游技術的同時,也一直積極探索、豐富開源技術功能,幫助提高開源技術穩定性。并將產出持續回饋給社區,與社區共同構建一個繁榮的開源生態。

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。 舉報投訴
  • Linux
    +關注

    關注

    87

    文章

    11294

    瀏覽量

    209341
  • 路由器
    +關注

    關注

    22

    文章

    3728

    瀏覽量

    113706
  • 數據包
    +關注

    關注

    0

    文章

    260

    瀏覽量

    24385

原文標題:UCloud基于Linux內核新特性的下一代外網網關設計及相關開源工作

文章出處:【微信號:LinuxDev,微信公眾號:Linux閱碼場】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦

    下一代廣電綜合業務網上營業廳的特點與功能

    政策的出臺,面向下一代廣播電視網(NGB)的業務及其運營成為各廣電運營商的核心工作內容,廣電運營商提供的業務類型開始增多,從“單業務”向“多業務、綜合業務”發展;與此同時隨著市場競爭的加劇,廣電運營商的服務理念也從“以業務為中
    發表于 04-23 11:33

    下一代定位與導航系統

    下一代定位與導航系統
    發表于 08-18 10:37

    小草帶你體驗 下一代LabVIEW 軟件

    :https://bbs.elecfans.com/jishu_1102572_1_1.html很多小伙伴由于各種原因,未能看到直播現場內容,先發布節視頻。NI公司將發布基于新軟件下一代LabVIEW,目前
    發表于 12-25 19:53

    如何利用新型Linux開發工具應對下一代嵌入式系統設計挑戰?

    內部增添工程能力。這兩種模式都已被證明是成功的,但是每種做法都需各自的成本。那么我們該如何利用新型Linux開發工具應對下一代嵌入式系統設計挑戰呢?
    發表于 07-30 06:05

    為什么說射頻前端的體化設計決定下一代移動設備?

    隨著移動行業向下一代網絡邁進,整個行業將面臨射頻組件匹配,模塊架構和電路設計上的挑戰。射頻前端的體化設計對下一代移動設備真的有影響嗎?
    發表于 08-01 07:23

    如何建設下一代蜂窩網絡?

    全球網絡支持移動設備體系結構及其底層技術面臨很大的挑戰。在蜂窩電話自己巨大成功的推動下,移動客戶設備數量以及他們對帶寬的要求在不斷增長。但是分配給移動運營商的帶寬并沒有增長。網絡中某通道的使用效率也保持平穩不變。下一代射頻接入網必須要解決這些難題,這似乎很難。
    發表于 08-19 07:49

    下一代SONET SDH設備

    下一代SONET/SDH設備
    發表于 09-05 07:05

    單片光學實現下一代設計

    單片光學 - 實現下一代設計
    發表于 09-20 10:40

    請問Ultrascale FPGA中單片和下一代堆疊硅互連技術是什么意思?

    大家好, 在Ultrascale FPGA中,使用單片和下一代堆疊硅互連(SSI)技術編寫。 “單片和下一代堆疊硅互連(SSI)技術”是什么意思?謝謝娜文G K.
    發表于 04-27 09:29

    用Java開發下一代嵌入式產品

    用Java開發下一代嵌入式產品在我10年的Java布道師生涯里,沒有哪次Java新版本發布能讓我如此興奮。Java 8的發布不僅在語言本身加入了些不錯的新特性,還在嵌入式開發上加入了很棒的功能
    發表于 11-05 09:12

    性能提升1倍,成本直降50%!基于龍蜥指令加速的下一代云原生網關

    重要方向,我們開啟了下一代網關的探索之路。傳統網關傳統網關通過流量網關與業務網關兩層
    發表于 08-31 10:46

    下一代網絡概述

    了解下一代網絡的基本概念掌握以軟交換為核心的下一代網絡(NGN)的形態與結構掌握下一代網絡的網關技術,包括媒體網關、信令
    發表于 06-22 14:26 ?34次下載

    下一代網絡體系結構及相關問題的研究

    下一代網絡體系結構及相關問題的研究1.引言隨著網絡體系結構的演變和寬帶技術的發展,傳統網絡向下一代網絡的演進勢不可擋。下
    發表于 08-06 15:03 ?1268次閱讀
    <b class='flag-5'>下一代</b>網絡體系結構及<b class='flag-5'>相關</b>問題的研究

    MontaVista推出下一代嵌入式linux操作系統 集成了最新的linux2.6內核

    montavista軟件公司日前宣布推出下一代嵌入式linux操作系統——montavistalinux專業版4.0(pro4.0)。
    發表于 12-15 09:59 ?2311次閱讀
    MontaVista推出<b class='flag-5'>下一代</b>嵌入式<b class='flag-5'>linux</b>操作系統 集成了最新的<b class='flag-5'>linux</b>2.6<b class='flag-5'>內核</b>

    開發適用于下一代汽車的汽車網關

    開發適用于下一代汽車的汽車網關
    發表于 10-31 08:23 ?1次下載
    開發適用于<b class='flag-5'>下一代</b>汽車的汽車<b class='flag-5'>網關</b>
    主站蜘蛛池模板: bl撅高扒开臀缝哦| 性虎成人网| 国模孕妇模特季玥之粉红| 一受n攻高h全肉np| 鸥美一级黄色片| 国产亚洲精品AV麻豆狂野| 2021乱码精品公司| 四虎国产精品免费观看视频| 久久青草免费线观最新| 超碰免费视频caopoom9| 亚洲精品青青草原avav久久qv| 美女大BXXXXN内射| 国产日韩欧美高清免费视频| 91视频18| 亚洲精品国偷拍自产在线| 暖暖的高清视频在线观看免费中文| 国产成人综合95精品视频免费| 中文字幕亚洲男人的天堂网络| 色姊姊真舒服| 男女床上黄色| 激情床戏揉胸吃胸视频| 俄罗斯呦呦| 99久久精品国产免费| 亚洲欧美一区二区成人片| 色婷婷粉嫩AV精品综合在线| 男人插曲女人身体视频| 嗨嗨快播电影| 国产爱豆剧果冻传媒在线| 97在线精品视频| 亚洲一区二区三区免费看| 无码国产欧美日韩精品| 欧美猛男gaygayxxgv| 旧里番ovaの催○セイ活指导| 国产女人喷潮视频免费| 岛国电影网址| se01短视频在线观看| 91成品视频| 5G在线观看免费年龄确认| 亚洲伊人精品| 亚洲欧美中文字幕高清在线| 小776论坛|