当前位置： 首页 > article >正文

TTL 传输中过期问题定位

article 2025/1/6 3:15:07

问题：

   工作环境中有一个ac+ap的环境，ac的wan口ip是192.168.186.195/24，ac上lan上有vlan205，其ip子接口地址192.168.205.1/24，ac采用非nat模式，而是路由模式，在上级路由器上有192.168.205.0/24指向ac的wan口地址192.168.186.195，而ac上有缺省路由0.0.0.0/0指向192.168.186.1，pc地址是192.168.186.118/24,gw是192.168.186.1。

现在ping192.168.205.1，打印TTL 传输中过期。如下图：

排查过程：

ping消息属于icmp协议的诊断工具命令，有导通的正常对request消息发出的reply回显和不正常的错误报告,或者没有在等待超时后，没有reply或者错误回显三种情况。ttl传输中过期，属于错误回显。

icmp消息四种功能描述：

  1. 错误报告：当IP数据包无法到达目的地或发生其他错误时，ICMP可以生成错误报告并将其返回给源主机。
  2. 诊断工具：ICMP还可以用于网络诊断和故障排除，例如ping命令。
  3. 路由选择：ICMP可以提供路由选择信息，帮助路由器选择最优路径。
  4. 流量控制：ICMP还可以用于控制网络流量，例如通过发送ICMP重定向消息，告知主机更好的路由选择，从而减少不必要的网络流量。

 icmp消息常见类型：

发现ac的地址回了 TTL 传输中过期，ttl exceeded是数据包传输过程中的节点收到ttl=1的包后，发出icmp消息给源主机，并丢弃该包数据。icmp发出的源ip是由节点的路由表决定的，会用正常的访问时的出口ip地址给源ip返回一个icmp消息。

抓包看到如下：

知道Time-to-live exceeded是当节点设备收到ip层ttl为1的包时，发给源ip，告知这个数据包的在网络中传输极限已经到达，将被丢弃。

看一下路由器route print  -4 回车

查一下arp表，看一下对应192.168.186.0网段的mac地址情况，知道一下数据的来源：

arp  -a | findstr  186.

C:\Windows\System32>arp  -a | findstr  186.  回车 findstr是在前一个命令里查找对应字符串
接口: 192.168.186.118 --- 0x12
  192.168.186.1           64-a3-41-03-a0-a1     动态
  192.168.186.192       cc-96-e5-23-3a-36     动态
  192.168.186.195       64-c3-41-b2-18-21     动态
  192.168.186.221       32-1e-5b-f9-eb-7e     动态

而自身的ip192.168.186.118的mac地址是

C:\Windows\System32>getmac  /v

连接名          网络适配器      物理地址            传输名称
=============== =============== =================== ==========================================================
以太网          Realtek PCIe Gb CC-96-E5-23-39-3C   \Device\Tcpip_{E23FF6BD-F5DA-4E0C-B23F-FB03429AAAB6}
WLAN            Realtek 8821CE  74-97-79-A9-A6-13   媒体已断开连接

看抓包的显示是设备ac192.168.186.195给回的ttl 传输中过期的消息。

发现开始的ping消息，ttl为128从Source: cc:96:e5:23:39:3c (192.168.186.118)发给Address: 64:a3:41:03:a0:a1 (192.168.186.1)，匹配路由表的默认路由和自身路由和直连路由.

而icmp的Time-to-live exceeded是从Source: 64:c3:41:b2:18:21 (192.168.186.195)发给cc:96:e5:23:39:3c（192.168.186.118）

为了看数据包的传输过程，执行一下tracert   -w 1  -d  192.168.205.1，查看一下数据传输的路径

-w 1是超时等待时间为1s，-d是不进行dns解析，这两个参数能加快回显速度。

C:\Windows\System32>tracert  -w 1 -d  192.168.205.1

