我正在尝试(如果重要的话,在 GNS3 中)使用一个非常简单的拓扑结构,该拓扑结构由三个通过集线器连接的路由器组成。我尝试从其中一个路由器 ping 到另一个路由器,例如从 R1 ping 到 R2。R3 使用 ICMP 重定向消息进行回复,导致 R1 重新向 R2 发出 ping 请求。循环继续无限地破坏模拟网络。问题是为什么 R3 会向 R1 回复不是发给它的 ICMP 消息(ping 是从 R1 到 R2)。
R3 路由表:
R3>enable
Password:
R3#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
O 10.1.0.0/16 [110/2] via 192.168.0.1, 00:58:17, FastEthernet1/0
O 10.2.0.0/16 [110/2] via 192.168.0.2, 00:58:17, FastEthernet1/0
C 10.3.0.0/16 is directly connected, FastEthernet0/0
L 10.3.0.1/32 is directly connected, FastEthernet0/0
C 192.168.0.0/16 is directly connected, FastEthernet1/0
192.168.0.0/32 is subnetted, 1 subnets
L 192.168.0.3 is directly connected, FastEthernet1/0
R3#
更新:问题不在于 ICMP 重定向,而在于任何路由器都会将其无法处理的 ICMP ping 数据包放回到它到达的接口,从而淹没网络,直到 TTL 过期。
答案1
原始答案
这种情况的发生是因为您的拓扑。我假设您正在 ping 192.168.0.0/16 子网?即使您正在 ping 路由器上的向外接口(10.1.0.0/16、10.2.0.0/16、10.3.0.0/16),它们在到达目的地的途中仍会通过 192.168.0.0 子网进行路由。发生这种情况的原因是您使用集线器连接同一子网上的所有三台机器(而不是交换机)。默认情况下,集线器的性质是广播在其所有接口上收到的所有消息(与通过响应了解哪些机器连接到其接口的交换机相反)。
因此,ICMP 数据包离开 R1,当它到达集线器时,它会被广播到 R2 和 R3(以及 R1)。这实际上将数据包复制成三份。重复的数据包到达 R1、R2 和 R3 并触发转发规则:
C 192.168.0.0/16 is directly connected, FastEthernet1/0
有效地将数据包弹回集线器。如此反复,您的网络就会被成倍增加的 ICMP 数据包淹没。解决方案:将集线器更改为交换机或no ip redirects
按照 Ron 的建议实施规则。
附录:比较和对比集线器与交换机,以及各种硬件协议的详细数据包交换机制
中心:
集线器是一种简单的设备,它只知道如何做一件事:在所有接口上广播它收到的内容。当数据包来自网络中心的三个路由器之一时,集线器会执行它所知道的操作:
ICMP 协议
与其他网络协议相比,ICMP 协议具有一些特殊特性。它位于 Internet(或 IP)层之上,即 TCP/IP 模型中的第 3 层。很多人乍一看以为它会与其他应用协议一起存在于第 2 层,但事实并非如此。这是因为 ICMP 最初设计为错误消息协议。ICMP 协议会在出现异常行为(例如数据包丢失或无法到达目的地)时报告有关 IP 层的元数据。因此,当 ICMP 数据包进入设备(例如路由器)时,设备会检查 ICMP 数据包的目的地,如果其目的地是设备本身,它会以新消息(例如 PING REPLY)进行响应。如果其目的地是另一台设备,它会减少生存时间 (TTL) 并根据设备的路由表发送数据包。
思科路由表
还有第三个需要考虑的部分,那就是 Cisco 设备的路由表。我们知道网络运行一段时间后路由表会是什么样子。回答您的问题:
为什么通过目标网络(例如 10.1.0.0)的任何路由器路由都会直接连接到它,而不会通过任何路由器报告。
这是由于 Cisco 路由器上的网络发现机制造成的。请注意路由表中的以下几行:
O 10.1.0.0/16 [110/2] via 192.168.0.1, 00:58:17, FastEthernet1/0
O 10.2.0.0/16 [110/2] via 192.168.0.2, 00:58:17, FastEthernet1/0
开头的 O 代表 OSPF,这是一种专有路由算法,用于填充 Cisco 设备上的路由表。我不确定路由表是如何填充的,但这有点不相关。每个路由器都知道它可以访问另外两个路由器的向外接口通过 192.168.0.0/16 子网发送流量。因此,当发往这些接口的数据包(例如,ICMP PING 请求)从集线器进入路由器时,每个路由器都知道它可以通过本地子网到达目标网络。因此,只要数据包不是发往设备本身,这些数据包的 TTL 就会减少,并且它们将被转发回集线器(下图发生在每个收到不发往自身且不是从自身发送的数据包的设备上):
如您所见,这三件事共同形成了一个循环,该循环不断转发并生成重复的 ICMP 数据包,直到数据包发生以下情况之一:
- 数据包到达目的地并被使用。
- 数据包的 TTL 达到零并被丢弃(但会生成 ICMP HOST UNREACHABLE 响应并在网络上发出)。
- 该数据包在接收设备上被注册为重复(已被消耗)并被丢弃。
我的回答可能有些泛泛,但你应该明白了。集线器生成的数据包比消耗的多。
交换机的行为有何不同(以及为什么我们使用交换机而不是集线器)
当你第一次插入交换机时,它就像集线器一样愚蠢。然而,主要的区别在于交换机可以学习通过关注通过设备的流量,可以确定数据包的来源和去向。当交换机第一次遇到数据包时,它不知道目的地连接到哪个接口,因此它会将其转发到其所有连接的接口。当它这样做时,它会将源和目标 IP 记录在其交换机表中。当检测到来自该目的地(并发往原始源)的响应时,它会完成交换机表中的条目。此后,交换机知道哪些 IP 地址连接到相应的接口从此时起,当它接受数据包时,它只会将其转发到它知道目的地连接的接口。这消除了重复数据包的问题。
MAC 地址与 IP 地址以及以太网与 PPP 的数据包路由
你问:
为什么路由器 R3 接收到 MAC 目的地为 R2 的数据包(从 R1 发送)时会在 ICMP 级别做出响应?
使用以太网和其他利用 MAC 地址的协议进行数据包路由
数据包可能以空或广播目标 MAC 地址开头(取决于硬件标准)。以太网硬件标准(以及少数其他标准,如 Wifi),当任何数据包从路由器或主机发出时,都会根据地址解析协议 (ARP) 表(此表用于跟踪 MAC 地址)检查目标 IP。如果在同一子网上找到与本地连接的机器匹配的地址,则在数据包发送到网络之前更新其 MAC 地址字段。但是,如果数据包的目的地是不同子网上的 IP 地址,则 MAC 地址将设置为默认网关的 MAC,或者它知道可以到达目标 IP 的网关(因为机器知道目标位于不同的网络)。
数据包路由 PPP、SLIP 和其他不使用 MAC 地址的硬件协议
通常,如果两个路由器(网关)直接连接,中间没有路由器,则这被视为“对等”连接。通常,这些类型的连接不是以太网,而是使用其他标准。这些标准中最常见的是点对点协议 (PPP),但还有其他标准,例如 SLIP 和 PPPoE(以太网上的 PPP)。如果路由器将其路由表中的“C”连接或“O”SPF 条目视为对等连接,则数据包上的 MAC 地址可以设置为空值,或设置为 BROADCAST,或者它们可以使用虚拟值,甚至根本不使用 MAC 地址(这可能因连接它们的硬件协议的标准而异,但在这种情况下我不熟悉)。为了确切地知道发生了什么,您必须了解有关 Cisco 路由器硬件标准的更多信息,以及它们如何处理 MAC 地址和对等连接以及它们正在使用哪种硬件协议(默认情况下很可能是 PPP)。
此情景的含义
当数据包通过网络传输时,每个接收路由器都会执行以下两项操作之一(取决于所使用的硬件协议):
- 以太网、Wifi等硬件标准:它要么在途中更改 MAC 地址如果它能找到一条路线,或者
- PPP、SLIP 和其他硬件标准:它使 MAC 留空,或将其设置为任何接收机器都可以接受的特殊 BROADCAST 值,或者它甚至可能根本不关心 MAC 地址,甚至可以将它们设置为虚拟值。
这种情况在网络上的每一跳都会发生,直到路由器检测到目标 IP 位于其本地以太网(或使用 MAC 地址的其他标准)子网中。这实际上是地址在硬件或物理层。因此,回答您的问题,在这种情况下,似乎 R3 只知道该数据包的目的地是另一个可以通过其 f1/0 接口到达的网络。 它不关心 MAC 地址是什么,因为它使用不利用 MAC 地址的协议。 据微软称:
查看线程,在 Ethereal 上看到的 MAC 标头是 WANARP 和 NDISWAN 之间添加的虚拟以太网标头。这样,网络监控(如 Ethereal)将 PPP 接口视为以太网 界面。但在网络上...数据包将不包含以太网报头,而是 TCP->IP->PPP 报头
因此,您不应该将网络监视器上的 MAC 地址视为 真实的 MAC 地址。
请注意,您的路由表中没有默认网关:
Gateway of last resort is not set
这一点,加上主要条目被列为directly connected
,表明它会将所有连接视为对等连接(因此与 MAC 地址无关)。
另外,您可能想知道为什么 MAC 地址不用于 PPP,或者更广泛地说,不用于一般的网络寻址。查看此帖子这里。对已接受答案的第一条评论证实了我所说的内容:
我要补充一点,一旦计算机确定它们位于同一个子网上,MAC 地址最终就会用于 IP 通信......第 3 层/IP 寻址主要由路由器使用 并且仅由主机使用来确定目标是否位于同一子网。(感谢 Sean C.)