CNESA - SE_Gao的文章

SE_Gao 的文章

交换机

某企业园区网S5700-EI堆叠交换机在线升级替换

问题描述设备升级换代，需将原华为S系列交换机汇聚堆叠组进行替换，拆除原堆叠组，替换成新堆叠组。替换过程中，需要将业务影响时间将至最低。处理过程 1、总体步骤第一步：将两台新交换机组成堆叠，备份旧设备配置，做好新设备的业务配置。第二步：先关闭原主交换机下行端口，再关闭原主交换机上行端口。第三步：shutdown新主交换机所有端口，将新主交换机替换原主交换机。第四步：关闭原备交换机的上行端口和下行端口，打开新主交换机所有端口。第五步：测试业务正常之后，拆除原备交换机。第六步：安装新备交换机，注意先接堆叠线，然后在通电。查看堆叠状态是否正常。 2、详细替换步骤实施内容操作步骤业务影响新汇聚配置旧设备配置备份，新汇聚设备，形成堆叠，做好相应配置，并核对。无影响开启长ping工具持续对各接入交换机管理地址及上行互连地址ping测试，执行以下各步骤时，不应出现业务中断情况，确认ping正常再进入下一步操作无影响关闭主交换机业务接口 Int range g 0/0/1 to g 0/0/19 Shutdown Int range g 0/0/21 to g 0/0/24 Shutdown 业务不中断无影响关闭主交换机上行接口 Int g 0/0/20 Shutdown 业务不中断无影响下电主交换机，移除线缆确认Ping测试无中断，关闭主交换机电源，业务不中断，并移除主交换机上所有线缆无影响替换主交换机，插入线缆将原主交换机拆除，在原位置替换安装新的主交换机，并加电，确保所有端口处于关闭状态；对应标签将线缆接入正确端口无影响关闭备交换机业务接口 Int range g 1/0/1 to g 1/0/19 Shutdown Int range g 1/0/21 to g 1/0/24 Shutdown 业务中断业务中断 10分钟关闭备交换机上行接口 Int g 1/0/20 Shutdown 业务中断开启主交换机上行接口 Int xg 0/0/4 Undo Shutdown 业务中断开启主交……

SE_Gao 2024-11-14

12 0 0
交换机

两台设备堆叠后，meth管理口对外可见一个还是两个

问题描述两台设备堆叠后，meth管理口对外可见一个还是两个解决方案两台设备堆叠后，对外只有一个管理口可见，且这个管理口为堆叠主设备上的；当主设备down掉后，这个管理口还会同步到备设备上去，且备设备上的管理口ip还是这个ip；但是如果堆叠分裂后，那就主备两台设备都有管理口，且都是同一个ip，这样会造成ip冲突。

SE_Gao 2024-11-13

37 0 0
交换机

S5700配置802.1x认证服务器绑定用户MAC后不能认证

问题描述交换机做802.1x认证，认证服务器不绑定MAC，用户认证成功；认证服务器绑定MAC，认证不成功。处理过程 1、不做MAC绑定测试认证成功，怀疑服务器绑定用户MAC后，未收到用户带MAC认证报文或者收到但未做回应。 2、服务器报文头分析确认，获取到用户MAC报文，未做回应； 3、华为交换机calling-station-id属性字段中MAC地址的格式为xxxx-xxxx-xxxx。通过如下命令更改MAC地址格式： system-view [HUAWEI] radius-server template huawei [HUAWEI-radius-huawei] calling-station-id mac-format dot-split mode2 uppercase 问题解决根因华为交换机MAC地址格式默认为xxxx-xxxx-xxxx，服务器识别格式为xx-xx-xx-xx-xx-xx 解决方案服务器不识别华为交换机默认MAC地址格式导致建议与总结不绑定MAC认证通过，绑定MAC认证不通过，仔细对比配置，缩小故障定位范围后，迅速针对性找出原因。

SE_Gao 2024-11-12

