YouTube + Компьютерные сети

Господа, дамы, здравствуйте!

В прошлом посте обсудили MTU и некоторые важные особенности, связанные с размерами пакетов и кадров, в этом давайте посмотрим: как можно менять MTU на различном оборудование, для примера рассмотрим следующие устройства:

1. Компьютер под управлением Linux, для этого будет использоваться виртуальная машина с Debian 10 (на схеме это Host_1).

2. Компьютер под управлением Windows 10 (значок с подписью Win).

3. Роутер CSR1000v под управлением IOS XE.

4. Хотелось бы еще рассмотреть классические коммутаторы, но коммутаторы под управлением IOL в EVE-NG, как я понял, всё-таки являются multilayer свичами, а не классическими L2, плюс на IOL у меня не получилось изменить канальный MTU, но SW на схему добавлен и мы немного с ним поработаем.

Схема, на которой будем всё это тестировать:

Зеленый кружок это возможность для выхода устройств лабы в реальную сеть, IP-адреса подписаны на схеме, а на линке SW/CSR кадры ходят в 200 влане, в сторону Windows кадры отдаются без метки.

Как изменить MTU на коммутаторе Cisco

Перед изменением MTU разберемся как его смотреть, есть стандартное заблуждение, что на оборудование Cisco в конфигурации нельзя увидеть значения MTU, если оно равно значению MTU по умолчанию, и действительно, команда show run не дает никаких результатов:

Можно даже посмотреть конфигурацию одного из интерфейсов:

Но почему-то многие забывают что есть show run all:

В лабе EVE-NG используется коммутатор IOL, MTU у них меняются на интерфейсах. Вот пример конфигурации интерфейса Ethernet0/0:

Если не увидели в выводе выше значение MTU, то вот строки: mtu 1500, mpls mtu 1500. Все интерфейсов на коммутаторе четыре:

Посмотреть MTU на интерфейсе можно еще и так:

Это канальный MTU. В конфигурации каждого порта мы видим два MTU: Ethernet и MPLS, оба равны 1500 байт, но порт можно перевести в режим роутера, тогда у него появится еще и IP MTU. Переводим порт:

Посмотрим какие MTU есть на коммутаторе:

Появилась строка ip mtu 1500, она относится к порту Ethernet0/1. Чтобы посмотреть IP MTU можно воспользоваться вот такой командной:

Возникла ошибка, дело в том, что интерфейс e0/1 переведен в режим роутера, но на нем не работает IP процесс, чтобы он заработал, надо настроить IP-адрес:

Теперь мы можем посмотреть IP MTU и другие параметры процесса IP:

MPLS MTU посмотреть можно так (но MPLS должен быть включен на интерфейсе):

Изменить канальный MTU можно было бы вот такой командой:

IP MTU на образах IOL меняется:

MPLS MTU тоже можно поменять:

Итоговая конфигурация интерфейса теперь такая:

Классические коммутаторы Cisco, как правило, не позволяют менять MTU отдельных интерфейсов и не имеют конфигураций MPLS MTU, у них есть так называемый system mtu, который позволяет задавать MTU всем интерфейсам сразу, показать не могу, поэтому отправлю к странице Configuration Guide для Catalyst 2960.

Команда Ping и размеры пакетов при пинге

Порт e0/1 на коммутаторе никак не влияет на передачу данных между хостами. MTU на всех линках, которые обеспечивают связность между ПК, сейчас стандартный и равен 1500 байт. Давайте в этом убедимся пингом с одного хоста на другой:

Здесь стоит обратить внимание на то, что опция -s 1472 задает размер ICMP вложения без учета ICMP и IP заголовков, таким образом получается, что сформированный IP-пакет равен 1500 байт. В этом легко убедиться, если посмотреть на дамп Wireshark:

Если указать размер 1473 байта, то пинга не будет:

На скрине зеленым выделен размер кадра, красным IP-пакета. А теперь сделаем пинг с роутера в сторону Debian:

По результату пингов можно сделать вывод, что в IOS XE задается размер IP пакета при выполнении пинга. В Windows при пинге задается размер ICMP вложения без учета заголовков IP и ICMP:

Вывод из этого всего простой. Когда вы задаете размеры чего-то при пинге, всегда узнавайте, чего именно размер вы задаете.

Как изменить MTU на роутере Cisco?

Фактически способы изменения различных MTU на роутере мы рассмотрели, когда говорили про коммутаторы, т.к. для примера использовался multilayer switch. Но давайте все-таки кое-что посмотрим.

