CN102333000A

CN102333000A - 一种基于多链接透明互联网络的邻居维护方法和设备

Info

Publication number: CN102333000A
Application number: CN201110337875A
Authority: CN
Inventors: 邹文宇; 曲进; 曹辉
Original assignee: Hangzhou H3C Technologies Co Ltd
Current assignee: New H3C Information Technologies Co Ltd
Priority date: 2011-10-31
Filing date: 2011-10-31
Publication date: 2012-01-25
Anticipated expiration: 2031-10-31
Also published as: CN102333000B

Abstract

本发明提供一种基于多链接透明互联网络的邻居维护方法和设备，为路由桥(RB)的每个端口建立邻居列表，接到Hello报文时查找邻居列表，如无，则在不含本端口时将其记录并标为单向邻居关系，在包含本端口时将其记录并标为双向邻居关系；如有，则将相应表项修改为双向邻居关系。发送Hello报文时，将所有邻居端口的MAC地址和端口ID携带于Hello报文中发送出去。应用本发明方案，由于为RB的每个端口维护邻居列表，利用MAC地址和端口ID来表示邻居端口，使得RB可以准确识别邻居端口，避免识别错误和网络震荡等问题。

Description

一种基于多链接透明互联网络的邻居维护方法和设备

技术领域

本发明涉及多链接透明互联(TRILL)网络技术，特别是一种基于TRILL网络的邻居维护方法和设备。

背景技术

TRILL是因特网工程任务组(IETF，Internet Engineering Task Force)推荐的二层(L2)网络标准。目前，大型数据中心开始利用以太网光纤通道(FCoE，Fibre Channel over Ethernet)等新技术将存储传输的IP传输融合到以太网连接上。但传统的生成树协议(STP，Spanning Tree Protocol)不适合融合网络或超大型数据中心的扩展，而TRILL却非常适合，这就使得TRILL网络越来越重要。随着时间的推移，TRILL网络有代替在L2网络上被普遍使用的STP协议。

下面简单介绍一下TRILL网络。在TRILL网络中，网络设备被称为路由桥(RB)，每个RB利用Hello报文与直连的另一RB设备进行交互。另外，在同一链路中，还需要选举指定路由桥(DRB)，由DRB为每个虚拟局域网(VLAN，Virtual Local Area Network)分配报文转发端口(AVF)。这样，RB将本地网络中的数据报文通过AVF上送到TRILL网络时，先进行TRILL封装，再通过TRILL网络传递到远端目的的RB。远端目的的RB再将该数据报文解封装后通过自身的AVF端口传送给远端本地网络。

TRILL网络中的邻居维护非常重要，因为邻居关系的建立可以使RB设备清楚网络中正确的拓扑结构，并以此为基础进行DRB选举、AVF的指定等其它操作。对同一个链路而言，现有的TRILL网络中的邻居维护方法只能应对单端口的RB设备，对于多端口的RB设备则无法准确识别，容易造成识别错误、网络震荡等不良影响。

发明内容

本发明提供了一种基于多链接透明互联(TRILL)网络的邻居维护方法和设备，对同一个链路也能准确识别多端口的RB，从而避免识别错误、防止网络震荡等缺陷。

针对第一个发明目的，本发明提出的技术方案是：

一种基于多链接透明互联TRILL网络的邻居维护方法，该方法包括：

为路由桥RB的每一个端口分别建立邻居列表，所述邻居列表包括邻居端口的媒体接入控制MAC地址和端口ID；

RB从一端口接到Hello报文时：

利用该Hello报文中的源MAC地址和端口ID查找本端口的邻居列表；

如果没找到相应表项，且该Hello报文不包括本端口的MAC地址和端口ID，则将所述Hello报文中的源MAC地址和端口ID记录在本端口的邻居列表中，且标记为单向邻居关系；

如果没找到相应表项，且该Hello报文包括本端口的MAC地址和端口ID，则将所述Hello报文中的源MAC地址和端口ID记录在本端口的邻居列表中，且标记为双向邻居关系；

如果找到相应表项，且该Hello报文包括本端口的MAC地址和端口ID，则将相应表项中为单向邻居关系的标记修改为双向邻居关系；

RB从一端口发送Hello报文时：

将本端口邻居列表中所有邻居端口的MAC地址和端口ID，以及本端口的源MAC地址和端口ID携带于该Hello报文中发送出去。

针对第二个发明目的，本发明提出的技术方案是：

一种路由桥RB，该设备包括：

收发单元，用于接收和发送Hello报文；

存储单元，用于分别保存各端口的邻居列表，所述邻居列表包括邻居端口的媒体接入控制MAC地址和端口ID；

