Настройка Ethernet интерфейсов на сетевых устройствах Cisco

Так, про то, как работать на CISC-ах с Виланами. Давайте обсудим, не с Виланами, с Ethernet-ами, с коммутацией на Ethernet. Давайте это всё и обсудим. Самое первое, что нам понадобится, это работа просто с обычными Ethernet-интерфейсами. Если мы говорим про настройку просто интерфейса Ethernet в CISC-е, то настроек там особо нет. Что на роутерах, что на свичах, настройка самой физики будет состоять фактически из двух параметров. Первый параметр — это то, что в кавычках скорость. Это не скорость, это выбор стандарта. Мы говорим, что у нас будет либо 10 BASE-T, либо 100 BASE-T, либо 1000 BASE-T. Если, например, у нас есть Fast Ethernet 0, мы можем предположить, что это, скорее всего, медный порт, и, скорее всего, медный порт будет 10 на 100, то есть он поддерживает либо 10 BASE-T, либо 100 BASE-T.

И мы выбираем: либо в 10 BASE-T работаем, либо в 100 BASE-T. Это мы не скорость регулируем, это мы стандарт выбираем. Либо мы можем сказать: какой согласуется, такой пусть и работает. Автосогласование — это довольно хорошая штука, которую рекомендуется использовать во всех случаях, когда она у вас корректно работает. Не используйте автосогласование только в одной ситуации — если почему-то у вас это автосогласование работает некорректно. То же самое с дуплексом. Вы можете сказать, что вы хотите использовать либо полный дуплекс, тогда у вас не работает схема CSMA-CD, она у вас выключена. Либо half-дуплекс, тогда у вас схема CSMA-CD включена. Либо автосогласование включить или выключить, в зависимости от того, что нам скажет сосед. Если вы нормально работаете в Ethernet, то я вам рекомендую эти настройки не трогать, они почти всегда работают хорошо.

Авто-авто вас спасёт в подавляющем большинстве ситуаций. В каких случаях имеет смысл трогать эти настройки? Самый простой пример — если вы берёте две железки. У вас на одной железке гигабитный порт и на другой железке гигабитный порт. И вы соединяете их патч-кордом. И в этом патч-корде биты 4, 5, 7, 8 жилок — какие-то из них повреждены. Гигабит на битом проводе завестись не сможет. Но при этом автосогласование работает с помощью LINK-пульсов, Fast LINK-пульсов, и оно работает по 1, 2, 3, 6 жиле. Соответственно, у вас автосогласование сообщает: я поддерживаю гигабит с одной стороны, я поддерживаю гигабит с другой стороны, обе стороны согласуют гигабит, и дальше этот гигабит не работает, потому что не хватает рабочих жил. Если у вас такая ситуация и вы не можете перепроложить провод, вы можете зафиксировать ручками скорость. 100 мегабит или 10 мегабит — те, которые работают по двум парам.

Понятное дело, лучше, конечно, перепроложить провод. Но иногда просто такой возможности нет. Может быть такое, что у вас не работает автосогласование, потому что одна из железок в принципе не умеет работать с автосогласованием. Она только ручками задаёт такие настройки. У меня был случай, когда я работал с VoiceOverIP-железками, Grandstream, кажется, и у них можно было только ручками задать скорость и дуплекс. Не было автосогласования, просто не работало оно. И там приходилось на порту свича жёстко задавать ручками, чтобы это всё работало хорошо. Это исключительно редкая ситуация, когда у вас это не работает автоматически. Поэтому в большинстве ситуаций оставьте это в автомате, оно работает хорошо. Циско-специфичная штука, которая на самом деле такое западло, если вы про это не знаете. Если вы зафиксируете одновременно скорость и дуплекс, у вас выключится автосогласование.

Если есть две железки, одна железка и другая железка, в одной вы говорите авто-авто, а в другой вы говорите 100-full, ручками задаёте обе настройки — и скорость, и дуплекс. Здесь автосогласование выключается, поэтому вы ничего не сообщаете о том, как вы работаете. Сосед в авто-авто спрашивает: как мне поработать-то? Он угадывает ваш стандарт. Он говорит: я буду работать на сотке, потому что он с помощью auto-sensing его услышал. И дальше он говорит: дефолтное значение для сотки — half, и он падает в 100-half. И у вас рассогласование дуплекса, у вас потери кадров идут. Поэтому, чтобы такого не было, не фиксируйте одновременно скорость и дуплекс. Либо, если вы это делаете, тогда фиксируйте и то, и другое с обеих сторон. Потому что если вы фиксируете с одной стороны и скорость, и дуплекс, у вас автосогласование выключается, и сосед не может понять, в каком режиме дуплекса вы работаете.

