OSPF“丢弃”(来自MT的路由从网络的其余部分被丢弃)

jkroon · 2022年6月3日星期五下午1:29

你好,

之前我发现viewtopic.php吗?t = 78327-这对我来说毫无意义，但我们决定禁用md5认证的解决方案值得一试，在仔细检查我们对“直接连接的攻击者”的缓解措施是否到位并可操作后，我们禁用了OSPF md5认证。这并没有以任何方式解决问题，因此，我们怀疑身份验证从来就不是真正的问题。

同一页面表明您的问题是数据包丢失。根据所涉及的任何路由器，我们都没有看到邻接关系的丢失。具体网段由2台(48x10G + 4x40G)交换机组成，在可能的情况下配对运行vPC (LACP)回路由器，或者在没有10G主用+ (2 × 1G LACP)备用的情况下(即只有1 × 10G端口可用)。我们也没有看到回声请求/响应帧的任何损失(我刚刚以1ms的间隔淹没了不到1000万个这样的请求，并且得到了0%的损失——对于一个在同一时期意外退出OSPF的路由器)。

每个受影响的路由器，我们每天会收到20到25个这样的辍学。详细的症状:

*同一L2段上的其他路由器会在一段时间内(有时会延长，例如半小时以上)丢弃来自MT的路由。
*来自其他地方的路由和发布到MT不受影响(即，MT保留它的路由到网络的其余部分)。

该段涉及的路由器(接口地址和DR选择优先级):

172.31.255.1 - FRR 8.2.2 -优先级200 -在08:15:33下降到下面
172.31.255.2 - FRR 8.2.2 -优先级200(当前DR) -下降到08:15:42
172.31.255.3 - l雷竞技RouterOS 6.48.4(48小时后升级)-优先级1
172.31.255.5 - l雷竞技RouterOS 6.49.6(当前BDR，今早升级)-优先级为1

我在日志中发现的导致路由删除的是相当多的“跳过洪水:从DR或BDR”。只有当路由器是DR或BDR时，我们才希望将大量更新发送回网络，这是有道理的。但我怀疑这也意味着路由器没有定期刷新它返回DR和BDR的路由，甚至不确定这是否是一个考虑因素，但我猜如果MT不让DR和BDR不时地知道它的路由仍然有效，它们就会经常被丢弃。

让我感到困扰的是，自从今天早上升级以来:重新启动的路由器一直不稳定，而在同一时间(仅仅4个多小时)，我们有4次从未重新启动的节点中断(上面是第一次的日志)。据我所知，这可能有两个原因:

1.重启可以暂时修复任何潜在的问题，然后它又会回来;或
2.如果一个路由器是DR或BDR，那么只要有lsa，它就会泛洪，导致它自己的路由器也会在对等体上被刷新。

我对OSPF协议不够熟悉，无法证实或拒绝这两种假设。

产生的问题:

* iBGP应该正常连接回环地址-如果OSPF失败，回环失败，iBGP失败，整个网络失败。我们不得不更新iBGP以使用接口地址将链路层故障转换为路由故障，但这些故障远低于目前的OSPF(每年少量故障，而OSPF几乎每小时退出一次)。
*次优内部路由(例如，将遵循BGP宣布的/21到路由反射器，而不是更具体的/28从OSPF到不同的路由器)。只是增加了额外的延迟，而不是列车撞击，因为下一跳将重定向(这不是MT)。
*源自microtik路由器的直连(连接路由)的非功能路由。雷竞技网站(类似环路的问题，幸运的是，这些目标网络通常用于路由EGP，所以99%的时间不是阻塞问题，因为大多数情况下只有路由器本身需要能够访问这些目的地)。

第一个是网络杀手。是的，我们可以通过路由到接口地址来解决问题，但这在很大程度上否定了网络中冗余的意义。

很高兴在第一端创建所有流量的pcap(对性能的影响要小得多)，但可以直接向microtik Support提供以上OSPF的原始日志(不能公开发布，但很高兴讨论和测试)。雷竞技网站

