Пинг 10000 пакетов

• Стандартная установка 2.1.4.

  Из локальной сети не выходят пинги в интернет больше чем 1472 байта!

  т.е.

  ping 8.8.8.8 -t -l 10000

  не проходит!

  Пытался искать по форуму, но поиск часто выбрасывает Error 403

  проблема не в провайдере, т.к. через другой роутер да и напрямую получается даже

  ping 8.8.8.8 -t -l 65000

• Пытался искать по форуму, но поиск часто выбрасывает Error 403

  поишите в гугле

  добавьте к поиску MTU

  ping + MTU

• Я пробовал выставлять MTU 1100 и 1300 и 1500 на LAN и на WAN интерфейсе. Всё равно не уходят пинги больше чем 1472 байт

• Тип подключения к Интернету ? Туннель при этом исп-ся (pppoe, pptp, l2tp) ?

  Всё просто :

  Верните стандартное значение MTU на pfsense. Далее, сделайте tracert
  до 8.8.8.8 , увидите через какие узлы идут пакеты. Затем – ping -l 1472 -f -t
  до ближайших 2-3-х узлов и увидите макс. размер MTU по пути к ним.

  Я уверен , что это ограничение провайдера\типа вашего подключения.

• Вернул стандартное значение MTU на pfsense.

  Подключение у меня  обычное со статическим ип адресом.

  Попробовал сделать так. В офисе сеть 192.168.2.0/24

  К ней подключил pfSense 2.1.4

  На ван порт пришел адрес по DHCP 192.168.2.34

  На лан порту использую адреса 192.168.15.0/24

  Делаю пинг до внутреннего хоста 192.168.2.44 размером 65000 из внутренней сети – норм пингуется.

  Делаю пинг до этого же хоста но машиной подключенной к pfSense с адресом 192.168.15.30 – максимальный размер 8150 байт!

  Что делать? =( никаких туннелей нет.

• насколько мне память не изменяет, у тебя такой большой пакет никогда не пролезет. его маршрутизатор не разделит на мелкие.

  у меня даже через обычную железяку большие пакеты отбрасывает. ибо нех

  вот если бы на оборудовании провайдера и по всему пути работал JF тогда да =)))

  а так фигушки.

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

  тут уже физика сети

 ping -n 5 -l 1500 www.google.com 

 Pinging www.google.com [74.125.224.82] with 1500 bytes of data:
Reply from 74.125.224.82: bytes=1500 time=68ms TTL=52
Reply from 74.125.224.82: bytes=1500 time=68ms TTL=52
Reply from 74.125.224.82: bytes=1500 time=65ms TTL=52
Reply from 74.125.224.82: bytes=1500 time=66ms TTL=52
Reply from 74.125.224.82: bytes=1500 time=70ms TTL=52
Ping statistics for 74.125.224.82: Packets: Sent = 5, Received = 5, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds: Minimum = 65ms, Maximum = 70ms, Average = 67ms 

 Pinging J3RTY22 [192.168.1.22] with 32 bytes of data:
Reply from 192.168.1.22: bytes=32 time<1ms TTL=64
Reply from 192.168.1.22: bytes=32 time<1ms TTL=64
Reply from 192.168.1.22: bytes=32 time=1ms TTL=64
Reply from 192.168.1.22: bytes=32 time<1ms TTL=64
Ping statistics for 192.168.1.22: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 1ms, Average = 0ms 

 Pinging SERVER [fe80::fd1a:3327:2937:7df3%10] with 32 bytes of data:
Reply from fe80::fd1a:3327:2937:7df3%10: time=1ms
Reply from fe80::fd1a:3327:2937:7df3%10: time<1ms
Reply from fe80::fd1a:3327:2937:7df3%10: time<1ms
Reply from fe80::fd1a:3327:2937:7df3%10: time<1ms
Reply from fe80::fd1a:3327:2937:7df3%10: time<1ms
Reply from fe80::fd1a:3327:2937:7df3%10: time<1ms
Reply from fe80::fd1a:3327:2937:7df3%10: time<1ms
Ping statistics for fe80::fd1a:3327:2937:7df3%10: Packets: Sent = 7, Received = 7, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 1ms, Average = 0ms
Control-C
^C 

