关于网关mac地址更改时主机行为的问题(虽然它涉及Windows,但我认为这是最好的论坛)。
假设 Windows 主机向目标 IP 发送流量,Windows 使用 ARP 表将流量发送到网关 MAC 地址。假设此网关 MAC 地址更改(未启用持久 MAC 地址的堆栈故障转移或其他情况),Windows 如何检测 MAC 地址更改?这个检测需要多长时间?
关于网关mac地址更改时主机行为的问题(虽然它涉及Windows,但我认为这是最好的论坛)。
假设 Windows 主机向目标 IP 发送流量,Windows 使用 ARP 表将流量发送到网关 MAC 地址。假设此网关 MAC 地址更改(未启用持久 MAC 地址的堆栈故障转移或其他情况),Windows 如何检测 MAC 地址更改?这个检测需要多长时间?
主机(Windows 或任何其他)试图通过尽可能多的方式保持其 ARP 表的准确性。通常缓存条目有一个超时,并且它只是在一段时间后被丢弃,因为它已经确认了这个地址(通常在 60 到 1500 秒的范围内)——但这只是为了处理最坏的情况。它还将在许多其他条件下更快速地更新它,特别是来自该其他主机的任何传入数据包。
在您描述的情况下,一台 PC 和一台路由器,如果路由器在流量中途突然更改以太网地址,则通常有许多 TCP 连接在通信。其中一个很可能是从路由器到 PC 的数据包,带有新的以太网地址。此时 PC 更新其缓存,并启动计时器。如果下一个数据包是传出的,PC 可以在进行 TCP 重试时使其缓存条目无效,并执行正常的 ARP 请求。(给定的操作系统是否这样做是其他地方的主题。)如果传出流量是仅发送的(可能是通过 UDP 的 syslog)并且路由器确实没有任何内容,那么 PC 将不知道任何有关更改的信息,并且将在我们上次从路由器收到超时后过期此缓存条目 - 这将是最后一个 ARP 回复。
正常情况是,当任何主机更改以太网(或 IP)地址时,它会发送 ARP 公告数据包以告知所有其他主机新的详细信息。
最坏的情况是 PC 不断向旧的以太网地址发送一些东西,直到缓存超时,然后发出新的 ARP 请求,数据包传输恢复。
ARP RFC 826确实是推荐阅读。地址冲突RFC 5227也涵盖了很多好的案例。
只是作为后记,路由器更改其 MAC 地址非常罕见,除非 a)它实际上是一个不同的路由器,或者 b)有某种重新配置。为了解决没有良好路由协议的主机的单点故障问题,热备份路由器协议和类似协议提供了多个路由器共享一个以太网地址的方法。(HSRP RFC 2281、VRRP RFC 5798)。
ARP 表中的条目具有有限的生命周期。
当它们过期时,ARP 进程将它们从表中删除,并且下次需要与关联的 IP 地址通信时,它将执行 ARP 请求以找出该 IP 地址的 MAC 地址 - 无论是相同的还是新的一个。
此外,此条目在使用时不会刷新,因此无论流量如何,它都会在生命周期值之后被丢弃。
因此,如果任何 MAC 地址发生变化,与相应主机的通信将失败,直到 ARP 条目过期并更新 APR 表。
如果发生更改,可能会发送无偿 arp以通知主机更改,但这取决于设备。