jkroon · 2022年6月4日星期六上午12:52

那么如何报告bug呢?

缺省情况下，OSPF的max-age为3600。不确定是否有可能改变这一点。

雷竞技网站Mikrotik只在上一个通告的最大年龄过期后才发送“刷新”lsa。我现在已经捕获了很多ospf流量，然后简单地查找源流量。

因此，环回地址的LSA在不同的时间被发送，但什么是普通的一天:

1.每次加载1小时后，该路由从其他路由表中删除。
2.雷竞技网站在此之后，Mikrotik发送了一段时间，在测量的情况下，间隔分别为(秒)4174、4139和4233。
3.在每一种情况下，丢弃的结束时间都与lsa的传输时间完全匹配，并且路由的移除时间都在几秒内小于3600秒。

有类似的“Transit”公告来自同一路由器，这表示相同的LS ID，然而，这些都是用来表示链路的，有趣的是，它发布回同一网络传输到另一个路由器，只有在它发布此Transit LS的同一接口上才“可见”。这些让我有点困惑，如果我把这些考虑进去，一切都会很好，就lsa的时间而言。

具体来说，只考虑从* 172.31.255.3发送的LS更新，并且只有当它包含一个LS ID 192.168.32.3(它是相关的环回地址)

在时间0时，LS更新将路由通告给它的环回。
在时间+3548 - LS更新表明它已经传输到172.31.255.2 (DR路由器，并且仅到此路由器)。
在时间+685 a Route LS再次，或4233从上面，这个中断是总共4233-3600=633计算，这大致相关的退学时间共计615秒。
+ 3480相同的过境LS更新。
+ 659再次路由LS更新，+4139秒从以前的路由LS更新，4139-3600=539，测量与ip路由监视器日志在9分钟或540秒。
+ 3491过境LS更新。
+ 683 Route LS Update，与上次Route LS Update相比+4174秒，4174-3600=574，测量值为575秒。

关于如何获得修复此实现的建议?应该是一个相对简单的计时器问题。如果我能接触到代码，我就会去挖……

jkroon · 2022年6月9日星期四下午12:22

看起来是重启解决了这个问题，所以这是一个基于时间的问题，需要重启(或者我们将继续测试)或实例重启(根据我在OSPF状态问题上的帖子)。

这需要多长时间还有待商榷。

目前，在重新启动另一个MT路由器后，似乎两者都很稳定。而且它们目前都不是DR或BDR(这取决于当前子网中的两个frr实例)。

不打算把这个问题解决了，因为坦率地说，我们最多在几周内等待它重新开始。每周重新启动生产路由器似乎也不是一个明智的答案。

jkroon · 2022年8月4日星期四12:03 am

只是给其他遇到这种情况的人一个更新——实例重启是不够的，你必须重新启动整个路由器。因此，除了最简单的用例外，唯一明智的做法是将microtik从我们的网络设置中删除。雷竞技网站

freshtechs · 2022年8月4日星期四上午7:08

我想是microtik的ospf有很多bug。雷竞技网站当你在做非常简单的事情时，它是有效的。但我认为没有完全实现，我有一个开放的票证支持，因为我注意到，如果有一个重启/实例重启涉及abr泄漏所有路由从骨干到stub/nssa区域。本质上，stub/nssa区域路由器都像骨干/area0路由器一样工作，所有的网络都在路由器上被知道，而不应该被知道。

AlexDF · 2022年8月8日星期一上午8:46

我们在混合供应商环境(Aruba, Cisco, Fortigate, PaloAlto)中实现了许多MK，并且我们没有注意到ospf (RouterOS版本6.48.6)上有任何环回路由振荡。l雷竞技能否提供有关ospf的配置摘要?亚历克斯。

jkroon · 2022年8月23日星期二下午4:38