Может быть, имеет смысл, если вы почему-то вынуждены со своей стороны зафиксировать и то, и другое, а на другую сторону вы не можете повлиять, ставьте хотя бы режим дуплекса half. Почему иногда говорят, что, когда вы провайдеру звоните, и вам говорят: попробуйте, пожалуйста, выставить вручную 10 half, может быть, поможет. Почему рекомендуют 10 мегабит? Потому что на маленькой скорости меньше вероятность того, что у вас ваш чип будет выдавать ошибку. Если там зашумлённый канал или что-то ещё, десятка при прочих равных работает лучше. Она работает на больших расстояниях, она работает с меньшими потерями. 10 BASE-T работает по бельевым верёвкам. Он даже по третьей категории работает, которая 16 МГц вытягивает. Поэтому, когда у вас интерфейс может работать на десятке, а может работать на сотке, сотрудник провайдера, который пытается затраблшутить проблему, предлагает вам понизить скорость до 10 мегабит, именно потому что десятка существенно менее требовательна к качеству линии. Вы переключаетесь в 10 мегабит, и у вас дальнобойность повышается, чувствительность становится лучше, и стабильность канала тоже становится лучше.

Для подавляющего большинства ситуаций 10 мегабит интернета вам будет за глаза хватать. Почему рекомендуют 10 half, а не 10 full? Именно потому что, если вы фиксируете скорость и дуплекс ручками одновременно, то у вас выключается автосогласование. Соответственно, ваш сосед при этом не сможет угадать, в каком режиме дуплекса вы работаете, и он будет работать в half. Поэтому, чтобы у вас не было рассогласования дуплекса, вы со своей стороны тоже фиксируете half. Не надо включать 10 full, надо включать 10 half именно по причине того, что с вашей стороны автосогласование при этом выключится. Если вы работаете в предприятии, ручками 10 half для проверки можно, конечно, поставить, посмотреть, к чему это приведёт, но стабильно в таком режиме работать не надо. Если вы понимаете, что у вас здесь десятка работает хорошо, а сотка работает не очень хорошо, перепроложите провод. В предприятии это всегда сделать можно. Не ленитесь.

Если провайдер может себе позволить сказать: включите 10 half, вам всё равно же, у вас там тариф 5 мегабит, поэтому будет оно в 10 мегабитах half работать, всё равно хватит. В предприятии такой подход неприемлем. На уровне канальном, что можно понастраивать? Фактически только MAC-адрес и только на тех устройствах, где MAC-адрес в принципе существует. На свичах, например, MAC-адрес вы поменять не можете. А на роутерах на интерфейсе есть MAC-адрес, его можно задать ручками. MAC-адрес, пробел и дальше указывайте желаемый MAC-адрес в фирменной цисковской форме. На роутерах также можно задать MTU. Если вы хотите включить джамбо-фреймы, вы должны включить их на всех устройствах в широковещательном домене. И, соответственно, роутер, дальше MTU, и вы задаёте диапазон, который вам будет допустим. Может быть такое, что вы будете ограничены какими-то цифрами, которые будут отличны от того, что здесь на слайде нарисовано.

Иногда бывает такое, что вы можете повысить MTU относительно 1500, дальше вверх, как на слайде нарисовано. Иногда бывает такое, что вы можете только понизить MTU. Вы не можете задать 1501 или 9000. Вы можете сказать: с 576 до 1500 вам дают размер. Не всегда игра MTU позволит вам увеличить максимальный размер кадра, который вы увидите в канале. Это зависит от конкретной железки. На свичах тоже можно играть MTU, но, как правило, на свичах, цисковских каталистах, вы можете не на уровне интерфейса задать максимальный размер кадра, а на уровне всей системы целиком. Там команда будет в глобальном конфиге — system MTU, и она задаётся отдельно для 10 и 100 мегабитных интерфейсов и для гигабита. Если мне память не изменяет, system MTU просто цифра — это для 10/100. Если system MTU jumbo — то это для гигабита. Там две цифры вы должны будете задавать. Далее.

