H3C S1850V2 链路聚合LACP 关于交换机 这款交换机是管理型的，支持不少功能，如下: 基本交换功能： VLAN 支持：支持虚拟局域网的配置和管理。 交换表：支持 MAC 地址学习和转发。 二层组播：支持组播的传输和管理。 管理和维护： 远程管理：支持 Telnet 和 SSH 等协议进行远程管理。 Web 管理界面：提供图形化的 Web 界面进行设备管理。 SNMP（Simple Network Management Protocol）：支持 SNMP 协议，用于网络监控和管理。 安全特性： 802.1X 认证：支持端口基于 IEEE 802.1X 的认证。 MAC 地址认证：通过 MAC 地址对设备进行认证。 静态 VLAN 认证：支持 VLAN 认证。 QoS（Quality of Service）： 802.1p 优先级：支持 IEEE 802.1p 优先级标记。 DiffServ（区分服务）：支持基于 DiffServ 的流量分类和标记。 链路聚合： 支持链路聚合以增加带宽和提高冗余性。 安全性功能： 动态 ARP 检测：用于检测和防范 ARP 欺骗攻击。 灵活的管理接口： Console 接口：通过串口连接进行设备配置。 Telnet/SSH：通过网络进行远程管理。 Web 界面：通过图形化的 Web 界面进行设备管理。 性能优化： Storm 控制：用于防范网络风暴，如广播风暴、组播风暴等。 IPv6 支持： IPv6 配置和管理功能。 端口镜像： 支持端口流量的镜像功能，用于网络监测和故障排除。 PoE（Power over Ethernet）: 如果你的 S1850V2-52P 支持 PoE，那么它可能提供 Power over Ethernet 功能，用于供电连接到交换机的网络设备，如 IP 摄像头、IP 电话等。 但是这款交换机基本上只支持在web管理，在CLI支持的配置非常有限，基本上最大的用途就是配置ip 交换机的默认ip是 192.168.0.233，所以调试的话，接入笔记本到同网段，然后访问此ip即可，也可以进入 cli 使用 ip-setup 来设置ip 配置管理vlan和业务vlan 既然是可web管理的，那么就需要配置当前网络环境的管理vlan48 以及 当前网络环境的业务vlan10，而不再使用默认的vlan1。再就是开启vlan后设置登录密码（默认无密码），首先保证默认的 ip 或 手动配置地址可以访问web (二层)交换机配置 1号端口 为trunk 与上联三层一样，这样可以放行两个vlan。在设备-端口管理-设置中 (三层)上联端口设置为 trunk，并且放行 vlan48 和 vlan10 int G 1/0/20 port link-type trunk port trunk permit vlan 10 48 port trunk pvid vlan 10 (二层)在网络-VLAN-创建中分别创建vlan10（业务）和vlan48（管理） (二层)在网络-VLAN-修改端口中，选中端口1，选择 tagged，把vlan10和48加上 (二层)在网络-VLAN虚接口-创建，创建两个VLAN的地址，其实创建一个vlan48的地址即可，此地址后续可以访问，作为管理ip，同时此网段也可以作为下一条，进入三层 (二层)在网络-IPV4路由-创建，创建下一跳路由，可以保证此接口出去的网络路由正常，下一条接口和网关ip，选择vlan48的即可 至此，其他接入此交换机的ip，如果配置vlan10或者vlan48，即可正常访问网络 配置链路聚合 这款交换机支持链路聚合功能，并且支持动态聚合，可以配合 NAS 支持的LACP使用，实现多条线路负载以及故障冗余 链路聚合以及LACP配置

