Cisco 会为自己的接口丢弃 TTL=1 的数据包吗?

网络工程 思科 ipv4 协议理论
2021-07-03 03:45:09

有许多关于路由器行为的问题与 TTL=1 的 IPv4 数据包和明显矛盾的答案。这个问题不是关于主机或路由器该做什么,而是关于设备在现场做什么的实际问题。

问题:在 IPv4 中,我们能否找到 Cisco 路由器或其他制造商的型号/配置,其中当数据包的目标地址是该路由器接口的地址之一时,路由器会丢弃已过期的 TTL=1 数据包?

我的信念是,路由器将对其任何 IP 地址(ACL 允许)的数据包做出相同的回复,到目前为止,我对我很容易获得的设备进行的实验已经证实了这一点。但这与 Ron Maupin 的实验相矛盾https://networkengineering.stackexchange.com/a/45421

  • 行为一是端点路由器递减TTL从近到远接口穿越
  • 行为2是端点路由器不递减TTL从近到远接口穿越

我只能找到行为 2 的路由器。

          MINIMAL                NON-MINIMAL

           =+=               +---R2---R3--...--+
            |Afar            |                 |Anear
            R                R1                Rn
            |Anear           |                 |Afar
    ===+====+====     ===+===+====           ==+==
       |                 |
       H                 H
   Anear = address of interface nearest H
   Afar  = address of interface not nearest H

实验 1:最小,使用 TTL=1 发送的数据包

该实验旨在与 Ron Maupin 在其回答中的基本相同https://networkengineering.stackexchange.com/a/45421

我们发现 TTL=1 的数据包到达近和远接口。

  • H 是 Ubuntu 192.168.0.210/24,默认路由到 192.168.0.1
  • R 是 Cisco 867VAE,版本 15.2(4)M3 近端是 vlan0 192.168.0.1/24,远端是 loopback0=10.0.0.1/24

坪附近

$ ping -t 1 -c 1 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=1.72 ms

H 上的 tcpdump 显示数据包以 TTL=1 离开,答案返回