На каждом интерфейсе у вас вот эта табличка Show Interface. Мы говорили уже про самую первую строчку, что она говорит, что интерфейс в AP, канальный уровень в AP. Мы уже готовы к тому, чтобы посмотреть на следующую строчку. И здесь мы будем видеть следующее. Во-первых, показывает, что за интерфейс у нас — Fast Ethernet. Это намёк на то, что интерфейс у нас раскачивается до 100 мегабит. Это тот MAC-адрес, который по факту сейчас используется. Если мы его не переопределили, он такой же, как на заводе. Если мы его переопределили, то BIA, Burned-In Address — это тот, который на заводе. Это Local Administered Address, а это тот, который заводской BIA. Дальше. MTU. Понятно, это какого размера кадр вы разрешаете отправлять и принимать на этом интерфейсе. Не просто отправлять или не просто принимать, а и отправлять, и принимать. Если указываете, что максимальный размер вложения в кадр 1500 байт, вы не разрешаете отправлять кадры с большим вложением, вы не разрешаете принимать кадры с большим вложением.

Если придёт кадр с вложением 1501–1502 байта, это будет для вас ошибка. Вы в счётчиках увеличите размер счётчиков с ошибками, кадр такой отбросите. У CISC эта концепция MTU, она, откровенно говоря, ошибочная. Из-за того, что CISC в своё время по-дурацки эту штуку сделала, нам приходится сейчас жутко ломать голову. Что такое MTU и как она работает. Дело в том, что в Ethernet-е нет такого термина MTU. Есть поле MAC client data. И оно имеет минимальный и максимальный размер — с 46 по 1500 байт. По факту значение MTU и то, что можно на предыдущем слайде задать, это как раз ограничение сверху на максимальный размер поля MAC client data.

Отдельно к этому есть ещё заголовок Ethernet-а, отдельно к этому есть ещё чек-сумма, отдельно к этому есть ещё преамбула. И фактически есть помимо MAC client data ещё 18 байт заголовков. Поэтому, когда мы говорим, что у нас есть полезные данные, которые можно вложить, — это самое MTU, это полезные данные, которые мы можем положить в кадр. Но при этом есть ещё 18 служебных байт, которые в любом случае передаваться будут должны. И мы, задавая размер полезных данных, фактически задаём максимальный размер кадра целиком — 1518 байт. При этом вы должны будете также знать, что есть другие линейки Cisco. В первую очередь это XR-линейка, у которой такая же команда MTU в том же самом месте, в точно такой же настройке интерфейса, но она задаёт сразу готовый размер кадра — уже не максимальный размер полезного вложения, а максимальный размер кадра целиком вместе с заголовком. Есть другие линейки, тоже цисковские и в том числе не цисковские, которые задают максимальный размер кадра, но без, например, чек-суммы — 1514 байт, если говорить про значение по умолчанию.

Поэтому имейте в виду: с термином MTU применительно к Ethernet-у бардак, в том числе и потому, что такого термина в стандарте просто нет. Нету такого термина MTU в Ethernet-е, вообще никак, совсем нету. Есть поле MAC client data, у которого есть ограничение на 1500 байт сверху. Более того, некоторые технологии, которые будут использоваться поверх, будут увеличивать максимальный размер кадра. Например, 802.1Q увеличивает на 4 байта кадр, и у нас получается 1522 байта вместе с заголовками. При этом MAC client data как бы не трогается. Формально, поэтому если вы включаете 802.1Q, вам команду MTU вводить не надо. Она как была 1500 байт полезной нагрузкой, так и остается. Дополнительно к ней 4 байта 802.1Q заголовка, дополнительно к ней 18 байт заголовка обычного Ethernet-а. В итоге получается 1522 байта. Оно само работает. Вам не надо ничего ручками разрешать побольше отправлять. Оно само разрешается. Но при этом, если вы будете

какие-то другие заголовки добавлять, не 802.1Q, а, например, есть такая штука Q-in-Q, провайдерская тема, когда вы 2 802.1Q заголовка добавляете. Там уже надо будет ручками добавлять место под этот второй 802.1Q заголовок. Cisco сама его не разрешает. Или, например, вы MPLS будете включать. Там тоже фактически добавляется еще один заголовок, который к максимальному размеру полезных данных будет добавлять еще 4 байта. Поэтому, если добавляете дополнительные заголовки, вам, возможно, нужно будет с MTU поиграть. Но, опять же, если вы не провайдер, если вы не включаете эти дополнительные заголовки, какие-то хитрые, кривые, косые, то вас это не особо сильно касается. Но если вдруг будет касаться, команда эта есть. Далее. MTU разобрались. BW — вполне очевидно. Это то,

