了解ICMP重定向消息

简介

  

本文档讨论互联网控制消息协议(ICMP)提供的数据包重定向功能。 本文档说明网络中ICMP重定向消息的存在通常表示什么，以及可以采取什么措施来最大限度地减少与导致生成ICMP重定向消息的网络条件相关的负面影响。

先决条件

要求

Cisco 建议您了解以下主题：

• Nexus 7000平台架构
• NX-OS软件配置
• 请求注解(RFC)792中记录的互联网控制消息协议

使用的组件

本文档中的信息都是基于特定实验室环境中的设备编写的。  本文档中使用的所有设备最初均采用原始（默认）配置。如果您使用的是真实网络，请确保您已经了解所有命令的潜在影响。

ICMP重定向消息

RFC 792“Internet控制消息协议”中对ICMP重定向功能进行了说明，具体示例如下

网关向以下主机发送重定向消息 情况。

网关G1从 连接网关的网络上的主机。网关， G1，检查其路由表并获取下一个 网关，G2，在通往数据报的Internet目的地的路由上 网络，X。

如果G2和由互联网源标识的主机 数据报的地址位于同一网络，重定向 消息发送到主机。重定向消息建议 主机将其网络X的流量直接发送到网关G2，作为 这是通往目的地的较短路径。

网关转发 原始数据报的数据到其互联网目的地。

此场景如图1所示。主机和两台路由器G1和G2连接到共享以太网网段，并在同一网络10.0.0.0/24中具有IP地址

主机的IP地址为10.0.0.100。主机的路由表中有一个默认路由条目，指向路由器G1的IP地址10.0.0.1作为默认网关。路由器G1在将流量转发到目的网络X时，使用路由器G2的IP地址10.0.0.2作为下一跳。 

当主机向目的网络X发送数据包时，会发生以下情况

1. IP地址为10.0.0.1的网关G1在其所连接的网络上从主机10.0.0.100接收数据包。

2.网关G1检查其路由表，并在通往数据包目的网络X的路由中获取下一个网关G2的IP地址10.0.0.2。

3.如果G2和IP数据包的源地址标识的主机位于同一网络中，则会向主机发送ICMP重定向消息。ICMP重定向消息建议主机将网络X的流量直接发送到网关G2，因为这是通往目的地的较短路径。

4。  网关G1将原始数据包转发到其目的地。

根据主机配置，它可能选择忽略G1发送给它的ICMP重定向消息。但是，如果主机使用ICMP重定向消息调整其路由缓存并开始直接向G2发送后续数据包，则本场景将获得以下优势

• 优化数据在网络中的转发路径；流量更快到达目的地
• 降低网络资源利用率，例如带宽和路由器CPU负载

如图2所示，在主机为G2作为下一跳的网络X创建路由缓存条目后，这些优势在网络中可见：

• 交换机和路由器G1之间链路的带宽利用率在两个方向上都会降低
• 由于从主机到网络X的流量不再流经此节点，因此路由器G1的CPU使用率降低
• 主机和网络X之间的端到端网络延迟得到改善。 

要了解ICMP重定向机制的重要性，请记住早期的互联网路由器实施主要依靠CPU资源来处理数据流量。因此，减少任何单台路由器必须处理的流量并尽量减少特定流量在到达目的地的过程中必须经过的路由器跳数是非常理想的。同时，第2层转发(也称为交换)主要在定制的专用集成电路(ASIC)中实现，从转发性能角度来说，与第3层转发（也称为路由）相比，是相对“便宜”的，这同样是在通用处理器中实现的。

较新的ASIC代可以同时执行第2层和第3层数据包转发。在硬件中执行第3层表查找有助于降低与路由器处理数据包相关的性能成本。此外，将第3层转发功能集成到第2层交换机(现称为第3层交换机)后，数据包转发操作更加高效，无需“单臂路由器”（也称为“单臂路由器”）设计选项，并避免了与此类网络配置相关的限制。