8 0 0
交换机

解决S5700-EI设备OSPF区域不够用现象

问题描述为某客户进行政务网核心交换机替换工作,使用3台S5700-EI设备替换2台C厂商设备,暂时作为核心使用。(以后会用S12800设备进行替换) 在替换准备过程中发现,原核心交换机上有100多个ospf区域,而S5700在ospf进程下只能建立20个区域,区域远远不够。处理过程向客户建议进行区域简化,即将100多个区域简化为20个区域,该方案遭到客户拒绝。 100多个区域对应的是全市100多个行政部门,如果进行简化,就需要全市政务网络大改,且涉及局点太多,工作量巨大。后研究影响ospf建立邻居的因素,发现共有9个: 1.Router-ID相同 2.区域ID不一致 3.认证不一致 4.掩码不一致(MA网络中) 5.hello和dead不一致 6.silent-interface(静默端口,端口不收不发) 7.priority(在MA网络中) 8.network不一致 9.MTU值不一致导致ospf邻居建立的因素中不包含ospf进程一项:即不同的ospf进程也可以建立邻居关系;我们针对这个问题,进行了模拟实验,并得到华为方技术支持确认,不同ospf进程可以建立邻居关系。 S5700-EI可以建立32个ospf进程,每个进程下可以建立20个区域,也就是说一台S5700-EI设备可以使用640个区域;不同的ospf进程可以进行路由引入,也就是说多个ospf进程可以汇总至一个ospf进程内。根据以上信息,我们最终解决了S5700-EI作为核心交换机,ospf进程下区域不够用的情况。

SE_Gao 2024-11-11

4 0 0
VMware vSphere

vCenter Failed to Start File System Check and Network Service

[Fixed] vCenter Failed to Start File System Check and Network Service Encountering issues such as "vCenter Failed to Start File System Check" and "vCenter Appliance Failed to Start Network Service" can disrupt this flow, potentially leading to downtime and operational setbacks. By Zelia / Updated on August 31, 2023 Share this: Table of Contents Causes of vCenter failed to start file system check Encountering the situation failed to start network service vCenter can be concerning, as it signals potential issues within the file system of your vCenter environment. This error message might appear during the startup process and can disrupt the normal operation of your virtualized infrastructure. Several underlying factors can trigger this error: Disk Corruption and File System Inconsistencies: A common cause of the "Failed to Start File System Check" error is disk corruption or inconsistencies within the file system. Unresolved disk issues can lead to a failed startup procedure as vCenter attempts to ensure data integrity. Unsuccessful Shutdown or System Crash: If vCenter was not shut down properly or if a system crash occurred during operation, it can result in file system errors that trigger the error message upon startup. Reasons for vCenter failed to start network service The "vCenter Failed to Start Network Service" error can disrupt the network connectivity and communication capabilities of your vCenter environment, impacting the management and operation of your……

SE_Gao 2024-11-08

8 0 0
VMware vSphere

vcenter failed to start file system check -1

After rebooting a Photon OS-based virtual appliance (vCenter Server Appliance for example), executing any commands on the shell (emergency mode) fails. Aria is down after power outage and it went to maintenance login The appliance fails to start and you see an error similar to - [FAILED] Failed to start File System Check on /dev/dis...uuid/XXXXX-XXX- See 'systemctl status systemd-fsck-root.service' for details. [DEPEND] Dependency failed for /sysroot. [DEPEND] Dependency failed for Initrd Root File System. [DEPEND] Dependency failed for Reload Configuration from the Real Root. Note: The preceding log excerpts are only examples. Date, time, and environmental variables may vary depending on your environment Environment VMware vCenter Server 8.0.x VMware vCenter Server 7.0.x VMware vCenter Server Appliance 6.7.x VMware vCenter Server Appliance 6.5.x VMware Identity Manager 3.3.x All VMware Aria Suite products VMware SDDC Manager 4.x VMware SDDC Manager 5.x VMware NSX-T Data Center 3.x (controller nodes only) Cause This issue occurs when a VM is forcefully halted as a result of storage failure, power failure, or software stack crash, causing file inconsistencies. Resolution To resolve this issue, scan and correct the filesystem by running fsck manually - Caution: Before proceeding, take a snapshot or backup of the affected virtual appliance. Reboot the virtual appliance, and immediately after the OS starts, press 'e' t……

