2.2 MBGP测试方法
作为BGP4对MPLS VPN应用的扩展,根据RFC2858定义的BGP多协议扩展标准,BGP协议添加了支持发送VPNv4路由、在Update报文中携带标签、RT和其他扩展团体属性的能力(由于本文只针对MPLS测试方法,对BGP在IPv6和组播方面的扩展这里不作讨论)。因此,测试MBGP时,除了可以使用BGP4基本测试方法对基本配置、路由发布、路由选路、BGP通用属性、路由策略、路由反射等进行测试外,还应当对下面MBGP几个特有方面进行测试:
2.2.1 能力协商
作为BGP4的一个扩展,在Open报文中将携带标示本地BGP所支持能力的参数,便于在对等体之间建立邻居前协商双方都支持的能力交集,建立对应能力的对等体关系。对能力协商的测试包括在两台PE间配置相应BGP能力后,他们之间的MBGP邻居是否能够正确协商建立对等体。我们不但需要测试普通PE间的I-MBGP邻居,还需要测试ASBR之间和跨域方式种使用的E-MBGP邻居关系,分别使用物理接口和LOOPBACK接口建立邻居关系等各种情况。另外,我们还应该验证在设备收到Open报文种携带了本地不支持和不能识别的能力参数时其处理是否正确。根据实现,我司设备在收到无法识别的能力参数后,应当主动发送一个Notification报文,并断开TCP连接。
2.2.2 RD与RT
RD(Route-Distinguisher)用于标示PE设备上不同VPN实例,其主要作用也就是实现VPN实例之间地址复用,它与IP地址一起构成了12byte的VPNv4地址空间,RD与路由一起被携带在BGP Update报文中发布给对端。一方面我们需要验证RD功能是否实现,PE设备是否能够根据不同RD实现IP地址复用,携带不同RD的相同IP路由在PE上应该对应不同VPN实例路由。同时,RD不具有选路能力,不应影响路由接收和优选,对于同一VPN携带不同RD的相同IP路由,PE设备不应根据RD优选路由或当两条不同路由进行处理。由于RD具有两种赋值形式,在测试中也需要考虑到使用不同结构RD路由的传递,特别是对临界值、非常规值(如AS号为65535,IP地址为广播、组播地址等)的测试。
RT(Route-Target)是VPNv4路由携带的一个重要属性,它决定VPN路由的收发和过滤,PE依靠RT属性区分不同VPN之间路由,也成为MBGP测试中的一个重点。
利用RT属性对VPN路由进行过滤。RT与RD属性具有相同数据格式,但属性分为Import和Export两种。Export属性跟随对应VPN路由通过MBGP发送到对端,而Import属性则用于与收到的VPNv4路由中携带的RT Export属性进行比较过滤路由。对RT过滤路由功能可以从匹配、不匹配等多个状态进行测试。
当PE设备上VPN实例中配置的RT export属性发生变化时,该PE发布对应这个VPN路由中携带的RT属性也应该同步变化,PE应该刷新这个VPN实例对应的VPNv4路由,更新其RT属性。同样,当VPN实例对应RT import属性变化时,被改变PE设备应该主动发出BGP refresh报文刷新VPN路由,用新配置的RT属性对路由进行过滤。
与RD不同,我们可以为一个VPN实例配置多个RT属性,并且RT属性被放置在BGP Update报文中的扩展团体属性中发布,格式与普通团体属性类似。那么当路由同时携带多个扩展团体属性和RT属性时,BGP协议、路由策略能否正确分析、处理这些不同属性,不会产生相互影响。
2.2.3 路由转发
作为一个路由协议,最基本最重要的功能就是必须保证路由传递正确,避免产生环路。作为BGP4的一个扩展,MBGP继承了其几乎所有特性,在路由测试方法上也与BGP大致相同,主要从选路、路由策略、环路检测、BGP各种属性等多个方面进行验证,这里也不作详细介绍。较BGP不同的一点是:PE设备在收到VPNv4路由后,只有当接收端PE与路由发送端PE之间的LSP隧道建立成功后,这些路由才变得有效,这也为路由优选增加了一条规则。因此,我们可以利用这点,将路由发布、更新与PE间LSP反复切换、LDP邻居关系改变、MPLS域内部路由变化等其他测试手段相结合,验证由于MPLS域引起的振荡是否会影响VPNv4路由的传递和学习。
由于RD的存在实现了IP地址空间重叠,多个VPN之间可以使用相同的IP地址。那么,MBGP在转发、处理VPNv4IP路由时能够根据RD、RT属性区分不同VPN空间路由。在测试中我们需要有意为不同VPN实例配置重叠的IP地址空间,验证MBGP能否正确处理这些路由。
2.2.4 标签分配
作为BGP协议另一个重要的功能扩展,MBGP具有为路由分配标签能力,路由可以是IPv4路由、VPNv4路由和IPv6路由。测试MBGP为这三种路由分配标签的功能需要搭建不同的测试环境,但其测试方法基本相同,都是验证MBGP能否为各种路由分配标签,为不同Site的VPNv4路由和IPv6路由以及不同IPv4路由分配的标签应该各不相同。并且应该考虑同一PE设备同时为这几种路由分配标签,并且存在路由振荡的情况,MBGP标签是否分配正确,被释放的标签能否及时收回等。
然而,MBGP应用并不是孤立的,它需要跟LDP等其他协议一起实现MPLS各种应用。所以,MBGP大部分功能测试还需要借助应用、组网进行。所以,MBGP相同更多方面的测试方法将在后面章节中继续讨论。
2.3 路由协议多实例测试方法
路由协议多实例用于PE设备与CE设备之间交换VPN路由。各个VPN路由在PE设备之间以VPNv4路由形式利用MBGP交换。到达PE设备后,需要通过支持多实例的路由协议向CE设备发布这些路由。目前实现多实例的路由协议包括:静态路由多实例、RIP多实例、OSPF多实例、ISIS多实例以及BGP多实例。需要说明的是:多实例只对PE设备而言,在CE设备没有多实例概念,因此对路由协议多实例的大部分测试和操作都在PE设备上进行,同时路由协议多实例不存在网络拓扑概念(OSPF除外,MBGP对支持OSPF路由传递进行了一些扩展,使多个Site的OSPF区域可以连接为一个整体),不必太多关注网络拓扑变化对路由协议的影响。所以,在测试路由协议多实例时,主要还是关注PE和CE之间邻居关系建立、路由交互,各个路由协议与MBGP互通、路由相互引入等方面。下面分别就各个协议具体一些测试方法进行讨论。
正如上面所说,对路由协议多实例的测试重点不再放在通过构建复杂网络结构,验证路由发布、计算和防止路由环路,因为我们只需要关注PE和CE两台设备之间的路由交换。与普通路由协议不同之处在于,多实例路由协议与VPN实例相关,一台PE设备上通常会存在多个VPN实例,一个VPN实例也会绑定多个接口,甚至同一个物理接口不同子接口下绑定的VPN实例也会不同。这种多类型接口、多VPN实例与多实例路由协议相结合成为我们测试多实例路由协议方法之一。相同VPN不同Site使用不同路由协议、他们之间路由相互引入、相同路由协议使用不用进程或不同VPN实例使用相同路由协议等都可以成为我们的测试手段。同一VPN实例可能会使用多种路由协议转发路由,这就存在各种路由协议间路由相互引入、发布的问题。同一条路由被多次反复引入后就会产生重复路由、路由振荡的问题。
当然,某些特殊的网络拓扑结构同样会引起路由环路:比如一台CE同时与多台不同PE连接使用相同或不同的路由协议发布路由,PE间又存在MBGP对等体关系。又如一台CE与PE间存在多条链路相连,而不同链路间使用不同路由协议,或被绑定到不同VPN实例都有可能引起路由环路、路由选路错误和路由不能正确刷新等问题。前段时间德国IZB项目中出现多次MPLS网上问题就是由于用户使用了CE连接到不同PE这种“双归属”网络结构,导致某些VPN路由无法及时刷新、路由产生环路甚至路由器定时重启等很多严重问题。
另一个方面,由于VPN实例支持重叠的IP地址空间也可能导致设备之间邻居关系建立不正常。相同路由协议多个VPN实例通过同一IP地址建立邻居,交换路由。同时在MCE组网模式下,CE设备上也配置为多实例路由协议,PE、CE相互将对端看作自己CE设备,此时邻居建立、路由交换又会有所不同。
对于RIP路由多实例,由于设备之间不需要建立邻居关系,在测试中只需要考虑与其他路由协议之间相互引入路由、RIP协议不同版本之间相同版本不同目的IP之间是否能够正常收发路由、带验证时路由收发等基本方面。
2.3.1 OSPF多实例
这里之所以将OSPF多实例单独进行讨论,是因为与其他路由协议不同,MBGP在PE设备直接传递OSPF多实例路由时为其作了一些扩展。在OSPF路由被引入到MBGP协议中发布给对端PE设备时,Update报文中不但携带了路由、RD、RT等通常VPNv4路由信息,还携带了关于原来OSPF路由中的Domain ID等扩展信息,使接收端PE设备再次将这些VPNv4路由重新引入到OSPF进程中时,能够根据这些信息将其转换为TYPE 3 LSA,而非通常的OSPF ASE路由。这样对于VPN网络而言,各个VPN Site网络被连接为一个整体,连接各个VPN Site的服务商MPLS网络成为一个大的骨干区,使OSPF多实例在PE上也有了网络拓扑结构的概念。同时,为了防止由这种网络结构带来诸如路由环路的问题,OSPF多实例自身也进行了相应扩展,包括引入了Domain ID、VPN Tag和Sham Link等概念,这都是有别于普通OSPF协议和其他多实例路由协议的地方,也是我们重点测试OSPF多实例协议的几个方面。针对VPN Tag属性我们多采用“双归属”网络结构,在不同PE上将MBGP路由与OSPF实例路由相互引入,同时对应不同VPN Site之间或不同VPN实例采用不同或相同Tag值,验证PE能否正确处理这些VPN路由。
由于OSPF多实例可以借助MBGP形成这样一个特殊的网络结构,在测试中我们通常会使用“双归属”网络结构,及同一CE设备和同一VPN Site不同CE设备同时连接到多个PE上,在PE上配置Sham Link以及相同或不同Domain ID,验证路由计算是否正确,是否会在PE设备上形成路由环路等。LSA类型、对VPN Tag处理、VPN路由选路和VPN路由环路是在测试OSPF多实例时主要关注的几个方面。在测试中,区域划分策略对测试结构有很大影响,由于我们默认MPLS域为骨干区,那么我们在VPN网络中部署骨干区时,如果没有将骨干区与PE设备相连同样会由于骨干区不连续而引起路由计算错误。所以,我们可以PE、CE之间的链路设置为非骨干区、骨干区和虚连接区域等几种不同情况分别进行测试。
2.4 其他MPLS应用相关模块测试方法
除了上面提到的路由协议多实例以外,还有两个比较小的模块容易被大家忽略:ARP多实例和NAT多实例。他们都不能算作一个完整的协议,只是为实现MPLS各种应用对原有功能进行了一些扩展。
ARP多实例其实是ARP表为了支持IP地址空间重叠而进行了相应扩展,为ARP各个表项添加了实例一项标识。因此测试时需要重点考虑重复地址空间时ARP表项建立情况,对应接口VPN绑定改变后,ARP表能否及时更新等。此外,当存在子接口时,不同子接口绑定到不同VPN实例时,很容易出现ARP表混乱的现象。反复变化接口和子接口绑定的VPN实例,可能会由于ARP表没有及时更新而引起转发问题。当然,频繁ShutDown/Undo ShutDown接口、热插拔网线和接口板等可靠性测试操作也是常用的测试手段。
NAT多实例是为解决VPN用户访问公网资源而提出的。其实质就是在选择NAT被转换IP时将VPN实例作为ACL一个限制条件,也就是ACL支持对指定VPN实例IP地址空间地址进行选择。其测试方法与普通NAT类似,在配置多个VPN实例并存在地址空间重叠的PE设备上对特定VPN实例地址进行NAT转换,不同VPN地址使用不同公网转换地址等。
2.5 LSPM模块测试方法
LSPM(Label Switch Path Management)不是一个独立模块,并不与某个协议对应。相比其他模块,它运行在“后台”,只有简单的几条配置和显示命令。但是,它却控制着整个MPLS标签交换操作,维护MPLS各种表项,管理隧道映射关系和所有类型隧道。LSPM可以说是MPLS控制层面与转发层面之间的一个接口,其功能主要包括:标签管理和静态LSP管理、MPLS表项维护和隧道管理三大基本功能。下面分别对这三个方面进行讨论。
2.5.1 静态LSP和标签管理
LSP可以利用各种协议动态产生,也可以进行手动配置。LSPM为我们提供了创建、管理静态LSP的功能。我们可以通过配置各种静态LSP,LSR在LSP中所处位置不同(Ingress、Egress或中间路由器)分别进行测试。根据实现,在Ingress实现FEC与LSP绑定,此时,LSP出接口需要与路由下一跳的出接口保持一致,而在中间路由器和Egress路由器上则不再判断LSP出入接口是否与路由保持一致,而仅仅通过手动分配的标签是否正确,出入接口状态是否正确来决定LSP的有效性。所以在测试中,我们可以采用标签会聚、多出口LSP备份并通过改变接口状态在配置的多条静态LSP间相互切换等方法验证对静态路由管理。当一个FEC被绑定到一条静态LSP的同时,LDP又为其分配了一条动态LSP,此时静态LSP具有优先有效性。
同样的,我们可以选择各种类型的接口作为静态LSP出、入接口,并且和动态LSP相互作为备份,考虑在比较复杂的网络振荡环境下LSP是否能够正确建立,MPLS是否正确转发。
MPLS报文是否成功转发是验证静态LSP是否配置成功的唯一有效方法,但是由于缺乏上层协议维护,LSP中任何一台路由器上静态LSP配置或工作发送错误都将导致整个LSP无法正常转发,这为问题定位带来一定困难。
为了更好、更可靠地管理标签,我司设备为静态LSP单独分配了一个标签空间(通常为16-1023),不与动态LSP、MBGP使用的标签进行复用。
2.5.2 MPLS相关表项维护
MPLS主要表项包括:MPLS LSP、MPLS FTN(V5版本修改为FIB)、MPLS ILM和MPLS NHLFE等。这些表中记录了FEC与MPLS标签绑定关系、MPLS标签出入接口信息、MPLS标签操作类型、多个MPLS标签对应关系等关系MPLS转发层面的重要信息。路由变化、LDP邻居关系变化、接口状态变化、全局和接口下MPLS相关配置变化等很多因素都会引起设备重新创建、刷新、删除这些表项,长时间、反复对这些表项进行操作,特别是在短时间内多次删除重建同一表项很可能会引起表项内容错误、无法访问等问题。因此,这些表项信息完整性和健壮性是我们测试的重点。很多MPLS转发问题都是由于这些表项本身错误或表项之间映射关系错误导致的。在测试MPLS全过程中都需要经常查看这些表项,特别是在路由经常发生振荡、接口状态不稳定时,MPLS表项是否能够正确刷新,及时与路由等各种状态同步是我们测试中的重点。
2.5.3 隧道管理
这里的隧道是指能够为各种MPLS应用服务,特别地能够为连接PE所使用的通道,主要包括LSP、GRE和MPLS TE Tunnel等。每一条隧道在创建和状态改变后都会通知LSPM模块,LSPM会根据LSP绑定FEC信息和Tunnel源、目的等信息自动将其与某个PE对应的VPN隧道相关联,实现PE之间VPN报文正常转发。
对LSPM隧道管理方面的测试主要需要考虑多条隧道备份、相互切换
2.6 异常、性能测试
提到异常、攻击测试其本身就是一个很大的测试范畴,包括异常协议报文攻击、攻击报文攻击和临界状态操作测试等等。对设备进行异常、攻击测试通常会使用各种测试仪器和测试工具,通过构造非正常协议、状态报文和状态攻击报文持续发送给设备,验证设备是否会产生异常。异常攻击测试的测试过程繁琐,测试方法也自成体系,其测试理论也在不断发展,本文就不对其进行详细讨论。这里只是就我们在测试中容易疏忽,而设备也容易出问题的两个方面进行讨论:
2.6.1 动态显示各种表项
这是对设备内存保护健壮性的测试。在设备对表项进行操作,特别是多进程同时访问同一个表项时,如果对内存保护不够,很容易出现内存访问错误,其后果也是致命的。但是,对这种问题的测试方法相对比较简单,向设备加入大量路由和删除这些路由的同时,反复显示路由表、LSP表、FTN、ILM等各种表项。特别是在进行删除表项操作时查看这些表,很可能会由于保护不够,使指针指向了一块已经释放的内存块引起访问错误。
2.6.2 携带超长属性值的协议报文
前面提到过,MBGP在传递VPNv4路由时会携带RT等属性,也会携带其他扩展团体属性,根据我司设备实现,对Update报文中所携带团体属性的个数(长度)是有所限制的,对于其他BGP属性也有类似规格。但是友商设备就未必有相同的规格,我司设备如何处理这些携带超长属性的报文是值得讨论的,但是设备不应该因此产生异常。记得一个网上问题就是由于我司设备无法识别团体属性长度大于32的Update报文,导致BGP邻居反复振荡,后来我们将规格修改到64以后,设备工作正常。以后是否还会遇到类似的问题,还需要我们仔细测试发现。
2.6.3 性能测试
性能测试包括对设备支持协议各种规格、配置、转发性能方面的验证。通常在进行性能测试时会使用到各种测试仪器和测试工具软件,也具有自己的测试方法论,将有其他文章对如何使用仪器测试MPLS进行专门讨论。这里我们主要从协议角度介绍归纳几个主要测试方面。
首先是配置规格测试。MPLS配置规格主要包括:BGP、LDP等协议邻居数目规格,VPN实例数目及其绑定接口数目规格,VPN实例支持RT数目规格,静态LSP规格,L2VPN对等体规格等。测试配置规格时不应该只关注是否能够完成配置,还应该验证配置是否生效,配置生效后设备功能是否正常,是否能够正确去掉这些配置,去掉配置后对应资源是否及时释放,反复配置是否存在内存泄漏等相关问题。并且设备在规格配置内,正确配置的各种协议、邻居是否能够正常建立,同时存在一定流量时设备是否依然能正常工作。
其次是路由相关规格测试。虽然在路由协议层面上设备支持路由的规格没有具体限制与内存相关,但是对于MBGP,特别是对于MPLS L3VPN应用,PE不但要负责转发路由,还需要为路由分配标签,所以对应路由规格实际还会收到各种表项长度限制。同时,LSP表长度、NHLFE表等这些表的建立都与路由相关,也都是通过路由生成。对这些规格测试同样需要验证表项建立、删除操作和内存泄漏等方面。
最后是转发性能测试。对于MPLS转发性能测试,通常手段包括ping大包和利用测试仪器打入大流量报文。这里特别需要指出得是,我们在测试转发性能时通常就只使用SMB一种仪器(如SmartWindow/SmartFlow等),还需要多使用如Chariot等状态流测试工具。状态流能更加真是反映实际网络状态,其结果也才更准确地反映设备的性能。
2.7 互通测试
提到互通测试,我们总会马上想到与Cisco、Juniper等友商设备之间的互通、协同工作,其实这里还应该包括我司不同产品间、相同产品新老版本间以及我司与华为NE设备间的互通。。这些差异很可能会引起某些功能无法正常运行,这都需要我们能够提前发现这些不同,修改或找
进行互通测试最基本的方法就是在测试环境中加入其他设备(包括其他厂商设备和允许其他版本的我司设备),共同构成测试网络实现一个功能。由于MPLS互连协议众多,各种应用网络拓扑比较复杂,而且还存在PE、P、ASBR等不同角色,在互通测试过程中,需要不断变化被测设备与互通设备之间关系、相对角色。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国