MPLS-TE多厂商对接排错案例

下载选项

PDF (246.5 KB)
在各种设备上使用 Adobe Reader 查看
ePub (78.4 KB)
在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上使用各种应用查看
Mobi (Kindle) (63.8 KB)
在 Kindle 设备上查看或在多个设备上使用 Kindle 应用查看

已更新: 2013 年 7 月 19 日

非歧视性语言

此产品的文档集力求使用非歧视性语言。在本文档集中，非歧视性语言是指不隐含针对年龄、残障、性别、种族身份、族群身份、性取向、社会经济地位和交叉性的歧视的语言。由于产品软件的用户界面中使用的硬编码语言、基于 RFP 文档使用的语言或引用的第三方产品使用的语言，文档中可能无法确保完全使用非歧视性语言。深入了解思科如何使用包容性语言。

当地语言翻译版本说明

思科可能会在某些地方提供本内容的当地语言翻译版本。请注意，翻译版本仅供参考，如有任何不一致之处，以本内容的英文版本为准。

硬件平台

ASR-9010

软件版本

IOS-XR 4.2.3

案例简介

众所周知，对于运营商或大型互联网公司来说，流量模型以及流量控制的精确程度直接影响到用户的体验和公司投资效益的产出。因此在这个网络基础架构从单一IGP承载流量的时代逐渐过渡到IGP+BGP+MPLS的机构过程中，对于流量模型的控制提出了新的需求和挑战。因此很多的大规模网络在自己的架构中加入了MPLS-TE（基于MPLS的流量工程）技术，以得到更加精确的流量控制和更为灵活的流量拓扑调整。

本次案例为某互联网公司，在基于新架构部署MPLS-TE进行多厂商互联时发生的问题为基础。针对多厂商MPLS-TE互联对接的错误排除进行分析。

故障诊断步骤

此网络为一个以IS-IS为基础IGP提供Loopback和网元路由可达，使用MP-BGP以VPN形式承载所有业务路由，以MPLS-TE为LSP构建方法的网络。每个节点到其他所有节点的流量全部通过MPLS-TE承载。

客户出现的问题为，当MPLS-TE隧道的主用路径失效后备用路径没有达到预期效果，流量出现丢失的情况。根据客户故障现象描述，使用以下步骤进行排查：

在主用路径Down后确定RIB表象中是否有到达TE隧道远端目的地址的路由。
确定RIB表中的远端目的地址路由在FIB中安装是否正确。
查看RSVP的邻居关系是否正常建立。
查看MPLS-TE隧道是否正常建立，是否有错误信息提示。
检查log是否有和MPLS-TE涉及槽位等相关的硬件错误log。

根据上述步骤阐述，在实际解决这个问题的过程中，我们先查看了log的情况。

RP/0/RSP1/CPU0:May 31 02:38:40.553 : ifmgr[246]: %PKT_INFRA-LINK-3-UPDOWN : Interface tunnel-te42, changed state to Down 
RP/0/RSP1/CPU0:May 31 02:38:40.557 : ifmgr[246]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface tunnel-te42, changed state to Down 
RP/0/RSP1/CPU0:May 31 02:38:40.559 : ifmgr[246]: %PKT_INFRA-LINK-3-UPDOWN : Interface tunnel-te43, changed state to Down 
RP/0/RSP1/CPU0:May 31 02:38:40.560 : ifmgr[246]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface tunnel-te43, changed state to Down 
RP/0/RSP1/CPU0:May 31 02:38:44.528 : ifmgr[246]: %PKT_INFRA-LINK-3-UPDOWN : Interface tunnel-te43, changed state to Up 
RP/0/RSP1/CPU0:May 31 02:38:44.529 : ifmgr[246]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface tunnel-te43, changed state to Up 
RP/0/RSP1/CPU0:May 31 02:38:44.530 : ifmgr[246]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface tunnel-te42, changed state to Up 
RP/0/RSP1/CPU0:May 31 02:38:44.531 : ifmgr[246]: %PKT_INFRA-LINK-3-UPDOWN : Interface tunnel-te56, changed state to Up

我们可以注意到，在主用接口出现问题时，我们本端的TE隧道确实出现了Down的情况，但是随着CSPF和RSVP的收敛完成，我们的TE隧道随即Up，并保持稳定

Name: tunnel-te42  Destination: 10.200.0.31 
  Status:
    Admin:    up Oper:   up   Path:  valid   Signalling: connected

    path option 100,  type dynamic  (Basis for Setup, path weight 405)
    Last Signalled Error: Fri May 31 02:38:40 2013
      Info: [9334] PathErr(24,5)-(routing, no route to dest) at 10.200.0.28
    Last Signalled Error [Reopt]: Thu May 30 11:01:54 2013
      Info: [8507] PathErr(2,0)-(Admin, Info reporting) at 10.200.4.141
    G-PID: 0x0800 (derived from egress interface properties)
    Bandwidth Requested: 1000 kbps  CT0
    Creation Time: Tue Mar 26 00:16:30 2013 (9w3d ago)
  Config Parameters:
    Bandwidth:        0 kbps (CT0) Priority:  3  3 Affinity: 0x0/0x0
Metric Type: TE (default)
<SNIP>
  History:
	"Tunnel has been up for: 09:19:20 (since Fri May 31 04:29:39 Beijing 2013)
    Current LSP:
      Uptime: 09:04:18 (since Fri May 31 04:44:41 Beijing 2013)

从隧道Up持续时间来看，我们的隧道在主接口出现问题后的几秒钟即Up，并且稳定维持。因此我们从MPLS-TE的工作结构考虑，MPLS-TE的数据路径是由两个彼此独立的单向隧道叠加，得到一个双向流量路径。既然我们本端的隧道状态无异常。那么问题随可能是对端设备到达我们本地隧道出现了问题。

经过和Juniper工程师沟通，发现在我们本地主接口出现问题后，Juniper到达我本地的隧道出现了Down的情况，此问题导致了流量出现了单通，影响了业务。

分析Juniper设备配置，发现Juniper在链路上使用了admin-group对端链路进行了着色，添加了affinity属性。因为Cisco设备针对自己未知的affinity属性的处理方式默认是拒绝所有，故在主用链路失效后，备用链路为两台ASR9K互联链路，这条链路并未被着色，导致通过此链路建立的MPLS-TE隧道不能携带任何的affinity属性，否则将拒绝MPLS-TE通过此路径建立。

找到故障原因后，经协商，在ASR9K为互联链路指定affinity，解决此MPLS-TE多厂商对接兼容性问题。

经验总结

从上面的问题我们可以看出，在多厂商MPLS-TE对接时，可能存在的问题关键和在相同厂商设备间进行排错时会有一些不同，需重点关注不同厂商间针对某些会直接影响工作的关键点的默认处理方式是否有不同，并结合双方配置以及协议状态进行深度排查，才有可能找到问题根本原因。

其他相关文档

无

MPLS-TE多厂商对接排错案例

下载选项

非歧视性语言

当地语言翻译版本说明

目录

硬件平台

软件版本

案例简介

故障诊断步骤

经验总结

相关命令

相关错误信息

其他相关文档

此文档是否有帮助?

联系我们

本文档适用于以下产品