J友商设备缺省使能非标签公网路由迭代LSP导致NE80E上做traffic policy不生效

发布时间:  2012-07-27 浏览次数:  95 下载次数:  0
问题描述
NE80E上用traffic policy做重定向,将接口收到的DNS报文重定向,使用中发现有一个DNS使用正常,但是这个DNS发给用户的报文未被重定向,其他的DNS发来的报文重定向正常。
组网:
DNS---internet---M320---城域网---(配置重定向的接口)NE80E---下挂用户网络
重定向匹配acl,匹配所有UDP协议DNS端口的报文。
告警信息

处理过程
1、在终端用户抓包,DNS交互的报文正常,与acl配置符合。
2、从DNS tracert用户,确实从此接口进入本地网络。核对上层网络路由,路径正确。在此NE80E的下行设备匹配,可以匹配到这个DNS发送的报文。
3、NE80E做traffic policy时,acl无法对mpls转发报文进行匹配命中,从而怀疑上层网络将此报文通过mpls转发送到NE80E;
4、进一步分析,NE80E上没有到下挂用户各网段的lsp,所以报文经过的lsp应该是到NE80E本身地址的lsp;
5、向上层网络排查,发现在J友商的M320设备上,缺省使能非标签路由迭代lsp的功能,而NE80E下挂的用户网段在NE80E上通过BGP协议发布,M320与NE80E为IBGP对等体,看到的用户网段下一跳为NE80E的loopback地址,M320在转发时,将匹配这些BGP路由的数据通过lsp转发给NE80E,导致NE80E上行接口配置的traffic policy无法命中。如果要解决此问题,只能在M320设备上进行调整。
6、NE80E V3R3版本提供route recursive-lookup tunnel命令开启非标签公网路由能够迭代到LSP隧道,但NE80E缺省关闭此功能。
根因
1、NE80E匹配的报文类型不正确;
2、DNS与用户交互报文不经过NE80E配置重定向的接口;
3、DNS发送的报文无法被acl命中。
建议与总结
M320设备的实现导致此DNS发给NE80E下挂用户的报文带有标签,所以在NE80E的上行口无法匹配acl,不能做traffic policy。本案例给排查traffic policy无法命中提供一个思路。

END