arp攻击解决方法 当网络时断时续，网页弹出各种出错ping内网关request out时断时续，考虑网络arp病毒；装个arp防火墙，找出攻击源，离线杀其毒，清除网内ARP表，然后路由，绑定arp网关及各主机对应mac，有效解决arp病毒广播，划分vlan或实行主机pppoe拔号上网，主机上相关操作cmd 里@echo offarp -darp -s ip macarp -a路由上(cisco)clear ip arparp ip mac arpa int f0/1dhcp snooping enableip source binding vlan 10 ip mac int f0/1show arp|include 攻击源mac华为、H3C路由器上display arp XXX 待更新  

服务做两台Exchange CAS的集群配置完NLB后发现同网段访问正常跨网段不通 问题描述:微软的NLB（网络负载均衡）服务做两台Exchange CAS（Client Access Server）的集群，配置完NLB后发现同网段访问正常，跨网段都无法访问，甚至在NLB网段的网关上都无法访问。拓扑如下：故障截图：处理过程:1.首先尝试从网关S7700上ping NLB虚地址10.16.68.254，发现不通。同网段都不通，最常见的原因就是没有对应的ARP记录。2.然后在网关上查看10.16.68.254的ARP记录，发现果然没有学习到。3.在同网段某台服务器上通过arp –a查看10.16.68.254的ARP记录，发现是组播MAC 03bf-xxxx-xxxx。一般在设备没有启用组播服务或者IGMP监听的情况下，网关设备是不处理组播ARP对应的报文的。根因根据MAC地址的规范，最高位是1时代表组播地址，0是为单播地址。所以0x03开头的地址为组播地址，网络设备在没有启用组播和IGMP侦听的情况下，网关设备不处理组播ARP对应的报文的。由于缺少二层ARP解析，造成三层无法ping通。解决方案通过在网关上手工静态绑定ARP记录。建议与总结根据MAC地址的规范，0x01,03,05,07开头的都是组播MAC地址，而我们最熟悉的组播MAC地址为01-00-5e开头，由此可能会造成思维定式，认为只有01-00-5e开头才是组播MAC。 有 

