-
单位PC访问某互联网业务失败之公网IP被网站封堵
客户局域网无法访问互联网某业务，客户发现在自己家能正常访问。 访问某网页时显示访问超时。（客户怀疑是防火墙策略拦截） 1、防火墙开启直通发现还是无法访问此业务。（怀疑是对端单位把用户公网IP给封锁了） 2、抓取用户访问互联网某业务的pc包，再抓取AF的数据包。 发现PC端的数据包和AF的数据包一致，说明AF没有拦截这个访问 分析数据包发现源到目的访问为RST，说明是对端拒绝的。 3、用户有多个公网IP，在AF上NAT策略上更换了另一个公网地址上网。发现用户的PC可以正常访问对端业务了。 对端单位的业务那边，把本端客户的公网地址给封锁了。 临时方案：如果有多个公网地址，可以在AF的NAT策略上更换公网地址去访问。 永久方案：联系对端单位管理员协商，把本用户的公网地址放通。 建议让客户和对端单位沟通一下是什么原因导致，公网IP被拦截或者是被封锁了。
SE_Gao 2024-11-21
5 0 0 -
锐捷S7805C跨设备无法ping通
一、故障现象 7805C ping S2不通，但是ping S1正常，S2 ping S1正常，S1 ping S7805C正常。 网络拓扑如下： 二、设备型号和版本 型号：S7805C 版本：S7800C_RGOS 11.0(4)B19T3, Release(05240612) 三、故障分析思路 确定网络环境是否存在环路，是否存在地址冲突； ACL计数判断是否未收到回应ICMP报文； 开启快转查看ICMP报文送达驱动； 专家ACL计数或者抓包查看对端回应ICMP报文是否合法； （注：对端回应ICMP不可达时ACL计数仍可以计数回应报文） 四、故障分析过程解析 检查双方路由均显示正常（ON2 10.0.0.0/8 10.0.15.1）； 检查环境中不存在地址冲突，环路等问题。华三设备均使用静态路由进行回指，华三S1设备可以ping通两端的S7805C和S2。7805C指定静态路由 10.0.42.1 255.255.255.255 10.0.15.1 仍不通； acl计数，7805cping对端华三设备有收发但是显示不通。华三设备ping 7805c 有收到但是没有回应； 设备端开启debug efmp packet filter ipv4_sip host 10.0.42.1 ipv4_dip host 10.0.15.3 v4_protocol icmp counter 5 显示未收到，acl计数结果有增长，使用debug pkt-monitor match诊断PI未发出，判断上层收到报文之后没有同步底层； 接口下使能匹配源目ip的ACL计数，全局使用匹配目的mac源目ip的ACL计数显示，接口下仅匹配ip的acl能够统计到回应icmp报文，但是全局下匹配目的mac和ip的acl记不到数，故友商设备回应icmp报文时目的mac地址异常导致S7805C认为不是回音给自己的报文所以没有送达设驱动； 抓包进一步确认显示友商S2回应报文在S2回应S1时显示目的MAC正常，但是S1回应S7805C时目的MAC发生变化。（实际测试每次回应报文经过S1之后目的MAC都会变化，每次变化的目的MAC不一样）； 故障原因说明：友商系统异常，导致转发回应报文的目的MAC地址会随机发生变化 ……
SE_You
2024-11-21
12 0 0 -
如何用多种方法查看 Linux ip 地址？
01 ifconfig概述 ifconfig（interface configuration）是一个传统的命令行工具，用于配置和显示网络接口的参数。它允许用户查看、启用、禁用网络接口，以及设置IP地址、子网掩码等网络参数。 01 特点 功能丰富：ifconfig可以显示和配置网络接口的各种参数，包括IP地址、子网掩码、广播地址等。 广泛支持：ifconfig在大多数Linux发行版中都有预装，使用广泛。 语法简单：ifconfig的命令语法相对简单，易于学习和使用。 02 基本用法 显示所有网络接口： ifconfig 显示特定网络接口： ifconfig eth0 启用/禁用网络接口： ifconfig eth0 up ifconfig eth0 down 设置IP地址： ifconfig eth0 192.168.1.10 netmask 255.255.255.0 显示简要信息： ifconfig -a 02 ip命令 ip命令是一个更现代的网络配置工具，功能更强大，语法更一致。它不仅可以显示网络接口的信息，还可以进行网络配置和管理。 01 基本用法 显示所有网络接口： ip addr show 显示特定网络接口： ip addr show eth0 启用/禁用网络接口： ip link set eth0 up ip link set eth0 down 设置IP地址： ip addr add 192.168.1.10/24 dev eth0 删除IP地址： ip addr del 192.168.1.10/24 dev eth0 显示路由表： ip route show 添加路由： ip route add 192.168.2.0/24 via 192.168.1.1 删除路由： ip route del 192.168.2.0/24 via 192.168.1.1 03 nmcli命令 nmcli是NetworkManager的命令行工具，适用于图形化管理网络连接。它提供了丰富的网络配置和管理功能。 01 基本用法 显示所有网络接口： nmcli device status 显示特定网络接口： nmcli device show eth0 启用/禁用网络接口： nmcli device disconnect eth0 nmcli device connect eth0 设置IP地址： nmcli connection modify eth0 ipv4.address……
SE_YJ 2024-11-21
6 0 0 -
事件日志
日志信息 [$1:STRING]. 日志含义 系统事件日志信息，如接口UP/DOWN信息等。 日志参数 表1 日志参数表 参数名称 参数含义 STRING 系统重启、接口UP/DOWN、升级版本、HA切换等信息。 可能原因 系统事件产生。 处理步骤 根据日志信息检查相应的模块，如有异常对应处理。 如果系统事件日志频繁提示“设备以冷启动方式启动”，需要排查供电环境或设备电源模块是否有故障。
SE_Gai 2024-11-21
7 0 0 -
防火墙会话机制与基本概念
会话机制与基本概念 一、会话概念： 当数据流经过AF转发时，AF会生成一个记录五元组、出入接口、路由匹配情况、策略匹配情况、nat转换情况等信息的表项，此表项称为会话 二、会话作用： AF转发数据时为了提升数据转发效率率并减少重复判断策略匹配情况而损耗设备性能，通过会话记录的策略等信息，进行数据快处理 三、会话的机制介绍： A：会话建立的条件参数： 1.老架构（五元组）：源IP，目的IP，源端口，目的端口，协议 2.新架构（七元组）：源IP，目的IP，源端口，目的端口，协议，VLAN，数据为二层或三层（数据经过AF时，AF是2层转发还是3层转发） B、会话匹配： 1.老架构：仅通过识别五元组信息是否已有会话一致，一致则根据对应会话转发并刷新老化时间，否则生成新会话。 2.新架构：在标准五元组场景的前提上针对数据包VLAN标签，以及首包为二层或三层的识别标签，共同组成七元组进行识别。若七元组完全一致则根据对应会话转发并刷新老化时间，否则生成新会话。 C、会话更新： 1、自然更新会话 TCP会话默认老化时间为30min，UDP会话默认老化时间为3min，ICMP默认老化时间为30s（对应时间可以在控制台修改），老化时间超过后会话过期清除，若同一五元组（七元组）数据在老化前再次触发则会刷新老化时间重新进老化计算。 2、recheck更新会话 recheck是指路由或者策略发生变化时（增/删/改操作），通知会话立即重新按照当前策略或路由的匹配情况进行更新并刷新老化时间。例如路由变化了，那已经建立的会话，需要重新去匹配路由，查询下一跳和出接口，如果转发情况发生变化则清理老会话并重新建立会话（recheck）。但是并非所有recheck场景均会重建所有会话，例如黑名单修改仅仅会让修改的IP相关会话recheck。 注：老架构存在NAT策略调整下发后不及时recheck的情况，可通过打包优化解决-- KB-AF-20210904-Na……
18 0 0 -
锐捷S57H交换机直连ping不通
一、故障现象 设备上行直连ping 172.31.12.253 不通。部分视频业务转发卡断异常。前后未做配置以及网络拓扑变更、影响业务。 网络拓扑如下： 二、设备型号和版本 设备型号：5750H 设备版本：B12P8 三、故障排查步骤 1、 了解交换机直连不通的丢包点在哪里（可以使用ACL计数初步定位） 2、 确定交换机本身存在异常时控制面报文发包情况可以通过快转判断是否正常 3、了解整体端口发包机制：功能组件---》快转---》pkt---》端口 4、根据收集的信息和抓包分析出故障原因 四、故障排查过程 通过现场的信息分析，初步定位客户业务场景超出了设备性能 详细分析如下： l 设备debug看ping 报文送到快转控制面延迟了30多秒。 l 快转发包虚线程慢，发现EFMP-1中libpkt_sock_thread占用cpu高。 PI这边进展： 现象原因：从快转发包来看，协议栈将icmp报文 发送给快转后，快转发包虚线程要15s后才进行发包（从log上看）。快转发包虚线程是跑在CPU核1核上。CPU1核是转发核，目前看只有EFMP-1和libpkt_sock_thread CPU高。 怀疑点： 进行EFMP-1这个快转转发核上gdb，发现都是卡在HZ接口，内部调用sysconf这个libc库中的系统调用，但是就算是使用该系统调用，理论上也不会卡住这么久。目前看也只有分片重组定时器使用HZ这个接口，现场需要看下是否有大量分片报文。 l 快转的报文构造的分段了，分成3段才发往驱动，说明设备收到分片报文。 l 实际抓包查看现网中存在大量的分片报文，并且有很多分片报文丢包，导致CPU收不到分片报文，导致在等大包的组包，因此造成CPU高。 为什么大包送CPU慢？ l 从客户现场的信息看、部分报文速率较大，已经达到了NFPP的攻击水线，部分报文已经被隔离，导致送CPU不完整。 l 关闭NFPP后故障依旧。 l 查看芯片报文不能送CPU的原因，芯片存在MMU丢包，就是送CPU的报文太多了。缓存不够用造……
SE_You
2024-11-20
6 0 0 -
系统操作日志
日志信息 operator_name=[$1:STRING];operate_ip=[$2:IPADDR];create_time=[$3:TIME];level=[$4:STRING];reason=[$5:STRING];result=[$6:STRING];managestyle=[$7:STRING];content=[$8:STRING] 日志含义 管理员[$1:STRING]在执行了[$7:STRING]，管理员的IP地址为[$2:IPADDR]，执行时间为[$3:TIME]，执行结果为[$6:STRING]，事件级别为[$4:STRING]，管理类型为[$7:STRING]。 日志参数 表1 日志参数表 参数名称 参数含义 operator_name 操作员名字。 operate_ip 操作IP地址。 create_time 操作时间。 level 事件级别。 reason 管理原因。 result 操作结果。 managestyle 管理类型。 content 操作内容。 可能原因 管理员执行操作。 处理步骤 正常运行信息，无需处理。
13 0 0 -
交换机光口对通就这么简单！
01 光口对通可行吗 是可以的，光纤局域网的主线是直接交换机的，其次在连路由器。 1、交换机后面还能再接交换机，交换机接交换机叫级联，理论上可以无穷的一直级联下去，但实际应用过程中，建议级联不超过四层。 2、级联可以定义为两台或两台以上的交换机通过一定的方式相互连接，根据需要，多台交换机可以以多种方式进行级联。在较大的局域网例如园区网(校园网)中，多台交换机按照性能和用途一般形成总线型、树型或星型的级联结构。 02 不同厂家交换机对通时需注意 1. 两台交换机的光模块是单纤还是双纤。 2. 两台交换机的光模块是单模还是多模。 3. 两台交换机的光模块波长是否一致(单纤时注意收发是否一致)。 4. 两台交换机的光模块发送光功率和光接收灵敏度是否在同一范围内。 5. 两台交换机的光模块传输距离是否相同。 6. 两台交换机的光模块的端口速率和双工模式是否相同。 03 两台交换机对通需满足 1、同模式光纤下统一为单纤或双纤，若单双纤对通时中间需加单双纤转换器。 2、光纤模式统一为单模或多模，若双纤时单模和多模光纤对通，中间需加单多模转换器。 3、双纤时波长需统一(850nm、1310nm、1550nm)，单纤时收发波长需统一(如：发送都为1310nm，接收都为1550nm或其他收发波长)。 4、发送光功率和光接收灵敏度需要在同一范围内。 5、光模块传输距离是否相同，若上述五个条件都满足，则可以在两个光模块中短距的距离内对通，但需注意长距离的光模块到达对端时的光接收灵敏度是否大于最小过载点。 6、光模块速率和双工模式应该都设置为强制百兆、千兆全双工或自协商，若一端自协商，另一端为强制百兆、千兆全双工，则不能link up。百兆光口和千兆光口不能对通。 04 两端都设置为自协商模式 双方互相发送/C/码流，如果连续接收到3个相同的/C/码且接收到的码流和本端工作方式相匹配，则返回给……
11 0 0 -
老架构防火墙日志上报MSS存在日志延时
老架构防火墙日志上报MSS存在日志延时 老架构防火墙日志上报MSS存在日志延时 有效排查步骤 1、排查域名能否正常解析通信，将脚本上传到后台，执行脚本python check_conn.py 2、排查获取接入地址REST接口是否正常 使用如下命令测试REST接口，corpcode=后面的参数为企业ID。 wget --no-check-certificate -qO - “https://device.sangfor.com.cn/sc ... 0&corpcode=16729605” 如果正常，会返回如下接入地址： {"code":0,"message":"成功","data":{"ip":"219.135.99.249","port":5000}} 3、排查步骤二返回的IP端口是否正常，最好抓包确认tcp握手是否正常 telnet 219.135.99.249 5000 / ssh 219.135.99.249 -p 5000 4、确认用户id是否正确，接入的设备名称要和云图上的设备名称一致，密码是否正确（一定要反复确认，配置不对也会报代理服务不可用） 5、检查防火墙日志上报相关日志：/fwlog/slog/log/最新日志.log，存在报错信息：invalid character 'u' looking for beginning of value。 防火墙上报日志到云端后，云端资源为新底座，上报线路切换到了clt1.sangfor.com.cn进行上报，防火墙自身依然是上报给clt.sangfor.com.cn，云端收到防火墙上报的数据后发现不是JSON格式，所以返回这个报错 老架构防火墙自身调整上报域名存在较大代码改动，暂时无法通过后台调整上报的域名，可通过修改防火墙host配置，将clt.sangfor.com.cn的域名和clt1.sangfor.com.cn的公网IP进行绑定，实现防火墙上报日志最终是上报clt1.sangfor.com.cn。 是 日志上报云图流程： 1.slog_clint(AF)调用云脑认证接口 https://auth.sangfor.com.cn/v1/auth 获取token； 2.slog_clint(AF)根据客户端i_get中的log.server主控地址，执行s_get获取上报配置，上报配置中包含需要的表，还有需要上报给那个……
20 0 0 -
锐捷S5750V2-L GRE场景下同步数据异常
一、故障现象描述 分部和总部的服务器同步数据异常，分部无法同步数据给总部服务器，分部上传大文件也无法获得总部服务器的响应，以及分部的考勤数据也无法传到总部服务器。 场景拓扑图如下： 拓扑描述：S5750V2-L和总部的核心设备建立GRE隧道来跨公网传输数据，S5750V2-L下的终端需要向总部核心下的服务器同步数据。 二、故障排查分析 了解到故障背景是将原思科设备替换为我司S5750V2-L交换机之后出现的问题，怀疑是我司交换机丢包导致，由于GRE报文通过acl计数无法统计到，故分别抓取正常情况和不正常情况的报文对比分析。 正常情况下，终端ping小包能通，终端侧抓包如下，收发包正常。 https://www.imgdata.cn/imgs/2024/12/24/9542215b05b36124.png 正常情况下，上联防火墙抓包如下，收发包正常。 异常情况下，终端ping大包不通，终端侧抓包没有reply。终端发出报文长度1514，但还未超出我司设备默认情况下最大支持的报文长度1522。（扩展说明：我司设备对报文长度设计的额外22字节，包括了Ethernet II 规范的6字节DA+6字节SA+2字节EtherType+4字节CRC，以及802.3ac增加的4字节vlan tag） 异常情况下，上联防火墙抓包如下，防火墙没有收到我司设备发出的icmp request，说明大包丢包位置在我司设备上。 进一步分析设备丢弃报文的原因，终端侧发出的icmp request报文是1514字节，加上4字节FCS(即CRC)和4字节vlan tag，长度刚好是1522，所以报文进入交换机接口时不会丢包。但长度超过了隧道口下的ip mtu 1360，从而导致了报文在GRE隧道口产生丢包。如果要让经过GRE封装后的报文能在交换机上正常收发，则需要在默认MTU的基础上扩展28字节，但可能会导致下一跳传输设备无法处理报文。 基于客户原设备可正常转发，分析正常tcp有协商机制，会协商发送的报文大小，交换机有icmp不可达功能，正常mtu……
SE_You
2024-11-19
9 0 0
硬件天地