на какой скорости оно по факту прямо сейчас работает. То, что у нас интерфейс теоретически может на 100 мегабитах работать, не означает, что он прямо сейчас на 100 мегабитах работает. Вот этот конкретный интерфейс работает действительно на 100 мегабитах. Вот эта штука — это приблизительная задержка сериализации. Когда у вас есть интерфейс, и на этом интерфейсе у нас есть шланг, по которому могут отправляться данные. Перед этим шлангом стоит выходной буфер. И кадры, которые попадают в этот выходной буфер, они разбиваются на отдельные битики и отправляются по сети в виде нуликов и единичек. Есть определенная задержка, которая требуется в любом случае для того, чтобы кадр, который попадает в исходящий буфер, сначала должен попасть в этот буфер, а потом он побьется на части и будет отправляться по сети. Вот эта задержка — это она и есть. Задержка сериализации. Это не означает, что кадр, который проходит через этот интерфейс, точно, гарантированно испытывает ровно такую задержку.

Это означает, что задержка меньше, чем это значение, быть точно не может. А дополнительно к нему могут быть еще другие задержки на принятие коммутационного решения или маршрутизационного решения или какого-то еще решения, всякие шейпинги, полисинги. Все это требует также времени. И это время будет суммироваться с задержкой. Меньше, чем эта задержка, быть в принципе технически не может. Но вы гипотетически можете поменять это значение. Оно чисто информационное, оно по умолчанию берется в качестве задержки сериализации. Но если вы хотите, вы можете его переопределить. Вы можете сказать: я своей администраторской волей хочу, чтобы здесь показывалась цифра не 100 микросекунд, а 1 секунда. Имею право. Это не значит, что у вас как-то пакеты будут иначе бегать. Это просто чисто информационная циферка, на которую некоторые протоколы могут обращать внимание для того, чтобы принимать какие-то свои решения. Но она не участвует в процессе обработки трафика. Это чисто информационная цифра для каких-то подсчетов.

Равно на самом деле и вот эта штука. Если вы хотите, вы можете сказать, что у вас есть интерфейс, называется Fast Ethernet. Он прямо сейчас работает на 100 мегабитах, но вы можете прямо сейчас сказать, что этот интерфейс 1 мегабит. И это не означает, что интерфейс по факту будет работать как-то иначе. Он работает на 100 мегабитах, он ровно на 100 мегабитах работает. Он на физике на такой скорости работает. Он не умеет иначе работать. Но вы можете сказать, что для каких-то подсчетов, для своей бухгалтерии мы считаем, что этот интерфейс будет мегабитный. Может быть, кто-то когда-то с бухгалтерией связывался. Есть бухгалтерский учет, есть управленческий учет. Бухгалтерия — это то, что мы показываем государству, сколько мы денег заработали. А управленческий учет — это то, что мы на самом деле посчитали. Вот это, соответственно, бухгалтерский учет. Что мы хотим задекларировать, условно говоря. Не то, что на самом деле там будет. А управленческий учет — это с какой скоростью он на самом деле работает, с какой задержкой.

Это могут быть вообще никак не связанные вещи. Далее. Я думаю, вы догадываетесь, что вот это такое и вот это такое. Это настоящая скорость и настоящий дуплекс. Счетчики за последние пять минут. Сколько бит за последнюю секунду пробежало? Точнее, нет. Сколько бит пробежало за последние пять минут, разделенные на 300, потому что в пяти минутах 300 секунд. Мы берем и в некоторый счетчик складываем все биты, которые пробежали за последние пять минут, и делим на 300. И получаем среднюю скорость в секунду за последние 300 секунд. То же самое на выход. Это input rate, это output rate. Биты в секунду и пакеты в секунду. Далее. Если вдруг вы когда-нибудь будете читать вот эту табличку, которая там есть,

в продолжении этой таблички здесь много-много всяких счетчиков. То, что здесь есть, не счетчиковая часть, мы как раз видели на предыдущем слайде. Здесь много всяких циферок. Эти циферки страшные, ужасные, пугающие, но на самом деле в них ничего особо ужасного нет. Я вам здесь табличку привел. Если хотите, можете себе куда-нибудь скопировать. Но, в принципе, она вся есть на сайте Cisco. Здесь нас будут интересовать input queue. Давайте сейчас попробую это показать. Где она есть? Вот она. Input queue и output queue. Input вот это. Output вот это. Это циферки следующие. Когда приходят пакеты, адресованные самому устройству, они будут обрабатываться некой входящей очередью. У нас будет вытаскивалка из входящего буфера пакетов, которые адресованы самому устройству, не предназначенных для транзита. Размер очереди для собственных пакетов будет ограничен неким числом.

