ICMP в Cisco IOS

Если говорить про управление утилитами ping и traceroute в цисках, то мы увидим следующее. Пингалка в цисках есть, можно попинговать соседа. Мы сегодня это даже уже делали. И вы можете это делать в пользовательском или в привилегированном режиме. В зависимости от того, где вы находитесь, вам будут доступны немного разные опции. Если вы в пользовательском режиме находитесь, вы можете написать ping, и дальше либо IP-адрес, либо имя узла в предположении, что у вас работает DNS, и ping попытается попинговать соседа. Если вы находитесь в решёточке, в привилегированном режиме, то вы можете заказать дополнительные опции, которые в пользовательском режиме будут недоступны. Во-первых, вы можете сказать, сколько пакетов вы хотите отправлять. По умолчанию отправляется 5 пакетов. Во-вторых, вы можете сказать, какого размера эти пакеты будут. Здесь суммарный размер, включая IP-заголовок, включая ICMP-заголовок. Если вы заказываете 1500 байт, то IP-пакеты получатся 1500 байт размера.

Я специально на этом делаю акцент, потому что в Windows, например, вы указываете размер содержимого ICMP эхо-реквеста, размер ключика минус L, и, соответственно, заголовки ICMP, заголовки IP там не учитываются. Там 1472 надо указывать для того, чтобы получить 1500-байтовые пакеты. А здесь вы указываете сразу готовый результат. И далее. По умолчанию, если мне память не изменяет, 64 байта у вас получаются пакеты. Что-то такого плана. Вы можете заказать, с каким адресом источника вы хотите пинговать соседа. Source, и дальше можно указать IP-адрес, можно указать интерфейс, с которого взять адрес. Если хотите, вы можете заказать, что пакеты должны отправляться с флагом DF, Do Not Fragment, что их нельзя фрагментировать. Очень полезно, когда вы выставляете вручную размер пакета. И это инструмент для диагностики MTU в трассе между отправителем и получателем.

Вы, перебирая различные размеры, говорите: давайте попробуем 1500 с ключом DF. Пингается? Не пингается? Окей. Давайте попробуем 1496, 1492. Такие характерные MTU, которые могут присутствовать в канале. И таким образом, понижая размер пакета с обязательным сохранением флага DF, вы обнаруживаете наконец тот размер пакета, который по факту работает. В некоторых ситуациях будет полезно. И также вы можете указать тайм-аут. По умолчанию тайм-аут 2 секунды. Но вы можете сказать, что вас интересует, допустим, тайм-аут 1 секунда или 10 секунд. По желанию. Если у вас очень медленный канал, вы можете сделать побольше, чем 2 секунды. Ещё есть расширенный режим, когда вы можете просто написать ping без указания каких-либо ключей. И там можно ещё более расширенную штуку получить. Вам начинает система с помощью мастера задавать вопросы

типа: что будем пинговать? Если вы просто соглашаетесь с первым вопросом, то предполагается, что вы будете использовать IPv4. Какой IP-адрес будем использовать? Сколько пакетов посылать? Это всё на самом деле repeat, IP-адрес. Какого размера пакеты? Вот оно. Какой тайм-аут использовать? Вот он опять же. Будете ли вы что-то ещё заказывать? Это всякие source, DF bit и так далее. Если вы здесь просто нажимаете Enter, то система начинает пинговать соседа или какой-то другой узел, и показывается, сколько пакетов вы посылаете, какие они, куда и какой тайм-аут. Здесь выводится результат, и здесь показывается статистика, сколько пакетов отправлено, сколько получено. Восклицательный знак обозначает, что вы отправили один пакет, и он дошёл до получателя, вернулся к вам, и всё в порядке, вы в пределах тайм-аута получили ответ. Если вы закажете... Так, если в винде указать размер 1500,

то он будет, по сути, включать фрагментацию и отправлять два пакета. Да. Давайте я покажу это. Вот у меня Windows. И я сейчас буду баловаться с утилитой ping. Ping 8.8.8.8. Вот оно пингается. Видно, что TTL я вижу 120. Это значит, что, скорее всего, узел 8.8.8.8 мне отправлял пакеты с TTL 128, но 8 прыжков между роутерами сократили приходящий TTL до 120. Если я укажу, что мне хочется пинговать соседа с пакетами большего размера, то я могу это заказать. Указываю минус L 1472. И тогда пакеты, которые будут уходить, будут уходить размером 1500 байт. Но конкретно здесь оно не работает, потому что это гугловский DNS, он такой кривой. Давайте я кого-нибудь другого попингую.