处理单元，用于RB从一端口接到Hello报文时：利用该Hello报文中的源MAC地址和端口ID查找本端口的邻居列表；如果没找到相应表项，且该Hello报文不包括本端口的MAC地址和端口ID，则将所述Hello报文中的源MAC地址和端口ID记录在本端口的邻居列表中，且标记为单向邻居关系；如果没找到相应表项，且该Hello报文包括本端口的MAC地址和端口ID，则将所述Hello报文中的源MAC地址和端口ID记录在本端口的邻居列表中，且标记为双向邻居关系；如果找到相应表项，且该Hello报文包括本端口的MAC地址和端口ID，则将相应表项中为单向邻居关系的标记修改为双向邻居关系；还用于RB从一端口发送Hello报文时：将本端口邻居列表中所有邻居端口的MAC地址和端口ID，以及本端口的源MAC地址和端口ID携带于该Hello报文中发送出去。

综上，由于本发明为RB的每个端口单独维护邻居列表，用MAC地址+端口ID唯一标识端口，并利用MAC地址和端口ID来表示邻居端口，使得RB可以准确识别邻居端口，避免识别错误和网络震荡等问题。

附图说明

图1是本发明实施例中的组网示意图。

图2是本发明实施例中RB接收Hello报文时的流程图。

图3是本发明实施例中RB发送Hello报文时的流程图。

图4是本发明实施例中Neighbor TLV格式的示意图。

图5是本发明实施例Neighbor TLV中Neighbor RECORDS的格式示意图。

图6是本发明实施例中RB的内部结构示意图。

具体实施方式

图1是本实施例的一个简单的多链接透明互联(TRILL)网络的组网图，包括若干路由桥(RB)，并用直线表示这些RB之间的连接关系。在图中，RB可能有多个端口(未画出)，每个端口利用MAC地址+端口ID来唯一标识。其中，所述的MAC地址就是该端口所在的RB的MAC地址，而端口ID就是该端口自身的ID号。

本实施例为RB的每一个端口单独建立邻居列表，用于记录该端口的邻居端口的相关信息，至少包括邻居端口的MAC地址和端口ID。实际应用中，邻居列表还可以包括邻居端口的其他信息，比如邻居关系标记、虚拟局域网(VLAN)、指定路由桥(DRB)优先级等信息等。

组网之后，对于同一个链路来说，各个RB按照协议规定发送Hello报文，并接收来自其它RB的Hello报文。各RB在发送和接收Hello报文的过程中获悉并维护邻居关系，从而明确整个网络的拓扑结构，为后续选举DBR、分配报文转发端口(AVF)等做好准备。

为了更好地描述本实施例方案，下面利用RB接收Hello报文和发送Hello报文两部分分别进行说明。

图2是本实施例接收Hello报文的流程图，如图2所示，该方法包括：

步骤201：RB从一端口接到Hello报文时，利用该Hello报文中的源MAC地址和端口ID查找本端口的邻居列表，如果没找到相应表项，则执行步骤202；如果找到相应表项，则执行步骤203。

这里所指Hello报文中的源MAC地址是发送该Hello报文的RB的MAC地址，端口ID是发送该Hello报文的RB中的某个端口的ID号。这里的源MAC地址和端口ID可以按照现有协议的规定携带于Hello报文，比如：Hello报文VLAN-Flags-sub-TLV中将携带发送该报文的端口ID。

由于邻居列表是记录邻居端口的，如果没有从列表中查找到，则表示发送该Hello报文的端口是一个新邻居，将利用以下的步骤202记录在邻居列表中。如果从列表中查找到，则利用以下步骤203操作。

实际应用中，RB接到Hello报文时，还可以将Hello报文中的源MAC地址和端口ID与自身的比较，如果相同，则表示该Hello报文是自身之前发出的Hello报文，无需处理，丢弃即可。

步骤202：如果该Hello报文不包括本端口的MAC地址和端口ID，则将该Hello报文中的源MAC地址和端口ID记录在本端口的邻居列表中，且标记为单向邻居关系；如果该Hello报文包括本端口的MAC地址和端口ID，则将该Hello报文中的源MAC地址和端口ID记录在本端口的邻居列表中，且标记为双向邻居关系；

这里所述的“本端口”就是步骤201中接收Hello报文的端口，其对应的邻居列表如表一所示：

序号	MAC地址	端口ID	邻居关系标记	其它
					...	...	...	...	...

表一

其中，“MAC地址”是邻居端口的MAC地址，应当填写Hello报文中的源MAC地址；“端口ID”是邻居端口的ID，应当填写Hello报文VLAN-Flags-sub-TLV中的端口ID；“邻居关系标记”表示本端口和邻居端口的相互关系，可以是单向邻居关系，也可以是双向邻居关系。“单向邻居关系”表示本端口已明确对端是邻居，但对端还没有明确本端口是其邻居。“双向邻居关系”表示本端口和对端都已经明确对方是邻居。