Learn how you can use the ping command to determine Maximum Transmission Unit (MTU) size

In computer networks, a path is a route between any two points or node–it connects a source node to a destination node.

A network path can contain links that are made possible by routers and other network devices. For instance, depending on your location, the path between your computer and the server hosting the Comparitech website
can contain several links, and network devices such as routers that connect each link to the next.

If a link or links along that particular path fails, it can dynamically switch to a different path that includes a different set of links and routers. Each network device, link, or path is constrained by the size in bytes of a single IP packet that it can convey. This constraint is called the Maximum Transmission Unit (MTU)
.

MTU in a nutshell

MTU is a measurement representing the maximum data packet that a network path, device, or interface will accept. Think of it as being like a height limit for vehicles passing through a particular freeway or tunnel. Vehicles that exceed the height limit cannot fit through, just as packets that exceed the MTU of a network cannot pass through that network. IPv4 and IPv6
require every link to support a specified MTU. These are called the IPv4 and IPv6 minimum link MTU. M TU parameters usually appear in association with a network device interface such as NIC and serial port. Links such as point-to-point networks usually decide MTU at connect time; while network protocols such as Ethernet have a fixed MTU size.

MTU Ethernet зафиксирован на уровне 1500 байт. Это означает, что самый большой IP-пакет или полезная нагрузка, которые может содержать кадр Ethernet, составляют 1500 байт. Сетевые коммуникационные протоколы обычно добавляют служебные данные (последовательность проверки заголовка и кадра) к полезной нагрузке, подлежащей транспортировке. Думайте о заголовке как о транспортировочной этикетке, прикрепленной к пакету, а о полезной нагрузке — как о фактическом содержимом пакета. Заголовок содержит информацию об адресах отправителя и получателя пакета. Структура кадра Ethernet определена в стандарте IEEE 802.3. Таблица 1.0 ниже представляет собой графическое представление структуры кадра Ethernet, включая описание каждого поля в кадре:

• Преамбула — информирует принимающую систему о начале кадра и разрешает синхронизацию.
• SFD (Разделитель начального кадра) — означает, что поле MAC-адреса получателя начинается со следующего байта.
• MAC-адрес назначения – идентифицирует принимающую систему.
• MAC-адрес источника – идентифицирует отправляющую систему.
• Type – определяет тип протокола внутри фрейма, например, IPv4 или IPv6.
• Data and Pad – содержит данные полезной нагрузки. Данные заполнения добавляются, чтобы соответствовать требованиям минимальной длины для этого поля (46 байт).
• FCS (последовательность проверки кадров) — содержит 32-битную проверку циклическим избыточным кодом (CRC), которая позволяет обнаруживать поврежденные данные.

Таким образом, MTU в основном определяет, насколько большой может быть область полезной нагрузки, включая TCP/IP
заголовки. Это значение настраивается, что означает, что вы можете изменить его, если хотите. Но обычно он возвращается к размеру по умолчанию, если вы не вмешиваетесь в него.

Итак, спросите вы, что лучше, большая полезная нагрузка или меньшая полезная нагрузка? Вообще говоря, большие пакеты могут быть намного эффективнее, чем использование меньших пакетов. Вы знаете, что с большими пакетами вы в основном передаете больше данных, но вы несете те же накладные расходы — те же заголовки Ethernet и последовательность FCS, что и с меньшим пакетом.

Однако вам придется столкнуться с одной серьезной проблемой: пакеты данных, превышающие MTU, не будут пропущены, и вам потребуется внести некоторые коррективы, чтобы это заработало. Чтобы обойти эту проблему, IPv4 представил механизм, который позволяет разбивать пакеты на более мелкие фрагменты, чтобы они могли пройти. Этот механизм называется фрагментацией.

Проблема с фрагментацией

Какой бы новой идея фрагментации ни звучала, она не лишена проблем. Фрагментация добавляет некоторую степень небезопасности, задержек и неэффективности сетевых коммуникаций. На момент написания фрагментация IP считается неустойчивой
и часто содержат уязвимости в системе безопасности, которые можно использовать для использования фрагментации. Злоумышленники могут использовать такие атаки, как атаки с перекрытием фрагментов, атаки с исчерпанием ресурсов, атаки с каплями слезы, ping of death и другие атаки, связанные с отказом в обслуживании
, чтобы использовать эти уязвимости.