192.168.99.1. И пакеты действительно уходят. 1472 байта я отправляю. 1472 байта мне в ответ отправляет узел 99.1. То, сколько я отправил, и то, сколько он мне отправил, напрямую не связано. Но конкретно этот узел в виде жеста вежливости делает то, что сколько я отправил, столько он мне и возвращает. И я утверждаю, что 1472 байта нагрузки плюс 8 байт ICMP плюс 20 байт IP дают как раз 1500 байт содержимого. Если я буду заказывать флаг DF, то оно может пройти, а может и не пройти. Если я буду отправлять 1500-байтовые IP-пакеты, они с некоторой вероятностью могут дойти до получателя без фрагментации. А могут и не дойти. Давайте проверим. Минус F в Windows заказывает отсутствие фрагментации. Я пытаюсь это сделать, и у меня роутер 192.168.

111 возвращает ответ, что нет, не получается такое сделать. Где-то в сети 1500-байтовые пакеты не пролезают. Надо их сокращать. Он здесь сказал, что якобы у нас три потеряны из четырёх. На самом деле, конечно, все четыре потеряны. Просто немного глюк со статистикой. Поэтому я делаю гипотезу. Гипотеза заключается в том, что у меня используется какая-то дополнительная инкапсуляция, какой-то дополнительный заголовок. И я думаю, сколько бы мне надо отправить, чтобы получилось хорошо. Допустим, 1400 байт я отправляю, и вижу, что 1400 байт доходит до получателя нормально. Давайте 1450 байт отправляем. 1450 уже не пролезает. 1440. 1440 тоже не пролезает. Сколько же там всего по заголовкам? 1430 тоже не лезет.

1420. 1420 уже лезет. 1425, 1426 не лезет. 1424 не лезет. 1422. 1422 лезет. 1423. Мы нашли границу. 1422 байта пролезает, 1423 байта не пролезает. Если я буду отправлять пакеты 1500 байт размером, они будут фрагментироваться, и некий транзитный роутер будет их резать на части. А так я вижу, что они не пролезают. Причём я подчёркиваю, не пролезает где-то в серединке, в транзите. Это не то, что мой узел не может отправить пакет 1423 байта размером. Если я попробую тот же Google DNS попинговать, 8.8.8.8, он пролезет. Ладно, 8.8.8.8 нет. Яндекс.ру. Вот Яндекс пингается.

Все те же самые ключи, пакеты такие же, ключи такие же, размеры пакетов такие же, но до Яндекса проходит, а до какого-то узла, который понакрутил дополнительную инкапсуляцию, не проходит. Как-то так. Да, какие же нюансы на каждом шагу. Расширенный режим. В цисках тоже можно пинговать. Вот здесь Extended Commands. Я предложил вам отказаться от расширенных команд, но там есть кое-что интересное. И первая штука, которая там интересная, это Sweep Range of Sizes. Вы можете на циске не заниматься таким ручным перебором, как я только что делал, когда говорил: 1430 пролезает, 1420 не пролезает. На циске можно сделать очень удобную вещь. Можно сказать: попробуй, пожалуйста, по чуть-чуть отправить пакетов каждого размера в диапазоне от А до Б. У меня была гипотеза,

что 1400 пролезает, 1500 не пролезает, где-то в серединке есть граница. Начинаю с 1400, и дальше 1401, 1402, 1403. Не ручками вбивать эти цифры, а автоматом перебрать по одному пакетику каждого размера. И будет сразу понятно, какие пакетики пролезают, какие пакетики не пролезают. Вот это Sweep Range of Sizes, очень удобная вещь. И второй механизм, который вы можете использовать в расширенном режиме, это задействовать поле Options в заголовке IP. Это единственная фактически возможность задействовать поле Options в IP в сегодняшнем мире. Сразу имейте в виду, что такие пакеты с полем Options вы, если сможете использовать, то только внутри своей сети и сугубо в академических целях. Потому что по факту эти опции никому не нужны и пригодиться они вам вряд ли могут. Что можно сделать с полем Options? Можно указать опцию Source Routing.