实际应用中，Hello报文的邻居类型长度值(Neighbor TLV)可用于携带邻居端口的MAC地址和端口ID。当然，也可以利用Hello报文的其他字段来携带，Neighbor TLV仅是一较佳实施例，并不作为携带邻居端口MAC地址和端口ID字段的限定。

在本步骤中如果用Neighbor TLV携带邻居端口的MAC地址和端口ID，“Neighbor TLV”中记录的是发送Hello报文的端口(对端)已经拥有的邻居，如果其中不包括本端口的MAC地址和端口ID，说明本端口没有被对端确认为邻居，而本端口此次可以确认对端是邻居，因此应当填写“单向邻居关系”。相应的，如果Hello报文的Neighbor TLV包括本端口的MAC地址和端口ID，说明本端口已经被对端确认为邻居，加之本端口此次也确认对端是邻居，因此应当填写“双向邻居关系”。

步骤203：如果该Hello报文包括本端口的MAC地址和端口ID，则将相应表项中为单向邻居关系的标记修改为双向邻居关系。

这里，如果用Neighbor TLV携带邻居端口的MAC地址和端口ID，假设Neighbor TLV中包含本端口的MAC地址和端口ID，表示本端口已经被对端明确为邻居。由于本端口接收到对端发送的Hello报文，说明对端也是本端口的邻居，因此本次可以明确本端口和对端为双向邻居关系。不管本端口邻居列表的相应表项原来为“单向邻居关系”还是“双向邻居关系”，本次应该确保其为单向邻居关系。即：如果原来为“双向邻居关系”，本次将其修改为“单向邻居关系”。当然，如果原来为“单向邻居关系”，此次就可处理标记。

以上是RB接收到Hello报文时对邻居关系进行维护的实施例，下面对RB发送Hello报文进行描述。

图3是本实施例发送Hello报文的流程图，如图3所示，该方法包括：

步骤301：RB从一端口发送Hello报文时，将本端口邻居列表中所有邻居端口的MAC地址和端口ID，以及本端口的源MAC地址和端口ID携带于Hello报文中。

实际应用中可以用Neighbor TLV携带邻居端口的MAC地址和端口ID，这里所述的Neighbor TLV就是步骤203中所述Neighbor TLV，其格式如图4所示。其中，“Neighbor RECORDS”表示邻居记录，表示若干个邻居端口的信息，其格式如图5所示。

步骤302：RB发送该Hello报文。

以上是RB接收和发送Hello报文两个部分的描述。

本实施例利用MAC地址+端口ID标识RB中的端口，可以准确地对不同或同一个RB的多个端口进行识别。

比如：某个RB有端口A和端口B，其MAC地址为MAC1，而端口A的端口ID为ID-A，端口B的ID为ID-B。应用本实施例方法，当端口A接收到端口B发送的Hello报文，端口A从该Hello报文的源MAC地址和端口ID知道该报文并非自身发送的报文，而是同一RB的另一端口发送的Hello报文，可将其作为邻居记录在本端口对应的邻居列表中。相反，当端口B接收到端口A发送的Hello报文，也可以准确地识别，从而可以避免现有技术在同一RB的多个端口之间无法建立正常的邻居关系的缺陷。

再比如：RB1有端口A和端口B，其MAC地址为MAC1，端口ID分别为ID-A和ID-B。RB2有端口C和端口D，其MAC地址为MAC2，端口ID分别为ID-C和ID-D。应用上述实施例方法，当RB2的端口C分别接收到RB1端口A和端口B的Hello报文，可以通过Hello报文的源MAC地址和端口ID知道这是两个不同的邻居，并将其分别记录在本端口的邻居列表中。这样，即使RB1的端口A和端口B有不同的配置，RB2也不会认为是同一个邻居的配置变化，相应的，也不会触发DRB重新选举、AVF重新指定等处理，从而避免网络的震荡。

再比如：RB1有端口A和端口B，MAC地址为MAC1，端口ID分别为ID-A和ID-B。RB2有端口C和端口D，MAC地址为MAC2，端口地址分别为ID-C和ID-D。应用上述实施例方法，当RB2的端口C接收到RB1端口A发来的Hello报文，可根据Hello报文的源MAC地址和端口ID明确RB1的端口A是邻居。同时，如果该Hello报文的Neighbor TLV还包含RB2的端口C的信息，则可以为RB1的端口A和RB2的端口C建立双向邻居关系。这样，就可以避免现有技术因无法识别同一RB的多端口无法建立正确的双向邻居关系的缺陷，使得后续DRB正确地分配AVF和路由计算等。