Все фрагменты пакета должны быть доставлены, чтобы пакет считался полученным. Фрагментированные пакеты собираются повторно, как только они достигают места назначения. Если хост-получатель получает фрагментированный пакет, он должен собрать пакет заново, и все это увеличивает задержку. Когда количество пакетов, которые необходимо фрагментировать, или число фрагментов велико, это может привести к ненужным издержкам. И если сеть отбрасывает какой-либо фрагмент, весь пакет теряется. Фрагментация IP может вызвать чрезмерное количество повторных передач, когда фрагменты сталкиваются с потерей пакетов, и такие протоколы, как TCP, должны повторно передавать все фрагменты, чтобы восстановиться после потери одного фрагмента.

В некоторых случаях пакеты не могут быть фрагментированы, и поэтому они не будут доставлены, если превысят MTU любого маршрутизатора или устройства на сетевом пути. Например, маршрутизаторы, реализующие протокол IPv6, будут отбрасывать все пакеты IPv6, превышающие MTU, поскольку они не могут быть фрагментированы в IPv6. Во-вторых, в сетях IPv4, когда в IP-заголовке пакета установлен флаг «Не фрагментировать», прикрепленный пакет не может быть фрагментирован. Если пакет превышает MTU, маршрутизатор вместо того, чтобы фрагментировать его, отбрасывает пакет и немедленно отправляет обратно ICMP-сообщение «слишком большой пакет» .
(обновление статуса) на исходный узел.

Чтобы решить эти проблемы, вы должны определить оптимальный размер IP-пакетов для отправки по сети. Эти пакеты должны быть скорректированы вручную или автоматически, чтобы не превысить MTU. Есть два возможных способа добиться этого:

• Ручной подход заключается в том, что отправляющее устройство отправляет оптимальный размер пакета или MTU, требуемый путем или принимающим устройством.
• Автоматический подход — это метод, называемый Path MTU Discovery, который помогает автоматически определять MTU пути между двумя хостами, чтобы можно было избежать фрагментации IP.

Обнаружение Path MTU и его ограничения

Обнаружение MTU пути (PMTUD), как следует из названия, представляет собой процесс обнаружения MTU на сетевом пути между двумя узлами, обычно с целью предотвращения фрагментации IP. При наличии PMTUD компьютер, пытающийся отправить пакеты на маршрутизатор, должен будет определить требования маршрутизатора к MTU и соответствующим образом скорректировать размер пакета, чтобы избежать фрагментации. P MTUD работает немного по-разному для сетей на основе IPv4 и IPv6.

Обнаружение MTU пути IPv4 работает путем установки бита флага «Не фрагментировать (DF)» в заголовках IP исходящих пакетов. Затем любое устройство на пути, чей MTU меньше пакета, отбросит его и отправит обратно ICMP «Пакет должен быть фрагментирован » .
сообщение. Это позволяет хосту-источнику соответствующим образом уменьшить значение Path MTU. Процесс повторяется до тех пор, пока MTU не станет достаточно малым, чтобы пройти весь путь без фрагментации.

IPv6 не допускает фрагментации, поэтому опции «Не фрагментировать» даже не существует. Поэтому маршрутизаторы, реализующие IPv6, не будут фрагментировать пакеты IPv6, поэтому, если пакеты превышают MTU, маршрутизаторы отбрасывают пакеты и отправляют обратно соответствующие сообщения ICMP без проверки флага «Не фрагментировать». Это позволяет хосту-источнику соответствующим образом уменьшить значение Path MTU. Процесс повторяется до тех пор, пока MTU не станет достаточно малым, чтобы пройти весь путь без фрагментации

.

В идеальных ситуациях PMTUD работает, как описано выше. Однако в некоторых случаях PMTUD дает сбой. По данным Целевой группы инженеров Интернета  (IETF), сбой может быть связан с такими факторами, как:

• Заблокированные сообщения ICMP: PMTUD зависит от способности сети доставлять сообщения ICMP на исходный узел. Однако многие устройства сетевой безопасности блокируют сообщения ICMP из соображений безопасности. Если сеть не может доставить сообщения ICMP на исходный узел, PMTUD не работает.
• Вредоносные атаки: PMTUD подвержен атакам, поскольку сообщения ICMP легко подделываются и не аутентифицируются получателем. Такие атаки могут привести к тому, что PMTUD выдаст излишне консервативные оценки PMTU.

Обычный обходной путь, реализованный в некоторых маршрутизаторах, заключается в том, чтобы сетевые устройства согласовывали и сообщали Максимальный размер сегмента (самая большая полезная нагрузка данных, которую устройство принимает из сетевого соединения) пакетов, которые они могут получить. Это известно как фиксация максимального размера сегмента (MSS).

Найдите MTU пути с помощью команды Ping

• -f: устанавливает флаг «Не фрагментировать» в заголовке пакета
• -l: Устанавливает размер пакета

На снимке экрана на рис. 1.0 выше видно, что мы отправляем ICMP-пакет размером 2000 байт на шлюз с IP-адресом 192.168.43.1. Размер пакета 2000 байт обычно больше, чем у большинства MTU в типичной сети Ethernet. Как видите, пакет успешно прошел путь и достиг пункта назначения, потому что он фрагментируется маршрутизаторами на пути.

Этап 2:
Теперь установите флаг «Не фрагментировать», используя приведенную ниже команду, и посмотрим, что произойдет: ping 192.168.43.1 -f -l 2000.

Как видно из снимка экрана на рисунке 2.0 выше, целевое устройство возвращает сообщение, в котором говорится: «Пакет должен быть фрагментирован, но установлен DF». Поскольку мы решили не фрагментировать пакеты, у всех маршрутизаторов на пути не будет иного выбора, кроме как отбросить пакет.

.

Этап 3:
Повторите описанный выше процесс и продолжайте настраивать размер пакета, пока не найдете MTU пути. На снимке экрана на рис. 3.0 выше мы начали с 1700 байт и двигались вниз с шагом в 100 байт, пока не получили успешный ответ на пинг. Это означает, что MTU пути между нашим источником и местом назначения составляет где-то между 1400 и 1500 байт.

.

Шаг 4:
Следующим шагом будет перемещение размера вверх и вниз с шагом 10 и 1, как показано на рисунке 4.0 выше, пока мы не определим правильный размер MTU. В основном мы ищем самый большой размер пакета, который не вернет ошибку. Это, наконец, привело нас к размеру пакета 1472 байта. Как видите, размер пакета 1473 был слишком большим, но 1472 байта оказались идеальным размером пакета. Размер пакета 1472 представляет собой размер полезной нагрузки или максимальный размер сегмента (MSS), как показано на рисунке 5.0 ниже.

В заключение отметим, что фактический размер MTU включает в себя размер заголовков TCP и IP, который может составлять от 20 до 60 байтов, в зависимости от среды передачи. Для нашей среды передачи заголовки TCP и IP составляют в общей сложности 28 байтов (8 байтов + 20 байтов). Следовательно, 1472 байта + 28 байтов дают нам фактический размер MTU, который составляет 1500 байт
. Обычно это размер MTU, разрешенный большинством сетей Ethernet на сетевом уровне.

Что такое MTU в пинге?

MTU означает Максимальная единица передачи
. Это максимальная длина пакета, которую может обработать коммутатор или маршрутизатор. Отправитель пакета проверяет MTU получателя и затем разбивает свои пакеты, если они длиннее этого максимума, поэтому ваша передача проходит в два раза больше пакетов, чем необходимо. Для обработки большего количества пакетов требуется больше времени, и их необходимо повторно собрать на принимающей стороне, поэтому несоответствие MTU на маршруте приведет к замедлению времени передачи.

Как рассчитывается MTU?