通过最多 30 个跃点跟踪到 192.168.205.1 的路由

  1    <1 毫秒   <1 毫秒   <1 毫秒 192.168.186.1
  2     1 ms     2 ms    <1 毫秒 192.168.186.195
  3    <1 毫秒    1 ms     1 ms  192.168.186.1
  4     1 ms     2 ms     1 ms  192.168.186.195
  5     1 ms     1 ms     1 ms  192.168.186.1
  6     1 ms     1 ms     1 ms  192.168.186.195
  7     1 ms     1 ms     1 ms  192.168.186.1
  8     1 ms     1 ms     1 ms  192.168.186.195
  9     1 ms     1 ms     *     192.168.186.1
 10     1 ms     *        *     192.168.186.195
 11     1 ms     *        *     192.168.186.1
 12     1 ms     4 ms     *     192.168.186.195
 13     2 ms     *        3 ms  192.168.186.1
 14     2 ms     2 ms     *     192.168.186.195
 15     2 ms     *        2 ms  192.168.186.1
 16     2 ms     4 ms     *     192.168.186.195
 17     2 ms     *        2 ms  192.168.186.1
 18     3 ms     2 ms     *     192.168.186.195
 19     2 ms     *        4 ms  192.168.186.1
 20     2 ms     2 ms     *     192.168.186.195
 21     2 ms     *        3 ms  192.168.186.1
 22     2 ms     2 ms     *     192.168.186.195
 23     2 ms     *        2 ms  192.168.186.1
 24     3 ms     3 ms     *     192.168.186.195
 25     2 ms     *        5 ms  192.168.186.1
 26     2 ms     2 ms     *     192.168.186.195
 27     3 ms     *        2 ms  192.168.186.1
 28     3 ms     2 ms     *     192.168.186.195
 29     3 ms     *        4 ms  192.168.186.1
 30     5 ms     3 ms     *     192.168.186.195

跟踪完成。

抓包显示

windows里tracert的原理就是分别发出发送ttl从1-30（最大ttl=30，当收到目的设备reply，命令停止发ping的request，记录终点的ip地址）的包ping的request（每个ttl取值发三次ping的request消息，ttl从1开始），看那个设备回icmp的ttl超时消息，就证明经过的路由器是那个。

该例中，抓包显示ttl从1-30，当ttl为奇数时，是上级路由器192.168.186.1回的回ttl excceed，当ttl偶数时，是ac192.168.186.195回的ttl  exceeded过期消息。说明，数据会在上级路由器192.168.186.1和192.168.186.195间来回传递。

查看上级出口路由器的路由配置：

C       192.168.186.0/24 is directly connected, vlan1.1   这直连路由
C       192.168.188.0/24 is directly connected, vlan1.1
S       192.168.202.0/24 [1/0] via 192.168.186.195, vlan1.1
S       192.168.205.0/24 [1/0] via 192.168.186.195, vlan1.1 发现有这样的一条静态路由

show ip int brief  查看上级路由器的子接口ip
Interface             IP-Address      Status Protocol
vlan1.1               192.168.186.1   UP     UP       default        

决定在192.168.186.195的ac上看看，数据包的流向。

登录ac，切换到linux操作系统下进行tcpdump

然后在cmd下执行一次ping包

C:\Windows\System32>ping  192.168.205.1  -n 1

正在 Ping 192.168.205.1 具有 32 字节的数据:
来自 192.168.186.195 的回复: TTL 传输中过期。

192.168.205.1 的 Ping 统计信息:
    数据包: 已发送 = 1，已接收 = 1，丢失 = 0 (0% 丢失)，

tcpdump的抓包显示如下：

 tcpdump  -i eth0  -nnevv  -ttt  icmp and host  192.168.186.118 回车， -i eth0  指定eth0接口

-nnevv是显示mac地址，并关闭dns解析，用数字显示端口 vv是显示协议详情，-ttt是显示时间格式为时分秒微秒

发现规律：ping的request消息被反射回去，下一包和上一包的mac地址交换，ttl减1，ip层源目的ip地址不变。

发现整个过程中，ttl在减1，知道ac收到ttl为1的包后，向源ip192.168.186.118对应mac CC-96-E5-23-39-3C发了ttl超时的消息，如上图所示。

看来，是上级路由器192.168.186.1查路由表项192.168.205.0/24 via 192.168.186.195，把ping的request消息发给192.168.186.195ac，而ac上没有落地的192.168.205.0/24的落地路由，没有落地处理，查自身的默认0.0.0.0/0,指向192.168.186.1，request消息，被ttl-1后，又送出给上级路由器192.168.186.1，上级路由器根据路由表项192.168.205.0/24 via 192.168.186.195又送过来，这个过程中，ip包中，ttl被减1，二层中mac地址在互换。ping的包在二者直接来回乒乓震荡，直到ttl为1，ip包的生命周期到了为止。

ac上为啥没有落地处理192.168.205.1的包而送出呢？在ac上查看

ac上show ip route发现有下面的打印：

XOS#show ip route
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
       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, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default

Gateway of last resort is 192.168.186.1 to network 0.0.0.0