我们在混合供应商环境(Aruba, Cisco, Fortigate, PaloAlto)中实现了许多MK，并且我们没有注意到ospf (RouterOS版本6.48.6)上有任何环回路由振荡。l雷竞技能否提供有关ospf的配置摘要?亚历克斯。

/routing ospf instance set [find default=yes] distribute-default=if-installed-as-type-1 redistribute-connected=\ as-type-1 redistribute-static=as-type-1 router-id=a.b.c。D /routing ospf interface add interface=bonding-cisco。2.路由网络类型=广播优先级=0 /路由ospf网络添加区域=骨干网=172.31.0.0/16

bonding-cisco。2的地址为172.31.255。d/24, and is a tagged vlan with id=2. cisco is named after the switch, which has no interface on vlan=2. Both MKs have the same identical config with only a.b.c.d differing.

FRR配置(x2):

接口bond0.2 IP ospf cost 10 IP ospf priority 200 exit router ospf ospf router-id A.B.C.D redistribute kernel metric-type 1 route-map view -permit-kernel redistribute connected metric-type 1 route-map view -filter-dynamic network 172.31.255.0/24 area 0 area 0 authentication message-digest exit

没有发布路由图，在两个frr实例之间，这里的路由保持不变。此外，路由MK => FRR保持不变，只有返回MK的路由被丢弃。

嗯，网络是16比24会影响事情吗?我不知道怎么做，因为这应该只在本地使用，以确定哪些接口属于哪些区域。

AlexDF · 2022年8月23日星期二晚上7:34

Hi jkroon，网络掩码/16不是问题，它只涉及到为ospf选择接口。
我不是重分配连接的粉丝，我更喜欢包含网络ip并将接口声明为被动。
在之前的帖子中，你报告了从mk到其他人的路由丢失，但现在从其他人到mk。你能澄清一下吗?
路由丢失时，ospf的调试日志如何处理?

jkroon · 2022年9月2日星期五下午6:58

Hi jkroon，网络掩码/16不是问题，它只涉及到为ospf选择接口。
我不是重分配连接的粉丝，我更喜欢包含网络ip并将接口声明为被动。
在之前的帖子中，你报告了从mk到其他人的路由丢失，但现在从其他人到mk。你能澄清一下吗?
路由丢失时，ospf的调试日志如何处理?

反过来。MK维护到其他主机的路由。

其他主机由于没有在一小时内“刷新”而失去了到MK的路由，详见之前的帖子。

我们特别不想包括其他网络并将其标记为被动，因为这些网络通常面向客户端，如果段上的另一台主机开始发布OSPF，即使是被动接口也可以加入到OSPF，我们已经看到我们的一些客户端这样做，所以这是非常危险的。Redistribute-connected做了我们需要的事情，因为它分发了直接附加的内容，并允许我们继续。

在这个阶段，我们正在认真考虑静态路由环路，并使用iBGP重新分发连接。这将变得棘手，因为我们将需要实现相当数量的额外BGP过滤，这是目前不需要的。

我将重新设置syslog到另一台主机…我们把物理主机移到了发送它的地方，但我认为这是合理的。

AlexDF · 2022年9月2日(星期五)晚7:21

嗨Jkroon

我很确定被动接口不能与同一局域网段内的主动ospf邻居加入，也不能处理任何收到的hello，因此实现这种方式是安全的，而不是重新分配连接。

无论如何，你可以做一个测试，包括环回ip编号作为ospf网络?显然在环回段上没有任何邻居。

您确定网络上没有任何环回ip或路由器id重叠吗?

亚历克斯

jkroon · 2022年9月4日星期日下午6:29

我很确定被动接口不能与同一局域网段内的主动ospf邻居加入，也不能处理任何收到的hello，因此实现这种方式是安全的，而不是重新分配连接。

据我所知，你错了。被动只是说它不会主动发送hello，但如果其他人发送hello，它肯定会加入网络。我们在网络的其他地方使用这个“功能”。

无论如何，你可以做一个测试，包括环回ip编号作为ospf网络?显然在环回段上没有任何邻居。

