<menu id="guoca"></menu>
<nav id="guoca"></nav><xmp id="guoca">
  • <xmp id="guoca">
  • <nav id="guoca"><code id="guoca"></code></nav>
  • <nav id="guoca"><code id="guoca"></code></nav>

    為何MPLS-TE需要導流操作?

    VSole2022-04-24 16:12:33

    為什么MPLS-TE需要有引流的操作(自動路由,靜態,tunne-policy),而LDP卻不需要?

    MPLS-TE和LDP不都是隧道嗎?

    LDP不是隧道,它僅僅是用來將路由表映射為標簽Label。

    MPLS-TE單向(Uni-Directional)隧道。所謂單向隧道是指,假設隧道Tunnel1的起點是上海PE,隧道的終點是北京PE,通過流量導流操作(Auto-Route,Static Route,Tunnel-Policy)從起點(上海PE)灌入,到達終點(北京PE),游戲就結束了。

    北京PE如果有返程的流量去上海PE,能使用上文的隧道Tunnel1嗎?

    不能。

    為何不能?

    因為Tunnel1在北京PE上壓根不存在。

    怎么辦?

    有兩種方法:

    • 方法1:北京PE作為起點,上海PE作為終點,由北京PE主動發起建立一個隧道Tunnelx,這個下標x,為任意正整數或0,假定也是Tunnel1吧。當Tunnel1處于UP狀態時,北京PE就可以通過流量導流操作(Auto-Route,Static Route,Tunnel-Policy)從起點(北京PE)灌入,到達終點(上海PE),流量就成功返回。
    • 方法2:北京PE不打算創建什么鬼MPLS-TE隧道,麻煩死了北京PE把流量的轉發全權交給路由表做決策。路由表查詢發現,流量需要轉發給上海的PE。流量就這么轉發出去了嗎?

    No,這種普通的IP轉發在這里玩不開了,為什么呢?

    因為IP報文的目的IP地址是私有IP,如10.x.x.x/8,在北京PE與上海PE之間,還有很多中間路由器P,它們沒有10.x.x.x/8的路由,如果將IP報文轉發給中間節點P,那么大概率丟包處理,永遠無法到達目的地。

    那如何是好?

    LDP粉墨登場,LDP就是為了解決以上難題而存在的。每個路由器,包括北京PE、上海PE、中間大量的路由器P,通過OSPF/ISIS知道每個PE的路由表,其中包括北京PE、上海PE、廣州PE、深圳PE、成都PE、西安PE、武漢PE等等。然后為每個PE使用LDP動態生成一個Label。這個Label可以告知中間節點路由器P,出口PE是誰?對于核心網的路由器P來說,只要根據Label能將流量轉發到出口PE了,就可以了。管你IP報文中的目的IP是什么?自作多情了,中間節點壓根不看目的IP,只看Label。

    回正題,北京PE查完路由表,然后根據路由表指示的出口PE為上海PE,然后查上海PE對應的LDP表,發現Label =2022,這個2022是誰告訴北京PE的?

    天津路由器P告訴的。這里的邏輯是,由于北京PE的OSPF/ISIS鄰居是天津P,天津P通過LDP會話北京PE:老哥,如果去往上海PE,請使用標簽2022。

    于是,北京PE將IP報文打包封裝起來,在外面打上標簽2022,包裹扔給天津P。

    天津P,通過查外包裝的2022,知道需要發給蘇州路由器P,使用蘇州路由器P告知的標簽3033。

    包裹到達蘇州,蘇州路由器P根據3033,知道包裹需要扔給上海PE,使用上海PE告知的標簽6066。

    包裹到達上海PE,上海PE將外包裝全部撕掉,只剩下原始的IP報文,目的IP可能是10.x.x.x/8,上海PE說,毫無壓力,查詢路由表就可以完成最終的轉發。這個路由表不是全局路由表,而是客戶專屬VRF路由表,里面塞滿了各種10打頭的私有路由表。

    用方法2,即LDP動態生成標簽,采用標簽轉發不是挺好的嗎,為何要有方法1存在的必要呢?

    從上文可以看出,LDP數據的源頭是OSPF/ISIS,最短路徑算法。按照最短路徑走G2是不錯的選擇,即北京-天津-濟南-蘇州-上海。但是由于這條G2線路太擁堵,盡管在OSPF/ISIS眼里是最優的,但是到達上海延遲非常大,事實上并不是最優的。因為隔壁的深海高速G15,非常空閑,雖然有點遠,但是延遲絕對比G2要小。

    盡管G15更優,可是我們卻無法將流量切換到G15,因為OSPF/ISIS總是會選擇G2,因為Cost最小。

    如何能將流量切到G15上去?

    這個工具就是MPLS-TE,TE是Traffic Engnieering的縮寫,就是為了自由切換流量而存在的。

    如何強迫流量走G15?

    只要建一個隧道,隧道起點為北京PE,隧道終點為上海PE,然后讓RSVP-TE去動態創建隧道就可以了嗎?

    當然不行。因為這條隧道依然會走G2,即北京-天津-濟南-蘇州-上海。

    需要加入約束算法,告知RSVP-TE,隧道起點為北京PE,隧道終點為上海PE,線路中一定要走青島、南通,其它的不Care。

    由于G2并不滿足這個約束條件,被剔除出去。然后就在滿足約束條件的路線中,挑選出最短路徑,這條線路最后只會是G15。

    然后北京PE使用RSVP-TE這個信令協議,沿著G15的線路預約好帶寬資源、標簽,沿途經過天津、青島、連云港、南通、上海。

    當G15單向隧道創建成功時,就可以通過流量導流操作(Auto-Route,Static Route,Tunnel-Policy)從起點(北京PE)灌入,到達終點(上海PE),游戲就結束了。

     

    最后,無論使用LDP轉發,還是MPLS-TE轉發,都使用標簽轉發,除了入口PE、出口PE檢查IP地址,其它節點壓根不看。

    流量路由表
    本作品采用《CC 協議》,轉載必須注明作者和本文鏈接
    ELB 彈性負載均衡(Elastic Load Balance,簡稱ELB)是將訪問流量根據分配策略分發到后端多臺服務器的流量分發控制服務。彈性負載均衡可以通過流量分發擴展應用系統對外的服務能力,同時通過消除單點故障提升應用系統的可用性。 01信息搜集 查詢IP地址組列表
    系統運行配置狀態檢查display interface #接口流量、鏈路狀態dis current-configuration inter #地址分配dis current-configuration |include ospf #路由擴散display ip routing-table #路由信息display ip interface #顯示 vlan 端口統計數據display saved-configuration #保存配置文件display logbuffer #日志信息display port trunk #查看參與 trunk 的端口03?vrrp 和端口聚合檢查display vrrp #查看虛擬路由冗余協議display vrrp statistics #查看主備用狀態display link-aggregation summary #查看鏈路聚合組的情況
    為什么MPLS-TE需要有引流的操作(自動路由,靜態,tunne-policy),而LDP卻不需要?MPLS
    Orange西班牙公司的RIPE賬號被盜,攻擊者將其網絡核心配置(BGP和RPKI)改為無效,導致全國互聯網中斷了大約3小時;據悉,攻擊者在信息竊取軟件的數據集中發現了此次被利用的賬號(未啟用雙因子認證),為了“找樂子”實施了此次攻擊。
    近日,紐約大學和魯汶大學的研究人員發現大多數VPN產品中都存在長達二十多年的多個漏洞,攻擊者可利用這些漏洞讀取用戶流量、竊取用戶信息,甚至攻擊用戶設備。
    近日,紐約大學和魯汶大學的研究人員發現大多數VPN產品中都存在長達二十多年的多個漏洞,攻擊者可利用這些漏洞讀取用戶流量、竊取用戶信息,甚至攻擊用戶設備。“我們的攻擊所需的計算資源并不昂貴,這意味著任何具有適當網絡訪問權限的人都可以實施這些攻擊,且不受VPN安全協議限制。
    sdn 網絡架構是否可以取代tcp/ip架構?1、sdn nfv不同于傳統路由表選路規則,通過openflo
    注意在整個過程中,客戶不要事先征集到現場或現場的人員操作情況。啟動或部署監測設備,針對病毒感染進行全面監測,避免死灰復燃。在此過程中并沒有展開分析,隨后制作收集所有相關的樣本日志等,并尋找感染源頭,并制定整改。先找出急用的木馬文件,不要于打包一份。
    雷神眾測擁有對此文章的修改和解釋權。如欲轉載或傳播此文章,必須保證此文章的完整性,包括版權聲明等全部內容。未經雷神眾測允許,不得任意修改或者增減此文章內容,不得以任何方式將其用于商業目的。
    應急響應的基本流程
    2022-01-01 08:34:07
    注意在整個過程中不要被客戶或現場的運維人員誤導。操作前需先征得客戶許可。
    VSole
    網絡安全專家
      亚洲 欧美 自拍 唯美 另类