针对上述方法，本发明还提供一种路由桥(RB)，其内部结构如图6所示，包括：

收发单元601，用于接收和发送Hello报文。

存储单元602，用于分别保存各端口的邻居列表，所述邻居列表包括邻居端口的MAC地址和端口ID。

处理单元603，用于RB从一端口接到Hello报文时：利用该Hello报文中的源MAC地址和端口ID查找本端口的邻居列表；如果没找到相应表项，且该Hello报文不包括本端口的MAC地址和端口ID，则将所述Hello报文中的源MAC地址和端口ID记录在本端口的邻居列表中，且标记为单向邻居关系；如果没找到相应表项，且该Hello报文包括本端口的MAC地址和端口ID，则将所述Hello报文中的源MAC地址和端口ID记录在本端口的邻居列表中，且标记为双向邻居关系；如果找到相应表项，且该Hello报文包括本端口的MAC地址和端口ID，则将相应表项中为单向邻居关系的标记修改为双向邻居关系；还用于RB从一端口发送Hello报文时：将本端口邻居列表中所有邻居端口的MAC地址和端口ID，以及本端口的源MAC地址和端口ID携带于该Hello报文中发送出去。

实际应用中，可以将邻居端口的MAC地址和端口ID携带于Hello报文的Neighbor TLV。也就是说，RB接到Hello报文时，处理单元603中所述本端口的MAC地址和端口ID是携带于接到的Hello报文的邻居类型长度值NeighborTLV中；RB从一端口发送Hello报文时，处理单元603中所述本端口的源MAC地址和端口ID是携带于要发送的Hello报文中。

当然，实际应用中，处理单元603还可以进一步用于：在RB从一端口接到Hello报文时，如果Hello报文中的源MAC地址和端口ID与本端口的一样，则丢弃该Hello报文。

以上是本实施例中RB的内部结构示意图。在实际应用中，RB也有相应的物理部件对应上述的逻辑结构。比如：物理上的一个以上的端口对应收发单元601，用于接收或发送Hello报文；存储部件对应上述的存储单元602，用于存储各端口的邻居列表以及使得RB运行的一系列代码；中央处理单元(CPU)，用于执行代码，以完成上述处理单元603可实现的功能。

应用本发明方案，由于为RB的每个端口单独维护邻居列表，用MAC地址+端口ID来唯一标识端口，并且利用MAC地址和端口ID来表示邻居端口，使得RB可以在接收到Hello报文时能够准确识别邻居端口，避免识别错误和网络震荡等问题。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims

1.一种基于多链接透明互联TRILL网络的邻居维护方法，其特征在于，该方法包括：

RB从一端口接到Hello报文时：

RB从一端口发送Hello报文时：

2.根据权利要求1所述的方法，其特征在于，

RB从一端口接到Hello报文时，所述本端口的MAC地址和端口ID是携带于接到的Hello报文的邻居类型长度值Neighbor TLV中；

RB从一端口发送Hello报文时，所述本端口的源MAC地址和端口ID是携带于要发送的Hello报文中。

3.根据权利要求1或2所述的方法，其特征在于，所述RB从一端口接到Hello报文时，该方法进一步包括：

如果Hello报文中的源MAC地址和端口ID与本端口的一样，则丢弃该Hello报文。

4.一种路由桥RB，其特征在于，该设备包括：

收发单元，用于接收和发送Hello报文；

处理单元，用于RB从一端口接到Hello报文时：利用该Hello报文中的源MAC地址和端口ID查找本端口的邻居列表；如果没找到相应表项，且该Hello报文不包括本端口的MAC地址和端口ID，则将所述Hello报文中的源MAC地址和端口ID记录在本端口的邻居列表中，且标记为单向邻居关系；如果没找到相应表项，且该Hello报文包括本端口的MAC地址和端口ID，则将所述Hello报文中的源MAC地址和端口ID记录在本端口的邻居列表中，且标记为双向邻居关系；如果找到相应表项，且该Hello报文包括本端口的MAC地址和端口ID，则将相应表项中为单向邻居关系的标记修改为双向邻居关系；还用于RB从一端口发送Hello报文时：将本端口邻居列表中所有邻居端口的MAC地址和端口ID，以及本端口的源MAC地址和端口ID携带于该Hello报文发送出去。

5.根据权利要求4所述的路由桥，其特征在于，

RB接到Hello报文时，所述本端口的MAC地址和端口ID是携带于接到的Hello报文的邻居类型长度值Neighbor TLV中；

6.根据权利要求4或5所述的路由桥，其特征在于，

所述处理单元进一步用于：RB从一端口接到Hello报文时，如果Hello报文中的源MAC地址和端口ID与本端口的一样，则丢弃该Hello报文。