三层交换机 arp 学习疑问

没看懂你的问题

不过无所谓，
交换机的 1 号口，收到过 SrcMac 为 A 的报文，它就会记录下来 A -> 1 号口；下次从其他口收到 DestMac 为 A 的报文，就会转发到 1 号口

@FabricPath 谢谢, 简单一点来说就是, 该服务器报文内使用的 IP 和 MAC 经过该三层交换转发出去后, 交换机是否会学习到其中的 IP/MAC 信息

@FabricPath 需要补充一下, 报文类型是 ICMP, 不是 ARP

你的问题应该是 三层交换机会不会只根据一个 IP 数据报更新他的 arp table
简单来说 不会 因为这个表是通过 arp 协议维护的
https://networkengineering.stackexchange.com/questions/59507/arp-table-updated-when-receive-message

当然 不排除可以在软件或硬件上做一些修改 让他支持这个功能的情况
不过支持这个功能有什么用呢..

好像 arp ，如果没有建立过连接，不会被维护在表里
arp -a 看不到， 你既然已经用 udp ，如果 client 和 server 都是自己写的程序，可以用 udp 广播，组播

三层交换机不能做 nat 吧？然后你怎么把包转过去？用流策略重定向？就算你重定向了发给 11.1.2.3 ，一般服务器没开路由功能直接就丢包了，不会回 icmp ，服务器开了路由就回又把包发给交换机

我觉得会 交换机都能转发包到服务器上 交换机上应该知道服务器的 mac 了 以我的理解要能过来包 得 2 层通才行

不会.
交换机不会根据 icmp 报文去更新 mac table.

只会根据 ARP 包更新 ARP 表，而且 ICMP 的外层源应该是 11

不会.
这怎么看都不对啊, 11.1.2.3 发给 10.1.2.3 和 10.1.2.4 的 icmp admin-prohibited 包, 源 MAC 和源 IP 对应该是 11.1.2.3 | abcd-ef01-0203, 目的 IP 是 10.1.2.3 和 10.1.2.4, 目的 MAC 是 11.1.2.3 的网关 MAC.
没道理会学到 10.1.2.4 | abcd-ef01-0203 的 ARP 表项

还是说你的服务器发的是 10.1.2.4 -> 10.1.2.3 的 icmp admin-prohibited 包? 源 IP 和源 MAC 是 10.1.2.4 和 abcd-ef01-0203?
这样的话, 可能会学到 ARP, 看策略

友情提醒 11.0.0.0/8 不适合用作内网地址。
然后作为专业运维表示你的问题很难看懂，交换机通常只维护 mac-address table ，arp 表一般是主机和本机有三层通信的场景，比如作为 vlan 网关用于 vlan 间通信。

@lurenjiaMAX 不是的, 是我在 A 内网收到了 B 内网内部的 udp 报文
该三层交换直接把别人通讯的报文原样转发到我这边, 然后 nft 根据 reject 动作回了 icmp admin-prohibited

@LinusJian 是的, 就是你第二段里说的这样的情况

@newborn 并非我组建的内网, 我把服务器托管在机房, 机房是这么配的
我把遇到的情况简化成了主楼
机房在交换上使用 dis arp | in abcd-ef01-0203 查到了大量有关于我服务器 mac 的表项
所以我想是不是因为 nf 回的 icmp admin-prohibited 导致交换学习到了这些表项
收到 saddr 10.1.2.3 daddr 10.1.2.4 的 udp 报文
回复 mac abcd-ef01-0203 icmp admin-prohibited saddr 10.1.2.4 daddr 10.1.2.3

@huaxie1988 我开了 net.ipv4.ip_forward, 所以主楼中 forward 链的动作是 reject 。如果没开的话, 到不了 forward 链上就会被 kernel 丢弃
现状是我从网关收到了别的内网的原样 udp 报文, reject 动作回了 icmp admin-prohibited 给网关。与网关通信的过程中就会接触到主楼中的三层交换

@Executor 大多数交换机只会通过 ARP 报文学习 ARP (ethtype == 0x0806). 但不排除有的交换会把所有进 CPU 的报文的 IP-MAC 都学到 ARP 里面
ARP 攻击也得是发非法 ARP 才算吧, 这种情况就算 DAI 都挡不住
还有就是为什么会把别的网段的包转到这个口, 这就很不合理
建议机房严查, 感觉是交换的 BUG

@LinusJian 可以确信的是我的网卡只绑定了 11.1.2.3 这个 IP, 所以就算 kernel 收到了请求 10.1.2.3 / 10.1.2.4 的 arp 报文也不应回复
机房认为我的服务器在进行 arp 欺骗攻击, 执意要清退。我在排除了上述情况后, 想起以前曾在网口上抓到其余内网通信的 udp 报文, 并且最近我在 forward 链上从默认 drop 改为 reject with icmpx admin-prohibited 动作, 所以才想是不是因为这个改动导致的

@Executor 我梳理下你的问题
udp 通讯 10.1.2.3 -> 10.1.2.4 被该交换机转发到 11.1.2.3 上
解读、正常网络上不会发生这种事情，10.1.2.3 -> 10.1.2.4 是单播通信，也就是会发给 10.1.2.4 而不是 11.1.2.3
这里的通信过程是 10.1.2.3 发起 arp 广播，10.1.2.4 设备响应，然后两者可以通信，广播过程中，交换机只在二层工作，也就是对于 10.1.2.3 发起的广播收束定向发给 10.1.2.4 所在的接口。

现在要考虑的就是为什么 11.1.2.3 会收到数据，可以认为交换机实际上并没有通过 vlan 之类的技术将广播隔离，然后这台 11.1.2.3 设备的 mac 地址与 10.1.2.4 相同，也就是你后面补充的机房认为你的机器在搞 arp 欺骗，这里交换机仅参与二层工作。

然后你提到 11.1.2.3 主机转发链上有拒绝策略，这种是会返回一个包给请求源的

所以数据流程可以梳理成这样，10.1.2.3 上发起对 10.1.2.4 的 ping ，该主机通过 arp 广播学到的 10.1.2.4 的 mac 为 abcd-ef01-0203 ， 交换机视角：mac 表上在两个不同的接口上记录了 abcd-ef01-0203 ，将数据包随机均衡发到这两端口
你的主机 11.1.2.3 收到了来自 10.1.2.3 至 10.1.2.4 的包，因为目标不是本机，所以执行转发动作，然后根据本机防火墙的策略，返回相应的禁止报文。

@Executor 说明机房自己做的一坨, 瞎整, 一刀切.
要不就忍气吞声, 把 drop 改回去, 要不就另寻其他机房吧