17:43:52.960574 IP (tos 0x0, ttl 1, id 11971, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.210 > 192.168.0.1: ICMP echo request, id 10823, seq 1, length 64
17:43:52.962266 IP (tos 0x0, ttl 255, id 11971, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.1 > 192.168.0.210: ICMP echo reply, id 10823, seq 1, length 64

平远方

$ ping -t 1 -c 1 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=1.27 ms

H 上的 tcpdump 显示 TTL=1 的数据包和返回的答案

17:44:32.094832 IP (tos 0x0, ttl 1, id 8632, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.210 > 10.0.0.1: ICMP echo request, id 10830, seq 1, length 64
17:44:32.096070 IP (tos 0x0, ttl 255, id 8632, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.0.1 > 192.168.0.210: ICMP echo reply, id 10830, seq 1, length 64

实验 2:非最小

这本来是一样的,但接口都是物理的,发送的 TTL 刚好足以到达路由器。我们发现 TTL=2 在近端和远端接口上失败,而 TTL=3 在近端和远端接口上成功。

  • H 是 192.168.0.210/24 上的 Ubuntu
  • Rn 是 Cisco 2811 15.1(4)M10,近端 FastEthernet0/0 位于 172.30.20.251/24,远端 FastEthernet0/1 位于 172.31.20.254/24

对于近端和远端地址,TTL=2(均失败)和 TTL=3(均成功)的结果相同。

$ ping -t 2 -c 1 172.30.20.251 | fgrep -i From
From 192.168.253.254 icmp_seq=1 Time to live exceeded
$ ping -t 2 -c 1 172.31.20.254 | fgrep -i From
From 192.168.253.254 icmp_seq=1 Time to live exceeded
$ ping -t 3 -c 1 172.30.20.251 | fgrep -i From
64 bytes from 172.30.20.251: icmp_seq=1 ttl=252 time=49.2 ms
$ ping -t 3 -c 1 172.31.20.254 | fgrep -i From
64 bytes from 172.31.20.254: icmp_seq=1 ttl=252 time=49.1 ms

这些是来自 H 的 tcpdumps:

TTL=2,数据包离开,超时返回

靠近

18:31:23.098358 IP (tos 0x0, ttl 2, id 38235, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.210 > 172.30.20.251: ICMP echo request, id 11423, seq 1, length 64
18:31:23.146825 IP (tos 0xc0, ttl 253, id 36603, offset 0, flags [none], proto ICMP (1), length 56)
    192.168.253.254 > 192.168.0.210: ICMP time exceeded in-transit, length 36
    IP (tos 0x0, ttl 1, id 38235, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.210 > 172.30.20.251: ICMP echo request, id 11423, seq 1, length 64

远的

18:31:23.152807 IP (tos 0x0, ttl 2, id 61977, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.210 > 172.31.20.254: ICMP echo request, id 11425, seq 1, length 64
18:31:23.201199 IP (tos 0xc0, ttl 253, id 36606, offset 0, flags [none], proto ICMP (1), length 56)
    192.168.253.254 > 192.168.0.210: ICMP time exceeded in-transit, length 36
    IP (tos 0x0, ttl 1, id 61977, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.210 > 172.31.20.254: ICMP echo request, id 11425, seq 1, length 64

TTL=3 时,ICMP 回显和响应近端和远端地址

近侧:

18:31:23.211459 IP (tos 0x0, ttl 3, id 38260, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.210 > 172.30.20.251: ICMP echo request, id 11427, seq 1, length 64
18:31:23.259514 IP (tos 0x0, ttl 252, id 38260, offset 0, flags [DF], proto ICMP (1), length 84)
    172.30.20.251 > 192.168.0.210: ICMP echo reply, id 11427, seq 1, length 64

远端

18:31:23.268194 IP (tos 0x0, ttl 3, id 61985, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.210 > 172.31.20.254: ICMP echo request, id 11429, seq 1, length 64
18:31:23.316748 IP (tos 0x0, ttl 252, id 61985, offset 0, flags [DF], proto ICMP (1), length 84)
    172.31.20.254 > 192.168.0.210: ICMP echo reply, id 11429, seq 1, length 64
2个回答

似乎不同的路由设备以不同的方式执行此操作,此答案仅详细说明了一个案例。评论中关于不同行为的讨论以及 IPv6 中的讨论非常有帮助。以下内容不应被视为对我的一般问题的明确回答

在路由器上使用数据包捕获的测试程序

带有 15.2(4)M3 的 Cisco 867VAE-K9 路由器具有多个本地接口,以及连接在 Virtual-PPP1 远端的测试计算机。我们将ping近接口和两个远接口,一个vlan,一个环回。

我们在一个多跳网络上执行此操作,以便我们可以看到发送的 ping 的 TTL 变化会导致到达路由器的数据包成功或失败以及 ping 响应,以便忽略任何其他配置问题,例如作为 ACL,路由。

Ping 从 H 发送到 GW,需要 TTL=3 才能到达。TTL=2 数据包未到达并由 R255 过期(带有 ICMP 时间超出消息)。

                       R255
                  .255/  \.255
 tunnels in          /    \
 192.168.253/24   .8/      \.0 on Virtual-PPP1
                  R8        GW---| 10.0.0.1 on Loopback0
  192.168.8/24    |.1       |.1 on Vlan1
       ======+====+==     ==+===
             |.192
             H

接口

gw#show ip int b
Interface                  IP-Address      OK? Method Status                Protocol
Loopback0                  10.0.0.1        YES NVRAM  up                    up      
Virtual-PPP1               192.168.253.0   YES IPCP   up                    up      
Vlan1                      192.168.0.1     YES NVRAM  up                    up   

数据包捕获的访问列表

gw#show access-list 111
Extended IP access list 111
    10 permit ip host 192.168.8.192 any
    20 permit ip any host 192.168.8.192

抓包

gw#monitor capture buffer BUF1
gw#monitor capture buffer BUF1 max-size 2000 
gw#monitor capture buffer BUF1 filter access-list 111
Filter Association succeeded
gw#monitor capture point ip process-switched POINT1 both
gw#monitor capture point associate POINT1 BUF1
gw#monitor capture buffer BUF1 clear
gw#monitor capture point start POINT1

在远程计算机上,这些都失败了(并且不会在 gw 上的数据包捕获中显示)

ping -c 1 -t 2 192.168.0.1
ping -c 1 -t 2 10.0.0.1
ping -c 1 -t 2 192.168.253.0

在远程计算机上,这些都成功了(并且都将显示在数据包捕获中)

ping -c 1 -t 3 192.168.0.1
ping -c 1 -t 3 10.0.0.1
ping -c 1 -t 3 192.168.253.0

完成捕获并导出 PCAP 文件

gw#monitor capture point stop POINT1 
gw#monitor capture buffer BUF1 export tftp://192.168.0.32/ping.pcap

捕获显示以 TTL=1 到达的数据包和发送的响应,对于近端接口和远端接口都是一样的。

$ tcpdump -nv -r ping.pcap 
reading from file ping.pcap, link-type RAW (Raw IP)
20:14:18.328670 IP (tos 0x0, ttl 1, id 20579, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.8.192 > 192.168.0.1: ICMP echo request, id 25603, seq 1, length 64
20:14:18.328670 IP (tos 0x0, ttl 255, id 20579, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.1 > 192.168.8.192: ICMP echo reply, id 25603, seq 1, length 64
20:14:18.556668 IP (tos 0x0, ttl 1, id 46061, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.8.192 > 10.0.0.1: ICMP echo request, id 25604, seq 1, length 64
20:14:18.556668 IP (tos 0x0, ttl 255, id 46061, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.0.1 > 192.168.8.192: ICMP echo reply, id 25604, seq 1, length 64
20:14:18.780667 IP (tos 0x0, ttl 1, id 38504, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.8.192 > 192.168.253.0: ICMP echo request, id 25605, seq 1, length 64
20:14:18.780667 IP (tos 0x0, ttl 255, id 38504, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.253.0 > 192.168.8.192: ICMP echo reply, id 25605, seq 1, length 64

结论

我们看到 TTL=1 的 ECHO REQUEST 数据包到达,然后 ECHO REPLY 数据包离开,用于近端和远端接口。

因此我们得出结论,Cisco 路由器不会减少 TTL 以到达但不会退出与 IPv4 数据包的入口接口不同的接口。

正如承诺的那样,我可以在以下设备上确认与上述相同的结果:

带有运行 VSS 的 Supervisor 2T 的 Cisco 6509。

cisco WS-C6509-E (M8572) processor (revision 0) with 3162112K/524288K bytes of memory. 
Cisco IOS Software, s2t54 Software (s2t54-ADVENTERPRISEK9-M), Version 15.2(1)SY5, RELEASE SOFTWARE (fc4)

思科 C9500-16X

Cisco IOS Software [Everest], Catalyst L3 Switch Software (CAT9K_IOSXE), Version 16.6.3, RELEASE SOFTWARE (fc8) 

思科 897 系列

Cisco IOS Software, C800 Software (C800-UNIVERSALK9-M), Version 15.4(2)T1, RELEASE SOFTWARE (fc3)

当数据包在多个接口之间在内部穿过路由器时,它们都不会减少 TTL。当数据包离开路由器时,它将被递减,当它被添加到输出接口上的出口队列时。