Windows ping df bit

Use Ping to determine MTU Packet size

Use ping to determine MTU packet size. The Maximum Transmission Unit that a router allows without packet fragmentation. The Maximum Transmission Unit describes the maximum packet size of a protocol in the network layer of the OSI model, which can be transmitted in networks without fragmenting the frames in the data link layer. This packet size fits into the payload of the data link layer protocol.

How to check optimal MTU size for Routers

To check the MTU of a path, you have to pass the parameter -f to ping to set the “don’t fragment bit (DF-Bit-Set)” for the ICMP test packet in the IPv4 header, only then you will receive a message if the MTU is exceeded.

The ICMP Packet and MTU size

Картинка с сайта: think.unblog.ch

Run ICMP Ping in the Windows command prompt to determine the MTU size of a desired path.

The parameter -f specifies that the packages are not fragmented.
The size of the send buffer is specified with -l.

C:\> ping -4 -f 1.1.1.1 -l 1473

Pinging 1.1.1.1 with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 1.1.1.1:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

As the above results show, the packets should be fragmented. If the -f parameter were omitted, the ping would respond with fragmentation, which we don’t want.

If you don’t get an reply but see “Packet needs to be fragmented but DF set.” you’ve not found the maximum ping size.

  Hint. It is best to gradually reduce the ping with the MTU value, in steps of 10+/-10 (e.g. 1472, 1462, 1440, 1400) until a packet size has been reached that is no longer fragmented and a response is received.

C:\> ping -4 -f 1.1.1.1 -l 1472

Pinging 1.1.1.1 with 1472 bytes of data:
Reply from 1.1.1.1: bytes=1472 time=7ms TTL=56
Reply from 1.1.1.1: bytes=1472 time=7ms TTL=56
Reply from 1.1.1.1: bytes=1472 time=7ms TTL=56
Reply from 1.1.1.1: bytes=1472 time=7ms TTL=56

Ping statistics for 1.1.1.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 7ms, Maximum = 7ms, Average = 7ms

The above results indicate that the packets will not be fragmented.

To get the right MTU size, take 1472 and add 28 to it. In the example above, 1472 is the correct value, and the size is 1500 for the network in which you work.

  Calculation: 8 bytes for the ICMP-header + 20 bytes for the IP-header + 1472 bytes for the ICMP-payload:  8 + 20 + 1472 = 1500

The Control Message Protocol Protocol (ICMP) in layer 3 of the network layer, which is used by ping to send a message via the ICMP payload, which is encapsulated with the IP header. The MTU cannot exceed the size of the ICMP packet of 1500 bytes.

ICMP packet at Network layer

ICMP packet at Data Link layer

Note. default size of ICMP payload is 32 bytes and the maximum is 1472, if the size of the payload packet is greater than 1472 then packet gets fragmented into small packets.

ICMP Message Packet decoding in Wireshark

Картинка с сайта: think.unblog.ch

The ICMP packet sent by the source machine is an echo request. The figure shows that ICMP query code 8 responds to the ping request.

Using Linux Ping set don’t fragment bit (DF-Bit-Set) in the Linux Shell and macOS Terminal

Use Linux ping in a terminal will using DF-bit-set do not fragment message.

$ ping -M do -s 1473 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1473(1501) bytes of data.
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
^C
--- 1.1.1.1 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 31ms

Typical MTU sizes

The ping command has
different implementation based on the operation systems and the networking
vendors’ and software’s devices. Most of the time, when the MTU must be tested,
the ping command is used with DF (Don’t Fragment) bit set. At the Ethernet
header must be added the IP header (20 bytes without Options) and ICMP header
(8 bytes); in some cases these values must be subtracted from the link MTU, in
some cases even the Ethernet frame header (12 bytes – DMAC, SMAC, Type) and
sometimes even the Ethernet CRC. 

Every operating system has
its own way to implement the ping command. After all, each networking equipment
has an operating system and most of the time the operating system is based on
Linux/Unix, you will find the fine print hiding somewhere in the code or on
vendors pages, if you search for it.

802.3 Ethernet frame – 1538 bytes