Это число 75. Это максимальный размер пакетов, которые мы можем для себя выдергивать одновременно из очереди. Сколько мы по факту прямо сейчас пакетов для себя храним в этой очереди? Ноль. Нисколько. Если вдруг вы видите, что у вас в этих цифрах после 0/75 или чего-то там еще начинаются какие-то счетчики расти, то есть здесь вместо 0/0 будут какие-то другие цифры, это значит, что пакеты, которые идут специально именно для вашего собственного устройства, не помещаются в очередь, и они дропаются по принципу tail drop. Output queue особо можно не смотреть, потому что в ней всегда место есть. Далее. После первой части есть вторая часть, которая не поместилась на предыдущем слайде, здесь чисто счетчики. Вот это общее количество пакетов за всю историю наблюдений, которые мы получили, и сколько там было байтов. Тут, понятное дело, если у вас долго работает железка,

и на ней сильно загруженный интерфейс, цифры могут быть достаточно заметны. Сколько среди всего этого количества пакетов было бродкастов, и среди них распознанных мультикастов? Сколько кадров Ethernet было слишком маленьких? У нас кадр в Ethernet не может быть меньше, чем 64 байта. Если кадр пришел, и он 60 байт, это неправильный, невозможный кадр, и, соответственно, если он пришел, сначала среда свободная, потом прибежало 60 байт, и снова среда освободилась. Это кадр невалидный, он не может быть таким. Соответственно, он расценивается как ошибка, и кадр-огрызок, это runt, он в счетчик соответствующий попадает. То же самое. Может быть такое, что среда была свободна, потом начинает что-то передаваться, передаются нули и единички, пробежало 1600 байт, и среда снова освободилась. Кадр не может быть 1600 байт, если мы не включали MTU повышенный, поэтому кадры, которые были больше, чем 1518 байт,

записываются в Giants. Общее количество ошибок на порту, которое было на приеме, записывается в Input Errors. Из них может быть такое, что у нас есть какие-то кадры, у которых не сошлась чек-сумма, либо вследствие коллизии, либо вследствие какой-то наводки, либо вследствие чего-то еще. Может быть такое, что у нас есть какие-то кадры, у которых количество бит не было кратно байту. У нас традиционно байт 8-битовый. И когда мы передаем какие-то кадры, они у нас обязаны состоять из байтов. Не может быть такого, что к нам прибежал кадр, а он 65 513 бит длиной. Не может быть такого, потому что у нас количество бит не делится на 8, следовательно, кадр не кратен байту. Если у нас такое прибежало, то растет счетчик frame. Ошибка фрейминга — это ошибка выравнивания по границе бита. И чек-сумма там тоже обязательно не сойдется. Далее. Сколько было мультикастов, сколько было кадров pause.

Если вы не используете паузу, там, скорее всего, по нулям будет. И сколько кадров не влезло в очередь, то есть пришлось их дропать, потому что у вас не хватило буферов на вход. Оно уже дублируется здесь. На выход. Сколько пакетов кадров отправили на выход, сколько они занимали байт, и сколько раз у нас случилась коллизия из-за того, что мы пытались что-то отправить, а нам навстречу что-то пробежало. В нормальной ситуации коллизии у вас быть не должно вообще. И может быть такое, что у вас будет несовпадение дуплексов. С одной стороны у вас есть узел с полным дуплексом, с другой стороны с half-дуплексом. Тот, который с полным дуплексом, фигачит кадры, и навстречу ему прибежит какой-нибудь half-дуплексный кадр, соответственно, для него это не проблема. Full-дуплексный сосед спокойно себя будет чувствовать. Half-дуплексный сосед может что-то отправлять и принимать в этот момент от full-дуплексного соседа, и он в этом случае будет объявлять коллизию.

Он будет говорить, у нас collision возник, событие коллизии. И может быть такое, что half-дуплексный сосед начал что-то отправлять, отправил там 100 байт, и после чего прилетел какой-то кадр от соседа full-дуплексного. Следовательно, коллизия возникла после передачи первых 64 байтов. Это событие невозможно при стандартном взаимодействии Ethernet-а, потому что коллизия не может произойти после первых 64 байтов. Но если у вас несовпадение дуплексов, то она может произойти, и тогда у вас будет расти вот такой счетчик. Late collision. Если вы работаете с Ethernet-ом, если вы видите late collision, то это либо вы протянули общую шину длиной больше 5 километров, что вряд ли, либо у вас несовпадение дуплексов, что существенно более вероятно. Эти ошибки имеют смысл смотреть. А non-protocol drop — это пришел какой-то кадр, который вы не можете прочитать. Ваш роутер получил кадр,