h3c无线之雷达信道的影响 0x1 现象 部分区域的同事基本上同时断网（漫游到其他AP上），同时观察此AP，发现指示灯为绿色常亮，过一段时间（大概数十秒或数分钟）后恢复正常。 架构及型号： AC： MSG360-20 AP: WAP712c、WAP712C-LI AC接三层下，AC下联POE交换机，AP接入POE交换机，所有配置基本上都是型号模板配置，所以应该不是配置问题，因为目前基本上相同的配置，只收到此AP有故障现象。 0x2 初步排查 通过对比时间，AP指示灯状态，再检索日志，发现如下异常： Dec 4 20:10:15 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yanfa_waibu changed from 161 to 60, Reason: Radar channel recover. Dec 4 20:10:16 2023 ac %%10STAMGR/6/STAMGR_CLIENT_OFFLINE: -DevIP=192.168.192.21; Client f46a-dd6e-2ced went offline from BSS 943b-b04d-3f20 with SSID Succez on AP 2f_yanfa_waibu Radio ID 1. State changed to Unauth. Reason:AP triggered (channel changed). Dec 4 20:10:16 2023 ac %%10STAMGR/6/STAMGR_CLIENT_OFFLINE: -DevIP=192.168.192.21; Client e00a-f671-e9f1 went offline from BSS 943b-b04d-3f20 with SSID Succez on AP 2f_yanfa_waibu Radio ID 1. State changed to Unauth. Reason:AP triggered (channel changed). Dec 4 20:10:16 2023 ac %%10STAMGR/6/STAMGR_CLIENT_OFFLINE: -DevIP=192.168.192.21; Client acbc-3278-d889 went offline from BSS 943b-b04d-3f20 with SSID Succez on AP 2f_yanfa_waibu Radio ID 1. State changed to Unauth. Reason:AP triggered (channel changed). Dec 4 20:10:16 2023 ac %%10STAMGR/6/STAMGR_CLIENT_OFFLINE: -DevIP=192.168.192.21; Client c889-f3ac-2271 went offline from BSS 943b-b04d-3f20 with SSID Succez on AP 2f_yanfa_waibu Radio ID 1. State changed to Unauth. Reason:AP triggered (channel changed). Dec 4 20:10:16 2023 ac %%10STAMGR/6/STAMGR_CLIENT_OFFLINE: -DevIP=192.168.192.21; Client bc03-5872-49fd went offline from BSS 943b-b04d-3f20 with SSID Succez on AP 2f_yanfa_waibu Radio ID 1. State changed to Unauth. Reason:AP triggered (channel changed). 可以看到先提示了信道改变，原因是: Radar channel recover ，然后下面就是客户端离线，原因是通道（信道）改变。 于是登录AC控制台查看了信道射频相关的配置，可以确定没有开启信道定时自动调优，但AP的信道设置是自动信道不锁定，结合信道会变化，怀疑是这里问题，于是修改为自动信道并锁定。 但设置后并没有恢复正常超过半天，又出现了同样的问题。所以可确定不是此配置影响，而目前最大的疑问在于，为什么锁定了信道仍然会自动变化，为什么其他AP不会变化，难倒是AP物理上存在故障了？ 0x3 radar? 在修改锁定信道也无法解决问题后，又尝试重启了AP，但后续也发现无法解决，所以目前为止比较怀疑的是AP硬件或者软件存在故障或BUG 不过仍然在百度和google查询了 Radar channel recover ，毕竟这里可能是唯一的错误信息了，但检索基本没有得到有效信息。 在一筹莫展的时候，我反复在想为什么配置了 锁定信道 但仍然会切换，这显然是软件行为，比锁定信道的优先级都高，于是我查询 H3C 中关于信道锁定的部分配置 auto lock ，这一查，终于发现了蹊跷： 【缺省用户角色】 network-admin 【参数】 channel-number：手动配置的射频工作信道。取值范围由区域码和射频模式决定。 auto lock：自动选择信道并加锁模式，由设备根据实际环境自动选择最优信道，并将该信道锁定。 auto unlock：自动选择信道并解锁模式。由设备根据实际环境自动选择最优信道，并将该信道设置为无锁模式。 【使用指导】 在手工指定工作信道模式时，如果在当前工作信道上发现雷达信号，则AP会立即将工作信道调整至其他信道。AP会在30分钟后将信道切换回手工指定的信道，并静默一段时间，如果在静默时间内没有发现雷达信号，则开始使用该信道；如果发现雷达信号，则再次切换信道。 在自动选择信道模式上，无论信道加锁与否，如果在当前工作信道上发现雷达信号，则AP会立即将工作信道调整至其他信道。 在只看参数的时候我觉得挺正常的， lock、unlock 在是意料之中的行为，不过在使用指导中发现了关键字 雷达，并且整体解释大意为，不论是手动设置、自动设置信道，不论是否加锁，只要检测到雷达信号，则会立即切换到其他信道，这和我遇到的现象是一模一样的。所以断网的原因终于找到了，那为什么会出现这个问题呢？ 0x4 原因 首先AP进行了信道切换，所以可以判断雷达也是有相关的信道，并且可能在当时发生冲突了。所以我们可以了解雷达信道的范围，检索的资料如下： 什么是雷达信道 信道52，56，60，64，100，104，108，112，116，120，124，128，132，136，140，144可作为雷达信道，如果某国家和地区支持的信道和雷达信道有重叠，则使用信道时请尽量避开雷达信道。当AP工作在5G射频频段时，AP通过DFS功能，进行雷达检测，当检测到雷达信道后会自动切换到其他工作信道，避免干扰雷达。 思科关于DFS和雷达信号的介绍 在了解了基本情况之后，我们大概可以知道，是因为AP检测到了相同信道的雷达信号，所以立即切换了信道，但这里仍然有疑点，室内真的存在雷达信号吗？并且一天中随机出现，这个我们无法验证，但解决办法是什么呢？ 既然雷达信道和wifi信道有一定重合，但wifi信道也较多，所以可以手动设置AP信道，在当前网络架构中完全不使用雷达信道 关闭雷达检测 `radar-detect disable` （不建议此方法） 此次问题是发生在室内，正常应该不存在雷达信号，所以基本上是误判，可以提交问题给厂家 或者 尝试升级 AC 固件版本。（本次升级后解决，如果升级后仍未解决可以采用更换非雷达信道办法） PS. 关于多个AP使用雷达信道 AP检测雷达信号使用的DFS技术，虽然是同一个信道，但能够判断具体是 WIFI 信号还是雷达信号，所以多个AP使用同一个雷达信道，也是不会发生切换的 其他 最后通过检索之前日志中的 radar ，发现不少 AP 其实是切换过信道的 Dec 4 09:20:44 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_neibu changed from 40 to 60, Reason: Radar channel recover. Dec 4 09:21:21 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_huiyishi changed from 165 to 56, Reason: Radar channel recover. Dec 4 12:16:23 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_waibu changed from 52 to 153, Reason: Avoid radar channel. Dec 4 12:16:24 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_huiyishi changed from 56 to 48, Reason: Avoid radar channel. Dec 4 12:46:23 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_waibu changed from 153 to 52, Reason: Radar channel recover. Dec 4 12:46:24 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_huiyishi changed from 48 to 56, Reason: Radar channel recover. Dec 4 13:25:01 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_neibu changed from 60 to 165, Reason: Avoid radar channel. Dec 4 13:55:01 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_neibu changed from 165 to 60, Reason: Radar channel recover. Dec 4 15:21:36 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_neibu changed from 60 to 52, Reason: Avoid radar channel. Dec 4 15:51:36 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_neibu changed from 52 to 60, Reason: Radar channel recover. Dec 4 18:02:55 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_waibu changed from 52 to 48, Reason: Avoid radar channel. Dec 4 18:32:55 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_waibu changed from 48 to 52, Reason: Radar channel recover. Dec 4 18:34:14 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_huiyishi changed from 56 to 60, Reason: Avoid radar channel. Dec 4 19:04:14 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_huiyishi changed from 60 to 56, Reason: Radar channel recover. Dec 4 19:40:15 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yanfa_waibu changed from 60 to 161, Reason: Avoid radar channel. Dec 4 19:54:24 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 1f_renshi changed from 52 to 44, Reason: Avoid radar channel. Dec 4 20:10:15 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yanfa_waibu changed from 161 to 60, Reason: Radar channel recover. Dec 4 20:24:24 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 1f_renshi changed from 44 to 52, Reason: Radar channel recover.

H3C设备持久化日志到rsyslog服务器 0x1 why 原因很简单，设备日志没有持久化，不能在性能、故障、安全等问题过后进行排查 0x2 how 日志 buffer 默认只有 512 条，没有进行持久化，这里我们仅配置 h3c 设备如何发送日志到 rsyslog 服务器 先查看当前有哪些vlan，确定使用哪个vlan接口作为源地址发送给日志服务器 dis int vlan br 此示例设置vlan 1为日志发送的源地址和接口 info-center loghost source Vlan-interface 1 设置日志的发送事件类型，这里设置为local6，与rsyslog中的保持一致 info-center loghost 192.168.3.100 facility local6 查看配置内容，以及是否启用等 dis info-center 至此，如果rsyslog服务器已经配置完成的话，那么可以在相关目录查看到设备的日志文件了