网络中MAC漂移障案例 问题描述1、网络异常时S9700 log 上报MAC 地址飘移； 2、网管监控到S9700 CPU 利用率超过阈值； 3、S9700 作为网关，下挂用户ping 不通网关。告警信息 Jul 23 2017 07:14:24+08:00 9700_01 L2IFPPI/4/MFLPVLANALARM:OID 1.3.6.1.4.1.2011.5.25.160.3.7 MAC move detected, VlanId = 853, MacAddress = 0080-87db-a942, Original-Port = GE11/0/44, Flapping port = Eth-Trunk1. Please check the network accessed to flapping port. Jul 23 2017 07:14:28+08:00 9700_01 L2IFPPI/4/MFLPVLANALARM:OID 1.3.6.1.4.1.2011.5.25.160.3.7 MAC move detected, VlanId = 850, MacAddress = 78e7-d1d2-de12, Original-Port = GE12/0/44, Flapping port = Eth-Trunk1. Please check the network accessed to flapping port. Jul 23 2017 07:17:16+08:00 9700_01 �FD/6/CPCAR_DROP_LPU(l)[85839]:Rate of packets to cpu exceeded the CPCAR limit on the LPU in slot 8. (Protocol=vrrp, ExceededPacketCount=011850) Jul 23 2017 07:17:16+08:00 9700_01 �FD/6/CPCAR_DROP_LPU(l)[85840]:Rate of packets to cpu exceeded the CPCAR limit on the LPU in slot 8. (Protocol=dhcp-server, ExceededPacketCount=042) Jul 23 2017 07:17:16+08:00 9700_01 �FD/6/CPCAR_DROP_LPU(l)[85841]:Rate of packets to cpu exceeded the CPCAR limit on the LPU in slot 9. (Protocol=vrrp, ExceededPacketCount=014381)处理过程 1、分析S9700_01 和S9700_02 的日志。 日志显示在发生MAC 漂移前，S9700_01 的端口GE9/0/42 置为forwarding，并且 是从discarding 状态超时15s 变成learning，再经过15s 变成forwarding 状 态。这说明此时对端没有发送STP 报文，可能是对端端口去使能了STP，或者其 他原因导致发包异常。继续分析对端设备AS_23 的信息进行确认。 Jul 23 2017 07:13:10+08:00 S9700_01 %MSTP/6/SET_PORT_DISCARDING(l)[85836]:In MSTP process 0 instance 0, MSTP set port GigabitEthernet9/0/42 state as discarding. --- 9/0/42 端口discarding Jul 23 2017 07:13:25+08:00 S9700_01 %MSTP/6/SET_PORT_LEARNING(l)[85837]:In process 0 instance 0, MSTP set port GigabitEthernet9/0/42 state as learning. ---端口 learning Jul 23 2017 07:13:40+08:00 S9700_01 %MSTP/6/SET_PORT_FORWARDING(l)[85838]:In MSTP process 0instance 0, MSTP set port GigabitEthernet9/0/42 state as forwarding. --- 端口forwarding Jul 23 2017 07:14:24+08:00 S9700_01 L2IFPPI/4/MFLPVLANALARM:OID 1.3.6.1.4.1.2011.5.25.160.3.7 MAC move detected, VlanId = 853, MacAddress = 0080-87db-a942, Original-Port = GE11/0/44, Flapping port = Eth-Trunk1. Please check the network accessed to flapping port. --- 产生mac 漂移2、分析友商AS_23 的日志。 S9700_01 的端口GE9/0/42 对端是友商交换机AS_23 的端口E1/0/47。 根据该设备的日志，在发生MAC 漂移前，一个端口突然变成learning 状态，4s 后端口进入Forwarding 状态，且根桥切换成自己。在网络中存在更高优先级设 备的情况下，根桥切换成自己，通常是因为链路拥塞或单板故障导致收不到报文 或者报文不上送，STP 超时将端口置为Forwarding 状态，但是从learning 到 Forwarding 的时间根据标准是15s。而这里只有4s，且配置中没有修改定时器， 是该设备STP 产生了故障。 %Jul 23 07:14:23 2017 MODULE_L2_MSTP[tMstp]:MSTP set port = 48, mst = 0 to LEARNING! --- 端口learning %Jul 23 07:14:27 2017 MODULE_L2_MSTP[tMstp]:MSTP set port = 48, mst = 0 to FORWARDING! ---4s 后端口forwarding %Jul 23 07:14:28 2017 MODULE_L2_MSTP[tMstp]:Root bridge has been changed. PRS is triggered: INSTANCE=0 --- 根桥发生变化 %Jul 23 07:14:28 2017 MODULE_L2_MSTP[tMstp]:CistRoot = 32768.00:01:7a:f8:00:45, CistRegRoot = 32768.00:01:7a:f8:00:45 --- 以本设备为根桥 AS_23 端口突然进入Forwarding 状态，以自己为根桥向S9700_01 发送报文， S9700_01 的9/0/42 端口收到优先级低于本设备的报文，进入discarding 状态 （见步骤1 的日志），并向AS_23 发送高优先级报文。AS_23 收到报文后会重新 以S9700_01 为根桥（见下面日志），并停止向S9700_01 发送报文，因此后续 S9700_01 的9/0/42 端口不再收到报文，15s 超时进入learning 状态，再经过 15s 超时进入forwarding 状态（见步骤1 的日志）。 %Jul 23 08:57:58 2017 MODULE_L2_MSTP[tMstp]:Root bridge has been changed. PRS is triggered: INSTANCE=0 ---根桥发生变化 %Jul 23 08:57:58 2017 MODULE_L2_MSTP[tMstp]:CistRoot = 0.d8:49:0b:8c:e4:a0, CistRegRoot = 32768.00:01:7a:f8:00:45 ---根桥恢 复成原来的S9700_01 至此，可以证明是AS_23 发生故障，端口forwarding，导致S9700_01 端口状态 震荡1 次，并产生MAC 漂移。2、将AS_23 连接S9700_01 上行口shutdown 后环路破除，网络恢复。 3、4、因组网为VRRP+RSTP，将AS_23 连接S9700_01 上行口shutdown 为临时解 决办法，后客户将AS_23 设备替换，测试正常。 根因 设备上报MAC 地址飘移，同时CPU 利用率高，下挂用户ping 不通网关，一般网 络有环路导致广播风暴，需要及时破除环路。 建议与总结 如果设备同时上报MAC 地址飘移，CPU 利用率高，协议报文CPCAR 丢包，一般为 网络中出现环路。在局域网中环路对网络稳定性影响较大，需要及时破除环路。 

