• 全部
  • 经验案例
  • 典型配置
  • 技术公告
  • FAQ
  • 漏洞说明
  • 全部
  • 全部
  • 大数据引擎
  • 知了引擎
产品线
搜索
取消
案例类型
发布者
是否解决
是否官方
时间
搜索引擎
匹配模式
高级搜索

H3C S6520X-30HC-HI 流量转发异常

21小时前提问
  • 0关注
  • 0收藏,63浏览
粉丝:0人 关注:0人

问题描述:

组网及组网描述:

网络架构如图所示,目前发现深信服AC上面有117.31访问117.140的数据,但是网关是在核心交换机的,而且路由也没有错的

3 个回答
粉丝:0人 关注:0人
粉丝:13人 关注:2人

故障根因:10.3.117.140 本机高频 ARP 泛洪 + 源 MAC (00:50:56:ab:45:b6) 主机跨网段异常绕行 AC,核心三层转发未生效

一、抓包信息拆解

  1. 源 MAC:00:50:56:ab:45:b6 → VMware 虚拟机 MAC 段,即 10.3.117.140 服务器本身
    • 大量ARP Request who-has 10.3.117.140:服务器本机疯狂发送请求自身 IP 的 ARP 报文(ARP 风暴)
    • 同时该服务器主动向外:UDP 61284→8235向外发包
  2. 网段说明:
    • VLAN117 网关:核心交换机 101.5(三层网关),正常 117.31→117.140 流量应在核心交换机本地三层转发,不经过深信服 AC (101.4)、AF (101.3)
    • 异常现象:业务流量被引流至 AC 设备,绕过核心三层转发

二、3 个核心诱因(按排查优先级)

诱因 1:117.140 服务器本机故障(最高概率,抓包直接佐证)

  1. 服务器(117.140/10.3.117.140)操作系统 / 虚拟机异常:中毒、程序异常、网卡驱动故障,持续广播请求自身 IP 的 ARP,造成 ARP 异常。
  2. 本机网关配置错误:服务器网卡网关未填写核心 VLAN117 网关 IP,错误配置成 AC/AF 地址,所有跨网段流量被迫上送 AC。
核查:登录 117.140 服务器ipconfig/route print查看默认网关。

诱因 2:核心交换机 VLAN117 三层转发失效(二层泛洪绕行上游 AC)

正常逻辑:117.31(VLAN117 同网段)访问 117.140,核心 Vlanif117 三层直接转发,不出核心上行口
异常逻辑:核心Vlanif117 协议 DOWN/IP 丢失 / ARP 表异常,三层转发失效→同网段流量变成二层广播,顺着上行链路(核心→AC→AF)转发,AC 抓到流量。
plaintext
# 核心交换机排查命令 display interface Vlan-interface 117 # 查看接口UP/DOWN、IP配置 display arp | include 117.140 # 查看服务器ARP条目是否正常 display ip routing-table 10.3.117.140 # 路由有效性
  • 若 Vlanif117 DOWN:检查 VLAN117 在核心是否存在、下联 trunk 是否放行 vlan117。

诱因 3:深信服 AC 侧配置引流(策略路由 / 镜像 / 网桥部署)

  1. AC 部署为透明网桥 / 旁路镜像 / 全局策略路由
    • 透明模式:核心上行串接 AC,所有进出流量天然经过 AC;
    • 旁路镜像:AC 配置端口镜像,仅复制流量(不影响转发,只是能抓到包);
    • 异常 PBR:核心交换机配置错误策略路由,强制 VLAN117 所有流量转发至 AC (101.4)。
plaintext
# 核心排查策略路由 display policy-based-route

三、分步排查落地操作

步骤 1:服务器侧(117.140)

  1. 关闭服务器网卡,ARP 风暴立即消失→确定服务器本机问题;
  2. 修正网卡默认网关为核心 VLAN117 网关 IP

步骤 2:核心交换机侧

  1. 确认 Vlan-interface117 UP、IP 配置完整;
  2. 确认 117.140 存在有效 ARP 条目,无 ARP 老化异常;
  3. 删除错误 PBR 策略路由。

步骤 3:深信服 AC 侧

  1. 查看 AC 部署模式:透明网关 / 旁路镜像 / 路由模式;
    • 镜像:AC 只是复制流量,转发仍走核心,属于正常抓包;
    • 透明串接:架构设计如此,所有上行必经 AC;
  2. 关闭 AC 临时测试:断开核心→AC 之间网线,117.31 访问 117.140 正常 = AC 串接组网。

四、补充区分关键概念

  1. AC 能抓到流量≠转发经过 AC
    • 端口镜像:仅复制报文,实际转发仍在核心,属于正常;
    • 流量真实绕行:报文二层 / 三层被转发至 AC,为故障。
  2. 同 VLAN117 内终端互访不需要经过网关,仅跨 VLAN 才走三层网关,现同网段绕行 AC = 三层失效 / 二层泛洪。

AC是桥接的,同网段访问也是经过AC? 不是直接走MAC地址吗?

