为了提高数据库访问速度，在局域网中另一台电脑上设置了从库，并绑定了固定的内网 ip 。但不知为何会经常 ping 不通（反过来也 ping 不通），同时两台电脑都能正常上外网。 ping 的提示信息是 Request timeout ，有时会出现 Host is down 。 按照网上的信息排查了一下，设置里防火墙是关着的（系统是 mac ），ping 路由器也没问题
都说经常 ping 不通，也许有 arp 病毒。 在 windows 遇到水星出的无线网卡互相 ping 不到。最后在每台电脑开机用 netsh 把两张无线网卡 mac 和 ip 对应关系写在开机脚本才永久解决了时通时不通，至今不知道为什么 。
搭车问下，局网内，有时 ping 的到，又是 ping 不到，如果用 ip 访问远程桌面，第一次连不到，出提示，关掉远程桌面窗口，重连一下就上去了，是什么原因？远程桌面用目标计算机名访问也是有概率第一次连不上。
这种可以上网查找一下 arp 实现过程，最好带上交换机型号。 像使用的 s5720s-li 52p pwr 。它的很多默认设定就是不适合 ap 环境，像终端在不同端口飘移会导致被抑制 经常要向同事解释一些我自己都觉得说不通的问题。 今天在立式线，10 米以内就有两个 AP 。笔记本出现了断了又信号非常好的情况，可是网络不通。。。当时是在同步文件时，突然没有下载速度。从距离和信号强度判断不应该发生的事，但当时就是这样。当然这种情况平时发生多半通过禁用 /修复无线网卡就可以了。 然后这几天测试接在 vlan5 的无线打印机时，vlan1 的电脑时通时不通。包括一直反应的车间打印机时通时不通。。。那台打印机就是从 xp 换成 win7 什么也没动，然后一直被反应经常打印不出来。在老厂就有长时间打印机睡着问题就想通过计划任务定期去唤醒打印机，好像最终也没结果。 之前遇到的同一 ap 上两台电脑互相 ping 不通，通过互相指定静态 arp 解决。同一端口怀疑接入 ap 点，因为客户端数量增加而导致的端口速率抑制问题。 最近这个时通时不通就不好解释了。晚上查了这个 mac 地址飘移问题，按文档解释是针对网络环网情况。至于无线终端通过不同接口漫游导致的 mac 地址飘移属于正常现象，通过日志分析，也确实都是在 ap 连接的端口做飘移。只是今天才看到这个选项里怎么有一个 quit vlan recover time,从字面上解释，退出 vlan 的恢复时间 10 分钟这是什么意思。似乎挺符合那个时通时断的现象，又有点说不通，必竟现场的终端在时刻移动中。那不就成 10*N 。也许又通过 mesh 的路由协议到达网络目的地。 今天被同事问到无线不好，要不要换宽带。。。要学会花钱，连原因都判断错，那就成乱花钱。确实也一直在强调通过花钱来提升工作效率。整天被怨电脑不行，网络不行这个不行，那个不行。哎，严重阻挡别人的工作效率，该换的陈年老古董就该换了。这么多可能，万一换了没效果谁来背锅。。。 最后在 dis anac-address flapping 将 vlan5 AP 加入 exclude vlan list 。应该还有一个问题，这些问题都是在使用了两年以后才发现，可能之前用 mesh,网状结构自行解决了一些。
今天又被叫去处理 2L4 处的 AP 断线问题，该处有 3 台电脑通过无线连接。由于其它 2 台电脑正常，另外一台頻繁出现掉线，用排除法的话多数为笔记本有问题。由于在现场笔记本頻繁的 ERP 断开，进入设备 AP 管理页面工作不到 49 天，却用掉了 swap 内存，最后无奈只能以重启 AP 结束。 终于忍无可忍对 Auto port-defend started.问题进行处理。之前在华为论坛询问关于该日志到底是端口抑制功能还是关闭功能，没有人给出准确的回答。这几天 google 了一下，部分文档提到了在启用 auto port-defend 时，系统将以 75%预设 CBR 速率进行工作。所以这应该属于端口抑制并不是关闭功能。由于华为交换机型号非常多，自己也不敢在业务系统上进行验证，想当然的就是这样了呗。 背景信息 如果某个端口下存在攻击者发起 DoS 攻击，从该端口上送 CPU 处理的大量恶意攻击报文会挤占带宽，导致其他端口的协议报文无法正常上送 CPU 处理，从而造成业务中断。 通过部署基于端口的防攻击功能，可以有效控制从端口上送 CPU 处理的报文数量，以防御针对 CPU 的 DoS 攻击。 该功能默认已使能。只有端口防攻击功能在已使能的情况下，才允许配置端口防攻击的其他相关功能。 s5720s-li 默认启用了 auto-defend 针对 source-mac/source-ip 特定的终端出现发包异常以后的自动防护处理。auto-port-defend 这个则是针对该端口，由于 AP 上接入了大量终端，很可能在这 AP 上的大量终端因为其中的一个终端发包有问题就导致该端口出现发包抑制，那么该端口上的其它的终端也可能连带出现网络异常。 观察了 display auto-defend attack-source history 并未出现办公用笔记本有发包超限记录所以不启用 whitelist 管理。简单的关闭 auto port-defend 功能，通过 auto-defend 对所有终端进行超过 60pps 以后发包抑制。感觉网络又快了点，希望这次能彻底解决无线网络问题。 display cpu-defend configuration all display auto-defend attack-source display auto-defend attack-source history display auto-defend attack-source detail display auto-port-defend whitelist display auto-port-defend attack-source display auto-port-defend statistics reset auto-port-defend statistics display arp static 使用实例 # 创建名称为 test 的防攻击策略。 system-view [HUAWEI] cpu-defend policy test [HUAWEI-cpu-defend-policy-test]display cpu-defend policy [HUAWEI-cpu-defend-policy-test]display cpu-defend policy test [HUAWEI-cpu-defend-policy-test] display cpu-defend configuration all #查看默认 [HUAWEI-cpu-defend-policy-test] dis this auto-defend enable auto-defend attack-packet sample 5 auto-defend threshold 60 #非 60 就有显示 auto-defend trace-type source-mac source-ip #默认不包含 source-portvlan auto-defend protocol arp icmp dhcp igmp tcp telnet 8021x undo auto-port-defend enable quit #cpu-defend-policy test #报错，似乎是无效规则。Info: Only car configuration can be activated on main control unit. cpu-defend-policy test global display auto-defend attack-source detail display auto-defend attack-source history [Switch]display auto-port-defend configuration Info: Auto port defend is disabled on slot 0. [Switch] # 将源 IP 地址为 10.1.1.1 和 10.1.1.2 的用户加入攻击溯源的白名单。 system-view [HUAWEI] acl 2000 [HUAWEI-acl-basic-2000] rule permit source 10.1.1.1 0 [HUAWEI-acl-basic-2000] rule permit source 10.1.1.2 0 [HUAWEI-acl-basic-2000] quit [HUAWEI] cpu-defend policy test [HUAWEI-cpu-defend-policy-test] auto-defend enable [HUAWEI-cpu-defend-policy-test] auto-defend whitelist 1 acl 2000 display auto-port-defend whitelist Auto port-defend started. 3L5 Jun 3 2020 08:49:19 GigabitEthernet0/0/3 3L6 Jun 3 2020 11:42:17 GigabitEthernet0/0/9 2L4 Jun 3 2020 07:37:25 GigabitEthernet0/0/25 Jun 3 2020 08:01:36 GigabitEthernet0/0/25 Jun 3 2020 09:06:27 GigabitEthernet0/0/25 Jun 3 2020 11:58:33 GigabitEthernet0/0/25 Jun 3 2020 12:27:16 GigabitEthernet0/0/25 Jun 3 2020 12:52:15 GigabitEthernet0/0/25 2L3 Jun 3 2020 08:02:18 GigabitEthernet0/0/29 Jun 3 2020 08:47:16 GigabitEthernet0/0/29 Jun 3 2020 11:02:18 GigabitEthernet0/0/29 Jun 3 2020 11:46:23 GigabitEthernet0/0/29 Jun 3 2020 11:54:59 GigabitEthernet0/0/29 Jun 3 2020 14:07:37 GigabitEthernet0/0/29 1L2 Jun 3 2020 12:14:54 GigabitEthernet0/0/37 1L3 Jun 3 2020 12:56:30 GigabitEthernet0/0/41
