TTL = 2のときにICMPパケットを生成しますか？
[〜＃〜] icmp [〜＃〜]time-exceededパケットのペイロードを調べると、時々それが最後の1つルーターであることに気付きました（返されるパケットのttl=2）、またはパケットをドロップしてICMPメッセージを生成する前のパケット（最大5ホップ前、ttl=5）。
どうして？この背後にある理由は何ですか？
Ciscoルーターでこれをどのように設定しますか？
編集：
[〜＃〜] all [〜＃〜]これらのパケットはICMPタイプ11コード0であることに注意してください。つまり、 ：
type = time-exceeded、code = ttl-zero-during-transit
Edit2：このようなICMPパケットの2つの例を次に示します。
###[ IP ]###
version = 4L
ihl = 5L
tos = 0x0
len = 168
id = 9969
flags =
frag = 0L
ttl = 243
proto = icmp
chksum = 0x19ea
src = 193.51.189.25
dst = 134.59.129.241
\options \
###[ ICMP ]###
type = time-exceeded
code = ttl-zero-during-transit
chksum = 0xbf6e
unused = 0
###[ IP in ICMP ]###
version = 4L
ihl = 5L
tos = 0x0
len = 52
id = 57161
flags = DF
frag = 0L
ttl = 2
proto = tcp
chksum = 0xcf32
src = 134.59.129.241
dst = 173.194.20.89
\options \
###[ TCP in ICMP ]###
sport = 43843
dport = http
seq = 3927922380L
ack = 3188073609L
dataofs = 8L
reserved = 0L
flags = A
window = 14165
chksum = 0x51f9
urgptr = 0
options = [('NOP', None), ('NOP', None), ('Timestamp', (5088093, 1579045454))]
###[ Padding ]###
load = '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x9d\xeb\x00\x08\x01\x01\x00\nA\x01'
###[ IP ]###
version = 4L
ihl = 5L
tos = 0x0
len = 168
id = 37758
flags =
frag = 0L
ttl = 246
proto = icmp
chksum = 0xaa73
src = 193.51.189.2
dst = 134.59.129.241
\options \
###[ ICMP ]###
type = time-exceeded
code = ttl-zero-during-transit
chksum = 0x2e1c
unused = 4
###[ IP in ICMP ]###
version = 4L
ihl = 5L
tos = 0x0
len = 60
id = 53079
flags = DF
frag = 0L
ttl = 5
proto = tcp
chksum = 0x6d73
src = 134.59.129.241
dst = 74.125.230.71
\options \
###[ TCP in ICMP ]###
sport = 45799
dport = http
seq = 2382327024L
ack = 0
dataofs = 10L
reserved = 0L
flags = S
window = 14600
chksum = 0x83ed
urgptr = 0
options = [('MSS', 1460), ('SAckOK', ''), ('Timestamp', (5088167, 0)), ('NOP', None), ('WScale', 4)]
###[ Padding ]###
load = '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00X\xf6\x00\x08\x01\x01\x04\x01\x81\xff'
http://packetlife.net/blog/2008/dec/22/disabling-mpls-ttl-propagation/
http://www.ciscopress.com/articles/article.asp?p=680824&seqNum=4
外側のラベルのTTLが0にデクリメントされると、パケットはMPLSでカプセル化されますが、内側のパケットTTLは更新されないため、TTLで期限切れのラベル付きパケットが転送され、内部IPパケット（明らかに有効なTTLを含む）が、最終的なMPLSルーターによって期限切れになったときに返されます。
============================
ラベル付けされたパケットTTLが期限切れになると、パケットは実際には「トンネル」の終わりまで転送されます。これは、TTLフィールドをデクリメントしたルーターが0には、元の送信者に戻る有効なルートがない可能性があります。したがって、MPLSラベルは、TTL有効期限を示すように編集され、最終的に、最終トンネルルーターは「有効だがラベルが期限切れ」のパケットをカプセル化解除して送信します。 TTL失敗メッセージで戻ってきます。
免責事項：いくつかのRFCのTTL関連のセクションを読みましたが、この処理について明確なことは何もなかったため、この動作はベンダーごとに異なる可能性があります。
キャプチャされたパケットからの証拠：
Internet Control Message Protocol
Type: 11 (Time-to-live exceeded)
Code: 0 (Time to live exceeded in transit)
Checksum: 0xf4df [correct]
Internet Protocol, Src: 192.168.1.x (192.168.1.x), Dst: 8.8.8.8 (8.8.8.8)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x80 (DSCP 0x20: Class Selector 4; ECN: 0x00)
Total Length: 92
Identification: 0x6b56 (27478)
Flags: 0x00
Fragment offset: 0
Time to live: 2 <===== payload of packet entering MPLS tunnel
Protocol: ICMP (1)
Header checksum: 0x7abb [correct]
Source: 192.168.1.x (192.168.1.x)
Destination: 8.8.8.8 (8.8.8.8)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0xf78f [correct]
Identifier: 0x0001
Sequence number: 111 (0x006f)
Sequence number (LE): 28416 (0x6f00)
Data (64 bytes)
MPLS Extensions
Version: 2
Reserved: 0x000
Checksum: 0x5581 [correct]
MPLS Stack Entry
Length: 0x0008
Class: 1
C-Type: 1
Label: 1864, Exp: 4, S: 1, TTL: 1
0000 0000 0111 0100 1000 .... = Label: 1864
.... .... .... .... .... 100. = Experimental: 4
.... .... .... .... .... ...1 = Stack bit: Set
Time to live: 1 <========== MPLS TTL
ルーターは、パケットの処理に費やされる1秒ごとに存続時間を1ずつ減らすことになっていますが、1未満だけ減らすことはできません。
したがって、ルーターがパケットの処理に1秒以上費やす場合、ルーターはTTL）を複数デクリメントする必要があります。ただし、ルーターがパケットの処理に、ひどく行き詰まっていない限り、1秒以上かかることは非常にまれです。
ルーター実装のバグを除けば、これを説明できるのはそれだけだと思います。
ここで何が起こっているのか正確には言えませんが、Time Exceededパケットは、TTLを超えている、またはフラグメントの再構築時間を超えている）のいずれかの条件で送信されます。コードは何ですか。送り返されます（ペイロードの2番目のバイト）。1の場合、パケットを送信する理由は再構成時間を超えています。これは通常、0.01秒ではなく60〜120秒に設定する必要があります。同じルーターがこれらのパケットを送り返しますか？戻ってきた完全なパケットを投稿できますか？質問のルーターに関する情報を投稿できますか？作成しますか？モデル？
可能ではありますが、この初歩的なレベルでのバグはありそうにありません。さらに、パケットの処理にかかる（速い）時間を考慮すると、問題の可能性をある種のループまたはバウンスに向けたいと思います。些細な/通常の場合、ルーターはTTLをデクリメントし、ルーティングテーブルに基づいてパケットを適切なインターフェイスに転送します。
TTLはルーターの実装に依存する可能性がある、より複雑なケースがいくつかあります。頭のてっぺんから、NATマスカレードパケットが「再入力」される可能性があります。アドレス変換が実行された後のルーター-これは通常、ルーターをテストしたい場合ですWAN IP from inside（これは機能しません）すべてのルーター）
例えば、
source:
local 10.1.2.3/24
destination:
public: 198.252.206.16/32 (an example..)
アドレス198.252.206.16は、インターネット（ルーターのWAN側））から見た自分のアドレスであり、内部で10.1.2.3にバインドされています。つまり、実際にはと同じホストです。送り主
ルーターはパケットを受信し、WANアドレスはそれ自体のアドレスであり、パケットはWANインターフェイス（実装に依存））に「再入」し、 LANアドレス10.1.2.3。
TTLは、すべてのルーターで機能しているわけではありません）が実装に依存している場合、どのように扱われますか。
「なぜtime-exceededパケットを受信するのか "（「の元の質問」に対する答えはどうですか？この背後にある理由は何ですか？ "）答えるのは簡単です：
キャプチャしたパケットを超えた時間を見てください。内部のコード値は何ですか。 0の場合は、生成ルーターでのTTLの問題であり、1の場合は、生成ルーターでの断片化の問題でした。
質問「Ciscoルーターでこれをどのように設定しますか？」は意味がありません。何を設定しますか？あなたの言ったことによると、異常な振る舞いは表示されていません。
"ルーターにTTLまたは断片化の問題があるのはなぜですか？"はここで良い質問だと思います。ルーター（常に同じものであると仮定）が確かに言うことはできませんが、少し推測できます。これは、インターフェイス間のMTUの不一致である可能性があり、バッファリングの問題である可能性もあります。これは、断片化の問題を想定しています。a=の場合TTLの問題、MPLSLSPまたはMPLSLSRの設定ミスが原因で、PHP/UHPなどが原因でICMP読み取り値が競合している可能性があります（可能性は低いですが）。
これらの時間超過メッセージを受信しているとき、現在のUDP/TCPフローに問題がありますか？それらのいずれかがドロップしますか？超過時間メッセージには、ICMPパケットの生成を引き起こしたデータパケットの一部が含まれている必要があります。元のデータユニットはジャンボフレームまたは大きなTCPパケット、DFビットセット？
そもそもICMPパケットが生成されている状況に関しては、先に進むことはあまりありません。