Она будет указывать не жёсткий маршрут. Вы скажете, через какие маршрутизаторы надо пропустить пакет в обязательном порядке. Вы скажете, что я, отправитель, отправляю пакет, и я хочу, чтобы маршрутизаторы 1, 2, 4, 10 обязательно пропустили через себя этот пакет. Мне всё равно, как вы это сделаете. Главное, сделайте. Или вы можете сказать strict, в жёстком виде сказать: первый должен передать второму, второй должен передать восьмому, восьмой — десятому. Понятное дело, что восьмой и десятый совершенно не обязательно могут быть связаны между собой. Но если вы задаёте жёсткий маршрут, то обязательно именно по такой трассе пакет должен пройти. В противном случае он никуда не пройдёт. Source Routing — очень кривая, косая вещь, которая по факту не нужна. Небезопасная, в первую очередь. И во-вторых, кто он вообще такой, отправитель, чтобы решать за маршрутизаторы, как им маршрутизировать трафик. Поэтому в реальности вы эти опции задавать не будете вообще никогда.

Они не нужны совсем. Когда-то авторы протокола предположили, что это может быть интересно в той логике, что отправитель и получатель — это всё-таки полноценные компьютеры, а транзитные роутеры — это маленькие тупые железки, которые чисто сервисные. И вычислительных мощностей у отправителей и получателей сильно больше, чем у транзитных роутеров. В 60-х, 70-х годах это было очень актуально, потому что много вычислительных возможностей транзитные роутеры предоставить не могли. Им было тяжело принимать решение, куда девать трафик. Но в случае с современным миром мы целиком полностью полагаемся на то, что роутеры лучше отправителей и получателей знают, как доставлять трафик в разные части сети. Поэтому эти опции никто не читает. А если даже они будут указаны, то такие пакеты просто будут пристрелены. Еще одна опция есть. Это опция record. Вы можете заставить все транзитные роутеры, когда они пропускают IP-пакет через себя,

записывать свой IP-адрес в заголовок IP-пакета. Смысл в том, что вы получите маршрутный лист в каждом пакете. Смотрите, есть трассировка, traceroute, утилита. Она отправляет много мелких пакетов и запоминает, кто прислал ответы, что я не смог ваш пакет промаршрутизировать. Вам для этого надо много ответов получить, много пакетов отправить, много всяких разных телодвижений, и вы получаете подобие трассы. Если у вас где-то будет, допустим, балансировка выполняться, то вы вообще там ничего не получите. Трассировка непонятно, что дает. Вы можете только сделать гипотезу, что пакет, возможно, пойдет по определенной трассе, если мы отправим следующий пакет ровно через те самые роутеры, которые прибивали пакеты с истекшим TTL. А опция record позволяет именно по факту отправить ровно один пакет и по факту посмотреть, кто его маршрутизировал.

Получатель сможет эту опцию прочитать и посмотреть, через какие конкретно роутеры конкретно этот пакет прошел. Понятное дело, что в опции мы в принципе не можем записать больше 40 байт, потому что у нас само поле options максимум 40 байт. Плюс еще у этой опции есть некий заголовок. Поэтому, учитывая, что IP-адрес каждого роутера занимает 4 байта, больше чем 9 IP-адресов в поле options не влезет вообще никак, потому что уже 10 IP-адресов занимают 40 байт, а еще заголовок надо вставить. Поэтому гипотетический максимальный размер количества маршрутизаторов, которые можно в поле record вписать, — 9 штук. По факту, транзитные роутеры не хотят рассказывать про то, что они промаршрутизировали трафик, потому что эту штуку они должны делать центральным процессором, а центральный процессор у роутеров, как правило, не очень мощный. Они все задачи по маршрутизации трафика

делают на специальных вычислительных процессорах, которые узко специализированы для задачи перекладывания пакетов между интерфейсами. И чем меньше там вмешательства будет в пакет, тем проще. Поэтому поле record вы можете затребовать, чтобы оно заполнялось, но по факту его заполнять никто не будет, и, скорее всего, даже такой пакет просто прибьется. И есть опция timestamp, это замерить время прохождения пакета по сети. Если вы сейчас подумали, что это что-то похожее на ping, record — что-то похожее на трассировку, а timestamp — что-то похожее на ping, когда мы видим, сколько миллисекунд прошло между узлами, — нет, это время TTL, которое вы видели в IP-пакете на этапе каждого роутера, который пропускал пакет через себя. Каждый роутер, пропуская пакет через себя, записывал, с каким TTL он его пропускал. Исходя из того, что когда-то давно TTL было время в секундах, которое пакет мог прожить по дороге, опция timestamp