Для начала обратим внимание что максимальный канальный MTU на интерфейсе роутера может быть 9216 байт:

При этом сейчас канальный MTU равен 1500 байт, давайте посмотрим на возможные значение IP и MPLS MTU:

Изменим L2 MTU, зададим максимальное значение:

Значение изменилось, а теперь давайте посмотрим на значения, которые можно задать IP и MPLS MTU:

Их верхняя граница отодвинулась на значение 9216 байт, при этом у IP минимальный MTU может быть равен 68 байт, а у Ethernet и MPLS 64. Давайте теперь посмотрим на линк в сторону коммутатора, в самом начале я упоминал, что на этом линке используется 200 влан, со стороны роутера настроен саб-интерфейс с номером 200, который инкапсулирует кадры в 200 влан, конфигурация выглядит так:

Поясню по поводу саб-интерфейса Gi2.200: о том, что на кадры нужно ставить метку с номером 200, говорит строка encapsulation dot1Q 200, цифра 200 после Gi2 это номер саб-интерфейса, эта цифра не обязана совпадать с номером влана, но для удобства их обычно делают одинаковыми.

Саб-интерфейс и влан в данном случае я городил, чтобы посмотреть на связь между MTU физического интерфейса и MTU саб-интерфейса.

Посмотрим какие MTU сейчас на Gi2 и Gi2.200:

Посмотрим какой MTU можно задать саб-интерфейсу:

Выставим саб-интерфейсу L2 и L3 MTU равными 1600 байт:

Роутер съел команду mtu 1600, но при этом задать ip mtu 1600 возможности нет. Давайте посмотрим применился ли L2 MTU 1600 для саб-интерфейса:

А вот и не изменился. Выставим L2 MTU 1600 байт для Gi2:

Выставили, он применился. Посмотрим MTU Gi2.200:

Увеличим MTU Gi2 до 1700 байт и посмотрим канальный MTU Gi2.200:

Канальный MTU саб-интерфейса увеличивается вместе с канальным MTU основного интерфейса. L3 MTU теперь тоже можно сделать 1700 байт, но мы сделаем 1600 байт:

Какие выводы мы можем сделать из увиденного?

1. В IOS XE значение Ethernet MTU саб-интерфейса наследуется от основного интерфейса.

2. Сетевым MTU саб-интерфейса можно управлять, но он не может быть больше канального.

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

По факту в IOS XE на саб-интерфейсе можно менять IP MTU и MPLS MTU, канальный MTU наследуется, это подтверждает вывод sh run all:

По результатам sh run all видим, что нет даже возможности задать канальный mtu на саб-интерфейсе, а вот конфигурация основной интерфейс.

Для дальнейшего рассмотрения я вернул MTU всех интерфейсов на 1500 байт.

Размер Ethernet заголовка и настройки MTU

В прошлом посте про MTU я говорил, что есть некоторые стандарты, которые увеличивают размер заголовка, самый очевидный и часто используемый в компьютерных сетях стандарт это 802.1q или VLAN, он добавляет к полю заголовка 4 байта, то есть эта добавка никак не должна влиять на способность оборудования пропустить кадр с MTU 1500, если на интерфейсах этого оборудования настроено 1500 байт.

Убедимся в этом, запустим пинг из Linux в Windows IP-пакетами размером 1500 байт и снимем дамп с двух линков:

1. На линке Host_1/CSR. Здесь кадр идет без поля 802.1q.

2. На линке CSR/SW, здесь кадры идут с меткой 200.

На линке коммутатор/Windows дамп снимать смысла нет, потому что коммутатор убирает метку, когда отдает кадр в сторону ПК. Пинг:

Дамп с линка между Линуксом и роутером:

Зеленым выделен размер кадра (Dst MAC + Src MAC + Type + Payload). Красным выделен размер пакета 1500 байт. Теперь кадр на линке между роутером и коммутатором:

Размер кадра увеличен до 1518 байт за счет того, что к заголовку добавились поля 802.1Q, но IP-пакет по-прежнему 1500 байт, данный кадр прошел через линк с MTU 1500 байт и это правильное поведение оборудование, но если вы работаете с каким-нибудь noname китайским тестируйте такие моменты.

Как изменить MTU интерфейса в Windows 10?

Сразу скажу, что я не самый быстрый стрелок на этом диком западе в части специфичных сетевых настроек на Винде, но как поменять MTU я знаю, для начала давайте посмотрим какие интерфейсы есть и какой MTU на них задан. Вот этой командной можно посмотреть канальные интерфейсы и их MTU в Windows:

