S12508由于配置URPF导致设备丢包案例分析
丢包解决方案
丢包解决方案一、问题描述在网络通信过程中，时常会浮现数据包丢失的情况，即发送方发送的数据包在传输过程中未能到达接收方。
这种情况会导致通信质量下降，影响用户体验和数据传输的可靠性。
因此，需要制定一套丢包解决方案，以提高网络通信的稳定性和可靠性。
二、解决方案1. 检查网络连接首先，需要检查网络连接是否稳定。
可以通过ping命令或者网络监测工具来检测网络延迟和丢包情况。
如果发现网络连接不稳定，可以尝试重新连接网络或者更换网络设备。
2. 优化网络设备配置对于网络设备，如路由器、交换机等，需要进行合理的配置和管理。
可以采取以下措施来优化网络设备配置：- 更新设备固件：及时更新设备的固件版本，以修复已知的丢包问题和提升设备性能。
- 调整缓冲区大小：根据网络负载情况，合理调整设备的缓冲区大小，以减少丢包的可能性。
- 优化路由表：检查并优化路由表，确保数据包能够按照最优路径进行传输，减少丢包的可能性。
3. 使用可靠的传输协议在数据传输过程中，选择可靠的传输协议可以减少丢包的风险。
TCP协议是一种可靠的传输协议，它通过序列号、确认应答和重传机制来保证数据的可靠传输。
相比之下，UDP协议是一种不可靠的传输协议，不提供丢包重传机制。
因此，在对数据可靠性要求较高的场景下，应优先选择使用TCP协议。
4. 使用前向纠错技术前向纠错技术可以在一定程度上修复丢失的数据包，提高数据传输的可靠性。
常见的前向纠错技术包括海明码、RS码等。
这些技术通过在数据包中添加冗余信息，使得接收方能够根据冗余信息恢复丢失的数据包。
在设计数据传输方案时，可以考虑引入前向纠错技术来降低丢包率。
5. 使用数据包重传机制为了保证数据的可靠传输，可以引入数据包重传机制。
当发送方发现某个数据包丢失时，会主动重传该数据包，直到接收方确认收到为止。
这种机制可以有效降低丢包率，提高数据传输的可靠性。
常见的数据包重传机制包括停等协议、选择重传协议等。
6. 实施流量控制和拥塞控制流量控制和拥塞控制是保证网络通信稳定的重要手段。
限速导致PING服务器丢包故障案例
限速导致PING服务器丢包某网吧出现PING服务器网关丢包严重现象，丢包率达标40%，从8505交换机上PING 网吧IP 也出现严重的丢包现象。
用dis int e 看端口状态看其有input errors，怀疑是用户端光电板有问题，到用户端换完光电板后情况不见好转，测光功率在正常范围之内。
由于网吧组网比较复杂，又容易受到内部机子感染病毒，怀疑是其局域网问题，进而进行了单机测试，情况不容乐观，还是出现严重丢包现象。
据网吧人员反应，其网吧内部的机子流量只能限制在250K以内，超过此值就会掉线。
看了其端口的限速配置，意识这正是问题所在。
interface Ethernet3/1/20description shuchengwangbaport access vlan 218traffic-shape 6144 1536traffic-limit inbound ip-group 3002 rule 0 system-index 81 tc-index 17 3 0 0 3traffic-limit inbound ip-group 3002 rule 1 system-index 82 tc-index 39 6144 768000 768000 6144此端口由于前阵时间出现ICMP攻击，而导致整台8505 CPU利用率过高，在其端口多加了ACL规则，禁止来自此端口IP 的ICMP 报文。
acl number 3002rule 0 permit icmp source 59.60.60.88 0.0.0.7rule 1 permit ip在恢复其端口配置后，没有出现丢包现象。
interface Ethernet3/1/20description shuchengwangbaport access vlan 218traffic-shape 6144 1536traffic-limit inbound ip-group 3001 rule 0 system-index 81 tc-index 17 6144 768000 768000 6144由于取消了其ICMP限制，担心此端口有可能再出现ICMP攻击，在此后的几天里我们观察其CPU利用率，没出现过高现象。
经典案例_PRB利用率与VoLTE丢包相关性解析
PRB利用率与VoLTE丢包相关性解析目录一、问题背景 (3)二、问题分析 (3)2.1 大用户对无线环境的影响 (3)2.2 大用户对基站负荷的影响 (7)三、解决措施 (9)3.1 PRB利用率高精准优化 (9)四、经验结论 (13)PRB利用率与VoLTE丢包相关性解析【摘要】上行丢包率是衡量VoLTE话音质量的一个重要的因素，深入挖掘VoLTE的丢包率与哪些指标有着正向的相关性，才能准确的定位问题原因。
本文基于PRB利用率与上行丢包的相关性深入解析基站的PRB利用率，CCE的利用率等基站负荷性能与丢包的影响。
通过分析丢包率和PRB利用率关联性最强，当RPB资源利用率大于40%以后丢包率恶化明显，丢包率和CCE拥塞也有一定的关系，在CCE拥塞率大于0.6%，对上行资源调度产生影响，丢包率也会出现恶化。
通过对现网TOP50小区进行分析处理，取得了一定的成效，QCI1上行丢包率降低了0.29%。
【关键字】PRB、丢包率、CCE【业务类别】优化方法一、问题背景VoLTE的上行丢包率作为考核的重要指标，同时丢包率也是衡量VoLTE话音质量的一个重要的因素。
深入挖掘VoLTE的丢包率与些指标有着正向的相关性，才能准确的定位问题原因。
本案例就是基于PRB利用率与上行丢包的相关性深入解析基站的PRB利用率，CCE的利用率等基站负荷性能与丢包的影响，从而拓展了解决VoLTE上行丢包的又一个新途径。
二、问题分析基于高校高负荷场景区域解析VoLTE上行丢包率选取高校区域50个站点，在较多用户（RRC连接数大于100）的前提下排除外部干扰的因素，筛选底噪低于-110的采样点430个。
2.1 大用户对无线环境的影响对比PRB利用率和底噪的关系，如下图：由上图可以看出在PRB利用率高的情况下底噪也随之升高，底噪较高的采样大部分分布在利用率大于40%以上部分，由于采样是在高校连片区域，用户呈连续性集中分布，可以用自身的底噪来近似为整体区域的底噪情况，因此在PRB利用率高的情况下，整个区域的底噪也会较高。
丢包解决方案
丢包解决方案引言概述：在网络通信中，丢包是指在数据传输过程中，部分数据包未能到达目的地。
丢包问题会导致网络连接不稳定，影响数据传输的可靠性和效率。
为了解决丢包问题，需要采取一系列的解决方案。
本文将介绍丢包问题的原因，并提供五个部分的解决方案，包括网络优化、硬件升级、错误恢复机制、负载均衡和数据压缩。
一、网络优化1.1 提升带宽：丢包问题可能是由于网络带宽不足导致的。
通过增加网络带宽，可以提高数据传输的速度和稳定性，减少丢包的发生。
1.2 优化网络拓扑结构：合理规划网络拓扑结构，减少网络节点之间的跳数和延迟，可以降低丢包的概率。
采用更高效的路由算法和拓扑优化工具，可以改善网络连接质量。
1.3 配置QoS（Quality of Service）策略：通过合理配置QoS策略，可以对不同类型的数据流进行优先级管理，确保重要数据的传输优先级高于其他数据，从而减少丢包的影响。
二、硬件升级2.1 更新网络设备：老旧的网络设备可能会导致丢包问题。
通过升级交换机、路由器等网络设备，可以提升硬件性能，增强数据传输的稳定性和可靠性。
2.2 优化网络接口：网络接口是连接设备和网络的关键部分，对丢包问题有着重要影响。
通过更换高性能的网络接口卡、光纤等，可以提高数据传输的质量，减少丢包的发生。
2.3 配置硬件防火墙：硬件防火墙可以对网络流量进行过滤和检查，防止恶意攻击和异常流量对网络造成干扰，从而降低丢包的风险。
三、错误恢复机制3.1 使用前向纠错码（Forward Error Correction）：前向纠错码是一种纠正数据传输过程中错误的技术。
通过在数据包中添加冗余信息，接收端可以根据这些冗余信息纠正部分错误，减少丢包的影响。
3.2 采用ARQ（Automatic Repeat Request）协议：ARQ协议是一种自动重传请求的协议，当接收端检测到丢包时，会向发送端发送重传请求，以便重新发送丢失的数据包。
3.3 配置流控制机制：流控制机制可以控制数据的传输速率，避免发送端过快发送数据导致接收端丢包。
4G优化案例：基于劣化原因快速处理VoLTE高丢包小区方案研究
基于劣化原因快速处理VoLTE高丢包小区方案研究XXXX年XX月目录基于劣化原因快速处理VoLTE高丢包小区方案研究 (3)一、概述 (3)2.1. VoLTE高丢包问题原因分析和定位 (3)2.2. 基于劣化原因的优化方法 (5)二、基于劣化原因的VOLTE丢包小区参数优化效果 (8)2.1. 弱覆盖场景 (8)2.2. 干扰场景 (12)2.3. 切换问题场景 (14)2.4. 特性参数 (17)三、经验总结 (18)基于劣化原因快速处理VoLTE高丢包小区方案研究XX【摘要】随着VOLTE业务的商用，VOLTE的感知变得越来越重要，由于VOLTE使用PS 域来实现语音通话功能，我们日常碰到的吞字、断续、单通等问题跟VOLTE的丢包有很大关系。
为了提高用户感知快速解决VOLTE的丢包问题，本次通过VOLTE丢包原因分析、丢包原因定义和丢包问题优化、效果验证这几个方面的研究，确定丢包原因定义和优化方法，为后期能快速排查并解决VOLTE丢包问题提高用户感知提供优化策略。
【关键字】VOLTE高丢包上行弱覆盖丢包优化【业务类别】VOLTE一、概述2.1.V oLTE高丢包问题原因分析和定位2.1.1.高丢包问题原因分析通过统计分析日常的VoLTE高丢包小区，目前现网的VOLTE高丢包原因主要可以分为如下6大类：➢弱覆盖问题（现网的主要问题是上行弱覆盖）；➢大话务资源受限问题(资源受限，导致大量CCE分配失败)；➢上行干扰问题；➢上行受限问题；➢下行干扰问题；➢切换问题（包括切换失败、乒乓切换、切换不及时、邻区缺失等）；FDD是上行受限系统，通过对VOLTE高丢包的原因占比分析可以看到，VoLTE上行覆盖受限和上行干扰对丢包影响最大，在分析高丢包小区时，重点需定位上行受限、上行干扰等问题，先通过参数优化，快速降低丢包率，改善语音感知。
VOLTE高丢包6类原因的占比分布图如下：2.1.2.高丢包小区劣化原因定义处理VoLTE高丢包小区的第一步是要对丢包原因进行定位。
丢包解决方案
丢包解决方案一、问题描述在网络通信过程中，丢包是指发送方将数据包发送到接收方时，由于各种原因导致部份或者全部数据包丢失的现象。
丢包问题严重影响了网络通信的效率和稳定性，因此需要寻觅解决方案来解决丢包问题。
二、问题原因分析1. 网络拥堵：当网络流量过大，网络设备无法及时处理所有数据包时，就会浮现丢包现象。
2. 网络延迟：当网络延迟过高，数据包在传输过程中需要花费较长期，容易导致数据包丢失。
3. 网络故障：网络设备故障、路线中断等问题都可能导致数据包丢失。
4. 数据包冲突：当多个数据包同时发送到同一个目的地时，可能会发生数据包冲突，导致部份数据包丢失。
三、解决方案针对丢包问题，可以采取以下解决方案来提高网络通信的稳定性和可靠性。
1. 使用可靠传输协议可靠传输协议能够确保数据包的可靠传输，即使浮现丢包情况也能进行重传，保证数据的完整性。
常用的可靠传输协议包括TCP（Transmission Control Protocol）和SCTP（Stream Control Transmission Protocol）。
2. 优化网络拓扑结构通过优化网络拓扑结构，合理规划网络设备的布局和连接方式，可以减少网络拥堵和延迟，降低丢包率。
可以考虑使用负载均衡技术、增加带宽、优化路由等方法来优化网络拓扑结构。
3. 使用数据包重传机制在传输过程中，如果发现数据包丢失，可以通过数据包重传机制进行重传，确保数据的完整性。
可以根据具体情况设置重传时间间隔和重传次数，以平衡传输效率和可靠性。
4. 引入流量控制和拥塞控制机制流量控制和拥塞控制机制可以有效地调节数据包的传输速率，避免网络拥堵和丢包现象的发生。
常见的流量控制和拥塞控制算法包括TCP的滑动窗口机制和拥塞避免算法。
5. 定期进行网络设备维护定期对网络设备进行维护和检修，及时发现并解决网络故障，可以减少丢包问题的发生。
维护工作包括设备清洁、固件升级、故障排查等。
6. 使用冗余技术冗余技术可以在一定程度上提高数据的可靠性和容错性。
网络丢包经典分析案例
网络丢包，请离我远去1 网络丢包-烦恼网络是多种设备的集合体，一个较为完善的网络除去网络终端大量的客户机以外，有众多的设备穿插集中，包括二层交换机、三层交换机、DSLAM、BAS、路由器、服务器、存储设备等。
而涉及到的网络协议、技术更为繁杂，要维护这么庞大以及技术复杂的网络，很多时候是雾里看花，总是看不清楚问题的实质，尤其是网络丢包问题，让多少网络专家为之彻夜难眠却又束手无策。
本案例汇集了经常遇到的网络丢包案例，希望这些小的案例能够为我们的日常网络维护提供一些启发。
2 网络丢包惨案-案例1某客户的服务器端局部网络连接图（图中略去了交换机上行连接设备）如下：两台服务器连在分别连接在S5100交换机的g1/0/3和g1/0/4端口。
服务器是第三方网管服务器,两台服务器之间有数据调用。
客户反馈访问网管服务器速度很慢，两台服务器之间ping大包时有大量丢包。
网络故障范围已经缩小至两台服务器之间的丢包，问题就变得比较简单，这种情况下，首先确认是故障点，那么我们看两台服务器PING报文的转发流程，总体上可以分为三部分：有两部分是服务器与交换机之间的转发、另外一部分是交换机之间的数据转发。
那么要排除该问题我们采取逐段分析排查的方法：1：首先在两台交换机之间互相Ping各自的管理IP地址，测验结果为不丢包，因此这两台交换机之间的问题可以排除在外；2：排查服务器与交换机之间问题：这部分的问题又可以细分为三个点：服务器、网线、交换机端口。
而这三个点的排查难度是由难到易，因此我们先排查交换机端口的问题；3：首先更换左端服务器与交换机连接的端口，更换后，丢包问题依然存在，可以排除左端交换机端口的问题，用同样的办法测试右端服务器与交换机端口，依然可以排除交换机端口的问题；4：那么接下来排查网线的问题，如果是线路的问题，那么在交换机的端口一定会产生大量的CRC错误，那么首先登录到左边交换机上查看端口G1/0/3的状态，没有发现有CRC错误，然后等到右边交换机上查看端口G1/0/4的状态，发现端口有大量CRC错误，而且CRC错误包的数量还在增长，因此初步怀疑该接口下的网线有问题，于是更换一条生产发货的网线更换后，丢包问题解决。
URPF
什么是单播反向路径转发URPF1 背景单播反向路径转发（Unicast Reverse Path Forwarding），是网络设备检查数据包源地址合法性的一种方法。
其在FIB表中查找该源地址是否与数据包的来源接口相匹配，如果没有匹配表项将丢弃该数据包，从而起到预防IP欺骗，特别是针对伪造IP源地址的拒绝服务（DoS）攻击非常有效。
2 URPF应用环境简介DoS（Denial of Service）攻击是一种阻止连接服务的网络攻击。
DoS的攻击方式有很多种，最基本的DoS攻击就是利用合理的服务请求来占用过多的服务资源，从而使合法用户无法得到服务的响应。
2.1 TCP泛洪图1 TCP泛洪攻击案例攻击的原理是向目标设备发送大量伪装连接的请求包，这些请求包的发起地址设置为目标不可到达的地址，这样对被攻击对象的第二次握手没有主机响应，造成被攻击对象主机内部存在大量的半开连接，以至于新的正常连接不能进入从而造成服务的停顿甚至死机。
2.2 SMURF攻击SMURF攻击是一种源地址欺骗攻击，攻击者假冒被攻击对象的IP地址向设备发送大量的广播ICMP echo请求报文。
因为每个包的目标IP地址都是网络的广播地址，所以设备会把ICMP echo请求报文以广播形式发给网络上的所有主机。
如果有大量主机，那么这种广播就会产生大量的ICMP echo请求及响应流量。
而且在发送ICMP echo请求数据包时，使用了假冒的源IP地址，所以攻击造成的ICMP流量不仅会阻塞网络，而且会产生攻击流量。
图2 SMURF攻击案例图如图2，Attacker仿冒Router B的地址对Router C进行攻击，如果Router C上的网络管理员检测到攻击，将会配置防火墙规则，将所有来自Router B的报文过滤，导致无辜的Router B 无法访问Router C。
此时，被攻击系统的管理员反而成为黑客的帮凶，使一些合法用户失去合法访问的权限。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
S12508由于配置URPF导致设备丢包案例分析关键词:∙URPF∙丢包∙0推荐，1495浏览∙1收藏，我的收藏问题现象如下拓扑图：S12508-1和S12508-2做VRRP，现场发现从S12508-FW这台设备跨S12508－02去ping S12508-01有大量丢包，丢包很规律，每五个包只会通一个。
S12508-FW直连ping S12508-2不会丢包，S12508-2与S12508-1直连互ping也不丢包。
并且业务一直也不受影响，就如下两个地址互ping有丢包: 从S12508-FW的本地地址（211.138.35.34）到S12508-1（221.181.39.254）[12508-FW]ping -c 12 -a 211.138.35.34 221.181.39.254Ping 221.181.39.254 (221.181.39.254): 56 data bytes, press CTRL_C to breakRequest time outRequest time outRequest time outRequest time outRequest time out56 bytes from 221.181.39.254: icmp_seq=0 ttl=255 time=8.305 ms Request time outRequest time outRequest time outRequest time outRequest time out56 bytes from 221.181.39.2549.1.1.2: icmp_seq=4 ttl=255 time=1.651 ms--- Ping statistics for 221.181.39.254 ---12 packet(s) transmitted, 2 packet(s) received, 83.3% packet loss原因分析1、分别在S12508-2与S12508-1进行流量统计，可以确定S12508-1已经把icmp reply报文发回去了，但是在直连的S12508-2的入口流量统计发现报文变少了。
如下流量统计：现场ping 20个包，只通了4个，在S12508-1的出口可以看到已经回复了20个报文，但是在S12508-2入口只统计到了4个。
acl number 3999rule 0 permit icmp source 221.181.39.254 0 destination 211.138.35.34 0 rule 10 permit icmp source 211.138.35.34 0 destination 221.181.39.254 0S12508-1的出口流量统计：Interface: Ten-GigabitEthernet8/0/9Direction: OutbounPolicy: liutongClassifier: liutongOperator: ANDRule(s) : If-match acl 3999Behavior: liutongAccounting Enable:20 (Packets)S12508-2的入口流量统计：Interface: Ten-GigabitEthernet8/0/9Direction: InboundPolicy: liutongClassifier: liutongOperator: ANDRule(s) : If-match acl 3000Behavior: liutongAccounting Enable:4 (Packets)2、由于两台设备互连接口是聚合接口2，有四个物理接口，最开始怀疑是链路问题导致丢弃，因此把Ten8/0/9接口shutdown来排除该链路问题，但是shutdown该接口后，报文从Ten8/0/11转发，问题依旧，S12508-2的入口的报文总是比S12508-1出口少。
3、进行路由排查，S12508-02到S12508-01走的是直连路由，出口是interface vlan140，该VLAN虚接口配置了严格URPF，严格URPF会检查从这个接口发出去的报文是否还从这个接口进来。
如果不从这个接口回来，那么报文将会被丢弃。
[H3C12508-02]dis ip routing-table 221.181.39.254Routing Table : PublicSummary Count : 8Destination/MaskProto Pre Cost NextHop Interface0.0.0.0/0 O_ASE 150 201 211.138.35.33 Vlan11 221.181.39.0/24 O_ASE 150 202 221.181.39.62 Vlan120O_ASE 150 202 221.181.39.190 Vlan130O_ASE 150 202 221.181.39.254 Vlan140O_ASE 150 202221.181.39.30 Vlan150O_ASE 150 202 221.181.46.253 Vlan160O_ASE 150 202 221.181.33.125 Vlan17 0221.181.39.224/24 Direct 0 0 221.181.39.248 Vlan140该互连vlan虚接口配置了严格URPF：interface Vlan-interface140ip address 221.181.39.248 255.255.255.224vrrp vrid 140 virtual-ip 221.181.39.225vrrp vrid 140 priority 110vrrp vrid 140 track interface Vlan-interface11 reduced 20ip urpf strict右边设备S12508-1上回应报文走的是6条等价路由，而icmp reply报文是CPU 发出的，CPU发出的报文是逐包转发，因此icmp reply报文是逐条路由进行回包，如果该报文正好走vlan-interface 140的路由，左边设备S12508-02可以URPF检查通过，ping则是正常的，如果走其他vlan-interface的路由，左边设备S12508-02的会URPF检查不通过，那么就会出现ping不通，所以表现就是每通1个包丢5个包：[H3C12508-01]dis ip routing-table 211.138.35.34Routing Table : PublicSummary Count : 7Destination/Mask Proto Pre Cost NextHopInterface0.0.0.0/0 O_ASE 150 201 211.138.35.41 Vlan11 211.138.35.32/29 OSPF 10 201 221.181.39.61 Vlan120 OSPF 10 201 221.181.39.189 Vlan130 OSPF 10 201 221.181.39.248 Vlan140 OSPF 10 201 221.181.39.29 Vlan150 OSPF 10 201 221.181.46.252 Vlan160 OSPF 10 201 221.181.33.124 Vlan1704、对于这样的组网进行实验室复现。
如下实验室复现拓扑图，S12508与S95E-2通过四个VLAN接口互连，VLAN 30 40 50 60对应的虚接口开启URPF：通过OSPF方式在S12508上发布4条等价路由到S95E-2，让S95E-2访问S95E-1的时候有4条等价路由，这个时候是每发送4个包，通一个包，丢三个包：[S9500E-1]ping -c 10 30.0.0.2PING 30.0.0.2: 56 data bytes, press CTRL_C to breakRequest time outRequest time outRequest time outReply from 30.0.0.2: bytes=56 Sequence=3 ttl=254 time=1 msRequest time outRequest time outRequest time outReply from 30.0.0.2: bytes=56 Sequence=7 ttl=254 time=1 msRequest time outRequest time out--- 30.0.0.2 ping statistics ---10 packet(s) transmitted,2 packet(s) received, 80.00% packet lossround-trip min/avg/max = 1/1/1 ms从S12508直连ping S95E-2是不丢包的：[S12508-V5] ping 30.0.0.2PING 30.0.0.2: 56 data bytes, press CTRL_C to breakReply from 30.0.0.2: bytes=56 Sequence=0 ttl=255 time=1 msReply from 30.0.0.2: bytes=56 Sequence=1 ttl=255 time=1 msReply from 30.0.0.2: bytes=56 Sequence=2 ttl=255 time=1 msReply from 30.0.0.2: bytes=56 Sequence=3 ttl=255 time=1 msReply from 30.0.0.2: bytes=56 Sequence=4 ttl=255 time=1 ms--- 30.0.0.2 ping statistics ---5 packet(s) transmitted ,5 packet(s) received ,0.00% packet loss round-trip min/avg/max = 1/1/1 ms[S12508-V5]dis ip routing-tableRouting Tables: PublicDestinations : 28 Routes : 31Destination/Mask Proto Pre Cost NextHop Interface1.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0 10.0.0.0/24 Direct 0 0 10.0.0.2 Vlan10 10.0.0.2/32 Direct 0 0 127.0.0.1 InLoop0 30.0.0.0/24 Direct 0 0 30.0.0.1 Vlan30……互连接口进行URPF配置：interface Vlan-interface30ip address 30.0.0.1 255.255.255.0ip urpf strictinterface Vlan-interface40ip address 40.0.0.1 255.255.255.0ip urpf strictinterface Vlan-interface50ip address 50.0.0.1 255.255.255.0ip urpf strictinterface Vlan-interface60ip address 60.0.0.1 255.255.255.0ip urpf strict#S95E-2到S95E-1的10.0.0.1地址走的ospf四条等价路由：[S9500E-2]dis ip routing-tableRouting Tables: PublicDestinations : 16 Routes : 22Destination/Mask Proto Pre Cost NextHop Interface1.1.1.1/32 OSPF 10 100 50.0.0.1 Vlan50 10.0.0.0/24 OSPF 10 101 50.0.0.1 Vlan50 OSPF 10 101 60.0.0.1 Vlan60 OSPF 10 101 30.0.0.1 Vlan30OSPF 10 101 40.0.0.1 Vlan40在S95E-2上调整ospf cost值，不形成等价：[S9500E-2-Vlan-interface30]ospf cost 10[S9500E-2-Vlan-interface30]dis ip rou[S9500E-2-Vlan-interface30]dis ip routing-tableRouting Tables: PublicDestinations : 16 Routes : 16Destination/Mask Proto Pre Cost NextHopInterface1.1.1.1/32 OSPF 10 10 30.0.0.1 Vlan30 10.0.0.0/24 OSPF 10 11 30.0.0.1 Vlan30 30.0.0.0/24 Direct 0 0 30.0.0.2 Vlan30 30.0.0.2/32 Direct 0 0 27.0.0.1 InLoop0 40.0.0.0/24 Direct 0 0 40.0.0.2 Vlan40在S95E-1上测试，恢复正常：[S9500E-1]ping -c 10 30.0.0.2PING 30.0.0.2: 56 data bytes, press CTRL_C to breakReply from 30.0.0.2: bytes=56 Sequence=0 ttl=254 time=1 msReply from 30.0.0.2: bytes=56 Sequence=1 ttl=254 time=1 msReply from 30.0.0.2: bytes=56 Sequence=2 ttl=254 time=2 msReply from 30.0.0.2: bytes=56 Sequence=3 ttl=254 time=1 msReply from 30.0.0.2: bytes=56 Sequence=4 ttl=254 time=1 msReply from 30.0.0.2: bytes=56 Sequence=5 ttl=254 time=1 msReply from 30.0.0.2: bytes=56 Sequence=6 ttl=254 time=1 msReply from 30.0.0.2: bytes=56 Sequence=7 ttl=254 time=1 msReply from 30.0.0.2: bytes=56 Sequence=8 ttl=254 time=1 msReply from 30.0.0.2: bytes=56 Sequence=9 ttl=254 time=2 ms--- 30.0.0.2 ping statistics ---10 packet(s) transmitted, 10 packet(s) received, 0.00% packet loss round-trip min/avg/max = 1/1/2 ms解决办法由于现场互连接口配置了严格URPF，并且报文出入不在同一个接口，导致报文丢弃。