云数据中心网络与SDN：1.8.2　控制与转发过程分析

1.8.2　控制与转发过程分析

现考虑以下拓扑：3台Leaf的SID分别为100/200/300，4台Spine的SID分别为10/ 20/30/40，现有两台主机MAC A和MAC B分别接在S 100和S 300下。建立好拓扑之后，ISIS发现拓扑，DRAP分配好SID和Ftag，ISIS通过SPF算法计算出SID转发表（Fabric-Path Routing Table），通过Root选举形成BUM转发表（Multidestination Tree），此时系统开始进入转发状态。

（1）对ARP Request的处理流程

图1-20给出了FabricPath对ARP Request的处理流程。

图1-20　FabricPath对ARP Request的处理流程

1）VLAN 10（图中未标出）中的A广播ARP Request，请求B的MAC地址。

2）S 100学习<VLAN 10，MAC A>与e1/13的对应关系，记录在MAC Table中。

3）S 100发现这是一个广播包，通过哈希选择了Ftag=1的子拓扑，并在该子拓扑形成的BUM转发树上进行转发。查Ftag转发表可知S 100上对应于该树的端口只有PO10，于是S 100封装外层包头，目的MAC为全F，使用SID.SSID.LID=100.0.12来生成源MAC地址（e1/13在S 100上的LID为12），标记Ftag，并将数据包从PO10发给S 10。

4）S 10从PO 100收到该数据包，发现它是一个广播包，其Ftag=1，查对应的BUM转发表可知本地对应于该树的端口有PO100、PO200和PO300，S 10将数据包的TTL减1，然后从PO 200和PO 300转发数据包。

5）S 300从PO 10收到数据包，发现它是一个广播包，其Ftag=1，查对应的BUM转发表可知本地对应于该树的端口有PO 10、PO 20、PO 30和PO 40，S 300将数据包的TTL减1，然后从PO 20、PO 30和PO 40转发数据包。

6）S 300发现本地有位于VLAN 10的CE端口，去掉外层包头后在这些CE端口上进行泛洪，于是B就收到了A的ARP请求。

这里需要注意的一点是，该ARP广播包并不会触发S 300上的MAC地址学习，因为FabricPath采用的是“基于会话”的MAC地址学习机制，只有内层目的MAC是已知的单播地址，才会对源MAC地址进行学习，保证学习到的MAC地址在接下来的一段时间内都会是活跃的。而在传统的MAC自学习机制中，凡是没有看见过的源MAC地址交换机都会进行学习，这意味着所有非静默主机的MAC地址会在所有的交换机上存在（假设均未老化），无论交换机是否存在于真实的MAC转发路径上。因此，FabricPath可以有效地减少Leaf交换机上无用的MAC地址表项。而对于Spine（如S 10）来说，它们永远看不到内层的MAC地址，其转发逻辑就是根据外层包头解析出SID/Ftag，然后查找ISIS已经计算好的SID转发表/BUM转发表进行转发，也就是说，Spine是不需要对任何endpoint的MAC地址进行学习的。

（2）对ARP Reply的处理流程

图1-21给出了Fabric Path对ARP Reply的处理流程。

1）B向A单播ARP Reply。

2）S 300学习<VLAN 10，MAC B>与e2/29的对应关系，记录在MAC Table中，S 300还发现这是个目的未知的单播包（由于之前S 300并没有学习A的MAC地址）。

3）S 200通过哈希选择了Ftag=1的子拓扑，并在该子拓扑形成的BUM转发树上进行转发。查Ftag转发表可知S 100上对应于该树的端口只有PO10、PO20、PO30和PO40，于是S 100封装外层包头，目的MAC置为周知的FabricPath Unknown Unicast地址01:0F:FF:C1:01:C0，使用SID.SSID.LID=300.0.64来生成源MAC地址（e2/29在S 200上的LID为64），标记Ftag，并将数据包从PO 10、PO 20、PO 30和PO 40发出。

4）S 10从PO 300收到数据包，发现它是目的未知的单播包，其Ftag=1，查对应的BUM转发表可知本地对应于该树的端口有PO 100、PO 200和PO 300，S 10将数据包的TTL减1，然后从PO 100和PO 200转发数据包。

5）S 100从PO 10收到数据包，发现它是未知的单播包，其Ftag=1，查对应的BUM转发表可知本地对应于该树的端口只有PO 10，说明S 100已经是Ftag=1的子拓扑的Leaf节点了。

6）由于本地有位于VLAN 10的CE端口，因此S 100去掉外层包头，查找MAC Table发现目的MAC地址是已知的单播地址MAC A，于是对源MAC地址进行学习，并通过e1/13进行转发。

图1-21　FabricPath对ARP Reply的处理流程

这里需要注意的是，S 100在学习远端的MAC B时，使用的是<VLAN，MAC>：SID.SSID.LID这种数据结构，即<VLAN 10，MAC B>:300.0.64，后续A向B发出的单播包外层的目的MAC地址就会通过300.0.64来生成。

（3）已知会话的单播处理流程

接下来，A开始向B发送单播的数据包，如图1-22所示。

1）A开始向B发送单播的数据包。

2）S 100查找MAC Table，解析出MAC B对应的远端地址300.0.64。

3）S 100查找SID转发表，得知SID=300的交换机可以通过PO 10、PO 20、PO 30和PO 40进行转发，通过哈希后选择了PO 30转发该数据包，通过300.0.64生成外层目的MAC，通过100.0.12生成外层源MAC，标记Ftag=1。

4）S 30从PO 100收到数据包，发现这是个目的地已知的单播包，通过外层目的MAC解析出SID，查找SID转发表并从PO 300转发数据包。

5）S 300通过PO 30收到数据包，发现这是个目的地已知的单播包，通过外层目的MAC解析出SID，发现目的地即在本地，再通过外层目的MAC解析出LID=64，然后去掉外层包头转发给B，同时对源MAC地址进行学习。

图1-22　FabricPath对已建立会话的流量的处理流程

这里要注意的是，在S 300上既可以通过LID关联到e2/29进行转发，也可以通过查找MAC Table直接获得B所在的端口e2/29进行转发。另外有些资料中也提到，FabricPath也在考虑通过集成MP-BGP来增强Overlay的控制平面，这里就不进行详细的介绍了。

上述就是FabricPath典型的转发流程。关于“基于会话”的MAC地址学习，图1-23更为清晰地给出了FabricPath“基于会话”的MAC地址学习的工作机制。

图1-23　FabricPath“基于会话”的MAC地址学习的工作机制