SecureCRT终端通过串口线登陆问题 问题描述:客户同时采购AR1200-S 路路由器器和S5724TP-SI 交换机组建公司⼩小型园区⽹网络，⾸首次使⽤用SecureCRT 终 端⼯工具通过串串⼝口线本地登陆对设备进⾏行行配置，SecureCRT 默认配置，登陆AR1200-S 路路由器器⼀一切正常， 同样的串串⼝口线、PC 和终端⼯工具登陆S5700 交换机只能输出信息，却完全⽆无法输⼊入命令⾏行行进⾏行行操作。处理理过程 1、客户最开始使⽤用的是标配AR1200-S 路路由器器的串串⼝口线登陆S5700 交换机，换成S5700 标配的串串⼝口线 后问题重现，同时这条串串⼝口线登陆AR 路路由器器正常，排除串串⼝口线问题； 2、S5700 交换机console ⼝口损坏，重启交换机，重启过程的打印信息输出正常，且交换机启动⼀一切正 常： BIOS LOADING ... Copyright (c) 2008-2010 HUAWEI TECH CO., LTD. (Ver127, Apr 11 2012, 10:27:20) Press Ctrl+B to enter BOOTROM menu... 0 Auto-booting... Update Epld file ............................ None Update FansCard file ........................ None Decompressing VRP software .................. done USB2 Host Stack Initialized. USB Hub Driver Initialized USBD Wind River Systems, Inc. 512 Initialized EHCI Controller found. Waiting to attach to USBD... USB_MODE_REG=0x3 Done. usbPegasusEndInit () returned OK 0x62ffe68 (tRootTask): usbBulkDevInit () returned OK PPI DEV SysInit......OK Vrrp cmd disable... BFD cmd disable...Hard system init.................OK Begin to start the system, please waiting ...... VOS VFS init.....................OKVOS monitor init.................OK CFM init advance.................OK PAT init ........................OK HA S2M init......................OK VOS VFS init hind ...............OK VRP_Root begin... VRP_InitializeTask begin... Init the Device Link.............OK CFG_PlaneInit begin..............OK CFM_Init begin...................OK CLI_CmdInit begin................OK VRP_RegestAllLINKCmd begin.......OK create task begin................ task init begin... Recover configuration...OK! Press ENTER to get started. 排除console ⼝口损坏； 3、检查SecureCRT 登陆配置，客户采⽤用默认配置：流控选项⾥里里选择了了RTS/CTS，将此流控选项去掉，保证流控为⽆无，之后再次登陆S5700 交换机，恢复 正常，可以正常输⼊入输出，进⾏行行配置等操作。 根因 1、串串⼝口线损坏 2、S5700 交换机console ⼝口损坏 3、SecureCRT 设置错误 建议与总结 采⽤用SecureCRT 终端⼯工具本地登陆AR 路路由器器与S5700 交换机时，流控选项⾥里里，勾选RTS/CTS 时， 登陆AR 路路由器器正常，但是对于S5700 交换机，必须将流控位全部去掉，才能正常登陆交换机。建议 采⽤用SecureCRT 登陆AR 路路由器器和S 系列列盒式交换机时，流控位全部勾掉，可保证都能正常登陆。 

华为话务台C803CTX振铃无声音提示解决方法 √> 华为话务台C803CTX/C802CTX用户打进来振铃无提示声音，话务台界面右下角声音提示无法勾选？华为话务台C803CTX振铃无声音提示解决方法下面先让我滑稽一下 ::aru:insidious:: 然后再到正文好了该正文了-.-下图是问题描述首先 点击-菜单栏-系统管理-解锁配置然后会发现有个框框弹出来让你输入密码，默认为空 直接回车即可。此时 声音提示就可以勾选啦这样声音就正常了版权声明：本文由刘大喵创作，转载时须注明出处及本声明。 本文链接：https://www.ledo.cc/605.html 友情提示：感谢阅读，如有错误，欢迎指正。

ASCII 码查询 ASCII 码查询＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 大写字母的 ASCII 码：值 描述 65 A 键 66 B 键 67 C 键 68 D 键 69 E 键 70 F 键 71 G 键 72 H 键 73 I 键 74 J 键 75 K 键 76 L 键 77 M 键 78 N 键 79 O 键 80 P 键 81 Q 键 82 R 键 83 S 键 84 T 键 85 U 键 86 V 键 87 W 键 88 X 键 89 Y 键 90 Z 键 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 小写字母的 ASCII 码：值 描述 97 a 键 98 b 键 99 c 键 100 d 键 101 e 键 102 f 键 103 g 键 104 h 键 105 j 键 106 j 键 107 k 键 108 l 键 109 m 键 110 n 键 111 o 键 112 p 键 113 q 键 114 r 键 115 s 键 116 t 键 117 u 键 118 v 键 119 w 键 120 x 键 121 y 键 122 z 键 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝0 至 9 键的 ASCII 码：值 描述 48 0 键 49 1 键 50 2 键 51 3 键 52 4 键 53 5 键 54 6 键 55 7 键 56 8 键 57 9 键 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