В левом столбце значение L2 MTU, вывод я такой делаю, потому что можно посмотреть расширенные настройки интерфейсов:

И тут написано Link MTU. Поменяем значение MTU интерфейсу со значением Ethernet на 1600 байт через командую строку. Изменения рекомендую вносить через командую строку, запущенную от имени администратора:

Слово "Ethernet" в команде для смены MTU это имя интерфейса, имена интерфейсов можно посмотреть командой ipconfig. В графическом интерфейсе можно изменить размер кадров, который должен уметь обрабатывать интерфейс, заходим в меню "Настройки параметров адаптера" и здесь жмем ПКМ на нужный интерфейс:

Выбираем пункт "Свойства"/"Properties".

Жмем на кнопку "Configure..."/"Настроить...". А далее идем по цифрам:

В русской версии Windows меню "Jumbo Packet" перевели как "Большой кадр". Значение 9014 байт это именно что размер кадра, потому что после того как будет выбрано 9014 байт, MTU интерфейса станет 9000 байт:

Когда вы включаете Jumbo кадры, интерфейс перезагружается.

Как изменить MTU в Linux?

Перейдем к Linux. Разберемся как проверять MTU на интерфейсах.

Прежде чем продолжить сделаю одно примечания. В посте о настройке лабы TTL я довольно подробно описал базовые сетевые настройки для Debian 10, плюс там же дал некоторые полезные ссыли, поэтому сейчас на этом вопросе подробно не останавливаюсь.

На конкретном интерфейсе MTU смотрим так:

На всех интерфейсах можно посмотреть так:

Или вот так:

Или даже так:

Разберемся с тем, как сделать временные изменения MTU на интерфейсе, изменять будем на ens3, этот интерфейс включен в мою домашнюю сеть, а через нее в интернет, для проверки попинуем Гугл:

Пакеты размером 1501 байт не проходят, пакеты размером 1500 байт проходят. Изменим MTU:

Запустим пинг:

Пакеты размером 1401 байт не проходят, 1400 байт проходят. Посмотрим параметры интерфейса:

У интерфейса ens3 MTU будет 1400 байт до перезагрузки машины, после ребута он вновь станет 1500 байт. Разберемся как изменить MTU на постоянной основе, как и большая часть других настроек Linux, постоянные изменения применяются через изменение конфигурационных файлов. Открываем файл с сетевыми настройками любым удобным редактором:

Находим конфигурацию нужного нам интерфейса и добавляем в нее значение MTU нужного нам размера, в моем случае 1400 байт:

Стоит учитывать что название и расположение файла с сетевыми настройками зависит от дистрибутива, с которым вы работаете. Давайте проверим изменился ли MTU:

Нет, он по-прежнему 1500 байт, надо передернуть:

Просто ifup будет недостаточно, сперва интерфейс надо выключить, потом включить. Контрольная проверка пингами:

И не забывайте, что в Linux есть замечательная утилита grep, которая позволяет избежать просмотра портянок различного рода конфигураций и диагностических выводов:

Ну и всё, спасибо, что дочитали!

Вопрос для вашего ответа

Почему роутер дает возможность установить минимальный MTU для IP 68 байт, а для MPLS и Ethernet 64 байта? В чем логика, если IP это вложение в Ethernet и тот же IP может быть закрыт MPLS заголовком?

Видео версия

Видео версия для тех, кому проще посмотреть и послушать, чем почитать.

Господа, дамы, здравствуйте!

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

Что такое MTU и PDU?

Читая или смотря что-то о компьютерных сетях, вы часто можете встретить две аббревиатуры: PDU и MTU. Первая расшифровывается как Protocol Data Unit, проще говоря PDU это обобщенное название фрагмента данных, которым обмениваются устройства по тому или иному протоколу. Например, IP устройства обмениваются пакетами, значит PDU в IP это пакет, у Ethernet это будет кадр или фрейм, а PDU в UDP это дейтаграмма.

MTU расшифровывается как Maximum Transmission Unit или максимальная единица передачи, проще говоря, это максимальный размер пользовательских(полезных) данных, которые можно передать внутри одного PDU тем или иным протоколом без фрагментации. Стоит пояснить, что понимается под полезными данными. Для Ethernet полезными данными может выступать IP-пакет, для IP-пакета полезными данными может быть ICMP сообщение, TCP сегмент или UDP дейтаграмма.

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

Но на самом деле в IP определение MTU отличается от Ethernet или TCP. Для IP MTU это пользовательские данные плюс заголовок пакета, поэтому картинка должна быть такой:

Но тогда непонятно: в чем разница между канальным и сетевым MTU? Разница будет видна при различного рода туннелях, мне ближе всего MPLS, поэтому вот пример MTU с MPLS:

Здесь мы видим, что MPLS заголовки включаются в MTU кадра, но не являются MTU пакета, для MPLS на оборудование можно задавать свой собственный MTU, но это отдельная история. Понятно, что чем больше в PDU выделено места для пользовательских данных по сравнению со служебными, тем для получателя услуги скорость будет выше. Вот здесь есть краткий обзор того, как различные размеры кадров и их MTU влияют на скорость для конечных хостов (правда не на нашем языке).

Примечание

Из выше описанного понятно, что MTU на канальном уровне не включает в себя байты, выделенные под Ethernet заголовок, но есть исключения. Например, оборудование Cisco под управлением ОС IOS XR считает канальный MTU не как размер полезной нагрузки в Ethernet кадре, а как размер полезной нагрузки + Ethernet заголовок. С этим нужно быть внимательным, особенно когда настраиваются протоколы, для которых MTU имеет значение, например, OSPF.

Максимальный размер MTU

Вопрос не такой однозначный и простой. Будем исходить из того, что MTU не может быть бесконечным, на это есть много причин, вот некоторые из них:

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

2. Когда-то раньше, когда в Ethernet сетях были топологии с общей шиной, а сети строились на хабах и повторителях, большие кадры и пакеты были невыгодны, поскольку в таких сетях пока один из участников канальной среды вел передачу, все остальные его слушали и молчали.

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

4. Потеря маленького пакета не так критична, как большого, вероятность получить искажение большого пакета выше, чем маленького.

Семейство Ethernet, а также фичи и костыли, которые к Ethernet приделываются, как правило, описываются стандартами IEEE. Самый базовый стандарт Ethernet это IEEE 802.3, он дает следующие верхнее ограничение на размер Ethernet кадра в целом и его MTU в частности:

1. Размер кадра не должен превышать 1518 байт.

2. MTU кадра должен быть 1500 байт.

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

Примечание

Большинство документов, описывающих IP это RFC (request for comment), изначально идея RFC была в том, что кто-то придумал какую-то фичу или метод, описал как ее реализовать и этот кто-то направляет своим коллегам запрос на комментарии к тому, что он придумал. Сейчас RFC можно считать рекомендациями к реализации той или иной фичи. Ethernet же описывается стандартами, полагаю, разница между словом рекомендация и стандарт особых пояснений не требует.

Минимальный размер MTU

Теперь поговорим о нижем ограничение для MTU. Если коротко, то оно есть и, как правило, это ограничение описывается стандартом протокола. Связаны такие ограничения с физикой нашего мира: дело в том, что сетевые устройства обмениваются физическими сигналами, которые генерируются и распространяются по среде передачи данных не мгновенно(хоть и на скоростях близких к скорости света в вакууме), если говорить про Ethernet, то здесь минимальный размер кадра связан с доменом коллизий (участком сети, где два кадра могут столкнуться друг с другом). Дело в том, что размер кадра должен быть настолько большим, чтобы отправителю кадра в случае возникновения коллизии хватило времени на детектирования коллизии.

Если хотите деталей, то поищите информацию про CSMA/CD. На современном оборудование метод CSMA/CD реализован, но зачастую не используется, в виду того, что домен коллизий ограничен линком между двумя конкретными устройствами, а на линке, как правило, работает full duplex (если вы переводите линк в half, то вопрос обнаружения коллизий на этом линке снова становится актуальным), т.е. для приема своя физика, а для передачи своя, что исключает возможности появления коллизий.

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

Для стандартов Ethernet со скоростями 10Mbps и 100Mbps минимальный размер кадра равен 64 байта, для стандартов Ethernet со скоростью 1000Mbps по меди(1000BASE-T) минимальный размер кадра увеличен до 512 байт, а если не ошибаюсь, то для стандарта 1000BASE-X(оптика) минимальный размер кадра 416 байт.

Насколько мне известно, стандарты, описывающие реализацию Ethernet на скоростях 2.5Gbps и выше, не предусматривают возможность работы в режиме half duplex, а это означает, что ограничений, которые накладывал CSMA/CD на размер кадра в этих стандартах нет. Сам не тестировал, но встречал упоминания о том, что для Ethernet кадров из стандартов для скоростей выше 1Gbps наследуется минимальный размер кадра в 512 байт.

Если говорить про связку IP+Ethernet, то здесь минимальные MTU для IP такие:

1. Для IPv4 минимальный MTU не может быть меньше 68 байт. Иногда можно найти информацию о том, что для IPv4 минимальный MTU равен 576 байт, но это не так, на самом деле 576 байт это гарантированный размер IP-пакета, который должен смочь обработать получатель, то есть хост в IP должен уметь обрабатывать пакеты размером 576 байт, а вот пакеты больших размеров он уже не должен уметь обрабатывать.

2. Для IPv6 минимальный MTU не может быть меньше 1280 байт.

Почему я не писал явные размеры минимальных MTU станет понятно ниже, когда речь пойдет про размеры Ethernet заголовка.

Размер Ethernet заголовка

Есть группа стандартов под номером IEEE 802, эта группа описывает сети LAN(local area network) и MAN(metropolitan area network). В этой группе есть подгруппа 802.3, в которой собрано всякое разное про Ethernet, плюс есть подгруппа 802.1, которая тоже будет нам интересна в контексте обсуждения Ethernet заголовка.

Таблица выше была взята с википедии. Группы 802.3 и 802.1 включают в себя некоторые стандарты, которые увеличивают размер Ethernet кадра за счет добавления или расширения служебных полей, это означает, что зачастую для того, чтобы пропускать такие кадры, оборудование должно поддерживать этот стандарт, эти стандарты как правило не требуют увеличения MTU на линках, но лучше заглянуть в документацию оборудования. Вот примеры таких стандартов.

IEEE 802.1q, 802.1p, 802.3ac

Первым делом стоит сказать про 802.1q, он описывает технологию VLAN, которая реализуется за счет добавления нового поля в заголовок кадра, и есть 802.1p, который описывает методы приоретизации трафика. Стандарт 802.3ac предписывает увеличение Ethernet-кадра на 4 байта, в этих четырех байтах как раз и содержится информация о влане и важности кадра.

IEEE 802.1ad

Стандарт 802.1ad известен больше как QinQ, он расширяет размер кадра как минимум до 1526 байт, этот стандарт позволяет добавлять в кадр две или более метки VLAN, при этом у каждой может быть свой приоритет. Метки и приоритеты как раз описаны в 802.1q и 802.1p. Как правило используют два влана, хотя, наверное, вы можете встретить сценарии с тремя и более тегами.

IEEE 802.1ah

Стандарт 802.1ah более известный как PBB или MACinMAC.

IEEE 802.1ae

Стандарт 802.1ae (технология MAC Security) позволяет генерировать кадры размером 1550 байт, 16 байт выделяется под заголовок MAC Security и 16 байт под поле ICV(контрольная сумма).

Хороший обзор Ethernet кадров различных стандартов и с различными доп. полями можно почитать здесь. Картинки выше взяты оттуда. А вот сравнение размеров различных Ethernet заголовков:

Изображение было взято отсюда. На самом деле размер кадра может больше, чем я описывал ранее. Кадры больше стандартных имеют даже свои названия, например, Baby Giant или Jumbo Frame, названия не официальные.

Baby Giant обычно называются кадры размером от 1519 до 1600 байт. Джамба фреймами обычно называются кадры больше 1518 байт. Не всё оборудование умеет работать с jumbo кадрами, как правило их поддержку нужно включить. Стандартов по обработке jumbo фреймов никаких нет, всё на совести вендора.

Теоретический максимально возможный размер Jumbo Frame ограничивает поле FCS и алгоритм CRC32(Cyclic Redundancy Check), который используется для проверки целостности данных в Ethernet, из-за этих ограничений размер не может превышать11455 байт. Если говорить о реальных реализациях, то современные роутеры позволяют задать канальный MTU немногим более 9000 байт.

И в завершении стоит сказать про стандарт 802.3as. Проблема Ethernet в том, что на ранних стадиях он развивался реактивно: возникала потребность в какой-то фичи, и под эту потребность придумывался новый заголовок, в котором вводились новые поля и этот новый заголовок был больше исходного. В итоге такое развитие привело к созданию стандарта 802.3as, он увеличивает размер кадра до 2000 байт, грубо говоря и не вдаваясь в детали, этот стандарт говорит о том, что кадр размером 2000 байт и MTU не более 1500 байт должен быть обработан любым Ethernet интерфейсом.

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

Видео версия

Для тех, кому проще слушать и смотреть

Вроде как всё, спасибо что дочитали!

Господа, дамы, здравствуйте!

Ниже поговорим о контрольной сумме в IP и посмотрим на то, как узлы вычисляют ее. Напомню, что IP не контролирует целостность пользовательских данных, контрольная сумма считается только для заголовка. Поскольку на каждом транзитном узле заголовок пакета изменяется, каждый узел пересчитывает контрольную сумму с учетом внесенных изменений при отправке пакета дальше.

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