图3基于图1中的场景。现在，第2层和第3层功能（最初由交换机和路由器G1两个独立节点提供）整合到单个第3层交换机中，如Nexus 7000系列平台。

当主机向目的网络X发送数据包时，网络中会发生以下情况

1. IP地址为10.0.0.1的网关L3交换机从其所连接网络上的主机10.0.0.100接收数据包。

2.网关L3交换机检查其路由表并获取通往数据包目的网络X的路由中下一个网关G2的地址10.0.0.2。

3.如果G2和IP数据包的源地址标识的主机位于同一网络中，则ICMP重定向消息将发送到主机。ICMP重定向消息建议主机将网络X的流量直接发送到网关G2，因为这是通往目的地的较短路径。

4。  网关将原始数据包转发到其目的地。

由于第3层交换机现在能够在ASIC级别同时执行第2层和第3层数据包转发，因此可以得出结论：ICMP重定向功能的优点、(a)通过网络改善延迟和(b)降低网络资源利用率，并且不再需要过多关注多点以太网段中的路径优化技术。

但是，由于第3层接口上启用了ICMP重定向功能，通过多点以太网段的次优转发仍然存在潜在的性能瓶颈，尽管原因与本文档后面的Nexus平台注意事项部分有所说明。

注意：IOS和NX-OS软件中的第3层接口默认启用ICMP重定向

注意：生成ICMP重定向消息时的条件摘要：第3层交换机会生成ICMP重定向消息，如果数据包要从接收此数据包的第3层接口转发出去，则会返回到数据包源。 

通过以太网的次优路径

内部网关协议(IGP)(例如开放最短路径优先(OSFP)和思科增强型内部网关路由协议(EIGRP))旨在同步路由器之间的路由信息，并在所有执行此类信息的网络节点上提供一致且可预测的数据包转发行为。以多点以太网络为例，如果网段上的所有第3层节点都使用相同的路由信息并在通往目的地的同一出口点上达成一致，则很少会出现此类网络中的次优转发。

要了解导致次优转发路径的原因，请记住，第3层节点独立做出数据包转发决策。即，路由器B做出的数据包转发决策不取决于路由器A做出的数据包转发决策。这是排除通过IP网络转发数据包的故障时需要牢记的关键原则之一，也是研究多点以太网中的次优转发路径时需要牢记的重要原则。

如前所述，在所有路由器都依赖单个动态路由协议在终端之间传输流量的网络中，不应通过多点以太网网段进行次优转发。然而，在现实网络中，发现各种数据包路由和转发机制的组合是非常普遍的，例如各种IGP、静态路由和基于策略的路由。这些功能通常用于实现通过网络转发所需流量。

虽然结合使用这些机制有助于微调流量并满足特定网络设计的要求，但忽略这些工具在多点以太网网络中共同导致的副作用可能导致整体网络性能下降。

静态路由

为了说明这一点，请考虑图4中的场景。路由器A具有到网络X的静态路由，路由器B作为其下一跳。同时，路由器B使用路由器C作为通往网络X的静态路由的下一跳。

  

当流量从路由器A进入此网络，通过路由器C离开，最终传送到目的网络X时，数据包在到达目的地的途中必须经过此IP网络两次。这不是有效使用网络资源。相反，将数据包从路由器A直接发送到路由器C将获得相同的结果，同时消耗更少的网络资源。

注意：即使在此场景中，路由器A和路由器C用作此IP网段的入口和出口第3层节点，但如果网络设备（如负载均衡器或防火墙）具有导致相同数据包转发行为的路由配置，则两个节点都可以替换为网络设备（如负载均衡器或防火墙）。

基于策略的路由

基于策略的路由(PBR)是另一种可导致通过以太网的次优路径的机制。但是，与静态或动态路由不同，PBR不在路由表级别运行。相反，它直接在交换机硬件中编程流量重定向访问控制列表(ACL)。因此，对于选择流量流，入口线路卡上的数据包转发查找会绕过通过静态或动态路由获取的路由信息。 

