【SDN】Openflow協議中對LLDP算法的理解--如何判斷非OF區域的存在

此前一直不能理解,Openflow中discovery的流程裏,非OF設備是如何發現的。最近終於解決了這個問題,總結如下。

【【Discovery】】

LLDP用於通告自己的信息,沒有傳遞性,即經過一個設備後會“消耗掉”,不會繼續轉發。

傳統的交換機/網絡設備對LLDP的處理方式:主要針對某個端口開啓/不開啓,即是否主動發送LLDP。發送與接收一般無邏輯關係。(很少有邏輯要求“收到LLDP才發送”)
若傳統設備已主動發起LLDP,OF交換機收到後會上傳到控制器,控制器可以判斷出這個LLDP是非OF設備發出的,但不能判定該非OF設備存在於OF區域中。因此不管傳統設備對LLDP如何處理,都按統一的算法進行判斷。

【前提條件】算法必須滿足2個假設:

  1. 非OF設備對廣播包有轉發能力(即在2層環境裏)

  2. 非OF設備不會傳遞LLDP包(即消耗)


【流程】控制器利用output指令要求OF交換機發送LLDP包和BDDP到所有的端口,LLDP先發送。

1 LLDP
 1.1 支持OF協議的交換機會上傳LLDP,證明是OF設備
 1.2 沒收到LLDP,有可能是主機,也可能是非OF設備,依賴BDDP包判斷
2 BBDP
  若廣播包從一個在[LLDP階段判斷出無直連關係的OF設備]收到它用paketIn封裝的broadcast包,證明兩個OF設備間有非OF的區域存在(而不是邊緣)。否則,該端口連接的是主機,或者是非內部包含的非OF區域。


簡單來說:收到LLDP與BDDP,則是OF交換機。僅收到BDDP,就是非OF交換機。都收不到是主機或邊緣非OF區域。


補充一個在floodlight官方文檔中摘過來的描述
Description

The link discovery service is responsible for discovering and maintaining the status of links in the OpenFlow network.
How it works

The link discovery services uses both LLDPs and broadcast packets (aka BDDPs) to detect links. The LLDP destination MAC is 01:80:c2:00:00:0e and the BDDP destination MAC is ff:ff:ff:ff:ff:ff (broadcast address). The ether type for LLDPs and BDDPs is 0x88cc and 0x8999. There are two assumptions made in order for the topology to be learned properly.

   Any switch (including OpenFlow switches) will consume a link-local packet (LLDP).
   Honors layer 2 broadcasts.

Links can either be "direct" or "broadcast". A direct link will be established if an LLDP is sent out one port and the same LLDP is received on another port. This implies that the ports are directly connected. A broadcast link is created if a BDDP is sent out a port and received on another. This implies that there is another layer 2 switch not under the control of the controller between these two ports.

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章