cisco7200路由器响应icmp消息而不是发给它

我试图在三个通过集线器连接的路由器的一个非常简单的拓扑结构中(在GNS3中,如果有的话)。 我试图从路由器之一ping到另一个说R1到R2的时间。 R3使用ICMPredirect消息进行应答,导致R1重新向R2发出ping请求。 循环在模拟networking上继续无限破坏。 问题是为什么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# 

更新:问题不是ICMPredirect,而是任何路由器将放置ICMP ping数据包的事实,它不能处理它到达的接口,从洪泛networking到TTL过期。

原始答复

这是因为你的拓扑结构。 我会假设你在192.168.0.0/16子网上ping? 即使您正在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数据包networking。 解决scheme:将集线器更改为交换机,或按照Ron的build议实施no ip redirects规则。

附录:比较和对比集线器与交换机,详细的分组交换机制以及各种硬件协议

Hub:

集线器是一个简单的设备,只知道如何做一件事:广播在所有接口上收到的内容。 当一个数据包来自networking中心的三个路由器之一时,集线器就会知道如何去做:

集线器IO

ICMP协议

与其他networking协议相比,ICMP协议具有一些特殊的特征。 它位于Internet(或IP)层之上,即TCP / IP模型中的第3层。 许多人乍看之下会认为它会和其他应用程序协议一起存在于第2层中,但事实并非如此。 这是因为ICMP最初被devise成错误消息协议 。 ICMP协议报告有关IP层的元数据,以防万一丢包或无法访问的目的地等exception行为。 所以,当一个ICMP数据包进入一个设备(如路由器)时,设备会检查它发往的ICMP数据包的位置,如果它的目的地是设备本身,它会用新的消息(例如PING REPLY)作出响应。 如果它的目的地是另一个设备,它会减less生存时间(TTL),并根据设备的路由表发送数据包。

思科路由表

还有第三个难题需要考虑,那就是思科设备的路由表。 我们知道路由表在networking运行一段时间后的样子。 回答你的问题:

为什么路由器通过目的地networking(比如10.1.0.0)通过192.168.0.0的路由直接连接到它,而不是通过任何路由器报告。

这是由于Cisco路由器上的networking发现机制。 注意路由表中的这些行:

 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,它是一种专有路由algorithm,用于填充Cisco设备上的路由表。 我不确定路由表是如何填充的细节,但这是无关紧要的。 每台路由器都知道它可以通过192.168.0.0/16子网发送stream量来访问其他两台路由器面向外的接口 。 因此,当发往这些接口中的任何一个(例如ICMP PING REQUEST)的数据包从集线器进入路由器时,每个路由器知道它可以通过本地子网到达目的地networking。 因此,只要数据包没有绑定到设备本身,这些数据包的TTL就会减less,它们将被转发回到集线器(下面的图表发生在每个接收到一个没有绑定自己的数据包并且没有发送的设备上从本身):

ICMP图

正如你所看到的,这三件事一起创build一个循环,保持转发和生成重复的ICMP数据包,直到数据包发生以下情况之一:

  1. 数据包到达目的地并被使用。
  2. 数据包的TTL达到零,并被丢弃(但在networking上生成并触发ICMP HOST UNREACHABLE响应)。
  3. 数据包在接收设备上已被注册为复制品(已被使用)并被丢弃。

在我的答案中可能有一些概括,但你得到的图片。 集线器产生的数据包多于消耗的数据包。

交换机的行为如何不同(以及为什么我们使用交换机而不是集线器)

当你第一次插入交换机时,就像集线器一样愚蠢。 但是,主要区别在于,交换机可以通过关注来自设备的stream量来了解数据包的来往和去向。 当交换机首次遇到数据包时,它不知道目的地连接到哪个接口,因此将其转发到所有连接的接口。 当它这样做时,它将源IP和目的IPlogging到它的交换表中。 当检测到来自该目的地(并且指向原始源)的响应时,它完成切换表中的条目。 在此之后,交换机知道哪些IP地址连接到相应的接口 。 从这时起,当它接受一个数据包时,它只会将它转发出来,知道目标是连接的。 这消除了重复数据包问题。