环回接口是安全的，因为没有人可以广播，是的，当然，我们可以测试，虽然我很确定这不会有什么不同。仍然需要重新分发连接，重新发布一堆其他/29，但如果这最终导致环回保持正常，那么当然，我们可以在考虑安全性后为其他段实现。

甚至不需要显式地使环回被动，由于没有与网桥关联的接口，默认情况下是这样。

您确定网络上没有任何环回ip或路由器id重叠吗?

如果你的意思是我确定网络上没有重复的路由器id，那么是的，我非常确定。对于重复的IP网络也是如此，所以所有路由都终止于一个不同的L2域，无论是环回域还是以太网段(在许多/大多数情况下是vlan)。

AlexDF · 2022年9月6日星期二下午5:25

很抱歉，但是我很确定被动接口不能加入任何邻接关系，也不能从其他ospf路由器接收任何路由。

根据micro雷竞技网站tik wiki:

被动的(yes | no;默认值:no)如果启用，则不发送或接收接口上的OSPF流量。

为了确定，我在实验室中重新创建了两个RouterOS设备，通过以太网接l雷竞技口连接;每个环回接口有一个ip，与路由器id相同;两者都通过以太网接口建立ospf邻接关系。

当两台路由器都将以太网接口“激活”为ospf时，loopback ip会相互交换，但是当两台路由器中只有一台将以太网接口标记为被动时，两者都松散邻接，并且都松散另一台的loopback ip路由。

确认被动是指入方向的ospf流量被丢弃，甚至在其他品牌的手册中也确认了这一点。

亚历克斯

jkroon · 2022年9月12日星期一晚上10:12

很抱歉，但是我很确定被动接口不能加入任何邻接关系，也不能从其他ospf路由器接收任何路由。

根据micro雷竞技网站tik wiki:

被动的(yes | no;默认值:no)如果启用，则不发送或接收接口上的OSPF流量。

好的，我将重新测试和验证。谢谢。

mducharme · 2022年9月13日星期二凌晨2:46

我只是想说我完全同意@AlexDF的观点。我发现当通过OSPF->网络发布所有内容并关闭再分发时，OSPFv2在M雷竞技网站ikroTik上非常防弹。而且，如果你之前把接口设置为被动的，并且你已经形成了邻居关系，那么就真的有问题了，因为这不应该发生。

我建议将接口“all”设置为被动，这将导致默认为被动，除非接口被明确定义为非被动。

jkroon · 2022年9月15日星期四凌晨1:11

很抱歉，但是我很确定被动接口不能加入任何邻接关系，也不能从其他ospf路由器接收任何路由。

根据micro雷竞技网站tik wiki:

被动的(yes | no;默认值:no)如果启用，则不发送或接收接口上的OSPF流量。

好的，我将重新测试和验证。谢谢。

所以我可以确认你的理解。包括其他路由器品牌，似乎大多数都是这样操作的，所以我们深入研究了被动的东西，我们不能重现我们以前有被动接口的方式，我们推测NMBA可能已经参与了，在无线网桥上正确传输，不能很好地处理多播流量。

现在，我们通过iBGP重新分发连接的和静态的数据(我们希望避免这种情况)。并且重新分发连接和静态现在已禁用OSPF方。我们可以使用被动接口策略完成连接，但这不适用于静态(不幸的是，我们需要静态，因为一些对等体拒绝使用eBGP并坚持静态路由)。

我只是想说我完全同意@AlexDF的观点。我发现当通过OSPF->网络发布所有内容并关闭再分发时，OSPFv2在M雷竞技网站ikroTik上非常防弹。而且，如果你之前把接口设置为被动的，并且你已经形成了邻居关系，那么就真的有问题了，因为这不应该发生。

我建议将接口“all”设置为被动，这将导致默认为被动，除非接口被明确定义为非被动。

谢谢后一个提示。这很有用。