и в нем написано, что внутри лежит что-то для него непонятное. Здесь кратенько, опять же, кратенько минут на 40, расшифровка всего того, что я уже вам расшифровал. Если захотите, можете где-нибудь эту табличку посмотреть на сайте Cisco. Что делать, если ничего не работает? Проверяем сначала физику. Если у нас где-то побился провод, то у нас не будет линка. Проверяем, что линк горит. Проверяем, что согласование сработало корректно, что у нас скорости и дуплексы выставлены одинаковые. Проверяем, что не зафиксированы где-нибудь и скорость, и дуплекс, потому что это выключает согласование. Как следствие, у нас может, если мы выключили, задали ручками скорость и дуплекс с одной стороны, с другой стороны некорректно угадаться дуплекс. Проверяем, что скорость согласовалась правильная, которая по факту

может эксплуатироваться на нашей линии. Может быть такое, что на конкретном проводе гигабит не работает, а 100 мегабит работает. Или 100 мегабит не работает, 10 мегабит работает. Чем больше скорость, тем меньше у вас времени передается отдельный битик, тем больше вероятность того, что если какая-то помеха прошла, то битик испортится. Тем хуже у вас будет соотношение сигнал-шум, тем больше будет кадров с ошибкой чек-суммы. Если вы видите, что чек-суммы пробегают слишком часто неверные, соответствующий счетчик растет, снижайте скорость или протягивайте заново провод. Проверяйте дуплекс. Они должны быть одинаковые. И в современном мире они обязаны быть полным дуплексом, потому что half-duplex сегодня нигде вы не встретите. Если вы выставили полный дуплекс, то никаких коллизий, ни late collision, ни просто collision у вас быть не может. Если вы видите коллизии, растущие на интерфейсе, значит, у вас включен механизм обнаружения коллизий, значит, там работает half-duplex, значит, что-то пошло не по плану. Это ошибка в современном мире.

Если у вас среда с общей шиной вдруг каким-то образом возникла, проверяйте отсутствие петель. Если вы вдруг в коаксиал замкнули кольцо или в хабе взяли два провода, протянули между двумя портами хаба, то работать просто на электрическом уровне не будет. На канальном уровне проверяем MTU. Если у вас есть широковещательный домен, то все узлы в широковещательном домене должны, обязаны иметь одинаковое MTU. Если вы где-то трогали MTU и сделали его больше, чем 1500, то убедитесь, что вы сделали его везде одинаковым. И на всех транзитных коммутаторах кадры с таким большим MTU должны обрабатываться. Их MTU должен быть как минимум не меньше. Если где-то у вас в сети транзитный коммутатор не будет пропускать большие кадры,

сами понимаете, они будут дропаться, и у вас кадры ходить не будут. Как проверить, что с MTU проблема? Есть характерные признаки, по которым это можно почти сразу угадать. Если у вас, например, есть какой-нибудь протокол доступа к файлам, типа SMB или FTP, или что-то в этом духе, то вы, как правило, с маленьким MTU можете получить листинг файлов. Вы можете зайти на, условно говоря, на расшаренную папку и посмотреть, что за файлы там лежат. И вы увидите список файлов. Но как только вы начнете пытаться скачать эти файлы, у вас будут зависать соединения, и рано или поздно оно будет отваливаться с ошибкой. Потому что сами файлы будут передаваться по SMB в больших пакетах, и они будут дропаться, если у вас несовпадение MTU. Проверяйте уникальность MAC-ов. MAC-адреса обязаны быть уникальны, с завода они таковые идут, но если вы где-то поменяли MAC-адреса, то, возможно, вы получите такое, что MAC-и где-то вы руками поставили одинаковые,

и, как следствие, это будет вызывать проблемы. Может быть такое, что если вы купили какие-то устройства у недорогого производителя, то два устройства будут иметь одинаковый MAC с завода. Такое бывает, редко, но бывает. Если вдруг у вас есть подозрение на такую вещь, то проверяйте, что MAC-и у вас не пересекаются. И немножко забегая вперед, убедитесь в отсутствии петель, если вы используете коммутаторы. Как правило, если петля в Ethernet возникает, то это проявляется в том, что сеть у вас практически перестает работать везде. Мы на ICD2 будем говорить про это, про то, как бороться с петлями. Так, далее. Что у нас еще есть? У нас есть механизм проверки того, как работает Ethernet. Если говорить именно про Cisco, то на Cisco есть довольно удобный протокол, который называется CDP, Cisco Discovery Protocol. Он замечателен тем, что он не требует никакой настройки. Завелся канал,