MAC与IP地址和使用以太网与PPP的分组路由

你问:

为什么接收到R2(从R1发送)的MAC目的地的数据包的路由器R3将在ICMP级别上响应呢?

使用以太网和其他协议利用MAC地址的分组路由

数据包可能以空的或BROADCAST目标MAC地址开始(取决于硬件标准)。 使用以太网硬件标准(以及less数其他的如Wifi),当任何数据包从路由器或主机发出时,目的地IP将通过地址parsing协议(ARP)表进行检查(这是保留跟踪MAC地址)。 如果在同一个子网上发现与本地连接的计算机相匹配的数据包,则在数据包的MAC地址字段在networking上发送之前会进行更新。 但是,如果数据包的目的地址是不同子网上的IP地址,则将MAC地址设置为默认网关的MAC或者知道它可以到达目的IP的网关(因为机器知道目的地在不同的networking上 )。

分组路由PPP,SLIP和其他不利用MAC地址的硬件协议

通常情况下,如果两台路由器(网关)直接连接,而没有路由器,则认为是“点对点”连接。 通常,这些types的连接不是以太网,而是使用其他标准。 这些标准中最常见的是点对点协议(PPP),但还有其他的如SLIP和PPPoE(PPP over Ethernet)。 如果路由器将其路由表中的“C”连接或“O”SPF条目视为对等连接,则可以将数据包上的MAC地址设置为空值,或设置为BROADCAST使用虚拟值,甚至根本不使用MAC地址(根据连接硬件协议的标准,这可能会有所不同,但在这种情况下,我并不熟悉这些标准)。 为了确切地说明发生了什么,您将不得不进一步了解Cisco路由器硬件标准以及它们如何处理MAC地址和对等连接,以及他们正在使用哪个硬件协议(默认情况下最可能是PPP )。

在这种情况下的意义

当数据包通过networking传输时,每个接收路由器都会执行以下两项操作之一(取决于所使用的硬件协议):

  1. 以太网,Wifi和其他硬件标准:如果可以find路由,则在路由中更改MAC地址 ,或者
  2. PPP,SLIP和其他硬件标准:它将MAC留空,或将其设置为任何接收机接受的特殊BROADCAST值,或者甚至可以不关心MAC地址,甚至可以将它们设置为虚拟值。

这发生在networking的每一跳,直到路由器检测到目标IP位于其本地以太网(或使用MAC的其他标准)子网上。 这是地址在硬件或物理层被翻译的有效方式。 所以,为了回答你的问题,在这种情况下,看起来R3都知道这个数据包是通过它的f1 / 0接口到达的另一个networking的。 它不关心MAC地址是什么,因为它使用的是不利用MAC地址的协议。 据微软称 :

看看Ethereal上看到的MAC头是在WANARP和NDISWAN之间添加的虚拟以太网头。 这样,networking监视器(如ethereal) 将PPP接口视为以太网 接口 。 但在有线networking上,数据包将不包含该以太网报头,而是TCP-> IP-> PPP报头

所以你不应该把networking监视器上的MAC地址视为 真正的MAC地址。

请注意,路由表中没有默认网关:

 Gateway of last resort is not set 

这和主条目被列为directly connected的事实一样,表明它将把它的所有连接看作是对等连接(因此MAC地址是不可知的)。

顺便说一句,你可能想知道为什么MAC地址不是用于PPP,或者更普遍的说是用于一般的networking寻址。 看看这个post在这里 。 对接受的答案的第一个评论确认了我一直在说的话:

我会补充说,一旦计算机确定它们在同一个子网中,MAC地址最终用于IP通信中。 第3层/ IP寻址主要由路由器使用,并且仅由主机用来确定目的地是在同一个子网上。 (感谢Sean C.)