这不是我们第一次在Mikrotik上使用高度不稳定的OSPFv2，即使是p2p的“以太网”链路(即，只有a /30路由雷竞技网站的网络上的OSPFv2)，我们实际上已经编写了脚本来检测坏的OSPF状态并自动纠正。不幸的是，这些检查在这里根本不起作用。这是一个完全不同的网络，我们咨询的一家公司想出了一个“每周重启一次”的计划，在凌晨2点重启他们网络中的所有路由器板，以缓解同样的问题。ios版雷竞技官网入口不幸的是，当你有路由器在核心位置时，这样做是不可能的。即使是版本升级也要仔细检查，看看它们是否真的需要，因为在这些路由器上安排5分钟的重启停机时间都是有问题的，不管晚上是什么时候。而重新填充BGP表需要相当长的时间。microt雷竞技网站ik会将FRR合并到路由器中，然后继续前进。l雷竞技

mducharme · 2022年9月15日星期四上午5:58

而重新填充BGP表需要相当长的时间。microt雷竞技网站ik会将FRR合并到路由器中，然后继续前进。l雷竞技

你是在将RouterOS v6与其l雷竞技他平台进行比较，而不是将RouterOS v7与其他平台进行比较，因为RouterOS v7从头开始重写了整个路由堆栈，包括所有协议。您会发现这些问题中的大多数在v7中都消失了，尽管由于堆栈是新的，当然还有一些新的错误正在解决。

jkroon · 2022年9月15日(星期四)上午8:20

而重新填充BGP表需要相当长的时间。microt雷竞技网站ik会将FRR合并到路由器中，然后继续前进。l雷竞技

你是在将RouterOS v6与其l雷竞技他平台进行比较，而不是将RouterOS v7与其他平台进行比较，因为RouterOS v7从头开始重写了整个路由堆栈，包括所有协议。您会发现这些问题中的大多数在v7中都消失了，尽管由于堆栈是新的，当然还有一些新的错误正在解决。

这是真的。我们现在正在采购两台新的RouterOS7路由器(现有的将l雷竞技被转移到新的POP上)。我们只是还没有勇气全部迁移到RouterOS v7。l雷竞技我们将在接下来的两到四周内开始采购，并开始将服务和对等节点逐一迁移到两个新的CCR路由器上。我们考虑过使用其他工具，但最终还是决定暂时使用microtik。雷竞技网站

在新配置的稳定性方面:

> /routing ospf export # sep/15/2022 07:14:23 by l雷竞技RouterOS 6.49.雷电竞app下载官方版苹果6 # software id= 22X0-517R # # model = CCR1016-12S-1S+ /routing ospf instance set [find default=yes] distribute-default=if-installed-as-type-1 router-id=loop_ip /routing ospf interface add interface=bonding-cisco。2.路由网络类型=广播优先级=0 /路由ospf网络添加区域=骨干网络=172.31.0.0/16添加区域=骨干网络=loop_ip/32

我们没有看到任何改善。

2.2.09-15 00:20:16: ospf 2.2.09-15 01:51:01: BGP 2.2.09-15 02:01:01: ospf 2.2.09-15 03:37:01: BGP 2.2.09-15 04:31:01: ospf 2.2.09-15 05:31:01: BGP 2.2.09-15 06:01:01: ospf 2.2.09-15 06:17:01: BGP 2.2.09-15 06:18:02: ospf

用来跟踪这个的代码:

# !/bin/bash loop_ips =(... ... ...) ip在" $ {loop_ips[@]}”做cproto = (ip ro sh ip / 32美元| sed负阻元件/ ^。*原型  ([^ ]+)( .*)?$/\ 1 / p”)lproto = $(美元尾n1。ip。原型| sed -re 's/。* //') [[ "${ cproto} " ! = " $ {lproto}“]]& &日期”+ % F % T: $ {cproto} " > >。美元的ip。原型完成

目前，至少循环不会无法到达，虽然目前的解决方案无法扩展(这是一个问题)，但至少我们是可操作的。

