- 产品与解决方案
- 行业解决方案
- 服务
- 支持
- 合作伙伴
- 新华三人才研学中心
- 关于我们
01-OpenFlow配置
本章节下载： 01-OpenFlow配置 (377.27 KB)
随着虚拟化技术的大规模应用，传统的网络架构和网络设备的不足越来越多的被暴露出来，如控制平面与转发平面相集成，扩展性低，不易定制，技术更新周期长，过于依赖网络设备商。而虚拟化技术要求设备操作简单灵活、扩展性能高、不需要用专门的芯片来进行转发控制。传统的网络设备已经无法满足虚拟化技术以及数据中心网络的需求。而SDN（Software Defined Network，软件定义网络）技术可以分离控制平面和网络转发平面，解决数据中心网络中所面临的问题。
OpenFlow是SDN（Software Defined Network，软件定义网络）架构中定义的一个控制器与转发器之间的通信接口标准。OpenFlow允许控制器直接访问和操作网络设备的转发平面，这些网络设备可能是物理上的，也可能是虚拟的路由器或者交换机。
OpenFlow的思想：分离控制平面和数据平面，二者之间使用标准的协议通信；数据平面采用基于流的方式进行转发。
OpenFlow网络由OpenFlow设备（Switch）和控制器（Controller）通过安全通道（OpenFlow channel）组成，如图1-1所示。Switch与Controller通过TLS或者TCP建立安全通道，进行OpenFlow消息交互，实现表项下发、查询以及状态上报等功能。下文如果没有特殊说明，交换机指的就是OpenFlow设备。
图1-1 OpenFlow网络组成
OpenFlow Switch有下面两种：
· OpenFlow-Only Switch：仅支持OpenFlow转发。
· OpenFlow-Hybrid Switch：既支持OpenFlow转发，也支持正常转发。本系列交换机即为OpenFlow-Hybrid Switch。
OpenFlow接口有下面三类：
· 物理接口：例如交换机的以太网接口等，可以作为入接口和出接口。
设备不支持匹配LoopBack接口。
· 保留接口：由转发动作定义的接口，实现OpenFlow转发功能。除Any接口外，其他接口仅可以作为出接口，仅Controller和Local可以作为入接口。具体类型请参见表1-1。
OpenFlow支持多实例。每个OpenFlow实例可以单独连接控制器，相当于一台独立的交换机，OpenFlow实例根据控制器下发的流表项指导流量的转发，下文如果没有特殊说明，交换机为一个OpenFlow实例。
OpenFlow实例通过VLAN划分作用范围，在实例的作用范围内，流量转发遵循流表中定义的规则。
OpenFlow实例配置完成后，需要进行激活才能生效。
OpenFlow需要将设备的支持能力、当前的接口信息等设备信息上报给控制器后，控制器才能够下发流表项指导转发。
在配置更改的情况下，需要重新激活实例，使配置生效。在激活配置时，OpenFlow实例会与所有控制器断开连接，然后重新进行连接。
OpenFlow协议规定OpenFlow实例需要将接口信息上报给控制器，这些接口包括物理接口、逻辑接口以及保留接口中的Local。
对于通过VLAN划分作用范围的OpenFlow实例，当且仅当接口所属VLAN完全包含了OpenFlow对应的VLAN后，该接口才是该OpenFlow实例的接口，可以被上报到控制器。如果配置了loosen模式，只要接口所在VLAN与实例配置VLAN存在交集，接口就属于OpenFlow实例。
OpenFlow通过流表（Flow Table）来匹配和处理报文，在同一个流表中按流表项的优先级进行先后匹配。一台交换机上可以包含一个或者多个流表。
· MAC-IP流表：通过MAC地址表和FIB表实现。只能匹配报文的目的MAC地址、VLAN以及目的IP地址，动作也仅支持修改报文的目的MAC地址、源MAC地址、VLAN以及指定出接口。
· Extensibility流表：扩展流表，使用TCAM（Ternary Content Addressable Memory，三态内容寻址存储器）实现，可以匹配报文的源MAC地址、目的MAC地址、源IP地址、目的IP地址、报文优先级、TCP源端口、TCP目的端口等。
· Match Fields：匹配规则。可以匹配入接口、报文头等字段。
· Priority：优先级。定义流表项之间的匹配顺序，优先级高的先匹配。
· Counters：统计计数。统计有多少个报文和字节匹配到该流表项。
· Instructions：动作指令集。定义匹配到该流表项的报文需要进行的处理。流表项动作指令集是对动作进行操作，流表项的动作有两种执行类型：
¡ 动作集（Action Set）：一系列动作的组合，设备不会立刻修改报文内容，直到报文不再需要进入下一级流表，动作集里每种动作仅有一个，并且按照图1-2从上到下的顺序执行。
¡ 动作序列（Action List）：需要立即执行的一系列动作，其动作内容与动作集相同，此时立即修改报文的内容，并且执行顺序按照下发的顺序执行。
|
进入下一级流表，Extensibility流表不支持该指令集 |
表1-3 动作类型（1.3.1版本）
|
可选/必选 |
||
|
转发报文到特定的OpenFlow端口，例如物理端口，逻辑端口以及OpenFlow保留端口 |
||
|
没有直接的动作来代表Drop，当动作集中不含有Output指令时，报文会被丢弃。通常空指令集，空动作集或者执行清空动作集后，报文会被丢弃 |
||
|
将报文转交给指定的Group表处理，该动作的确切含义由Group的类型定义 |
||
|
Set-Queue动作为报文指定队列ID。当报文被转发到特定端口时，队列ID通常被用于QoS |
||
|
识别报文字段的类型，并且可以修改该字段的值。Set-Field动作通常只适用于报文最外层的字段（比如当内外层均有VLAN tag时，该动作只修改最外层的VLAN Tag） |
· Timeouts：超时时间。包括了Idle time和Hard time。
¡ Idle time：在Idle time时间内，如果没有报文匹配到该流表项，则此流表项被删除。
¡ Hard time：在hard time时间超时后，无论是否有报文匹配到该流表项，此流表项都会被删除
· Cookie：控制器下发的流表项的标识。
如图1-3所示，报文进入设备后，设备先解析报文，然后从第一个流表开始，按照流表编号从小到大依次匹配，当数据包成功匹配一条规则后，将首先更新该规则对应的统计数据（如成功匹配数据包总数），然后根据规则中的指令进行相应操作（比如转下一个流表继续处理、修改或者立即执行该数据包对应的动作等）。当数据包处于最后一个流表时，其对应的动作将被执行（比如转发至某一端口、修改数据包某一字段或丢弃数据包等）。
图1-3 OpenFlow转发示意图
每个流表都包含一个Table Miss流表项，该表项用于定义在流表中没有匹配的报文的处理方式，该表项匹配任何报文，优先级为0，动作指令与正常表项相同。
Group Table由Group表项组成，Group表项被流表项所引用，提供额外的报文转发功能。
图1-4 Group表项结构
· Group Identifier：Group ID，用于识别Group，32bits。
· Group Type：Group类型，All：执行所有动作桶，用于组播或者广播。
· Counters：当报文被Group处理时，更新计数器。
· Action Buckets：一个由动作桶组成的有序列表。每个动作桶由许多动作组成。
Meter Table由Meter表项组成，Meter表项被流表项所引用，为所有引用Meter表项的流表项提供报文限速的功能。
图1-5 Meter表项结构
· Meter Identifier：Meter ID，用于识别Meter，32bits。
· Meter Bands：一个Meter表项可以包含一个或者多个Meter Bands，每个Meter Band定义了速率以及动作。当报文的速率超过了某些Meter Band，根据这些Meter Band中速率最大的那个定义的动作进行处理。
· Counters：当报文被Meter处理时，更新计数器。
· Band Type：Band类型，定义报文如何处理。为可选，可使用丢弃（drop），即报文高于该速率会被丢弃；以及重新标记DSCP（dscp remark）。
· Rate：Meter用于选择Band的最低速率，即报文速率高于该速率并最接近该速率，该Band将被应用。
· Counters：当Band处理报文时，更新计数器。
· Type Specific arguments：某些Band含有的特定参数。
交换机与控制器通过TLS或者TCP建立Channel，进行OpenFlow消息交互，实现表项下发、查询以及状态上报等功能。
OpenFlow协议中定义了三种消息类型，即：Controller to Switch消息、异步消息和同步消息，每种报文类型都有多种子类型。
Controller to Switch消息是指由控制器产生并发送到交换机，可以不需要交换机响应。这些消息主要由控制器用来对交换机进行状态查询和修改配置等操作。
表1-4 Controller to Switch消息（1.3.1版本）
|
控制器发送该请求了解交换机对OpenFlow的支持能力，交换机必须回应该请求 |
|
|
控制器使用该消息管理交换机的状态，如增加、删除、修改、交换机的流表项/Group表项，以及交换机端口的属性 |
|
|
用于通过交换机特定端口发送报文，这些报文可以通过Packet-In消息触发，也可以通过控制器直接发送。通常Packet-Out消息包含整个之前接收到的Packet-In消息所携带的报文或者buffer ID（用于指示存储在交换机内的特定报文）。这个消息需要包含一个动作列表，当交换机收到该动作列表后会对Packet-Out消息所携带的报文执行该动作列表。如果动作列表为空，Packet-Out消息所携带的报文将被交换机丢弃 |
|
|
控制器用该消息确认之前下发动作是否成功。控制器发送Barrier请求消息，当交换机之前下发的流表等操作都已经成功时会回复Barrier应答消息 |
|
|
用于设定或查询OpenFlow channel的角色。通常用于交换机和多个控制器相连的情况 |
|
|
控制器使用该报文设定异步消息过滤器来接收其只希望接收到的异步消息报文，或者向交换机查询该过滤器。通常用于交换机和多个控制器相连的情况 |
异步（Asynchronous）消息是由交换机发送给控制器，用来通知交换机上发生的异步事件的消息。例如，当某一条规则因为超时而被删除时，交换机将自动发送一条流表项删除消息通知控制器。
|
转移报文的控制权到控制器。对于所有通过匹配流表项或者Table Miss后转发到保留端口Controller端口的报文均要通过Packet-in消息送到控制器。也有部分其他流程，如TTL检查等，也需要通过该消息和控制器交互。Packet-In既可以携带报文，也可以通过在交换机内部设置报文的Buffer来仅携带报文头以及其Buffer ID传输给控制器。控制器在接收到Packet-In消息后会对其接收到的报文或者报文头和Buffer ID进行处理，并发回Packet-out消息通知交换机如何处理该报文 |
|
对称（Symmetric）消息主要用来建立连接和检测对方是否在线等。
|
当交换机和控制器建立连接时，双方发送Hello消息进行交互 |
|
|
用于验证控制器与交换机之间连接的存活，控制器和交换机都会发送Echo request/reply消息，接收到Echo request消息时，必须能返回Echo reply消息。也可用于测量控制器与交换机之间链路的延迟和带宽 |
|
OpenFlow Switch Specification Version1.3.1
表1-7 OpenFlow配置任务简介
|
配置OpenFlow实例的基本能力 |
配置OpenFlow实例对应的VLAN |
|||
|
配置OpenFlow实例与控制器的连接模式 |
||||
|
配置Extensibility流表项的上限 |
||||
|
配置OpenFlow实例对应的VLAN禁止MAC地址学习 |
||||
|
配置OpenFlow实例的Datapath ID |
||||
|
配置OpenFlow定时器 |
||||
|
配置QINQ模式 |
可选 |
|||
|
配置允许聚合成员端口出现在控制器下发的流表中 |
可选 |
|||
当LLDP与OpenFlow配合使用时，需要在Openflow网络设备上全局使能LLDP功能，但为了此时LLDP不影响OpenFlow控制器发现拓扑，建议在OpenFlow实例内的接口上关闭LLDP功能。有关LLDP的详细介绍，请参见“二层技术-以太网交换配置指导”中的“LLDP”。
|
创建OpenFlow实例，并进入OpenFlow实例视图 |
||
|
（可选）配置OpenFlow实例描述 |
缺省情况下，未配置OpenFlow实例的描述信息 |
下面配置用于定义OpenFlow实例的基本能力，设备与控制器建立连接后，会向控制器上报这些基本能力，控制器根据这些能力下发表项。
配置OpenFlow实例对应的VLAN后，对应VLAN内的流量根据OpenFlow流表项转发，其它VLAN内的流量进行正常转发。
· 不能将同一个VLAN映射到多个实例中，否则，流量无法正确处理。
· 如果OpenFlow实例对应的VLAN不存在，在激活实例后，不存在的VLAN会自动创建。在实例激活后，请不要删除OpenFlow实例对应的VLAN。
· 配置VLAN对应的VLAN接口下不允许配置BFD MAD检测功能，该功能的相关内容请参见“IRF配置指导”中的“IRF”。
表1-9 配置OpenFlow实例对应的VLAN
|
进入OpenFlow实例视图 |
||
|
配置OpenFlow实例对应的VLAN |
缺省情况下，没有配置OpenFlow实例对应的VLAN |
|
进入OpenFlow实例视图 |
||
|
配置OpenFlow实例下的流表类型和流表ID |
缺省情况下，Extensibility流表ID为0，没有配置MAC-IP流表ID 一个OpenFlow实例只支持配置一个MAC-IP表和一个Extensibility表，如果多次执行该命令，后面的配置将会覆盖前面的配置 MAC-IP表的ID值必须小于Extensibility表的ID值 |
OpenFlow实例与控制器连接时，支持以下两种模式：
· Single模式：同一时刻，OpenFlow实例仅与一个控制器建立连接，配置的多个控制器之间互为备份，当且仅当当前的连接断开后，OpenFlow实例连接下一个控制器，直到连接成功。
· Multiple模式：同一时刻，OpenFlow实例可以与多个控制器建立连接，在与某个控制器连接失败或者断开连接后，在重连时间间隔后重新与之进行连接，直到连接成功。
Single模式下，设备根据Controller ID从小到大顺序依次连接控制器，只有在前一个控制器连接不上时才会连接下一个控制器，如果配置了多个路由不可达的控制器，设备遍历到路由可达的控制器建立连接可能耗时较长。
表1-11 配置OpenFlow实例与控制器的连接模式
|
进入OpenFlow实例视图 |
||
|
配置OpenFlow实例与控制器的连接模式 |
缺省情况下，OpenFlow实例与控制器的连接模式为multiple |
在OpenFlow实例中允许定义Extensibility流表支持的表项最大值，当控制器下发的流表表项个数超过最大值的时候，向控制器返回失败。
表1-12 配置Extensibility流表项的上限
|
进入OpenFlow实例视图 |
||
|
配置Extensibility流表项的上限 |
缺省情况下，Extensibility流表项的上限为65535 |
带内管理VLAN是OpenFlow实例对应的VLAN中的一个或多个VLAN，专门用于在OpenFlow实例内建立该实例与控制器的连接。
配置带内管理VLAN后，带内管理VLAN中的数据报文不再进行OpenFlow转发，并且仅在带内管理VLAN中的端口不再属于OpenFlow接口。因此，进行该功能的配置前，请用户做好网络规划。
带内管理VLAN必须是OpenFlow实例对应的VLAN的子集。
|
进入OpenFlow实例视图 |
||
配置该功能后，OpenFlow实例对应的VLAN的MAC地址学习功能被禁止。
带内管理VLAN不受该功能限制。
表1-14 配置OpenFlow实例对应的VLAN禁止MAC地址学习
|
进入OpenFlow实例视图 |
||
|
配置OpenFlow实例对应的VLAN禁止MAC地址学习 |
缺省情况下，OpenFlow实例对应的VLAN允许MAC地址学习 |
表1-15 配置禁止OpenFlow实例上送Controller的端口类型
|
进入OpenFlow实例视图 |
||
|
配置禁止OpenFlow实例上送Controller的端口类型 |
缺省情况下，OpenFlow实例中所有接口都上报Controller |
使用active instance命令激活OpenFlow实例后，且Controller没有下发动作前，Table Miss表项的缺省动作为丢弃报文，配置该功能后，Table Miss表项的缺省动作修改为允许报文进行正常转发。
表1-16 配置Table Miss表项的缺省动作
|
进入OpenFlow实例视图 |
||
|
配置Table Miss表项的缺省动作 |
缺省情况下，Table Miss表项的缺省动作为丢弃报文 |
OpenFlow网络中，每个OpenFlow实例都使用唯一的Datapath ID来标识本实例。缺省情况下，OpenFlow实例的Datapath ID由实例ID和设备桥MAC组成，用户可以配置Datapath ID。
表1-17 配置OpenFlow实例的Datapath ID
|
进入OpenFlow实例视图 |
||
|
配置OpenFlow实例的Datapath ID |
缺省情况下，OpenFlow实例的Datapath ID由实例ID和设备桥MAC组成，前16位为实例ID，后48位为设备桥MAC |
此功能用于激活实例。如果实例已经与控制器建立了连接，修改OpenFlow实例的基本能力配置后，需要重新激活该OpenFlow实例，此时，OpenFlow实例会断开与所有控制器的连接，清除已经下发的流表，根据当前的配置更新OpenFlow实例的能力集，重新与控制器建立连接。
重新激活OpenFlow实例会导致流量中断，请谨慎使用。
|
进入OpenFlow实例视图 |
||
一个OpenFlow交换机可以与多个Controller建立连接，初始连接时，多个Controller的角色相同，权限相同，Controller可以通过OpenFlow消息设置本Controller的角色，各种角色的权限如表1-19所示。
|
处于该角色的Controller拥有全部权限，可以下发流表项，查询统计信息，接收设备上报的状态信息，在多个Controller中仅能有一个Controller是Master角色 |
|
|
处于该角色的Controller同样拥有全部权限，相对于Master角色，唯一不同的是可以有多个Controller处于Equal角色 |
|
|
处于该角色的Controller仅拥有部分权限，Controller to switch消息中不能下发流表项，Group表项以及Meter表项，不允许修改接口配置和设备配置，不允许执行Packet Out操作。异步消息中，默认情况下设备不会上送Flow Remove消息和Packet In消息，仅能上送接口状态变化消息，但是异步消息的上送能力可以通过Controller的设置异步消息进行修改 |
一个OpenFlow实例可以连接多个控制器，但仅允许与一个控制器建立主连接，用于控制消息的处理（下发流表项、获取数据、信息上报等），需要使用TCP/SSL保持可靠的连接。
|
进入OpenFlow实例视图 |
||
|
最多支持配置64个控制器 |
一旦OpenFlow实例与所有控制器断开连接，则OpenFlow实例必须进入连接中断模式，模式分为两种：
· Secure模式：连接断开后，交换机根据流表项转发。不主动删除控制器下发的表项，而是等待表项超时后进行删除，一旦连接建立成功，未超时的表项依然存在。
· Standalone模式：连接断开后，交换机正常转发。
如果交换机与控制器重新连接成功，则继续作为OpenFlow设备根据流表项进行转发。
|
进入OpenFlow实例视图 |
||
控制器和交换机都会发送Echo request/reply报文，用于验证连接是否正常。
连接检测定时器用于定义发送Echo request报文时间间隔，当超过三次Echo request报文发送并且没有收到Echo reply报文，则OpenFlow实例与控制器的连接断开。
OpenFlow实例与控制器重连的时间间隔定义OpenFlow实例与控制器断开连接后再次开始重新连接的时间间隔。
|
进入OpenFlow实例视图 |
||
|
配置发送Echo request报文的时间间隔 |
缺省情况下，发送Echo request报文的时间间隔为5秒 设备CPU负担较大的情况下，请配置较大的发送Echo request报文的时间间隔 |
|
|
配置OpenFlow实例与控制器重连的时间间隔 |
缺省情况下，OpenFlow实例与控制器重连的时间间隔为60秒 |
此功能仅在支持MAC-IP流表情况下，决定是否支持控制器在查询或者删除流表项时包含动态MAC地址。
|
进入OpenFlow实例视图 |
||
配置本功能后，带有双层VLAN Tag的报文通过Extensibility表之后，还是会带双层VLAN Tag。
表1-24 配置QINQ模式
|
操作 |
命令 |
说明 |
|
进入系统视图 |
system-view |
- |
|
进入OpenFlow实例视图 |
openflow instance instance-id |
- |
|
配置QINQ模式 |
qinq-network enable |
缺省情况下，没有配置QINQ模式，带有双层VLAN Tag的报文通过Extensibility表之后，只带一个内层的VLAN Tag |
配置本功能后，允许聚合成员端口出现在控制器下发的流表中。
表1-25 配置允许聚合成员端口出现在控制器下发的流表中
|
操作 |
命令 |
说明 |
|
进入系统视图 |
system-view |
- |
|
进入OpenFlow实例视图 |
openflow instance instance-id |
- |
|
允许聚合成员端口出现在控制器下发的流表中 |
permit-port-type member-port |
缺省情况下，允许聚合成员端口出现在控制器下发的流表中 |
在完成上述配置后，在任意视图下执行display命令可以显示配置后OpenFlow的运行情况，以及控制器下发的流表项。
表1-26 OpenFlow显示和维护
|
显示OpenFlow实例的详细信息 |
|
|
显示OpenFlow实例的流表信息 |
display openflow instance instance-id flow-table [ table-id ] |
|
显示OpenFlow实例的控制器信息 |
|
|
显示OpenFlow实例的Group表信息 |
|
|
显示OpenFlow实例的Meter表信息 |
|
|
显示OpenFlow实例的概要信息 |
|
|
reset openflow instance instance-id controller [ controller-id ] statistics |
· 创建OpenFlow实例1，把VLAN 4092和4094映射到OpenFlow实例中1，并激活实例。
· 使用VLAN 1作为OpenFlow实例1与控制器通信的VLAN。
· 配置OpenFlow实例1连接的控制器，用来控制器能够控制OpenFlow实例1上的流量转发。
图1-7 OpenFlow配置组网图
# 创建VLAN 4092和4094。
[Switch] vlan 4092
[Switch-vlan4092] port gigabitethernet 1/0/1
[Switch-vlan4092] quit
[Switch] vlan 4094
[Switch-vlan4094] port gigabitethernet 1/0/2
[Switch-vlan4094] quit
(2) 创建实例并映射VLAN
[Switch-of-inst-1] classification vlan 4092 mask 4093 loosen
(3) 配置控制器1的IP地址为192.168.49.49，并激活实例
[Switch-of-inst-1] controller 1 address ip 192.168.49.49
[Switch-of-inst-1] active instance
# 显示实例详细信息。
[Switch-of-inst-1] display openflow instance 1
Instance 1 information:
Configuration information:
Description : --
Active status : Active
Inactive configuration:
None
Active configuration:
Classification VLAN, loosen mode, total VLANs(2)
4092, 4094
In-band management VLAN, total VLANs(0)
Empty VLAN
Connect mode: Multiple
Mac address learning: Enabled
Flow table:
Table ID(type): 0(Extensibility), count: 0
Flow-entry max-limit: 65535
Datapath ID: 0x00010cda415e232e
Default table-miss: Drop
Forbidden port: None
Port information:
GigabitEthernet1/0/1
GigabitEthernet1/0/2
Active channel information:
Controller 1 IP address: 192.168.49.49 port: 6633
(1) VLAN匹配
配置OpenFlow实例对应的VLAN后，对VLAN的匹配存在一定的限制。
表1-27 VLAN匹配项列表
|
匹配OpenFlow实例对应VLAN内的所有报文 |
||
|
匹配无VLAN tag的报文，但是入接口的PVID必须是在OpenFlow实例对应的VLAN范围内 |
||
|
-/有值 |
||
|
-/非0x1000的值 |
||
|
匹配有VLAN tag的报文，但是该VLAN tag必须在OpenFlow实例内 |
||
|
-/有值 |
根据VLAN+MASK进行匹配，前题是VLAN+MASK必须在OpenFlow实例内 |
|
对于协议报文，相关的协议配置使能后，协议报文不会进入OpenFlow转发处理，仍然由相关协议进行处理，对于LLDP报文的使用限制请参见1.11.5 匹配LLDP报文的限制。
(3) MetaData的匹配
MetaData用于在流表间传递匹配信息，非第一级流表支持下发MetaData的匹配，如果Controller在第一级流表下发了MetaData的匹配项，交换机返回不支持。
· 单级流表的情况下，支持Clear actions。
· 多级流表的情况下，设备不支持Clear actions与其它instruction的动作配合，仅支持单独下发Clear Actions。
不支持Action List中包含多个Output，仅支持一个Output，请参见1.11.2 Action List和Action Set整合的限制。
在非最后一级流表的情况下，交换机支持Write MetaData/MetaMask的操作，否则交换机返回不支持。
非最后一级流表的情况下，交换机支持Go To Table的操作，否则交换机返回不支持。
OpenFlow Switch设备整合Action Set和Action List为Action Set，其整合原则如下。
Action List和Action Set中的Action（除Output和Group外）如果不存在冲突，则全部保留为Action Set；如果存在冲突，则以Action Set的动作替换Action List中的动作（其原因是Action List要执行在Action Set之前）。
· 当Action List和Action Set中都存在一个Output的Action时，Action List中的Output发送的报文不会对报文进行任何修改，其执行顺序最优，Action Set中的Ouput会执行Action List和Action Set中的所有修改。
· 当Action List和Action Set中仅存在一个Output的Action时，该Output为报文出接口，执行顺序按照Action Set的顺序。
· 当Action List中存在一个Output的Action，Action Set中存在一个Group的Action（Output的Action存在与否都可以）时，Action List中的Output发送的报文不会对报文进行任何修改，Group在Action Set中。
在Packet out消息中Output为Normal、Local、In port或Controller时，入接口只能是设备上的物理接口或者逻辑接口，不能是OpenFlow保留接口。
在Packet Out消息中如果同时存在报文ID和报文，交换机只会获取报文ID对应的缓存报文进行处理，忽略消息中携带的报文。
· 如果Packet Out消息中的报文没有VLAN tag，则交换机将入接口的PVID做为报文所在的VLAN进行转发处理。
· 如果入接口不是设备上的接口，且Output是设备上的接口，则使用出接口的PVID发送。
· 如果入接口不是设备上的接口，且Output是保留口Flood和All，请参见4. 出接口限制。
Packet Out中指定的Output为保留接口的Flood和All时的处理机制。
(1) 出接口为Flood的情况
· Packet Out的报文携带VLAN tag，则报文在该VLAN内广播。
· Packet Out的报文没有携带VLAN tag，但是入接口是OpenFlow Swtich上的接口，则报文在入接口的PVID内广播。
· Packet Out的报文没有携带VLAN tag，并且入接口是Controller，则报文在所有OpenFlow接口发送。
(2) 出接口为All的情况
· Packet Out的报文携带VLAN tag，则报文在该VLAN内广播。
· Packet Out的报文没有携带VLAN tag，报文都在所有OpenFlow接口发送。
对于Packet in消息中的报文：
· 上送时如果其VLAN tag与该报文入接口的PVID相同，那么该报文的VLAN tag会被删除。
· 上送时如果其VLAN tag与该报文入接口的PVID不同，那么该报文的VLAN tag不会被删除。
· 对于上送原因是No Match的报文支持缓存，缓存大小是1K个报文。
· 对于其它上送原因的报文不支持缓存，整个报文都会被上送，并且Cookie是全F。
OpenFlow网络可以通过LLDP发现拓扑，对于匹配LLDP报文存在如下限制：
· 设备上必须全局使能LLDP。
· LLDP报文匹配后上送Controller不受实例限制，只要收到LLDP报文的接口在OpenFlow实例内，并且实例内有匹配LLDP报文并上送Controller的表项，则LLDP报文就会在该实例上送Controller。
· OpenFlow实例在激活后会默认生成Table Miss表项，其动作是Drop，默认表项不能够被Controller通过Modify的动作修改，不能被Controller通过Mulipart消息查询到，仅能由Controller通过Add进行添加Table Miss的动作进行修改。
· Table Miss表项仅能通过严格匹配进行修改和删除，在非严格匹配的情况下，即使匹配项是通配也不能够操作Table Miss表项。
· Table Miss表项被删除后，会生成默认的Table Miss表项，其动作是Drop。
· 在非严格匹配的情况下，不支持通过match域为通配修改所有普通流表项。
表1-28 MAC-IP流表二层表项支持能力
|
· Go to table（在存在多级流表的情况下，即使Controller不下发流表项，交换机默认下发该动作） · Write Meta（在存在多级流表的情况下，即使Controller不下发流表项，交换机默认下发目的MAC匹配的MetaData） |
表1-29 MAC-IP流表三层表项支持能力
|
· 单播目的IP地址 |
|
|
单播目的MAC地址（如果下发，目的MAC地址需要是匹配VLAN的虚接口MAC地址） |
|
|
· 修改源MAC地址（源MAC地址会修改为目的出接口所在VLAN虚接口的MAC地址） · TTL减1 · Go to table（在多级流表存在的情况下，即使Controller不下发，Swtich上默认下发该动作） · Write Meta（在多级流表存在的情况下，即使Controller不下发，Switch上默认下发目的IP地址匹配的MetaData） |
MAC-IP流表中，Controller需要遵循如下限制下发表项，否则可能会造成转发错误。
表1-30 MAC-IP流表二层表项限制
|
目的MAC地址不是本机MAC地址 |
|
|
出接口属于匹配的VLAN |
表1-31 MAC-IP流表三层表项限制
|
· 匹配的VLAN所对应的VLAN虚接口UP · 目的MAC地址是匹配VLAN的MAC地址 · 目的IP地址不是本机IP地址 |
|
|
· 目的MAC地址不是本机MAC地址 · 如果修改源MAC地址，源MAC地址必须是目的出接口所在VLAN虚接口的MAC地址 |
三层表项能够下发的前题是匹配VLAN所对应的VLAN虚接口存在并且处于UP状态，且VLAN虚接口做为OpenFlow接口上报（包括了VLAN虚接口的链路状态状态和MAC地址），在VLAN虚接口删除时同时也会上报给Controller，需要由Controller删除对应的三层流表项，因此需要Controller保证三层表项的正确性，Switch端不对三层表项的匹配项限制进行检查。
MAC-IP流表的Table Miss支持下列Output Action：
· Go To Table：进入下一级流表；
· Drop：丢弃报文；
· Controller：报文上送Controller；
· Normal：报文正常转发。
在支持MAC-IP流表的情况下，接机支持Controller获取和删除动态MAC地址表项。
Controller可以通过指定VLAN、单播MAC或者单播MAC与VLAN来获取和删除动态MAC地址表项。
MAC-IP Table 和 Extensibility Table通过MetaData/Mask可以实现多级流表。
MAC-IP Table支持Write MetaData/Mask，Extensibility支持Match MetaData/Mask。
MetaData Mask每个Bit表示不同的含义，MetaData中对应的Bit位置位表示匹配，未置位表示通配，具体参见表1-32。
|
目的MAC |
1，置位，表示匹配到目的MAC |
|
|
0，未置位，表示未匹配到目的MAC |
||
|
源MAC |
1，置位，表示匹配到源MAC |
|
|
0，未置位，表示未匹配到源MAC |
||
|
目的IP |
1，置位，表示匹配到目的IP |
|
|
0，未置位，表示未匹配到目的IP |
||
不同款型规格的资料略有差异, 详细信息请向具体销售和400咨询。H3C保留在没有任何通知或提示的情况下对资料内容进行修改的权利!
支持
售前咨询
售后咨询
人工在线咨询