Ethernet завелся, если вы просто воткнули разъем, он сразу там заводится, никакой настройки не требуется. Так вот, CDP тоже не требует никакой настройки. Он будет просто работать, он будет рассылать кадры на всех интерфейсах, где он включен, и он будет показывать, на каких интерфейсах он эти самые CDP-шные кадры поймал. Очень удобная штука для диагностики и для построения карты сети. Если вдруг вам досталась в наследство сеть, которая непонятно как построена, никакой карты, ничего нет, CDP для этих целей можно будет использовать. Он работает следующим образом. Он отправляет кадры на специальный мультикастовый адрес. 0100.0CCC.CCCC. Обратите, пожалуйста, внимание на то, что этот MAC-адрес именно мультикастовый, у него самый младший бит, выставленный в единичку в первом байте. И этот самый OUI, Organizational Unique Identifier, это будет 00000C. Этот 00000C нам еще неоднократно сегодня будет встречаться, и сегодня, и завтра, и в ближайшие две недели.

И это OUI компании Cisco. И эта штука, это Vendor Assigned ID, просто он для красоты такой выбран. Если вдруг вам интересно, эти CDP-шные кадры отправляются в инкапсуляции 802.3, они используют LLC-расположение и SNAP-расположение, там трехбайтовый код производителя протокола, и здесь мы видим опять 00000C, и двухбайтовый код самого протокола 2000. Это запоминать не надо, просто любопытный момент, что конкретно этот протокол использует не EtherType-расположение, а 802.3. Далее. CDP хорош тем, что просто включили — он работает. И вы сразу видите всех соседей, которые поддерживают CDP на своих железках. Допустим, есть у вас два свича, которые соединены между собой проводом,

первый свич и второй свич, и они просто соединены проводом. Вы отправляете CDP-шные кадры на одном порту, и они принимаются на другом порту. Возможно, там отправляются в ответ, нас сейчас не сильно интересует. Вы просто сразу на этом свиче видите, кто отправляет такие кадры. Этот самый мультикастовый MAC, он специальный, специфический, и Cisco, понимая, что это свой цисковский протокол, дальше такие кадры не форвардят, они их пожирают сами, и даже несмотря на то, что они теоретически могли бы дальше их разбросать, они этого не делают. Они на порту приняли такой кадр от коммутатора А, коммутатор Б принял кадр, он записал в табличку, что на каком-то порту я вижу соседа А, дальше он информацию о том, что он видит А, не передает. Вместо этого он передает свои собственные CDP-шные кадры на каждом порту. Он их не форвардит, он их пожирает, терминирует, и дальше на всех остальных портах сам отправляет кадры CDP-шные, но уже свои собственные, другие кадры.

Внутри CDP-шных кадров передается куча всякой разной диагностической информации. Рассказывается про то, что это за узел, роутер, свитч, телефон, что за операционная система используется с точным номером версии. Немножко рассказывается про топологию сети, каким портом это отправлено. Поэтому если вдруг эта информация попадает в руки хакеру, он из этого может извлечь довольно много полезного для себя и вредного для вас. Поэтому в реальной сети CDP рекомендуется выключать в целях безопасности. Зачем он нужен, если вдруг хакер его перехватит, он может получить много информации, что облегчит ему жизнь. Мы не хотим хакерам облегчать жизнь, мы хотим выключать CDP. Тем более, что для нормальной работы он, в принципе, не сильно нужен. Надо понимать, что CDP — это протокол фирменный, цисковский, поддерживает его полторы компании, поэтому если у вас сеть не на Cisco, то и выключать вам особо нечего. CDP будет работать очень простым образом.

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

информацию о соседе тоже выкидываете, и у вас сосед из этой таблички пропадает. Вся суть протокола CDP в том, что вы ведете табличку соседей. И в этой табличке сразу видно, кто вам отправляет, каким интерфейсом, самые CDP-шные кадры, кто живой, кто не живой. Очень простенький, но при этом довольно удобный протокол. Если у вас все отправляется хорошо, все доставляется хорошо, то в табличке соседей всегда актуальна информация о том, какие соседи есть, каких нет. Вы можете настроить как то, с какой частотой отправлять кадры, так и то, какой срок годности будет в ваших кадрах, которые вы отправляете в сторону ваших соседей. Обратите внимание, срок годности задаете вы. Вы указываете соседям, в течение какого времени им следует хранить информацию о вас. Как это включается? По умолчанию на роутерах и свичах Cisco, линейки Cisco IOS,