AlexDF · 2022年9月15日星期四上午9:41

无论如何，我只能确认RouterOS 6.48.6在混合品牌环l雷竞技境下是可以的。在我们的核心网络中，我们有microtik CCR设备与雷竞技网站Cisco, Aruba, Fortigate和其他公司进行通信，并且邻居关系已经上升了许多天，应该有其他方面需要评估。

设备间ospf定时器是否相等?例如，我们在使用缺省(隐式)ospf定时器的FortiOS v7.0.6中遇到了一个ospf振荡问题，我们需要显式地配置它们。
是否有任何中间交换设备(或ospf设备内部的交换逻辑)可以限制组播数据包，如速率限制，igmp snooping等?

亚历克斯

jkroon · 2022年9月15日星期四上午10:41

无论如何，我只能确认RouterOS 6.48.6在混合品牌环l雷竞技境下是可以的。在我们的核心网络中，我们有microtik CCR设备与雷竞技网站Cisco, Aruba, Fortigate和其他公司进行通信，并且邻居关系已经上升了许多天，应该有其他方面需要评估。

邻里关系似乎永远不会重置……只有维护路由的LSA才会刷新。

设备间ospf定时器是否相等?例如，我们在使用缺省(隐式)ospf定时器的FortiOS v7.0.6中遇到了一个ospf振荡问题，我们需要显式地配置它们。
是否有任何中间交换设备(或ospf设备内部的交换逻辑)可以限制组播数据包，如速率限制，igmp snooping等?

没有配置显式定时器，所有定时器都依赖于默认的(标准指定的)定时器，我以前研究过这个问题，唯一可以真正混淆的定时器是hello定时器，这些计时器会导致建立不匹配的失败，就像MTU一样。澄清一下，两个FRR实例:

配置定时器间隔，Hello 10秒，死亡40秒，等待40秒，重传5

两个Mikroti雷竞技网站ks:

Retransmit-interval =5s transmit-delay=1s hello-interval=10s dead-interval=40s

