三国R1P1 导致主交换机无法连接

kajisan

在升级到三国R1P1 之后经常出现断网状态。
断网时无法访问中心交换机。
后来去掉PA之后就一切恢复正常。。

PA是连接在 中心交换机  到 出口路由 中间的。。不知道为什么会导致中心交换机都出错。。。

之前的版本没问题。。

kajisan

仿佛记得升级之后开启过伪ip防御。。
关闭了看看效果先。。

tomasi17

效果如何？

kajisan

还是会出现整个主交换机无法连接的情况，频率说不清楚是降低还是没变。 (症状就是其他所有机器ping 主交换机ip 都timeout)

没有接PA的话不会出现这个情况。。网络情况大概是

我的机器->其他交换机--->主交换机--PA网桥1->主路由
                      |-------------------------->PA管理口

因此出现故障的时候我登录pa都是正常的。只看见了流量大幅度下降。

kajisan

这个是到网桥的端口信息
FastEthernet3/3 is up, line protocol is up (connected)
  Hardware is Fast Ethernet Port, address is 0004.4d90.ec66 (bia 0004.4d90.ec66)
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
     reliability 255/255, txload 9/255, rxload 18/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 100Mb/s, link type is auto, media type is 10/100BaseTX
  input flow-control is unsupported output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input never, output never, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 228689
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 7243000 bits/sec, 946 packets/sec
  5 minute output rate 3763000 bits/sec, 839 packets/sec
     25981114690 packets input, 18887752634089 bytes, 0 no buffer
     Received 9953100 broadcasts (8782716 multicast)
     51472 runts, 0 giants, 0 throttles
     408609 input errors, 357137 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     27587808030 packets output, 22101725282446 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     1 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

这个是到上面那个回复的其他交换机的端口信息
FastEthernet3/4 is up, line protocol is up (connected)
  Hardware is Fast Ethernet Port, address is 0004.4d90.ec67 (bia 0004.4d90.ec67)
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 100Mb/s, link type is auto, media type is 10/100BaseTX
  input flow-control is unsupported output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input never, output never, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 12646
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 301000 bits/sec, 51 packets/sec
  5 minute output rate 54000 bits/sec, 53 packets/sec
     6757026346 packets input, 6917165866362 bytes, 0 no buffer
     Received 11328993 broadcasts (7817749 multicast)
     1 runts, 0 giants, 0 throttles
     4 input errors, 3 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     5777589486 packets output, 2872246654569 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     1 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

看不出来有什么问题啊。。

kajisan

每次被断开的时间都是1分钟左右。非常有规律。。。

kajisan

来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
请求超时。
请求超时。
请求超时。
请求超时。
请求超时。
请求超时。
请求超时。
来自 10.1.60.254 的回复: 字节=32 时间=12ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间=2ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间=4ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
请求超时。
请求超时。
请求超时。
请求超时。
请求超时。
请求超时。
请求超时。
来自 10.1.60.254 的回复: 字节=32 时间=4ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间=3ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间=3ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间=1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间=1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间=4ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间=1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间=1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间=1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间=1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间=1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间=2ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
请求超时。
请求超时。
请求超时。
请求超时。
请求超时。
请求超时。
请求超时。
来自 10.1.60.254 的回复: 字节=32 时间=2ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间=2ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间=3ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间=10ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间=2ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间=1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间=1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间<1ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间=16ms TTL=255
来自 10.1.60.254 的回复: 字节=32 时间=1ms TTL=255

10.1.60.254 的 Ping 统计信息:
    数据包: 已发送 = 229，已接收 = 208，丢失 = 21 (9% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 0ms，最长 = 27ms，平均 = 1ms
Control-C
^C
C:\Users\Administrator>

每次被阻断的时间都很短。。。。。。。但我在pa的策略里面根本没有阻断策略啊。只有限速策略。。
只有接了PA之后才会出现。。。我现在去升级到旧版本看看还会不会出现。。

kajisan

换回旧版本48小时。。故障没有再现。。看来确实问题出在三国R1P1上。。

beta没敢测试。。

proe

我这也出问题，回到R1，如果再出问题就换版本了