эта штука включена. Ее не надо включать в явном виде, она и так работает. Если вдруг вы будете работать, допустим, с Cisco IOS XE, то там надо включить это в явном виде. cdp run — это включить сам сервис CDP. И, понятно, no cdp run — выключить его совсем. И если он у вас работает, в глобальном конфиге можно задать таймеры. cdp timer и cdp holdtime. Timer — это как часто отправлять, holdtime — это срок годности. Минимальное значение, которое можно выставить, это пятерку для таймера или десятку для holdtime. В лабораторных сценариях мы будем как раз выставлять минимальное значение 5 на 10. В реальной сети не надо никакие таймеры выставлять, надо выставлять no cdp run и выключать его совсем. Есть несколько исключений. Когда CDP может быть полезен? Во-первых, если вы собираетесь построить карту сети, потому что вы пришли в компанию и вы не знаете, как устроена сеть, вам интересно, кто на кого каким портом смотрит. И второй случай, когда CDP может быть полезен,

это если у вас есть Cisco телефоны. Cisco IP-телефоны, они будут часть настроек получать через Call Manager, а часть настроек получать по CDP. Поэтому в некоторых случаях CDP будет полезен. Но если у вас не используются Cisco свитчи, не используются Cisco телефоны, то выключайте его, он ничем вам не поможет. Можно запретить или разрешить использование CDP на отдельном интерфейсе. По умолчанию на всех интерфейсах CDP разрешён, поэтому по факту полезно будет его выключить на интерфейсе. Это no CDP enable. Или отменить запрет использования — просто CDP enable. Полезно в ситуации, когда у вас есть свитч, на нём 48 портов, и к одному из них подключен Cisco телефон. Такой Cisco телефон, как мог, так нарисовал. И вы хотите здесь, здесь, здесь, здесь, здесь выключить CDP, а на этом порту оставить.

Тогда вы говорите: на этих всех no CDP enable, а на этом оставить CDP enable. И глобальный сервис CDP run тоже вам придётся оставить. Нельзя сделать так, чтобы по умолчанию он был выключен на всех портах, кроме одного. Надо в явном виде выключить на тех портах, на которых не нужен. Табличка соседей будет выглядеть следующим образом. Есть команда show CDP neighbors, которая покажет, какие соседи у вас есть, какими интерфейсами вы их видите, какими интерфейсами они посылают кадры CDP-шные вам, какой срок годности, то есть hold time, и кто они. В нашем случае есть железка, которая называется switch. Я просто знаю, что это за топология была, поэтому я знаю, что это одна и та же железка с названием switch, которая двумя портами посылала информацию нам. И гигабитом 0/0, и гигабитом 0/1. Выглядело это вот так. Гигабит 0/0, гигабит 0/1. И здесь то же самое. Гигабит 0/1.

Здесь 0/0, гигабит 0/1. И это — это мы, а это — железка с названием switch. И мы получаем на двух разных интерфейсах, и на гигабите 0/0, и на гигабите 0/1, информацию о том, что у нас есть сосед с хостнеймом switch. Мы не можем сказать, что это точно один и тот же сосед только по названию, но я просто вам говорю, что именно в этой ситуации это так и было. Оно нам посылало свои кадры гигабитом 0/1, гигабитом 0/0. Это Port ID, это каким портом оно нам послало. Local Interface — это каким портом мы это поймали. И Capability — это что оно заявило, что оно умеет. R — это то, что оно в принципе теоретически может выполнять задачи маршрутизации. Действительно, свитчи цисковские могут быть и роутерами тоже.

S — это то, что оно теоретически может коммутировать трафик. Действительно, свитчи цисковские могут коммутировать трафик. И буковка I означает, что оно умеет работать с протоколом подслушивания мультикаста IGMP. Internet Group Membership Protocol. Действительно, он, наверное, может. Если вдруг вам интересно, что точно это за железки, например, посмотреть версию IOS или что-то ещё, есть команда show cdp neighbors detail или show cdp, дальше вы указываете название железки, которая вас интересует, например, switch, и оно расскажет детально про каждую железку, что она знает. В нашем случае мы видим, что это Cisco, что это Cisco IOS XE, судя по всему, 3850-й свитч. Когда был IOS компилирован, какая точная версия XE. Довольно много информации. И если вдруг атакующий такой кадр сможет перехватить, то он может, например,

зная, что именно в этой версии IOS есть какая-то определённая уязвимость, эту уязвимость проэксплуатировать. Поэтому CDP на обычных абонентах точно надо выключать. Исключение — телефон, если у вас телефон Cisco. Так.