The Ethernet frame,
including the ICMP header, has 1538 bytes if we include Preamble, SFD, CRC and
IFG.

When the ping command with
DF (Don’t Fragment bit set) is issue, for 1500 bytes MTU, the following values
are the maximum:

1.
 Windows – 1472 bytes
(the IP+ICMP headers are not included in the MTU value); the command is looking
like below:

ping
[IP] -l 1472 –f

2.  Linux – 1472 bytes
(the IP+ICMP headers are not included in the MTU value); the command is looking
like below:

ping
-s 1472 -M do [IP]

3.
Cisco IOS – 1500 bytes (IP+ICMP headers are included in the
MTU value); the command is looking like below:

ping
[IP] size 1500 df-bit

4.
 Cisco IOS XR – 1500 bytes (IP+ICMP
headers are included in the MTU value); the command is looking like below:

ping
[IP] size 1500 donnotfrag

5.
Cisco NXOS – 1472 bytes (IP+ICMP headers are NOT included in the
MTU value); the command is looking like below:

ping
[IP] packet-size 1472 df-bit

6.
Juniper Junos – 1472 bytes (the IP+ICMP headers are not included
in the MTU value); the command is looking like below:

run
ping [IP] size 1472 do-not-fragment

7.
Huawei VRP – 1472 bytes (the IP+ICMP headers are not included
in the MTU value); the command is looking like below:

ping
 -s 1472 -f [IP]


I have added below some of
the other Ethernet encapsulation, yellow part representing the IP+ICMP header
which you must not forget to subtract from the size of the packet from ping
command. Cisco is an exception as it adds automatically the IP+ICMP header to
the packet size (and even VLAN TAG in 802.1Q). Also Huawei is another
exception, the tagged frames, QinQ frames and L2VPN frames do not take into
consideration the additional payload of the frames (IP+ICMP must be subtracted),
but for L3VPN the additional payload headers and IP+ICMP must be subtracted
also. If you want to read some more information about MTU you can check the Almighty-MTU .

802.1Tagged Ethernet frame – 1542 bytes

802.1 AD Double Tagged Ethernet frame – 1546 bytes

MPLS 802.1 AD Double Tagged Ethernet frame – 1558 bytes

I feel like this MTU size
and ping with different implementation for different vendors and products and
software really require a standard else we will face the same mess we have
right now. What do you think?

By Mihaela Paraschivu

Картинка с сайта: habr.com

«Для чего в команде ping используются опции Loose, Strict, Record, Timestamp и Verbose?» — такой вопрос мне недавно встретился в вендорном экзамене. Они позволяют влиять на маршрутизацию ICMP пакетов и собирать информацию о транзитных L3-устройствах. Но занимаясь сетевыми технологиями уже достаточно давно, я почти никогда их не использовал.

Мне стало не совсем понятно, почему такой вопрос вообще присутствует в тесте. Вернувшись домой, решил узнать, вдруг я действительно постоянно упускаю из виду что-то важное?

Утилита ping нам всем хорошо знакома. Помимо стандартного «ping 8.8.8.8», можно использовать различные опции, среди которых присутствуют интересующие нас. Их наименование и описание у вендоров примерно одинаковое.

Опции Loose, Strict, Record, Timestamp, Verbose включены в утилиту ping на многих сетевых устройствах. Есть поддержка в Windows.

Record (Record Route)

Пакет ICMP с опцией Record при прохождении через L3-устройства записывает IP-адреса исходящих интерфейсов. Делается это как в сторону пункта назначения, так и обратно. Это удобно, например, при диагностировании проблем, связанных с асинхронной маршрутизацией. Получается вроде traceroute, только лучше.

Но рано радоваться: максимальное количество записей равно девяти. Причём в них входят данные об IP-адресах устройств в обе стороны. Обусловлено данное ограничением тем, что информация об IP-адресах сохраняется не в теле пакета, а в заголовке. Поле с опциями не может быть слишком большим. Оно ограничено 40 байтами. Нам, в конце концов, по сети нужно гонять полезные данные, а не заголовки. В этот объём помещается всего девять записей (4 байт на каждый IPv4 адрес). Оставшиеся (40-4*9)=4 байта уходят на отметку о типе опции, длине и пр. атрибутах. Напомню, максимальный размер всего заголовка IPv4 – 60 байт.

