Создание пакетов ICMP при TTL = 2?

http://packetlife.net/blog/2008/dec/22/disables-mpls-ttl-propagation/

http://www.ciscopress.com/articles/article.asp?p=680824&seqNum=4

Ваши пакеты инкапсулируются в MPLS, когда TTL внешней метки уменьшается до 0, но TTL внутреннего пакета не обновляется, поэтому помеченный пакет с истекшим TTL пересылается, а внутренний IP-пакет (с очевидно допустимым TTL) возвращается в истек срок действия последнего маршрутизатора MPLS.

============================

Когда срок действия помеченного пакета истекает, пакет фактически пересылается до конца «туннеля», в котором он включен, поскольку маршрутизатор, уменьшивший поле TTL до 0, может не иметь действительного маршрута обратно к исходному отправителю. Таким образом, метка MPLS редактируется, чтобы указать истечение срока TTL, и в конечном итоге конечный туннельный маршрутизатор декапсулирует «действительный, но истек срок действия метки» и отправляет его обратно с сообщением об ошибке TTL.

Отказ от ответственности: я прочитал относящиеся к TTL разделы нескольких RFC, но ничего не было определено относительно этой обработки, поэтому я бы сказал, что это поведение может варьироваться от поставщика к поставщику.

Свидетельство из захваченного пакета:

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.

Таким образом, если маршрутизатор тратит на обработку пакета больше секунды, он должен уменьшите TTL более чем на единицу. Однако очень редко маршрутизатор бы тратить больше секунды на обработку пакета, если только он не застрял.

За исключением ошибок реализации маршрутизатора, это единственное, что я могу придумать, чтобы это объяснить.

Хотя это возможно, ошибка на этом элементарном уровне маловероятна; плюс, учитывая (быстрое) время, необходимое для обработки пакетов, я бы предпочел направить сходство проблемы на какой-то цикл или отскок. В тривиальном / обычном случае маршрутизатор уменьшает TTL и направляет пакет на правильный интерфейс на основе своей таблицы маршрутизации.

Есть несколько более сложных случаев, когда TTL может зависеть от реализации маршрутизатора. Из моей головы идет NAT маскировка где пакет может "повторно войти" в маршрутизатор после выполнения трансляции адресов - обычно это тот случай, когда нужно проверить IP-адрес WAN маршрутизатора из внутри (и это работает не на всех роутерах)

Например,

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 отправляется при одном из двух условий: превышен TTL или превышено время повторной сборки фрагмента. Какой код отправлен обратно (второй кусок полезной нагрузки). Если это 1, причина отправки пакета - превышено время сборки. Обычно это значение должно быть от 60 до 120 секунд, а не 0,01 с. Всегда ли один и тот же маршрутизатор отправляет эти пакеты обратно? Можете ли вы отправить полный пакет, который вы получаете, и? Можете ли вы разместить информацию о роутерах в вопросах? Делать? Модель?

Ответ на "Почему ты получаешь time-exceeded пакеты"(ваш исходный вопрос"Как так? По какой-то причине?") легко ответить:

Посмотрите, сколько времени вы захватили, какое значение кода внутри. Если он равен 0, это была проблема TTL на генерирующем маршрутизаторе, если это было 1, это была проблема фрагментации на генерирующем маршрутизаторе.

Вопрос "Как это установить в маршрутизаторе CISCO?"не имеет смысла, установить что? В соответствии с тем, что вы сказали, не было обнаружено необычного поведения.

"Почему у маршрутизатора есть проблемы с TTL или фрагментацией?Я считаю, что здесь хороший вопрос. Если маршрутизатор (при условии, что он всегда один и тот же) находится вне вашего контроля, то мы не можем сказать наверняка. Но мы можем немного порассуждать. Это может быть несоответствие MTU между интерфейсами , я полагаю, это также может быть проблема с буферизацией. Предполагается, что это проблемы с фрагментацией. Если это проблема с TTL, это может быть неправильная конфигурация MPLS LSP или MPLS LSR, который дает конфликтующее чтение ICMP из-за PHP / UHP и т.д. (хотя маловероятно).

Когда вы получаете эти сообщения об истечении времени, возникают ли проблемы с текущими потоками UDP / TCP, пропадают ли какие-либо из них? Сообщение о превышении времени должно содержать часть пакета данных, которая вызвала генерацию пакета ICMP, является ли исходный блок данных jumbo-кадром или большим TCP-пакетом, установлен ли в нем бит DF?

Вы не так много рассказали о контексте, в котором в первую очередь генерируются пакеты ICMP.