S*      0.0.0.0/0 [1/0] via 192.168.186.1, vlan1.4093 
C       127.0.0.0/8 is directly connected, lo
C       192.168.186.0/24 is directly connected, vlan1.4093
C       192.168.202.0/24 is directly connected, vlan1.202

没有192.168.205.0/24的直连路由显示，为啥，一般没有路由条目，要么没有配置，要么配置的路由对应网口没有激活，导致直连路由没有生成。检查一下子接口和网口的物理连接情况：

XOS#show int brief
The brief information of interface(s) under route mode:
Status: ADM - administratively down
Interface             IP-Address      Status Protocol Description
vlan1.1               172.16.81.1     DOWN   DOWN     
vlan1.202             192.168.202.1   UP     UP       202                 
vlan1.205             192.168.205.1   DOWN   DOWN     205        发现有配置子接口ip，但是down状态        
vlan1.4093            192.168.186.195 UP     UP       
vlan1.4094                            DOWN   DOWN     

The brief information of interface(s) under bridge mode:
Status: ADM - administratively down
Duplex: A - auto;H - half;F - full
Type:A - access;T - trunk;H - hybrid
Interface             Status Speed  Duplex Type PVID Description
eth0                  UP     1g     F      A    4093 eth0
eth1                  DOWN   1g     F      A    4094 eth1
eth2                  DOWN   1g     F      A    205    发现对应vlan205网络物理是down状态，导致子接口也是down状态
eth3                  DOWN   1g     F      A    202  
eth4                  UP     1g     F      T    202  
eth5                  UP     1g     F      A    202 

查看路由：

XOS(config-if)#show ip route    
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
       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, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default

Gateway of last resort is 192.168.186.1 to network 0.0.0.0

S*      0.0.0.0/0 [1/0] via 192.168.186.1, vlan1.4093
C       127.0.0.0/8 is directly connected, lo
C       192.168.186.0/24 is directly connected, vlan1.4093
C       192.168.202.0/24 is directly connected, vlan1.202

发现192.168.205.0/24的直连路由没有生成，而原因是对应子接口没有up，就是含有vlanid205

的网络接口物理状态没有up。

明白原因了，由于对应vlan205的接口down导致子接口down，没有对应直连路由生成，导致数据包到达ac后，无法落地，再次没送出，而上级路由器里有192.168.205.0/24指向192.168.186.195的路由条目，所以request消息，又被ttl减1后送来，再送出，这样乒乓循环，直到ac收到ttl为1的ping的reques消息后，发出ttl exceeded给源ip后，丢弃该包后结束。

解决方法：

只要解决子接口up问题，直连路由就会生成。

SVI 虚拟子接口接口 up的 条件，下面其一满足即可：
1、有接口被 access 这个vlan ，且这个物理接口 up
2、这个svi有trunk口，并且允许这个vlan 通过

我们把一个up的物理接口改成trunk口，默认vlanid不变，但添加vlanid205为物理上通过的vlanid。

解决方法把一个up的端口，改为trunk口，添加允许通过vlanid205

-------------------------------------------
 Interface name          : eth5
 Switchport mode         : trunk
 Ingress filter          : enable
 Acceptable frame types  : all
 Default Vlan            : 202
 Configured Vlans        : 202 205

XOS#show ip route
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
       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, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default

Gateway of last resort is 192.168.186.1 to network 0.0.0.0

S*      0.0.0.0/0 [1/0] via 192.168.186.1, vlan1.4093
C       127.0.0.0/8 is directly connected, lo
C       192.168.186.0/24 is directly connected, vlan1.4093
C       192.168.202.0/24 is directly connected, vlan1.202
C       192.168.205.0/24 is directly connected, vlan1.205  对应的192.168.205.0/24直连路由生成了

ping的结果：

C:\Windows\System32>ping  192.168.205.1  -n 1

正在 Ping 192.168.205.1 具有 32 字节的数据:
来自 192.168.205.1 的回复: 字节=32 时间=1ms TTL=64

192.168.205.1 的 Ping 统计信息:
    数据包: 已发送 = 1，已接收 = 1，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 1ms，最长 = 1ms，平均 = 1ms

tcpdump的结果：

 tcpdump  -i  eth0  -nnevv  icmp
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:16:32.985443 64:a3:41:03:a0:a1 > 64:c3:41:b2:18:21, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 127, id 16894, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.186.118 > 192.168.205.1: ICMP echo request, id 1, seq 968, length 40
15:16:32.985489 64:c3:41:b2:18:21 > cc:96:e5:23:39:3c, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 48259, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.205.1 > 192.168.186.118: ICMP echo reply, id 1, seq 968, length 40