Картинка с сайта: habr.com

Запускаем с ПК под управлением ОС Windows ping с опцией Record Route (-r) до адреса 192.168.36.2:

Обмен пакетами с 192.168.36.2 по с 32 байтами данных:
Ответ от 192.168.36.2: число байт=32 время=12мс TTL=252
    Маршрут: 192.168.31.2 ->
           192.168.32.2 ->
           192.168.34.2 ->
           192.168.35.2 ->
           192.168.36.2 ->
           192.168.35.1 ->
           192.168.33.1 ->
           192.168.31.1 ->
           192.168.20.1

Статистика Ping для 192.168.36.2:
    Пакетов: отправлено = 1, получено = 1, потеряно = 0
    (0% потерь)
Приблизительное время приема-передачи в мс:
    Минимальное = 12мсек, Максимальное = 12 мсек, Среднее = 12 мсек

Пакeт ICMP Echo Request c выставленной опцией Record Route (Type = 7) в заголовке IP:

Картинка с сайта: habr.com

ICMP Echo Request доходит до получателя. По пути в него добавляются адреса транзитных устройств. Получатель берёт заполненные поля опции IP заголовка, копирует их в ICMP Echo Reply и отправляет назад. Пока ICMP Echo reply доберётся до инициатора пинга, он обрастёт записями обратного маршрута.

В ответном пакете ICMP Echo Reply, который получит ПК, опция Record Route будет уже заполнена:

Картинка с сайта: habr.com

Можно заметить, что в нашей сети имеет место ассиметричная маршрутизация.

R1#ping   
Protocol [ip]: 
Target IP address: 192.168.36.2
Repeat count [5]: 1
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands [n]: y
Source address or interface:
Type of service [0]: 
Set DF bit in IP header? [no]: 
Validate reply data? [no]: 
Data pattern [0xABCD]: 
Loose, Strict, Record, Timestamp, Verbose[none]: R
Number of hops [ 9 ]: 
Loose, Strict, Record, Timestamp, Verbose[RV]: 
Sweep range of sizes [n]: 
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.36.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.20.1 
Packet has IP options:  Total option bytes= 39, padded length=40
 Record route: <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)