SE_Gao 2024-11-07

16 0 0
VMware vSphere

vcenter failed to start file system check

I am having a VMWare Lab running on VMWare Workstation. The Lab is having 2 ESXi instances and vCenter is running on top of one of the ESXi. Datastore is iSCSI connected to a Windows Server 2019 running also on VMWare Workstation. Recently vCenter has been experiencing some issues with the Datastore and was refusing to initiate with the following error – [FAILED] Failed to start File System Check on /dev/vg_root_0/lv_root_0 Step one: Solve the issue In order to solve this issue, you can run these commands: #/bin/sh #blkid Here is the output of the command, the path that needs to be repaired is underlined. To confirm the issue run this command: #systemctl status systemd-fsck-root And finally to fix it run the command: #fsck -y /dev/mapper/vg_root_0-lv_root_0 After that, reboot vCenter and it should start without any problems.

SE_Gao 2024-11-06

28 0 0
交换机

NAT和路由，谁先谁后

版权声明：我已加入“维权骑士”(http://rightknights.com)的版权保护计划，所有知乎专栏“网路行者”下的文章均为我本人（知乎ID：弈心）原创，未经允许不得转载。在我迄今10年的网络从业生涯中（新加坡7年，沙特3年），参与过不计其数的网络设计和运维项目，项目规模大大小小的都有，接触过无数和NAT相关的配置和排错，什么静态NAT、动态NAT、端口映射还有PAT在不同厂商的设备上都实操过（思科的居多）。我发现一个问题：虽然作为每一位网工必修课的NAT技术很常用，大多数网工都会照着厂商给的配置手册或者设备上现成的running config改配置，但是真正钻研过这项技术，遇到问题时会排错的人真的不多。我在现在工作的地方--沙特阿卜杜拉国王科技大学(KAUST)担任IT网络运维组二把手时面试过不少求职者，这些求职者当中不乏工作经验8年以上，手握3个，4个，5个甚至更多的CCIE“大牛"们。技术面试环节中有一道题我是必问的：一台配置了NAT的思科路由器是先执行路由选择(Routing)，还是先执行NAT? 我听到过的答案五花八门，至今没有一个人能给我一个完全正确的回答。在给出正确答案之前，我先出一道题：问题背景：某公司A和某公司B最近开始有业务往来，要求公司A的主机192.168.11.1和公司B的主机192.168.44.4能够通信。网络拓扑如下：由于公司A和公司B的内网都是用192.168.0.0 /16网络，这里必须用NAT来解决主机A到主机B的通信问题。因为公司B没有驻场网络工程师，所以负责这个项目的公司A的网工选择在自家公司的路由器R2上配置NAT（这里默认R1,R2,R3,R4都是跑IOS的思科路由器）。NAT配置的要求如下：公司A的192.168.11.1(主机A)在进入公司B的内网前，需要在R2上被转换成172.16.23.1 公司B的192.168.44.4(主机B)在进入公司A的内网前，需要在R2上被转换成192.168.1.4 根据上述需求，公司A的网工在R2上完成了……

SE_Gao 2024-11-05

38 0 0
交换机

h3c 802.1X+MAC认证接入后5s内进入guest vlan

问题描述交换机上配置了802.1X+MAC认证+guest vlan： # dot1x dot1x authentication-method eap dot1x quiet-period dot1x timer quiet-period 10 dot1x timer tx-period 5 # mac-authentication mac-authentication timer quiet 1 mac-authentication user-name-format mac-address with-hyphen uppercase # interface GigabitEthernet1/0/2 dot1x undo dot1x handshake dot1x mandatory-domain imc_dot1x undo dot1x multicast-trigger dot1x unicast-trigger dot1x timer reauth-period 60 mac-authentication mac-authentication carry user-ip mac-authentication domain imc_dot1x mac-authentication timer auth-delay 10 mac-authentication guest-vlan 450 undo mac-authentication offline-detect enable # 测试认证终端接入认证到进入guest vlan需要花30s以上，想要实现接入后进入guest vlan的时间在5s内。过程分析收集debugging dot1x all、debugging mac-authentication all、debugging radius all 从debug看整个流程都是正常的： *Jul 3 02:08:19:982 2024 S5130 DOT1X/7/EVENT: Processing new mac event: UserMAC=****.****.****.****, VLANID=450, Interface=GigabitEthernet1/0/2. ====1x处理newmac; *Jul 3 02:08:31:993 2024 S5130 MACA/7/EVENT: Processing MAC authentication delay: UserMAC=****.****.****.****, VLANID=450, Interface=GigabitEthernet1/0/2. ====1x 客户端2次没有应答，总共10秒左右超时，转mac-auth；macauth添加延迟表； *Jul 3 02:08:42:402 2024 S5130 MACA/7/EVENT: Authentication delay timer expired: UserMAC=****.****.****.****, VLANID=450, Interface=GigabitEthernet1/0/2. ====在10秒后，开始触发macauth； *Jul 3 02:08:42:403 202……

SE_Gao 2024-11-04

5 0 0
Windows

如何将USB 3.0驱动程序装入Windows服务器2008 R2SP1，以用于Dell R230、R330、T30、T130、T330

症状 Windows Server 2012之前的版本（包括WS 2008 R2 SP1）本身并不支持USB3.0。戴尔的第13代服务器型号(R/T/M/FX) 430和更高版本配备有USB 2.0和USB 3.0。在较低的型号上仅提供一个USB 3.0。USB 3.0 驱动程序在 W2008 中不是原生的。警告：戴尔服务器型号（R/T） 330 和更低版本（R230、T130）仅限 USB 3.0，并且在 BIOS 中没有切换 USB 模式的选项，这使得传统操作系统安装更具挑战性。转到解决方案如何在高于（R/T） 330 的服务器型号上从 USB 3.0 切换到 USB 2.0。 USB 模式可在 BIOS 中设置：（图 1） BIOS 中有一个切换开关，允许用户选择使用 USB 2.0 或 USB 3.0（出厂默认为 2.0）。使用USB2.0选件让安装较早版本的Windows变得轻而易举。警告：较低的型号（R/T 330、230、130、30）上不存在此开关，因为硬件仅为 USB 3.0。图 1：戴尔 BIOS 使用默认介质的 USB 3.0 时，在没有键盘和鼠标功能的情况下，安装会卡在以下阶段（图 2）：图 2：设置屏幕中的停止安装解决方案如果可能，最方便的解决方案是安装 Windows 2012，它本身包含 USB 3.0 驱动程序，并且在安装过程中没有问题。如果此解决方案不可行，备用方法是将 USB 3.0 驱动程序注入安装介质中。提醒：在启动以下任何选项之前，请确保在未安装防病毒软件的计算机上执行以下步骤。已发现防病毒程序会干扰映像的创建，从而导致其在安装的各个阶段失败。为了顺利安装，必须将 Intel USB 3.0 驱动程序整合到 Windows 2008 R2 SP1 介质的“install.wim”和“boot.wim”中。每个“.wim”文件都有多个索引，因此您必须将英特尔 USB 3.0 驱动程序注入到每个“.wim”文件的所有适用索引中。Microsoft 提供了一个名为部署映像服务和管理（DISM）的工具，允许修改“wim”文件。在Windows 8和Windows Server 2012以及使用Windows PowerShel……

SE_Gao 2024-11-01

124 0 0