pc的cmd下ping效果：

C:\Windows\System32>ping  192.168.205.1

正在 Ping 192.168.205.1 具有 32 字节的数据:
来自 192.168.205.1 的回复: 字节=32 时间=1ms TTL=64
来自 192.168.205.1 的回复: 字节=32 时间=1ms TTL=64
来自 192.168.205.1 的回复: 字节=32 时间<1ms TTL=64
来自 192.168.205.1 的回复: 字节=32 时间<1ms TTL=64

192.168.205.1 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 0ms，最长 = 1ms，平均 = 0ms

总结：

路由转发，就是二层mac层不断更改mac地址的过程，而ip层除了ttl还有经过nat设备更换目的ip外，其他的不变。就像信件的传递，邮车中转的邮局的城市街道门牌号不断变化，但信件的收发地址是不变的。

对于一个节点设备，收到一个ip包，判断是否落地，要看是否有直连网络路由和主机路由，目的ip符合主机路由就在节点上落地处理，符合直连路由，而且arp表表项有对应ip和mac对照关系，就改变mac层的源和目的mac转发出去，mac地址表项里没有对应项，就发出arp消息请求目的ip的mac，得到响应后，添加mac地址表项，再组包发出，没有得到arp响应，就由节点设备根据路由表选择对应ip发出目标主机不可达消息告知源主机。

TTL传输中过期，通常指的是数据包在网络中的生存时间（TTL值）超出限制，导致数据包被路由器丢弃，并且路由器会向数据包的发送方发送一个ICMP“Time Exceeded”消息。以下是一些可能导致TTL传输中过期的原因：

  1. ‌网络设备问题‌：路由器、交换机等网络设备配置错误或故障，可能导致数据包在传输过程中被错误地处理或丢弃。如果网络设备无法正确处理或转发数据包，就会引发TTL过期。

SVI 虚拟子接口接口 up的 条件，下面其一满足即可：
1、有接口被 access 这个vlan ，且这个物理接口 up
2、这个svi有trunk口，并且允许这个vlan 通过

tracert就是发ttl从1到xx的包，根据icmp的ttl传输中超时消息确定经过节点设备ip。

本例就是对应子接口物理接口没有up，导致路由环路导致出现的ttl传输中过期的问题。


http://www.kler.cn/a/464769.html

相关文章：

  • 探索 Android Instant Apps：InstantAppInfo 的深入解析与架构设计
  • 急需升级，D-Link 路由器漏洞被僵尸网络广泛用于 DDoS 攻击
  • PHP在做api开发中，RSA加密签名算法如何使用 ？
  • Django中自定义模板字符串
  • 力扣hot100——贪心
  • 高等数学学习笔记 ☞ 无穷小比较与等价无穷小替换
  • 【网络协议】路由信息协议 (RIP)
  • 【PyTorch][chapter 28][李宏毅深度学习][Diffusion Model-2]
  • C# 设计模式（结构型模式）：装饰器模式
  • 【51单片机-零基础chapter1】
  • MySQL/Oracle集群
  • 操作系统论文导读（八）：Schedulability analysis of sporadic tasks with multiple criticality specifications——具有多个
  • 8086汇编(16位汇编)学习笔记10.寄存器总结
  • 数据的高级处理——pandas模块进阶——使用Python进行数据分析
  • 六十二：HTTP/3: QUIC 协议格式
  • 爬虫在分析网站结构时的注意事项及代码示例
  • 活动预告 |【Part2】 Azure 在线技术公开课：迁移和保护 Windows Server 和 SQL Server 工作负载
  • 【数字电路一】逻辑代数基础
  • TLS: WebRTC中ThreadManager的线程局部存储
  • 【2024华为OD-E卷-100分-传递悄悄话】（题目+思路+JavaC++Python解析)
  • 【ShuQiHere】使用 SCP 进行安全文件传输
  • 音视频入门基础：MPEG2-PS专题（2）——使用FFmpeg命令生成ps文件
  • docker compose模式下，volumes中的${HOSTNAME}识别不了
  • (ICLR-2023)ADALORA：自适应预算分配，实现参数高效微调
  • ReconFusion: 3D Reconstruction with Diffusion Priors 论文解读
  • 2025年01月01日Github流行趋势