在图5中，路由器A和路由器B使用其中一个动态路由协议交换有关目的网络X的路由信息。两者都同意路由器B是通向此网络的最佳下一跳。

但是，在路由器B上的PBR配置会覆盖从路由协议接收的路由信息并将路由器C设置为到网络X的下一跳，因此满足触发ICMP重定向功能的条件，并将数据包发送到路由器B的CPU以进行进一步处理。

点对点链路上的ICMP重定向

到目前为止，本文档所指的是连接了三个（或更多）第3层节点的以太网，因此称为多点以太网网络。但请注意，ICMP重定向消息也可以在点对点以太网链路上生成。

请考虑图6上的场景。路由器A使用静态默认路由将流量发送到路由器B，而路由器B则使用指向路由器A的网络X的静态路由。

此设计选项也称为单宿主连接，在将小型客户环境连接到服务提供商网络时是一个热门选择。此处，路由器B是提供商边缘(PE)设备，而路由器A是客户边缘(CE)设备。

请注意，典型CE配置包括指向Null0接口的客户IP地址块的聚合静态路由。此配置是推荐的最佳实践，适用于具有静态路由的单宿主CE-PE连接选项。但是，在本示例中，假设不存在此类配置。

假设路由器A与网络X失去连接，如图所示。当来自客户网络Y或远程网络Z的数据包尝试到达网络X时，路由器A和B将在彼此之间退回流量，在每个数据包中递减IP生存时间字段，直到其值达到1，此时无法进一步路由数据包。

现在，当流向网络X的流量在PE和CE路由器之间来回回退时，CE-PE链路带宽利用率显着（并且不必要地）增加，如果在点对点PE-CE连接的一端或两端启用ICMP重定向，问题就会更加严重。在这种情况下，流中发往网络X的每个数据包将在相应路由器的CPU中多次处理，以帮助生成ICMP重定向消息。

Nexus平台注意事项

当在第3层接口上启用ICMP重定向，并且传入数据包同时使用此接口到入口和出口第3层交换机时，会生成ICMP重定向消息。虽然第3层数据包转发是在Cisco Nexus 7000平台上的硬件中完成，但交换机的CPU仍负责构建ICMP重定向消息。为此，CPU在Nexus 7000管理引擎模块上，需要获取流的IP地址信息，该流的路径可以通过网段优化。这是入口线卡将数据包发送到管理引擎模块的原因。

如果ICMP重定向消息的最近消息忽略它，并继续将数据流量转发到启用ICMP重定向的Nexus交换机的第3层接口，则会为每个数据包触发ICMP重定向生成过程。

在线路卡级别，流程以硬件转发异常的形式启动。当线卡模块无法成功完成数据包转发操作时，ASIC上会出现异常。在这种情况下，需要将数据包发送到Supervisor模块以正确处理数据包。  

注意：Supervisor模块上的CPU还会处理许多其他数据包转发异常，例如处理生存时间(TTL)值设置为1的IP数据包，或在发送到下一跳之前需要分段的IP数据包。

在Supervisor模块上的CPU向源发送ICMP重定向消息后，它通过出口线卡模块将数据包转发到下一跳来完成异常处理。

Nexus 7000管理引擎模块使用功能强大、能够处理大量流量的CPU处理器，而该平台设计为在线卡级别处理大部分数据流量，而无需在数据包转发过程中与管理引擎的CPU处理器接触。这使CPU能够专注于其核心任务，将数据包转发操作留给线卡上的专用硬件引擎。

在稳定网络中，数据包转发异常（如果发生）预期会以相当低的速率发生。根据这一假设，可以由Supervisor CPU处理，而不会对其性能产生重大影响。另一方面，如果CPU处理以极高速率发生的数据包转发异常，则可能对系统的整体稳定性和响应性产生负面影响。