позволяла на каждом роутере записывать время, TTL каждого пакета. Но сами понимаете, что сегодня вы на всех роутерах будете видеть ровно одну картину, что TTL всегда вычитает одну единичку каждый роутер. Поэтому опция совершенно бесполезна в современном мире. Если вы пингуете соседа, то мы делаем это все не ради каких-то мифических опций, а ради вот этой одной строчечки. И там будут всякие разные символы. Самый ожидаемый символ — это восклицательный знак. Если мы отправили ping и получили на него в ответе восклицательный знак, то мы за время таймаута получили тот самый ожидаемый ответ ICMP тип 0, код 0. И все хорошо, пинги ходят. Если мы не получили вообще никакого ответа, то показывается точечка. Вот пример того, как мы отправили некоторое количество запросов

и никаких ответов не получили. С некоторой вероятностью можно утверждать, что такой узел в сети, допустим, отсутствует или с ним нет связи. Если вы видите какие-то другие буковки или значки, то это будет означать всякое разное. Во-первых, есть вариант, вы получаете U. Значит, Destination Unreachable какой-то пришел, но не Packet Too Big. То есть либо Network Unreachable, либо Port Unreachable. Еще есть А, Administrative Лепрахиб, это 3, по-моему, 5, что ли, это тоже отдельный случай. Ну, короче говоря, все ушки, это не удается доставить пакет, потому что что-то мешает. Есть сообщение M, это как раз Packet Too Big. Вы отправили пакет с пингом, заказали флаг DF, и он не пролез по дороге. Соответственно, в этом случае показывается M, что надо бы фрагментацию сделать, и не получается. Если вдруг у вас есть цепочка

роутеров, первый отправляет пакет второму, второй третьему, третий четвертому, четвертый пятому, и в какой-то момент в каком-то канале между роутерами случается затык, а ICMP штатно имел возможность сказать, ребята, притормозите отправку, потому что вы как бы слишком много трафика генерите. То есть, можно было отправить сообщение, ребят, притормозите. Это тоже штатная фича ICMP с типом, если мне память не изменяет, 5, или 4, или 5. Ну, соответственно, вот в этом случае вы можете увидеть буковку Q. Значит, какой-то транзитный роутер не смог доставить трафик до получателя из-за перегрузки канала, и отправил сообщение, я прибил пакет, потому что очередь на отправку была заполнена. Но, опять же, в современном мире вы это не увидите, потому что эту штуку считается неприличным отправлять, потому что как бы и так уже где-то перегрузка возникла, а вы еще дополнительный какой-то лишний трафик генерите, и типа это только повышает нагрузку на другие части сети, поэтому по факту все вот эти

вот сообщения про перегрузку, про заторы, про congestion management ICMP-шные, они обычно в интернете пристреливаются. Если вдруг вы отправили пинга, и он протух по дороге, ну, то есть у вас на системе прописан слишком маленький tool, будет показываться ampersand, и любые другие типы сообщений, которые, впрочем, очень маловероятны, это вопросик, то есть что-то другое пришло, какой-то сюрприз. Вот. Трассировка тоже в цисках есть, указываете в пользовательском или в привилегированном режиме трейс роут, дальше IP-шник или имя, и он начинает трассировать узел. Показывается в немножко другом порядке, то есть в Windows я вам показывал, сначала показывается время, там, раз, два и три, а потом кто отправил ответ. Здесь наоборот, кто отправил ответ, а потом раз, два, три. Ну, и если хотите, можете в расширенном режиме просто сказать трейлс роут, без параметров, и дальше отвечаете на вопросы.

Кого, с каким источником, сколько пакетов отправлять, начиная с какого ТТЛ, заканчивая каким ТТЛ, и, соответственно, вы, когда пользуетесь трассировкой в ЦИСКе, вы отправляете UDP-шные пакеты, ну, UDP-шные датограммы с номерами портов 3, 3, 4, 3, 3, 3, плюс ТТЛ. То есть начинается с 3, 3, 4, 3, 4, потом 3, 3, 4, 3, 5, 3, 3, 3, 4, 3, 6, и в ответ вы видите на UDP-шные датограммы сообщение, соответственно, 3, 3, port-unreachable. То есть когда приходит сообщение от действительно обладателя этого IP-шника, он говорит, я не знаю, что ты вообще-то за порты такие выбрал, у меня на этих портах ничего не слушает. 3, 3 это port-unreachable. В Windows, например, вы отправляете ICMP-сообщение, то есть вы отправляете ICMP-сообщение, какое оно там есть-то?