Reply to request 0 (3 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:
   (192.168.31.2)
   (192.168.32.2)
   (192.168.34.2)
   (192.168.35.2)
   (192.168.36.2)
   (192.168.35.1)
   (192.168.33.1)
   (192.168.31.1)
   (192.168.31.2) <*>
 End of list

Success rate is 100 percent (1/1), round-trip min/avg/max = 3/3/3 ms

Timestamp

Когда пакет ICMP с опцией Timestamp проходит через L3-устройство, оно записывает в него метку с указанием текущего времени. Схема работы аналогична опции Record, только вместо адреса ставится время. Как и в предыдущем случае пакет может содержать только девять записей о времени (для ОС Windows – четыре, так как кроме временной метки, добавляется IP-адрес устройства).

Картинка с сайта: habr.com

Время в пакете указано в формате UNIX time. Анализ данных имеет хоть какой-то смысл, если все устройства синхронизированы по времени (в нашем примере этого нет).

C:\Users\user>ping -n 1 -s 4 192.168.36.2

Обмен пакетами с 192.168.36.2 по с 32 байтами данных:
Ответ от 192.168.36.2: число байт=32 время=4мс TTL=252
    Отметка времени: 192.168.31.2 : 43990397 ->
               192.168.32.2 : 43990389 ->
               192.168.34.2 : 2187294073 ->
               192.168.35.2 : 2190888543

Статистика Ping для 192.168.36.2:
    Пакетов: отправлено = 1, получено = 1, потеряно = 0
    (0% потерь)
Приблизительное время приема-передачи в мс:
    Минимальное = 4мсек, Максимальное = 4 мсек, Среднее = 4 мсек

Strict (Strict Source Route)

При использовании данной опции задаётся список IP-адресов L3-устройств, через которые ICMP пакет обязательно должен пройти. Причём именно в той последовательности, которую мы указали. Записей, по традиции, максимум девять.

Работает опция просто: на каждом хопе IP-адрес назначения меняется на тот адрес, который мы указали при запуске утилиты ping.

Картинка с сайта: habr.com

Все адреса хранятся в заголовке IP нашего ICMP пакета. Поэтому каждое транзитное устройство может их подсмотреть. Такая схема позволяет обходить текущие правила маршрутизации на каждом устройстве, так как фактически имеем пересылку пакета на соседнее устройство.

В нашей схеме R2 имеет маршрут в сеть 192.168.36.0/24 через R3. Но так как у нас жёстко прописаны устройства в опциях ICMP пакета, R2 передаст его напрямую на R4.

Запускаем утилиту ping с опцией -k (Strict Source Route) в ОС Windows и прописываем адреса устройств.

Обмен пакетами с 192.168.36.2 по с 32 байтами данных:
Ответ от 192.168.36.2: число байт=32 время=5мс TTL=252
    Маршрут: 192.168.35.1 ->
           192.168.33.1 ->
           192.168.31.1 ->
           192.168.20.1

Статистика Ping для 192.168.36.2:
    Пакетов: отправлено = 1, получено = 1, потеряно = 0
    (0% потерь)
Приблизительное время приема-передачи в мс:
    Минимальное = 5мсек, Максимальное = 5 мсек, Среднее = 5 мсек

Пакeт ICMP Echo Request c выставленной опцией Strict Source Route (Type = 137) в заголовке IP на нашем ПК выглядит следующим образом:

Картинка с сайта: habr.com

ПК подставил 192.168.20.1 в качестве адреса получателя. Остальные адреса транзитных устройств благополучно запаковал в поля опции IP (записи Source Route). Адрес конечного устройства добавил в запись Destination.

Этот же пакет, после того, как он минует R1:

Картинка с сайта: habr.com

IP-адрес отправителя остался без изменений. IP-адрес получателя поменялся на новый – 192.168.31.1. Это значение взято из поля Source Route, когда пакет ICMP только поступил на R1.

Важно отметить, что R1 занёс в поле опций новую запись — Recorded Route. Туда подставлен IP-адрес интерфейса R1. Данное поле понадобится, чтобы ответный пакет (ICMP Echo reply) вернулся по тому же маршруту, что и ICMP Echo request. Точно также будут поступать и остальные устройства. Поэтому, когда пакет ICMP попадёт на R5, в опции Strict Source Route будет содержаться список IP-адресов интересов, через которые должен пройти ответный пакет.

ICMP Echo reply, полученный ПК:

Картинка с сайта: habr.com

Поле Recorded Route переписывается по мере прохождения пакета ICMP Echo reply, так как там всегда указан адрес исходящего интерфейса для текущего пакета. Поэтому R1, когда получит ICMP Echo reply, заменит 192.168.31.2 на 192.168.20.1.

Если в команде ping мы опустим один из адресов, например, последний (192.168.35.1 – R5), R4 должен будет отправить пакет сразу на устройство с адресом 192.168.36.2. Но так как эта сеть не является для него локальной, R4 отрапортует о том, что заданный узел недостижим. Маршрутизировать пакет по обычным правилам он не будет.

Для обработки опции Record на сетевом оборудовании должен быть включен режим source routing. Например, на оборудовании Cisco он включён по умолчанию.

Loose (Loose Source Route)

Данная опция по сути очень похожа на опцию Strict. Но, в отличии от Strict, в опции Loose задаётся не жёсткий маршрут движения ICMP пакета, а лишь выборочные устройства. Т.е. пакет может маршрутизироваться и другими устройствами. Максимальное количество адресов – девять.

Схема работы аналогична предыдущему случаю. Разница в том, что пакет с опцией Loose может маршрутизироваться транзитными устройствами по обычным правилам.

Картинка с сайта: habr.com

Запускаем утилиту ping с опцией -j (Loose Source Route) в ОС Windows и прописываем адреса устройств.

Обмен пакетами с 192.168.36.2 по с 32 байтами данных:
Ответ от 192.168.36.2: число байт=32 время=4мс TTL=250
    Маршрут: 192.168.32.1

Статистика Ping для 192.168.36.2:
    Пакетов: отправлено = 1, получено = 1, потеряно = 0
    (0% потерь)
Приблизительное время приема-передачи в мс:
    Минимальное = 4мсек, Максимальное = 4 мсек, Среднее = 4 мсек

Пакeт ICMP Echo Request c выставленной опцией Loose Source Route (Type = 131) в заголовке IP на нашем ПК выглядит так:

Картинка с сайта: habr.com

ПК подставил адрес R3 (192.168.32.1) в качестве получателя. При этом адрес конечного устройства R5 (192.168.36.2) указал в опции IP (запись Destination). Далее пакет маршрутизируется в сети по обычным правилам, пока не попадёт на R3. R3 подставит в качестве адреса назначения адрес R5 и в опциях пропишет свой адрес, через который должен будет вернуться ответный пакет (запись Recorded Route). После чего отправит его в сеть.

Ответный пакет ICMP Echo reply особого интереса не представляет, так как аналогичен ранее рассмотренным. В опциях будет указан адрес исходящего интерфейса R3 (запись Recorded Route), через который прошел пакет.

Verbose

Данная опция активируется автоматически при выборе любой из ранее описанных. Предоставляет более детальный вывод информации на экран. На сам пакет ICMP она никак не влияет. В Windows в команде ping такой опции нет.

Чтобы мы могли воспользоваться этими опциями, промежуточное оборудование должно их поддерживать. С этим проблем не будет. К новшествам мира ИТ относить весь этот «rocket science» не приходится. Напрашивается вывод: опции Loose, Strict, Record, Timestamp могут быть полезны, даже с учётом ограничения в «девять». Если бы не следующие нюансы, связанные с безопасностью.

Первое. Опции Record и Timestamp могут благополучно использоваться для проведения разведки в сети. С их помощью можно исследовать топологию сети, получить отпечатки, по которым определить ОС и тип устройства, через которые проходил пакет с данными опциями.

Второе. Опции Loose и Strict позволяют управлять движением пакета, игнорируя стандартные правила маршрутизации. Это предоставляет широкие возможности для попыток проникновения в различные сегменты сети, куда в случае обычной маршрутизации доступа не должно быть. Также возможно проведение разведки для анализа топологии сети. Проведение атак по утилизированию полосы пропускания на определённых сегментах сети. Вариантов много.

Третье. Часть сетевого оборудования обрабатывает пакеты с установленными опциями программным образом на уровне control-plane (без использования различных схем оптимизации маршрутизации трафика), что безусловно нагружает ЦПУ. А значит есть возможность осуществить DoS атаку на такое устройство.

Многие вендоры (есть даже отдельное RFC 7126) рекомендуют пакеты с указанными опциями никак не обрабатывать. Варианты предлагают разные. Вплоть до отбрасывания таких пакетов. Правда у некоторых из производителей бывают диссонансы: с одной стороны рекомендуем отбрасывать такие пакеты, с другой — «Record is a very useful option».

Быстрая попытка проверить соответствие этим рекомендациям у пары интернет-провайдеров показали, что часть опций всё-таки работает. Но source routing отключён везде.

Получается интересный вывод. Опции Loose, Strict, Timestamp, Record могут быть полезны при диагностике проблем в сети. Но вопрос безопасности нивелирует это.

В итоге у меня всё-таки осталось чувство непонимания. Почему озвученный в начале вопрос присутствовал в тесте? Относительно полезна опция Record и то при небольшой глубине сети. Остальные опции под вопросом.

Напоследок небольшой опрос. Всем хорошего дня!

Пользуетесь ли Вы опциями Loose, Strict, Timestamp, Record?

Проголосовали 446 пользователей. Воздержались 76 пользователей.