Nexus 7000平台设计提供多种机制来保护交换机CPU免受大量流量的影响。这些机制在系统中的不同点实施。在线路卡级别，有硬件速率限制器和控制平面策略(CoPP)功能。两者都设置流量速率阈值，从而有效控制从每个线路卡模块转发到Supervisor的流量。 

  

这些保护机制优先考虑对网络稳定性和交换机可管理性至关重要的各种控制协议（如OSPF、BGP或SSH）的流量，同时积极过滤对控制交换机平面功能不重要的流量类型。大多数数据流量（如果由于数据包转发异常而转发到CPU）都受此类机制的严格管制。

  

虽然硬件速率限制器和CoPP策略机制提供了交换机控制平面的稳定性并强烈建议始终启用，但它们可能是导致整个网络中数据包丢弃、传输延迟和整体应用性能不佳的主要原因之一。因此，了解流量流经网络的路径并拥有工具来监控能够和/或预期使用ICMP重定向功能的网络设备非常重要。

监控和诊断工具 

  

show ip traffic

Cisco IOS和NX-OS软件都提供了检查CPU处理的流量统计信息的方法。这可以通过show ip traffic命令完成。此命令可用于检查第3层交换机或路由器接收和/或生成ICMP重定向消息

Nexus7000# show ip traffic | begin ICMP

ICMP Software Processed Traffic Statistics
------------------------------------------
Transmission:
 Redirect: 1000, unreachable: 0, echo request: 0, echo reply: 0,



 ICMP originate Req: 0, Redirects Originate Req: 1000
 Originate deny - Resource fail: 0, short ip: 0, icmp: 0, others: 0
Reception:
 Redirect: 0, unreachable: 0, echo request: 0, echo reply: 0,



Nexus7000#

运行show ip traffic命令几次，然后检查ICMP重定向计数器是否增加。

Ethanalyzer

Cisco NX-OS软件具有内置工具，可捕获进出交换机CPU（称为Ethanalyzer）的流量。

注意：有关Ethanalyzer的详细信息，请参阅Nexus 7000上的Ethanalyzer故障排除指南

图7显示的场景与图3中的场景类似。此处网络X被192.168.0.0/24网络取代。

主机10.0.0.100向目的IP地址192.168.0.1发送连续的ICMP回应请求流。主机使用Nexus 7000交换机的交换机虚拟接口(SVI)10作为到远程网络192.168.0.0/24的下一跳。为了演示目的，主机配置为忽略ICMP重定向消息。

使用以下命令捕获Nexus 7000 CPU接收和发送的ICMP流量

Nexus7000# ethanalyzer local interface inband capture-filter icmp limit-captured-frames 1000

Capturing on inband
2018-09-15 23:45:40.124077   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request
2018-09-15 23:45:40.124477     10.0.0.1 -> 10.0.0.100   ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.124533   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request
2018-09-15 23:45:40.126344   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request
2018-09-15 23:45:40.126607     10.0.0.1 -> 10.0.0.100   ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.126655   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request
    2018-09-15 23:45:40.128348   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request
 2018-09-15 23:45:40.128611 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
    2018-09-15 23:45:40.128659   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request
2018-09-15 23:45:40.130362   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request
2018-09-15 23:45:40.130621     10.0.0.1 -> 10.0.0.100   ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.130669   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request
2018-09-15 23:45:40.132392   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request
2018-09-15 23:45:40.132652     10.0.0.1 -> 10.0.0.100   ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.132700   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request
2018-09-15 23:45:40.134347   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request
2018-09-15 23:45:40.134612     10.0.0.1 -> 10.0.0.100   ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.134660   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request
2018-09-15 23:45:40.136347   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request
2018-09-15 23:45:40.136598     10.0.0.1 -> 10.0.0.100   ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.136645   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request
2018-09-15 23:45:40.138351   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request
2018-09-15 23:45:40.138607     10.0.0.1 -> 10.0.0.100   ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.138656   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request

...

以上输出中的时间戳表明，本示例中突出显示的三个数据包同时捕获，即2018-09-15 23:45:40.128。下面是此数据包组的每个数据包细分