根据文档，传输延迟和等待计时器似乎是不同的东西，并且不会影响协议。等待时间导致FRR在重新计算之前等待此时间(https://docs.frrouting.org/en/latest/ospfd.html)，其中Mikr雷竞技网站otik只是说“链路状态传输延迟是在接口上传输链路状态更新数据包所需的估计时间”——实际上什么也没说。该标准规定lsa的有效期为3600秒，每1800秒必须重传一次，并且必须使用重传间隔在传输时获得ack。换句话说，Mikrotik必须每雷竞技网站半小时为lsa发送(和接收)一次ack。它不会这样做。希望RoS7能够修复这个问题，因为BGP设置现在已经非常丑陋了，我们真的很想再次清理它。

就广播和多播的速率限制而言，现在(昨晚)已经设置为接口容量的1%的速率限制，以减轻外部对等体(不在我们的直接控制之下)的问题，这些问题正在搞乱并引起问题。

1%听起来并不多，直到我提到这个设置中涉及的所有端口都是10G，所以每个端口允许100Mbps的广播和另外100Mbps的多播流量。其中大多数是LACP到CISCO Nexus对上的vpc，所以可能高达20G，但我相信广播流量将根据LACP出口散列策略散列到一个或另一个链路上。

我相信我之前也发布了MT日志，显示它不发送LSA刷新。在任何时候都适当地保持邻接。

mducharme · 2022年9月15日(星期四)下午3:00

换句话说，Mikrotik必须每雷竞技网站半小时为lsa发送(和接收)一次ack。它不会这样做。

你好,

我不明白。这对我来说没有意义的原因是我们在RouterOS上使用OSPFv2的唯一问题是，在某些情况下，在收到所有LSA之前，它过早地进入“full”状态。l雷竞技有时它收到的lsa很少，路由表大部分是空的，有许多东西不可达。在这种情况下，需要半个小时的时间，路由表才会变得完整，并且所有丢失的路由都出现，没有丢失。如果这是真的，MikroTik没有发送L雷竞技网站SA的每半个小时，我不明白为什么半小时是“神奇”的时期，我们的路由器突然有了所有的路由，之后就没事了。

AlexDF · 2022年9月16日(星期五)晚上7:20

我重新创建了一个小实验室，连接两个RouterOS设备(v.6.48.6)，通过以太网接口l雷竞技连接设备;每个环回接口有一个ip，与路由器id相同;两者都通过以太网接口建立ospf邻接关系。然后我捕获了它们之间9个小时的以太网通信。

我确认:

-它们不会失去邻接，因为hello数据包每隔10秒发送一次
-由于每30分钟定期发送LSA更新并通过LSA ack从对面设备确认，它们不会丢失远程路由到环回

因此可以肯定的是，ospf协议本身没有实现错误，但在您的场景(设备或配置)中存在一些特定的问题。

如果可用，您能否尝试将备用CCR互连到备用FRR以重现最小场景?

jkroon · 2022年10月25日星期二下午2:16

我重新创建了一个小实验室，连接两个RouterOS设备(v.6.48.6)，通过以太网接口l雷竞技连接设备;每个环回接口有一个ip，与路由器id相同;两者都通过以太网接口建立ospf邻接关系。然后我捕获了它们之间9个小时的以太网通信。

我确认:

-它们不会失去邻接，因为hello数据包每隔10秒发送一次
-由于每30分钟定期发送LSA更新并通过LSA ack从对面设备确认，它们不会丢失远程路由到环回

因此可以肯定的是，ospf协议本身没有实现错误，但在您的场景(设备或配置)中存在一些特定的问题。

如果可用，您能否尝试将备用CCR互连到备用FRR以重现最小场景?

我看看能不能安排一下。很抱歉没电了，我要处理一些其他的事情。

OSPF“丢弃”(来自MT的路由从网络的其余部分被丢弃)

OSPF“丢弃”(来自MT的路由从网络的其余部分被丢弃)

Re: OSPF“dropouts”(来自MT的路由从网络的其他部分被丢弃)

Re: OSPF“dropouts”(来自MT的路由从网络的其他部分被丢弃)

Re: OSPF“dropouts”(来自MT的路由从网络的其他部分被丢弃)

Re: OSPF“dropouts”(来自MT的路由从网络的其他部分被丢弃)

Re: OSPF“dropouts”(来自MT的路由从网络的其他部分被丢弃)

Re: OSPF“dropouts”(来自MT的路由从网络的其他部分被丢弃)

Re: OSPF“dropouts”(来自MT的路由从网络的其他部分被丢弃)

Re: OSPF“dropouts”(来自MT的路由从网络的其他部分被丢弃)

Re: OSPF“dropouts”(来自MT的路由从网络的其他部分被丢弃)

Re: OSPF“dropouts”(来自MT的路由从网络的其他部分被丢弃)

Re: OSPF“dropouts”(来自MT的路由从网络的其他部分被丢弃)

Re: OSPF“dropouts”(来自MT的路由从网络的其他部分被丢弃)

Re: OSPF“dropouts”(来自MT的路由从网络的其他部分被丢弃)

Re: OSPF“dropouts”(来自MT的路由从网络的其他部分被丢弃)

Re: OSPF“dropouts”(来自MT的路由从网络的其他部分被丢弃)

Re: OSPF“dropouts”(来自MT的路由从网络的其他部分被丢弃)

Re: OSPF“dropouts”(来自MT的路由从网络的其他部分被丢弃)

Re: OSPF“dropouts”(来自MT的路由从网络的其他部分被丢弃)

Re: OSPF“dropouts”(来自MT的路由从网络的其他部分被丢弃)

Re: OSPF“dropouts”(来自MT的路由从网络的其他部分被丢弃)

Re: OSPF“dropouts”(来自MT的路由从网络的其他部分被丢弃)

谁在线?