А, ну, собственно говоря, да, ICMP-сообщение echo-request и получаете в ответ echo-reply. И получение чего угодно отличного от TTL-expire in transit обозначает как раз то, что трассировку пора заканчивать. Давайте попробуем показать, что ли, как это работает, где у нас наша циска. Так, enable ping-10, 0, 8, 1. Оно, типа, даже ping-ается. То, что здесь показывается, один пакет якобы не дошел, а 4 дошло, это на самом деле нормальное явление. Это связано с работой аппаратного ускорителя, когда самый первый пакет утилита ping-генерирует, он нигде не теряется по сети, он просто не отправляется. Наш роутер не знает, куда его отправить. Это, опять же, специфика цисковского аппаратного ускорителя.

Все остальные пакеты нормально отправляются по сети и доставляются до получателя, и на них возвращается ответ, потому что в тот момент, когда второй пакет собирается отправляться, уже аппаратный ускоритель готов к работе. Ну и, соответственно, если я сейчас повторно попингую тот же самый узел, он сразу будет пингаться, аппаратный ускоритель уже отработал и уже готов обрабатывать такие пакеты. Он просто вот самый первый пакетик теряет из-за того, что не готов обработать трафик на него. Так. Если я захочу, я могу указать, опять же, source 10, 0, там, 8, какой у меня, 9 айпишник. Ну, опять же, пингается, у меня другого айпишника нет, поэтому здесь проблем быть не должно. Могу указать size 1500 байт, опять же, они должны пингаться. Могу больше указать, не только 1500, могу 3000 байт указать. 300, понятно, 300 работает, 3000 тоже работает. Здесь генерируется два пакета, по факту,

или даже три, и, соответственно, вот сама моя система понимает, что надо сгенерировать пакет пинга размером 3 килобайта, потом говорит, я не пропущу его в Ethernet интерфейс, его придется порезать на полуторакилобайтные пакеты, делает первый пакет полтора килобайта, второй пакет полтора килобайта, а третий пакет 40 байт. Потому что у него еще заголовок тоже должен быть, и заголовок у второго пакета тоже должен быть. Поэтому, если мы делаем два дополнительных пакета, у нас размер заголовка растет на 40 байт. Двух заголовков получается. Ну и да, у нас получается три пакета, 1500, 1540. Можно заказать donut fragment, dfbit, и тогда у нас такой пакет не пролезет. Вот, он говорит, не пролезает. так, что еще тут рассказать? Трассировка, ну трассировка у нас пока скучная система, 10, 0, 8,

1. Она покажет, что трассировка выполняется, и самый первый узел присылает сообщение port enrichable, поэтому, да, у нас самая первая строчка, она же будет и самой последней строчкой. Ну вот, используя эти два инструмента, вы можете достаточно неплохо угадывать места, в которых у вас есть проблема какая-то в сети. То есть, в нашем случае проблемы в сети между 10, 0, 8, 9 и 10, 0, 8, 1 нету. Пинги пингаются, трассировка трассируется, следовательно, связь между этими двумя узлами есть, по крайней мере, на уровне этих протоколов. То есть, как минимум, мы можем сразу исключить, что между нами нет проблем с физикой, что между нами нет проблем на сети, в ум уровне, все маршруты у нас установлены правильно, провода все живые. Так что, если где-то что-то и не работает с нашей стороны, то это может быть только, например, какой-то, не знаю, фаервол какой-то криво настроенный или что-то в этом духе. А вот все остальное работает корректно. Раз такой трафик ходит, то теоретически

какой-то абстрактный трафик может пройти, если только его там, допустим, фаервол не пристрелят. Ну что, на сегодня, пожалуй, хватит. Мы прошли сегодня все служебные вспомогательные протоколы, ARP, DHCP, ACMP. И остались у нас темы следующих модулей. На сегодня все. Спасибо за внимание. Пока-пока. Продолжение следует...