• 第一个数据包是入口数据包，在本例中为ICMP回应请求。

2018-09-15 23:45:40.128348 10.0.0.100 -> 192.168.0.1 ICMP回应(ping)请求

• 第二个数据包是网关生成的ICMP重定向数据包。此数据包将发送回主机。

2018-09-15 23:45:40.128611 10.0.0.1 -> 10.0.0.100 ICMP重定向（主机重定向）

• 第三个数据包是在CPU路由后在出口方向捕获的数据包。虽然上面未显示，但此数据包的IP TTL已递减，校验和已重新计算。

2018-09-15 23:45:40.128659 10.0.0.100 -> 192.168.0.1 ICMP回应(ping)请求

在浏览具有许多不同类型和流量的数据包的大型Ethanalyzer捕获时，将ICMP重定向消息与相应的数据流量关联起来可能并不容易。

在这些情况下，请关注ICMP重定向消息，以检索有关次优转发流量的信息。ICMP重定向消息包括互联网报头以及原始数据报数据的前64位。数据报的源使用此数据将消息与相应的进程匹配。

使用带有detail关键字的Ethanalyzer数据包捕获工具来显示ICMP重定向消息的内容，并查找未最优转发的数据流的IP地址信息

Nexus7000# ethanalyzer local interface inband capture-filter icmp limit-captured-frames 1000 detail 

...

Frame 2 (70 bytes on wire, 70 bytes captured)
 Arrival Time: Sep 15, 2018 23:54:04.388577000
 [Time delta from previous captured frame: 0.000426000 seconds]
 [Time delta from previous displayed frame: 0.000426000 seconds]
 [Time since reference or first frame: 0.000426000 seconds]
 Frame Number: 2
 Frame Length: 70 bytes
 Capture Length: 70 bytes
 [Frame is marked: False]
 [Protocols in frame: eth:ip:icmp:ip:icmp:data]
Ethernet II, Src: 00:be:75:f2:9e:bf (00:be:75:f2:9e:bf), Dst: 00:0a:00:0a:00:0a (00:0a:00:0a:00:0a)
 Destination: 00:0a:00:0a:00:0a (00:0a:00:0a:00:0a)
 Address: 00:0a:00:0a:00:0a (00:0a:00:0a:00:0a)
 .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
 .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
 Source: 00:be:75:f2:9e:bf (00:be:75:f2:9e:bf)
 Address: 00:be:75:f2:9e:bf (00:be:75:f2:9e:bf)
 .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
 .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
 Type: IP (0x0800)
Internet Protocol, Src: 10.0.0.1 (10.0.0.1), Dst: 10.0.0.100 (10.0.0.100)
 Version: 4
 Header length: 20 bytes
 Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
 0000 00.. = Differentiated Services Codepoint: Default (0x00)
 .... ..0. = ECN-Capable Transport (ECT): 0
 .... ...0 = ECN-CE: 0
 Total Length: 56
 Identification: 0xf986 (63878)
 Flags: 0x00
 0.. = Reserved bit: Not Set
 .0. = Don't fragment: Not Set
 ..0 = More fragments: Not Set
 Fragment offset: 0
 Time to live: 255
 Protocol: ICMP (0x01)
 Header checksum: 0xadd9 [correct]
 [Good: True]
 [Bad : False]
 Source: 10.0.0.1 (10.0.0.1)
 Destination: 10.0.0.100 (10.0.0.100)
