某局点H3C S7500E交换机配置策略路由后策略路由转发异常问题

某局点H3C S7500E交换机配置策略路由后策略路由转发异常问题

 

一、   组网：

二、   问题描述：

现场75E 设备上下发了大量的ACL规则后又想使用S7500E交换机进行策略路由的配置：使部分访问201.1.1.2这台服务器的数据流按照普通路由转发，其他所有经过交换机转发的三层数据流全部按照策略路由转发。于是现场工程师小G充分的了解了用户需求后，决定使用QOS策略方式完成策略路由功能，他在S7500E交换机上进行了如下配置：

acl number 3001

rule 0 deny ip destination 200.1.1.0 0.0.0.255

rule 5 deny ip destination 172.19.0.0 0.0.255.255

rule 10 deny ip destination 172.23.0.0 0.0.255.255

rule 15 deny ip destination 172.24.0.0 0.0.255.255

rule 20 deny ip destination 172.25.0.0 0.0.255.255

rule 25 deny ip destination 10.254.0.0 0.0.255.255

rule 30 deny ip destination 10.232.0.0 0.0.255.255

rule 35 deny ip destination 10.0.0.0 0.255.255.255

rule 45 deny ip destination 110.75.120.0 0.0.0.255

rule 50 deny ip destination 121.0.31.45 0

rule 55 deny ip destination 121.0.31.149 0

rule 60 deny ip destination 119.42.224.0 0.0.15.255

rule 65 deny ip destination 110.76.0.0 0.0.31.255

rule 70 deny ip destination 172.29.0.0 0.0.255.255

acl number 4000 name PBR

rule 0 permit dest-mac 0023-89d5-e8c8 ffff-ffff-ffff(目的MAC为75E三层接口的MAC地址)

traffic classifier PBR operator and(匹配acl 4000的流做PBR)

if-match acl 4000

traffic classifier NO_PBR operator and(匹配acl 3001的流不做PBR)

if-match acl 3001

traffic behavior PBR_LB

redirect next-hop 202.1.1.2

traffic behavior NO_PBR

filter permit

qos policy PBR_LB

classifier NO_PBR behavior NO_PBR

classifier PBR behavior PBR_LB

当在GE1/0/2端口inbound方向下发QOS策略路由后发现，200.1.1.0网段访问201.1.1.2服务器通信异常。经过流量统计和镜像抓包分析发现，本不应该被重定向的报文被重定向了，200.1.1.0网段访问201.1.1.2服务器的流量并没有按照自己预想的方式进行普通路由转发。

于是小G再次检查配置，200.1.1.0网段访问201.1.1.2服务器的回程数据流满足ACL 3001的rule 0，数据流所对应的动作为permit，允许数据流通过，那么将该流量直接按照路由表转发，并且不进行下一条策略的匹配。即使该回程数据流同时满足ACL 4000的rule 0，也不应该执行重定向的动作。

三、   过程分析：

1. 策略路由概述

策略路由是一种依据用户制定的策略进行路由选择的机制。与单纯依照IP报文的目的地址查找路由表进行转发不同，策略路由可以基于到达报文的源地址、目的地址等信息灵活地进行路由选择。一般来讲，策略路由的优先级要高于普通路由，即设备在转发报文时，如果相应接口使能了策略路由，那么首先将报文与策略路由的匹配规则进行比较，如果符合匹配条件，则按照策略路由进行转发。如果报文与策略路由的匹配规则进行比较后，发现报文无法匹配策略路由的条件，再按照普通路由进行转发。

本系列交换机支持两种策略路由配置方式：PBR方式和QoS策略方式：

1.1 PBR方式：通过ACL制定匹配规则，支持对报文的下一跳，优先级及缺省下一跳进行设置, 以指导报文的转发。

1.2 QoS策略方式：通过流分类来制定匹配规则，并使用“重定向到下一跳”的流行为动作，将满足流分类规则的报文向指定的路径进行转发，从而实现灵活的路由选择。

2. 75E交换机ACL匹配原理

对于S75E交换机的交换芯片来说，acl是按照slice组进行存储的，一般是256个rule存储在一个slice组。拿SC板卡为例，该板卡支持4K acl，acl就存储在4096/256=16组中。在进行rule的匹配查找时，ACL查找原则是芯片对16个组一起进行查找，然后16个组根据自己组内的匹配情况，对比返回的动作结果是否有相互冲突的情况存在。如果各slice动作之间有冲突，则执行index高的slice对应的动作（一般是先下发的优先）；如果各slice动作之间没有冲突，则全部执行。汇总来说，导致相同流被不同rule匹配，满足下面三个条件的话，就会导致上面问题的出现：

2.1 一条流量，在设备上有两个或者以上的rule能同时满足匹配条件；