Как ни странно, разные системы имеют разные определения того, что входит в расчет MTU. В частной сети стандартный MTU составляет 1500 бит. Это содержимое фрейма, которое не включает заголовок фрейма или контрольную сумму фрейма (FCS). Ethernet MTU включает в себя заголовок TCP/IP в заголовке и конце этих кадров. Ping упаковывает содержимое пакета до заданной длины, а затем добавляет заголовки TCP/IP. Эта длина полезной нагрузки данных на самом деле известна как размер сегмента, поэтому вы можете определить максимальный размер сегмента (MSS) с помощью Ping. Поскольку стандартная длина заголовка IP составляет 20, а заголовок TCP — 8 бит, вы можете ожидать, что максимально допустимая длина, которую вы обнаружите с помощью Ping, будет на 28 бит короче, чем фактический размер пакета. Итак, если вы выведете с помощью Ping MSS 1482, у вас будет MTU 1500.

Как пропинговать MTU 9000?

Чтобы проверить, будет ли маршрут принимать пакет длиной 9000 бит, вам нужно выполнить команду Ping, которая запрещает фрагментацию и упаковывает полезную нагрузку данных. Длина этой полезной нагрузки должна составлять 8972 бита. Когда заголовки пакетов добавлены (28 бит), общая длина пакета, который будет отправлен Ping, будет 9000. Итак, введите команду:

ping -f -l 8972

Замените IP-адрес или доменное имя цели на

• 03.02.2017

• 3081

Сергей Калашников, CCIE

Технический директор

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

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

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

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

Record (Record Route)

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

 Обмен пакетами с по с байтами данных:
Ответ от : число байт= время=мс TTL= Маршрут: -> -> -> -> -> -> -> ->
Статистика Ping для : Пакетов: отправлено = , получено = , потеряно = (% потерь)
Приблизительное время приема-передачи в мс: Минимальное = мсек, Максимальное = мсек, Среднее = мсек 

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

 R1
Protocol [ip]:
Target IP address:
Repeat count []:
Datagram size []:
Timeout seconds []:
Extended commands [n]: y
Source address interface:
Type of service []:
Set DF bit IP header? [no]:
Validate reply data? [no]:
Data pattern []:
Loose, Strict, Record, Timestamp, Verbose[none]: R
Number of hops [ ]:
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending , -byte ICMP Echos to , timeout seconds:
Packet sent a source address of
Packet has IP options: Total option bytes= , padded length= Record route: <*> () () () () () () () () ()
Reply to request ( ms). Received packet has options Total option bytes= , padded length= Record route: () () () () () () () () () <*> End of list
Success rate percent (/), round-trip min/avg/max = // ms 

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

 C:\Users\user>ping -n -s
Обмен пакетами с по с байтами данных:
Ответ от : число байт= время=мс TTL= Отметка времени: : -> : -> : -> :
Статистика Ping для : Пакетов: отправлено = , получено = , потеряно = (% потерь)
Приблизительное время приема-передачи в мс: Минимальное = мсек, Максимальное = мсек, Среднее = мсек 

Strict (Strict Source Route)

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

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

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

 Обмен пакетами с по с байтами данных:
Ответ от : число байт= время=мс TTL= Маршрут: -> -> ->
Статистика Ping для : Пакетов: отправлено = , получено = , потеряно = (% потерь)
Приблизительное время приема-передачи в мс: Минимальное = мсек, Максимальное = мсек, Среднее = мсек 

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

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

Если в команде 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 может маршрутизироваться транзитными устройствами по обычным правилам.

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

 Обмен пакетами с по с байтами данных:
Ответ от : число байт= время=мс TTL= Маршрут:
Статистика Ping для : Пакетов: отправлено = , получено = , потеряно = (% потерь)
Приблизительное время приема-передачи в мс: Минимальное = мсек, Максимальное = мсек, Среднее = мсек 

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

Данная опция активируется автоматически при выборе любой из ранее описанных. Предоставляет более детальный вывод информации на экран. На сам пакет 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 и то при небольшой глубине сети. Остальные опции под вопросом.

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

1. Олифер, Компьютерные сети 7 издание
2. Таненбаум, Компьютерные сети

Похожее:

Непрерывный пинг: Как сделать пинг без остановки в командной строке route – программа, команда (Windows, Unix,…) Static Routing Commands on Cisco IOS XR Software – Cisco IT-блог о веб-технологиях, серверах, протоколах, базах данных, СУБД, SQL, компьютерных сетях, языках программирования и создание сайтов