Internet Control Message Protocol
 Type: 5 (Redirect)
 Code: 1 (Redirect for host)
 Checksum: 0xb8e5 [correct]
 Gateway address: 10.0.0.2 (10.0.0.2)
 Internet Protocol, Src: 10.0.0.100 (10.0.0.100), Dst: 192.168.0.1 (192.168.0.1)
 Version: 4
 Header length: 20 bytes
 Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
 0000 00.. = Differentiated Services Codepoint: Default (0x00)
 .... ..0. = ECN-Capable Transport (ECT): 0
 .... ...0 = ECN-CE: 0
 Total Length: 84
 Identification: 0xf986 (63878)
 Flags: 0x00
 0.. = Reserved bit: Not Set
 .0. = Don't fragment: Not Set
 ..0 = More fragments: Not Set
 Fragment offset: 0
 Time to live: 254
 Protocol: ICMP (0x01)
 Header checksum: 0xa8ae [correct]
 [Good: True]
 [Bad : False]
 Source: 10.0.0.100 (10.0.0.100)
 Destination: 192.168.0.1 (192.168.0.1)
 Internet Control Message Protocol
 Type: 8 (Echo (ping) request)
 Code: 0 ()
 Checksum: 0x02f9 [incorrect, should be 0xcae1]
 Identifier: 0xa01d
 Sequence number: 36096 (0x8d00)

...

禁用 ICMP 重定向

如果网络设计要求流量从其进入交换机或路由器的同一第3层接口路由出去，则可以通过在相应的第3层接口上明确禁用ICMP重定向功能来阻止流量通过CPU路由。

事实上，对于大多数网络，最好主动禁用所有第3层接口（物理接口，如以太网接口，虚拟接口，如端口通道和SVI接口）上的ICMP重定向。使用no ip redirects NX-OS接口级命令禁用第3层接口上的ICMP重定向。按照以下步骤验证ICMP重定向功能是否已禁用

• 确保no ip redirects命令已添加到接口配置

Nexus7000# show run interface vlan 10

interface Vlan10
  no shutdown
 no ip redirects
  ip address 10.0.0.1/24

Nexus7000#

• 确保接口上的ICMP重定向状态显示“禁用”

Nexus7000# show ip interface vlan 10 | include redirects
  IP icmp redirects: disabled
Nexus7000#

• 确保NX-OS软件组件将ICMP重定向启用/禁用标志设置为“0”，该软件组件将接口配置从交换机的管理引擎推送到多个线路卡之一

Nexus7000# show system internal eltm info interface vlan 10 | i icmp_redirect
  per_pkt_ls_en = 0, icmp_redirect = 0, v4_same_if_check = 0
Nexus7000#

• 确保在一个或多个线路卡上将特定第3层接口的ICMP重定向启用/禁用标志设置为“0”

Nexus7000# attach module 7
Attaching to module 7 ...
To exit type 'exit', to abort type '$.' 
Last login: Wed Sep 15 23:56:25 UTC 2018 from 127.1.1.1 on pts/0
module-7#

 
module-7# vdc 6

module-7# show system internal iftmc info interface vlan 10 | include icmp_redirect
 icmp_redirect : 0x0 ipv6_redirect : 0x1 
module-7# 

摘要

RFC 792中所述的ICMP重定向机制旨在优化通过多点网段的转发路径。  在Internet早期，这种优化有助于节省昂贵的网络资源，如链路带宽和路由器的CPU周期。

随着网络带宽变得更经济实惠，以及基于CPU的分组路由逐渐发展为专用硬件ASIC中更快的第3层数据包转发，通过多点网段实现最佳数据传输的重要性降低了，并且现在网络设计人员并没有像过去那样重视这一点。

默认情况下，每个第3层接口上都启用ICMP重定向功能。但是，网络人员并不总能理解它向多点以太网网段上的网络节点通知最佳转发路径的尝试，并采取相应措施。

在结合使用各种转发机制（如静态路由、动态路由和基于策略的路由）的网络中，如果未进行适当监控而启用ICMP重定向功能，则可能导致不需要使用传输节点CPU来处理生产流量。这反过来又可能对生产流量和网络基础设施的控制平面稳定性产生重大影响。

对于大多数网络，主动禁用网络基础设施中所有第3层接口上的ICMP重定向功能是一种好做法。这有助于防止在第3层交换机和路由器的CPU中处理生产数据流量的场景，因为在多点网段中有更好的转发路径。