2.2 这些能同时匹配的rule，在交换芯片中分布在不同的组内；

2.3 这些rule对应的动作是不冲突的。最常见互不冲突的动作有：redirect和filter permit，redirect和filter deny。

3. 我们对照案例的问题，根据该类问题发生的三个条件一一进行对比

3.1 相同流在设备上匹配两个或者两个以上的rule。

200.1.1.0网段访问201.1.1.2服务器，数据流的回程报文目的地址是200.1.1.0网段，满足了ACL 3001中rule 0的定义。同时，由于数据需要在S75E设备进行三层路由转发，所以回程报文目的MAC地址对应的MAC肯定是S75E交换机的MAC地址0023-89d5-e8c8，同时也满足了ACL 4000中rule 0的定义。

3.2 数据流同时匹配的rule分布在不同的slice组内；

进行这个规则的判断，需要查看交换机的硬件表项。查看每个rule实际存储在具体哪个组中，一般需要在设备的诊断模式下，收集如下命令：

debug qacl show acl-resc 槽位号 芯片号

debug qacl show acl-type 槽位号

debug qacl show 槽位号 芯片号 verbose 显示开始号 acl-type 类型号

根据客户现场下发的规则，通过命令查看交换机的硬件表项发现，数据流同时匹配的规则，的确分布在不同的slice组中（见红色标注）。

[H3C-diagnose]debug qacl show 3 0 v 0 a 2

========

Acl-Type MQC Port, Stage IFP, GroupPri 13, EntryID 146, Active

Health 1, PoolFree 0, PoolID 0, Prio_Mjr 518, Prio_Sub 14,Slice 2,SliceIdx 0

Policy 3001, Classifier 3001, Behavior 3001

Rule Match --------

        Ports: 0x000000800, 0x01fffffff

        Dest IP: 200.1.1.0, 255.255.255.0

        IP Type: Any IPv4 packet

Actions --------

        Permit

========

Acl-Type MQC Port, Stage IFP, GroupPri 12, EntryID 175, Active

Health 1, PoolFree 0, PoolID 0, Prio_Mjr 518, Prio_Sub 14,Slice 3,SliceIdx 0

Policy 4000, Classifier 4000, Behavior 4000

Rule Match --------

        Ports: 0x000000800, 0x01fffffff

        Lookup: STP forwarding, 0x18, 0x18

        Dest mac: 0023-89D5-E8C8, FFFF-FFFF-FFFF

Actions --------

        L3Switch ipv4 addr 202.1.1.2, 255.255.255.255, nexthop_idx 0x186a4, ulRtnPbrIndex 1

3.3 这些rule对应的动作是不冲突的。

查看现场设备的配置我们知道，两个流对应的动作分别是redirect和filter permit，是不冲突动作的组合。

4. 问题分析结果

根据上面的分析可见，200.1.1.0网段访问201.1.1.2服务器的三层回程流量，在经过S75E以太网交换机的时候，需要同时做允许和重定向的动作，导致流量最终被重定向了，所以和客户的本意----200.1.1.0网段到该服务器的流量不做重定向出现了冲突，这样就可以解释现场出现的问题了。问题原因分析清楚后，我们来看一下该问题的解决方案。

四、   解决方法：

既然该问题需要满足上面提到的三个条件才会出现，那么我们见招拆招，根据产生问题的要素解决该类问题：

1. 减少包含关系的rule配置

既然由于同一流被不同rule同时匹配，才会出现这种问题发生的概率，那么配置时注意尽量不要或者减少配置有这类包含关系的rule。这个解决方法与实际使用的配置思维相关，例如上面的案例，客户本意是到指定网段的流量不做重定向，而余下的三层流量都要做重定向,可以将配置改为到某些指定的网段做重定向，而余下的不做重定向。这样，余下的不做重定向这个要求实际上不需要下发任何acl，这样也就从根本上解决了问题。

2. 调整rule的实际位置

只有跨不同组的rule 才会出现动作同时生效的情况，那么尽可能让这些rule在同一个slice组内。例如，通过查看交换机硬件表项的rule规律，我们可以查看到每个rule所在组的信息，所以我们可以在不同rule之间插入或者调整两个rule之间的其它rule数量和顺序，力争保证两个rule在同一个组内。但是这个方法对配置人员的要求较高，一般不推荐使用。

 

五、   注意事项：

1.  如果客户使用PBR方式进行策略路由，如果满足上述问题发生条件，也会出现同样的问题。

2.  S75E SA系列单板不支持重定向到下一跳的流行为，因此不能实现通过QoS方式实现策略路由的功能。

3.  PBR方式只能应用到三层口，包括VLAN接口、三层以太网端口等；QoS策略方式只能应用到端口、VLAN或全局的入方向。