zhiliao_AyNagS 发表时间:21小时前 更多>>

AC是桥接的,同网段访问也是经过AC? 不是直接走MAC地址吗?

zhiliao_AyNagS 发表时间:21小时前
粉丝:17人 关注:1人

针对您描述的 H3C S6520X-30HC-HI 核心交换机网关下,深信服 AC 上观察到 117.31 访问 117.140 流量异常(路由看似正确但转发存在问题)的情况,这通常属于三层转发丢包或策略拦截的典型故障。
建议按照以下四个维度由浅入深进行排查:

一、 检查跨 VLAN 三层转发基础配置

如果 117.31 和 117.140 属于不同的网段/VLAN,且网关在核心交换机上,必须确保核心的三层转发功能正常:
  1. 确认 SVI 接口状态:执行 display ip interface brief,检查这两个网段对应的 VLAN-Interface(SVI)是否已创建,且物理与协议状态均为 UP,IP 地址配置无误。
  2. 核对直连路由表:执行 display ip routing-table,确认路由表中是否存在这两个网段的直连路由(Direct)。如果缺少对应网段的 SVI 接口,即使全局开启了 ip route-enable,也无法生成直连路由导致转发断裂。

二、 排查 ACL 与 QoS 策略拦截

网关设备上的安全策略是造成“路由对但不通”的最常见原因:
  1. 检查端口/全局 ACL:使用 display packet-filter 和 display acl [ACL编号] 命令,检查核心交换机连接深信服 AC 的上行口,以及终端接入的下行口是否应用了数据过滤策略。重点排查是否有规则误拦截了 117.31 到 117.140 的特定 IP 通信。
  2. 检查 QoS 策略:执行 display qos policy interface 等命令,查看是否在接口或全局下发了基于 ACL 的 QoS 策略或流行为(如重标记、丢弃等),错误的 QoS 关联会导致报文被静默丢弃。

三、 利用流量统计定位丢包节点

如果上述静态配置均无异常,建议使用 ACL 流量统计功能精准定位流量在哪个环节丢失:
  1. 提取流量特征:通过抓包确认异常流量的具体特征(如源 IP 117.31.x.x,目的 IP 117.140.x.x)。
  2. 下发统计策略:创建一个高级 ACL(如 3000)匹配该特定 IP 对,并建立 Traffic Classifier 和 Behavior(开启 accounting packet),将其应用到核心交换机的相关接口入方向(Inbound)。
  3. 分析计数结果:稍后执行 display qos policy interface 查看命中计数。若入方向有计数但出方向无计数,说明报文在设备内部转发时丢失(可能是查表失败或被内部策略拦截);若入方向也无计数,说明报文根本没有到达该核心接口。

四、 检查 ARP 表项与底层链路

  1. 核查 ARP 解析:执行 display arp | include 117.31 和 display arp | include 117.140,确认核心交换机能否正确学习到这两个 IP 对应的 MAC 地址。若 ARP 缺失或频繁刷新,可能是网络中存在 ARP 攻击或环路导致表项耗尽。
  2. 排查物理层错误:执行 display interface brief,检查核心交换机上下行接口的 CRC 错误、Input/Output errors 是否持续增长。物理链路质量差也会导致三层报文转发异常。

编辑答案

你正在编辑答案

如果你要对问题或其他回答进行点评或询问,请使用评论功能。

分享扩散:

提出建议

    +

亲~登录后才可以操作哦!

确定

亲~检测到您登陆的账号未在http://hclhub.h3c.com进行注册

注册后可访问此模块

跳转hclhub

你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作

举报

×

侵犯我的权益 >
对根叔社区有害的内容 >
辱骂、歧视、挑衅等(不友善)

侵犯我的权益

×

泄露了我的隐私 >
侵犯了我企业的权益 >
抄袭了我的内容 >
诽谤我 >
辱骂、歧视、挑衅等(不友善)
骚扰我

泄露了我的隐私

×

您好,当您发现根叔知了上有泄漏您隐私的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您认为哪些内容泄露了您的隐私?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)

侵犯了我企业的权益

×

您好,当您发现根叔知了上有关于您企业的造谣与诽谤、商业侵权等内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到 pub.zhiliao@h3c.com 邮箱,我们会在审核后尽快给您答复。
  • 1. 您举报的内容是什么?(请在邮件中列出您举报的内容和链接地址)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
  • 3. 是哪家企业?(营业执照,单位登记证明等证件)
  • 4. 您与该企业的关系是?(您是企业法人或被授权人,需提供企业委托授权书)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

抄袭了我的内容

×

原文链接或出处

诽谤我

×

您好,当您发现根叔知了上有诽谤您的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您举报的内容以及侵犯了您什么权益?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

对根叔社区有害的内容

×

垃圾广告信息
色情、暴力、血腥等违反法律法规的内容
政治敏感
不规范转载 >
辱骂、歧视、挑衅等(不友善)
骚扰我
诱导投票

不规范转载

×

举报说明