Алгоритм расчета контрольной суммы в IP-заголовке

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

1. Заголовок разбивается на слова по 16 бит слева направо.

2. Поле контрольной суммы само равно 16 бит, узел, получивший пакет, для расчета контрольной суммы не должен учитывать значение поля контрольная сумма.

3. Таким образом если у заголовка нет опций, а само поле контрольной суммы мы отбрасываем, то получается 9 слов по шестнадцать бит, в общем виде одно слово будем обзывать буквой W, таким образом у нас есть слова от W0 до W8.

4. Чтобы узнать контрольную сумму мы должны сперва сложить все слова: Wsum = W0+W1+W2+W3+W4+W5+W6+W7+W8. Правило о том, что от перестановки мест слагаемых сумма не меняется здесь тоже работает.

5. Если Wsum получилась размером больше, чем 16 бит, получившееся число разбивается на два слова по 16 бит, которые затем складываются между собой(и так нужно будет повторять до тех пор, пока не получим число 16 бит).

6. И наконец нужно выполнить операцию "исключающего ИЛИ" между шестнадцатеричным числом FFFF и получившимся Wsum. Это и будет контрольная сумма.

Если честно мне никогда не был понятен алгоритм, описанный словами. Поэтому ниже пример.

Рассчитываем контрольную сумму на калькуляторе

Чтобы проверить свои расчет, проще всего сделать дамп пакета, в котором контрольная сумма уже посчитана.

Слева в Wireshark мы видим представление пакетов удобное нам, человекам, а справа мы видим байтовой представление пакетов, где каждый байт представлен числом в шестнадцатеричной системе счисления, минимальное значение одного байта 00(ноль в десятичной), максимальное его значение FF(255 в десятичной), но для расчета нас интересуют слова по два байта.

Если слева нажать на строку Internet Protocol Version 4..., то справа нам подсветятся байты, соответствующие IP-заголовку. Байты я разбил на слова зелеными рамками, красная рамка это поле контрольная сумма и его мы отбросим.

Итого у нас получилась вот такая сумма:

Не забудьте переключить калькулятор в режим HEX, чтобы выполнять вычисления в шестнадцатеричном формате:

Число 287FC в шестнадцатеричной системе счисления занимает места больше, чем 16 бит, а значит надо разбить его на два числа по 16 бит и сложить их, делается это так:

Чтобы записать шестнадцатеричное число 87FE в двоичном виде шестнадцати бит хватит, а значит нам надо сделать FFFF XOR 87FE, здесь XOR это ИСКЛЮЧАЮЩЕЕ ИЛИ, подробнее про операцию можете почитать на вики, мы же сейчас возьмем калькулятор, переведем своё число в двоичный вид и сделаем XOR с двоичным числом 1111111111111111 (в HEX на калькуляторе можно сделать то же самое).

В результате получилась та же контрольная сумма, что и насчитал роутер (7801 в шестнадцатеричном виде):

В общем, ничего сложного нет.

Для самостоятельного расчета

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

Оранжевым выделено поле TTL, его значение изменилось(3c в шестнадцатеричной это 60 в десятичной), красным выделена контрольная сумма, у нее изменился первый байт, все остальные байты заголовка без изменений. Для закрепления алгоритма попробуйте самостоятельно рассчитать контрольную сумму этого заголовка.

Видео версия

Для тех, кому проще смотреть, чем читать.

Господа, дамы, здравствуйте!

Продолжаю серию публикаций про IP, этот пост продолжение предыдущего, ранее мы разобрались как записывать IP-адреса и что они собой представляют, здесь же предлагаю немного попрактиковаться и поработать с CLI Cisco и Huawei.

Настройка IP-адресов на роутере Cisco

Схема, на которой будем тренироваться, довольно простая. На ней подписаны роутеры и адреса с масками, которые нужно настроить на их интерфейсах, если адрес подчеркнут, то на интерфейсе он должен быть основным, остальные вторичные.

Лаба собрана в EVE-NG, если это важно. Начнем с настроек R1, на этом роутере нет конфига, поэтому при запуске IOS предлагает нам выполнить настройки в диалоговом режиме, мы естественно отказываемся:

После отказа роутер выполнил проверку своих интерфейсов и сообщил их статус, а также у нас появилось приглашение ко вводу Router>. Если есть приглашение, значит, мы можем вводить какие-то команды, если приглашение ко вводу заканчивается на знак больше, то значит, мы в EXEC режиме, в этом режиме нам доступно очень ограниченное число команд. Чтобы их все посмотреть, нужно написать знак вопроса и нажать Enter:

Но нам, чтобы выполнить какие-либо настройки, надо перейти сперва в привилегированный режим, а затем в режим конфигурации. Делается это так:

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

Команда configure terminal переводит роутер в режим глобальной конфигурации, приглашение ко вводу снова изменилось. Сначала дадим роутеру имя, чтобы понимать, с каким именно узлом мы работаем (приглашение ко вводу изменится).

У промышленных роутеров, как правило, конфигурации разделены на секции: есть глобальная секция, мы сейчас в ней, есть секция, в которой осуществляются настройки протоколов маршрутизации, например, OSPF или BGP, есть секции, в которых хранятся настройки различных префикс-листов и правил доступа, а есть секция настроек интерфейсов, она нас сейчас и интересует. Перейдем в режим конфигурации интерфейса, который направлен в сторону R2, приглашение ко вводу снова изменится.

Сначала подпишем интерфейс.

Теперь зададим ему основной IP-адрес. При настройке IP-адреса на оборудование маску нужно указывать обязательно.

Примичание: назначать IP-адреса мы должны на канальные интерфейсы, в данном случае интерфейс FastEthernet0/1 представляет собой два уровня: канальный и физический, поэтому и адрес мы будем назначать на него. На роутерах есть возможность создавать на основе физических интерфейсов саб-интерфейсы, саб-интерфейсы относятся только к канальному уровню.

Интерфейс нужно включить. Как правило, роутеры Cisco из коробки идут с выключенными физическими интерфейсами, и их нужно включать, а порты их коммутаторов обычно сразу включены.

Роутер нам сообщит, что интерфейс включился. Команда shutdown выключает интерфейс, ключевое слово no инвертирует действие команды, например, удалить IP-адрес можно так:

Посмотреть текущую настройку интерфейса fa0/1 можно так:

Во-первых, можно использовать сокращения: fa=FastEthernet, sh=show, run=running-config, int=interface. Во-вторых, можно использовать кнопку Tab, если вы не помните, как правильно печатается команда, сработает автодополнение. И в-третьих, ключевое слово do следует использовать только в режиме конфигурации, без него в режиме конфигурации команды просмотра не работают. В EXEC и привилегированном режимах слово do писать перед show не надо.

Чтобы из режима конфигурации интерфейса выйти в режим глобальной конфигурации, нужно написать exit(поднимает на уровень выше), чтобы сразу перейти в привилегированный режим, нужно написать end(всегда выводит полностью из режима конфигурации, вместо end можно использовать сочетание клавиш ctrl+z).

На Fa0/1 настроим вторичный адрес:

О том, что он вторичный говорит ключевое слово secondary, вторичный адрес из той же сети, что и основной. Перейдем на интерфейс Fa0/0 и попробуем на нем настроить IP-адрес из этой же подсети:

Роутер нас предупреждает, что на Fa0/0 мы назначили адрес из подсети, которая настроена на Fa0/1. Если сперва назначить адрес, а потом попытаться включить интерфейс, то адрес будет назначен, но IOS не даст такой интерфейс включить. Вот такое предупреждение будет, если попытаться включить интерфейс с пересечением:

Если сперва включить интерфейс, как в примере, а затем попытаться настроить пересекающийся адрес, то адрес назначен на интерфейс не будет. Важно понимать что один конкретный роутер контролирует пересечение адресации только на своих интерфейсах пересечения с соседями роутером никак не контролируется.

Давайте на Fa0/0 настроим три адреса со схемы, вот его конфигурация:

Основной адрес и один из вторичных здесь из одной подсети второй вторичный адрес из другой подсети. Вот так выглядит итоговая конфигурация Fa0/1:

Некоторые полезные диагностические команды для роутеров Cisco

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

Посмотреть какие основные IP-адреса настроены на интерфейсах можно такой командной (br=brief).

Можно посмотреть детальную информацию по IP параметрам на интерфейсе, в ней будут видны вторичные адреса:

Посмотреть как интерфейсы подписаны можно так (des=description).

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

Посмотреть мак-адрес интерфейса можно вот такой командной, он будет во второй строке (также здесь есть другая мнформация о канальном уровне интерфейса).

Чтобы не смотреть такие длинные портянки, можно пользоваться регулярными выражениями. Например, вот так можно оставить только те строки, в которых встречается последовательность символово add:

Если кто не знал, вертикальная черта перед in называется пайп, после пайпа возможны такие варианты:

В данном случае использовался include, чтобы найти вхождение подстроки в строку. Смысла описывать настройку R2 не вижу, т.к. там меняются IP-адреса, а команды те же.

Настройка IP-адресов на роутере Huawei

Huawei нам не предлагает никаких диалогов, просто предлагает нажать любую кнопку, а затем ввести имя пользователя и пароль, в данном случае используется образ виртуального маршрутизатора AR1000V, логин и пароль по-умолчанию super. При первом входе роутер предложил сменить пароль, я согласился:

У Huawei режим просмотра не делится на Exec и привилегированный, есть режим, в который вы попадаете сразу после подключения к устройству(не знаю как он по-умному называется и, если честно, не интересно, поэтому его я буду называть просто режимом просмотра) и есть режим system-view, в котором есть возможность конфигурирования, а также расширенные команды для диагностики.

Приглашение ко вводу в режиме просмотра обрамлено знаками меньше/больше. Режим system-view прямыми скобками.

Tab и различного рода сокращения в Huawei работают тоже. Давайте настроим:

Командной sysname мы дали имя R3, далее перешли в режим конфигурации интерфейса GigabitEthernet0/0/1, подписали его, затем попробовали включить (у HW логика та же, что и у Cisco, но вместо no используется undo), но роутер сообщил нам, что интерфейс уже включен, видимо, маркетологи Huawei еще не догадались зарабатывать на консольных кабелях, как Cisco.

Далее хочу обратить внимание, что мы настраиваем линк R1 <-> R3, со стороны R1 основной адрес был 10.0.0.1/24, а здесь настаивается 20.0.1.3/24, посмотрим, что из этого выйдет. Когда настраиваются вторичные адреса у Huawei, они отмечаются ключевым словом sub. На этом настройка закончена, в завершении приведена итоговая конфигурация интерфейса. В HW из режима конфигурации не надо использовать никаких ключевых слов для выполнения команд просмотра, вместо show здесь display.

В каком бы контексте конфигурации вы не находились сочетания ctrl+z вас вернет в режим просмотра, а команда quit вернет на уровень выше(аналог exit).

Давайте на роутере Huawei на интерфейсе Gi0/0/0 попробуем настроить адреса из тех же подсетей, что и адреса интерфейса Gi0/0/1.

Как видим основной адрес задать не удалось, только description. Ок, зададим основной адрес из другой подсети. А вторичные попробуем из тех же, что и на Gi0/0/1.

Во-первых, маску при назначении можно задавать одним числом, во-вторых, роутер не дал нам настроить вторичные адреса из тех же подсетей, что есть на интерфейсе Gi0/0/1 и это правильно. Вот корректные настройки:

Команды просмотра для роутеров Huawei

Приведу аналогичные диагностические команды для Huawei. Посмотреть настроенные адреса на интерфейсах можно так:

Посмотреть параметры IP-протокола на интерфейсе так:

Информацию за канальный протокол интерфейса можно посмотреть так:

Регулярные выражения здесь тоже есть:

Посмотреть ARP-таблицу роутера:

Подписи портов можно посмотреть так:

Примечание.

Все настройки, которые были сделаны, нужно сохранить в энергонезависимую память, иначе после перезагрузки роутера он вернется к исходной конфигурации, так как сейчас они есть только в оперативной памяти. На Huawei это делается командой save, на Cisco есть два варианта: write или copy running-config startup-config.

Проверяем работу схемы

Нам осталось убедиться, что все работает, для этого давайте попускаем пинги от R1 к R3, будем явно указывать адрес из-под которого мы будем пинговать, и адрес, который мы будем пинговать.

Пингуем адрес 20.0.0.3 со всех трех адресов интерфейса Cisco, адрес источника назначается ключевым словом source.

Все три пинга успешны. Дабы не занимать время и место просто скажу, что остальные адреса, настроенные, на интерфейсе Huawei тоже пингуются со всех трех адресов роутера R1, которые настроены на интерфейсе в сторону R3.

Вопросы для ваших ответов

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

Предлагаю разобраться с тремя вопросами:

1. Какие адреса или адрес будет использовать роутер Cisco если пинговать ответные адреса Huawei без указания source IP?

2. Какие адреса или адрес будет использовать Huawei, если пинговать ответные адреса Cisco и не указывать source IP?

3. При текущих конфигурациях будут ли пинговаться адреса, настроенные на линке R2/R3 с роутера R1? Почему?

Видео версия

Для тех кому нравится больше смотреть, чем читать вот видео на тему поста: