Сети для самых маленьких. Часть четвертая. STP

I think that I shall never see
A graph more lovely than a tree.
A tree whose crucial propertyеу
Is loop-free connectivity.
A tree that must be sure to span
So packets can reach every LAN.
First, the root must be selected.
By ID, it is elected.
Least-cost paths from root are traced.
In the tree, these paths are placed.
A mesh is made by folks like me,
Then bridges find a spanning tree.

— Radia Joy Perlman

В прошлом выпуске мы остановились на статической маршрутизации. Теперь надо сделать шаг в сторону и обсудить вопрос стабильности нашей сети.
Дело в том, что однажды, когда вы — единственный сетевой админ фирмы “Лифт ми Ап” — отпросились на полдня раньше, вдруг упала связь с серверами, и директора не получили несколько важных писем. После короткой, но ощутимой взбучки вы идёте разбираться, в чём дело, а оказалось, по чьей-то неосторожности выпал из разъёма кабель, ведущий к коммутатору в серверной. Небольшая проблема, которую вы могли исправить за две минуты, и даже вообще избежать, существенно сказалась на вашем доходе в этом месяце и возможностях роста.

Итак, сегодня обсуждаем:

  • проблему широковещательного шторма
  • работу и настройку протокола STP и его модификаций (RSTP, MSTP, PVST, PVST+)
  • технологию агрегации интерфейсов и перераспределения нагрузки между ними
  • некоторые вопросы стабильности и безопасности
  • как изменить схему существующей сети, чтобы всем было хорошо




Оборудование, работающее на втором уровне модели OSI (коммутатор), должно выполнять 3 функции: запоминание адресов, перенаправление (коммутация) пакетов, защита от петель в сети. Разберем по пунктам каждую функцию.

Запоминание адресов и перенаправление пакетов: Как мы уже говорили ранее, у каждого свича есть таблица сопоставления MAC-адресов и портов (aka CAM-table — Content Addressable Memory Table). Когда устройство, подключенное к свичу, посылает кадр в сеть, свич смотрит MAC-адрес отправителя и порт, откуда получен кадр, и добавляет эту информацию в свою таблицу. Далее он должен передать кадр получателю, адрес которого указан в кадре. По идее, информацию о порте, куда нужно отправить кадр, он берёт из этой же CAM-таблицы. Но, предположим, что свич только что включили (таблица пуста), и он понятия не имеет, в какой из его портов подключен получатель. В этом случае он отправляет полученный кадр во все свои порты, кроме того, откуда он был принят. Все конечные устройства, получив этот кадр, смотрят MAC-адрес получателя, и, если он адресован не им, отбрасывают его. Устройство-получатель отвечает отправителю, а в поле отправителя ставит свой адрес, и вот свич уже знает, что такой-то адрес находится на таком-то порту (вносит запись в таблицу), и в следующий раз уже будет переправлять кадры, адресованные этому устройству, только в этот порт. Чтобы посмотреть содержимое CAM-таблицы, используется команда show mac address-table. Однажды попав в таблицу, информация не остаётся там пожизненно, содержимое постоянно обновляется и если к определенному mac-адресу не обращались 300 секунд (по умолчанию), запись о нем удаляется.
Тут всё должно быть понятно. Но зачем защита от петель? И что это вообще такое?

Широковещательный шторм

Часто, для обеспечения стабильности работы сети в случае проблем со связью между свичами (выход порта из строя, обрыв провода), используют избыточные линки (redundant links) — дополнительные соединения. Идея простая — если между свичами по какой-то причине не работает один линк, используем запасной. Вроде все правильно, но представим себе такую ситуацию: два свича соединены двумя проводами (пусть будет, что у них соединены fa0/1 и fa0/24).


Одной из их подопечных — рабочих станций (например, ПК1) вдруг приспичило послать широковещательный кадр (например, ARP-запрос). Раз широковещательный, шлем во все порты, кроме того, с которого получили.


Второй свич получает кадр в два порта, видит, что он широковещательный, и тоже шлет во все порты, но уже, получается, и обратно в те, с которых получил (кадр из fa0/24 шлет в fa0/1, и наоборот).


Первый свич поступает точно также, и в итоге мы получаем широковещательный шторм (broadcast storm), который намертво блокирует работу сети, ведь свичи теперь только и занимаются тем, что шлют друг другу один и тот же кадр.


Как можно избежать этого? Ведь мы, с одной стороны, не хотим штормов в сети, а с другой, хотим повысить ее отказоустойчивость с помощью избыточных соединений? Тут на помощь нам приходит STP (Spanning Tree Protocol)

STP

Основная задача STP — предотвратить появление петель на втором уровне. Как это сделать? Да просто отрубить все избыточные линки, пока они нам не понадобятся. Тут уже сразу возникает много вопросов: какой линк из двух (или трех-четырех) отрубить? Как определить, что основной линк упал, и пора включать запасной? Как понять, что в сети образовалась петля? Чтобы ответить на эти вопросы, нужно разобраться, как работает STP.

STP использует алгоритм STA (Spanning Tree Algorithm), результатом работы которого является граф в виде дерева (связный и без простых циклов)

Для обмена информацией между собой свичи используют специальные пакеты, так называемые BPDU (Bridge Protocol Data Units). BPDU бывают двух видов: конфигурационные (Configuration BPDU) и панические “ААА, топология поменялась!” TCN (Topology Change Notification BPDU). Первые регулярно рассылаются корневым свичом (и ретранслируются остальными) и используются для построения топологии, вторые, как понятно из названия, отсылаются в случае изменения топологии сети (проще говоря, подключении\отключении свича). Конфигурационные BPDU содержат несколько полей, остановимся на самых важных:
  • идентификатор отправителя (Bridge ID)
  • идентификатор корневого свича (Root Bridge ID)
  • идентификатор порта, из которого отправлен данный пакет (Port ID)
  • стоимость маршрута до корневого свича (Root Path Cost)
Что все это такое и зачем оно нужно, объясню чуть ниже. Так как устройства не знают и не хотят знать своих соседей, никаких отношений (смежности/соседства) они друг с другом не устанавливают. Они шлют BPDU из всех работающих портов на мультикастовый ethernet-адрес 01-80-c2-00-00-00 (по умолчанию каждые 2 секунды), который прослушивают все свичи с включенным STP.

Итак, как же формируется топология без петель?

Сначала выбирается так называемый корневой мост/свич (root bridge). Это устройство, которое STP считает точкой отсчета, центром сети; все дерево STP сходится к нему. Выбор базируется на таком понятии, как идентификатор свича (Bridge ID). Bridge ID это число длиной 8 байт, которое состоит из Bridge Priority (приоритет, от 0 до 65535, по умолчанию 32768+номер vlan или инстанс MSTP, в зависимости от реализации протокола), и MAC-адреса устройства. В начале выборов каждый коммутатор считает себя корневым, о чем и заявляет всем остальным с помощью BPDU, в котором представляет свой идентификатор как ID корневого свича. При этом, если он получает BPDU с меньшим Bridge ID, он перестает хвастаться своим и покорно начинает анонсировать полученный Bridge ID в качестве корневого. В итоге, корневым оказывается тот свич, чей Bridge ID меньше всех.

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

Роли портов

После того, как коммутаторы померились айдями и выбрали root bridge, каждый из остальных свичей должен найти один, и только один порт, который будет вести к корневому свичу. Такой порт называется корневым портом (Root port). Чтобы понять, какой порт лучше использовать, каждый некорневой свич определяет стоимость маршрута от каждого своего порта до корневого свича. Эта стоимость определяется суммой стоимостей всех линков, которые нужно пройти кадру, чтобы дойти до корневого свича. В свою очередь, стоимость линка определяется просто- по его скорости (чем выше скорость, тем меньше стоимость). Процесс определения стоимости маршрута связан с полем BPDU “Root Path Cost” и происходит так:
  1. Корневой свич посылает BPDU с полем Root Path Cost, равным нулю
  2. Ближайший свич смотрит на скорость своего порта, куда BPDU пришел, и добавляет стоимость согласно таблице
    Скорость портаСтоимость STP (802.1d)
    10 Mbps100
    100 Mbps19
    1 Gbps4
    10 Gbps2
  3. Далее этот второй свич посылает этот BPDU нижестоящим коммутаторам, но уже с новым значением Root Path Cost, и далее по цепочке вниз
Если имеют место одинаковые стоимости (как в нашем примере с двумя свичами и двумя проводами между ними — у каждого пути будет стоимость 19) — корневым выбирается меньший порт.

Далее выбираются назначенные (Designated) порты. Из каждого конкретного сегмента сети должен существовать только один путь по направлению к корневому свичу, иначе это петля. В данном случае имеем в виду физический сегмент, в современных сетях без хабов это, грубо говоря, просто провод. Назначенным портом выбирается тот, который имеет лучшую стоимость в данном сегменте. У корневого свича все порты — назначенные.

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


*На картинке маршрутизаторы выступают в качестве коммутаторов. В реальной жизни это можно сделать с помощью дополнительной свитчёвой платы.

Состояния портов

Чуть раньше мы упомянули состояние блокировки порта, теперь поговорим о том, что это значит, и о других возможных состояниях порта в STP. Итак, в обычном (802.1D) STP существует 5 различных состояний:

  • блокировка (blocking): блокированный порт не шлет ничего. Это состояние предназначено, как говорилось выше, для предотвращения петель в сети. Блокированный порт, тем не менее, слушает BPDU (чтобы быть в курсе событий, это позволяет ему, когда надо, разблокироваться и начать работать)
  • прослушивание (listening): порт слушает и начинает сам отправлять BPDU, кадры с данными не отправляет.
  • обучение (learning): порт слушает и отправляет BPDU, а также вносит изменения в CAM- таблицу, но данные не перенаправляет.
  • перенаправление\пересылка (forwarding): этот может все: и посылает\принимает BPDU, и с данными оперирует, и участвует в поддержании таблицы mac-адресов. То есть это обычное состояние рабочего порта.
  • отключен (disabled): состояние administratively down, отключен командой shutdown. Понятное дело, ничего делать не может вообще, пока вручную не включат.

Порядок перечисления состояний не случаен: при включении (а также при втыкании нового провода), все порты на устройстве с STP проходят вышеприведенные состояния именно в таком порядке (за исключением disabled-портов). Возникает закономерный вопрос: а зачем такие сложности? А просто STP осторожничает. Ведь на другом конце провода, который только что воткнули в порт, может быть свич, а это потенциальная петля. Вот поэтому порт сначала 15 секунд (по умолчанию) пребывает в состоянии прослушивания — он смотрит BPDU, попадающие в него, выясняет свое положение в сети — как бы чего ни вышло, потом переходит к обучению еще на 15 секунд — пытается выяснить, какие mac-адреса “в ходу” на линке, и потом, убедившись, что ничего он не поломает, начинает уже свою работу. Итого, мы имеем целых 30 секунд простоя, прежде чем подключенное устройство сможет обмениваться информацией со своими соседями. Современные компы грузятся быстрее, чем за 30 секунд. Вот комп загрузился, уже рвется в сеть, истерит на тему “DHCP-сервер, сволочь, ты будешь айпишник выдавать, или нет?”, и, не получив искомого, обижается и уходит в себя, извлекая из своих недр айпишник автонастройки. Естественно, после таких экзерсисов, в сети его слушать никто не будет, ибо “не местный” со своим 169.254.x.x. Понятно, что все это не дело, но как этого избежать?

Portfast

Для таких случаев используется особый режим порта — portfast. При подключении устройства к такому порту, он, минуя промежуточные стадии, сразу переходит к forwarding-состоянию. Само собой, portfast следует включать только на интерфейсах, ведущих к конечным устройствам (рабочим станциям, серверам, телефонам и т.д.), но не к другим свичам.

Есть очень удобная команда режима конфигурации интерфейса для включения нужных фич на порту, в который будут включаться конечные устройства: switchport host. Эта команда разом включает PortFast, переводит порт в режим access (аналогично switchport mode access), и отключает протокол PAgP (об этом протоколе подробнее в разделе агрегация каналов).

Виды STP
STP довольно старый протокол, он создавался для работы в одном LAN-сегменте. А что делать, если мы хотим внедрить его в нашей сети, которая имеет несколько VLANов?

Стандарт 802.1Q, о котором мы упоминали в статье о коммутации, определяет, каким образом вланы передаются внутри транка. Кроме того, он определяет один процесс STP для всех вланов. BPDU по транкам передаются нетегированными (в native VLAN). Этот вариант STP известен как CST (Common Spanning Tree). Наличие только одного процесса для всех вланов очень облегчает работу по настройке и разгружает процессор свича, но, с другой стороны, CST имеет недостатки: избыточные линки между свичами блокируются во всех вланах, что не всегда приемлемо и не дает возможности использовать их для балансировки нагрузки.

Cisco имеет свой взгляд на STP, и свою проприетарную реализацию протокола — PVST (Per-VLAN Spanning Tree) — которая предназначена для работы в сети с несколькими VLAN. В PVST для каждого влана существует свой процесс STP, что позволяет независимую и гибкую настройку под потребности каждого влана, но самое главное, позволяет использовать балансировку нагрузки за счет того, что конкретный физический линк может быть заблокирован в одном влане, но работать в другом. Минусом этой реализации является, конечно, проприетарность: для функционирования PVST требуется проприетарный же ISL транк между свичами.

Также существует вторая версия этой реализации — PVST+, которая позволяет наладить связь между свичами с CST и PVST, и работает как с ISL- транком, так и с 802.1q. PVST+ это протокол по умолчанию на коммутаторах Cisco.

RSTP

Все, о чем мы говорили ранее в этой статье, относится к первой реализация протокола STP, которая была разработана в 1985 году Радией Перлман (ее стихотворение использовано в качестве эпиграфа). В 1990 году эта реализации была включена в стандарт IEEE 802.1D. Тогда время текло медленнее, и перестройка топологии STP, занимающая 30-50 секунд (!!!), всех устраивала. Но времена меняются, и через десять лет, в 2001 году, IEEE представляет новый стандарт RSTP (он же 802.1w, он же Rapid Spanning Tree Protocol, он же Быстрый STP). Чтобы структурировать предыдущий материал и посмотреть различия между обычным STP (802.1d) и RSTP (802.1w), соберем таблицу с основными фактами:

STP (802.1d)RSTP (802.1w)
В уже сложившейся топологии только корневой свич шлет BPDU, остальные ретранслируютВсе свичи шлют BPDU в соответствии с hello-таймером (2 секунды по умолчанию)
Состояния портов
— блокировка (blocking)
— прослушивание (listening)
— обучение (learning)
— перенаправление\пересылка (forwarding)
— отключен (disabled)
— отбрасывание (discarding), заменяет disabled, blocking и listening
— learning
— forwarding
Роли портов
— корневой (root), участвует в пересылке данных, ведет к корневому свичу
— назначенный (designated), тоже работает, ведет от корневого свича
— неназначенный (non-designated), не участвует в пересылке данных
— корневой (root), участвует в пересылке данных
— назначенный (designated), тоже работает
— дополнительный (alternate), не участвует в пересылке данных
— резервный (backup), тоже не участвует
Механизмы работы
Использует таймеры:
Hello (2 секунды)
Max Age (20 секунд)
Forward delay timer (15 секунд)
Использует процесс proposal and agreement (предложение и соглашение)
Свич, обнаруживший изменение топологии, извещает корневой свич, который, в свою очередь, требует от всех остальных очистить их записи о текущей топологии в течение forward delay timerОбнаружение изменений в топологии влечет немедленную очистку записей
Если не-корневой свич не получает hello- пакеты от корневого в течение Max Age, он начинает новые выборыНачинает действовать, если не получает BPDU в течение 3 hello-интервалов
Последовательное прохождение порта через состояния Blocking (20 сек) — Listening (15 сек) — Learning (15 сек) — ForwardingБыстрый переход к Forwarding для p2p и Edge-портов


Как мы видим, в RSTP остались такие роли портов, как корневой и назначенный, а роль заблокированного разделили на две новых роли: Alternate и Backup. Alternate — это резервный корневой порт, а backup — резервный назначенный порт. Как раз в этой концепции резервных портов и кроется одна из причин быстрого переключения в случае отказа. Это меняет поведение системы в целом: вместо реактивной (которая начинает искать решение проблемы только после того, как она случилась) система становится проактивной, заранее просчитывающей “пути отхода” еще до появления проблемы. Смысл простой: для того, чтобы в случае отказа основного переключится на резервный линк, RSTP не нужно заново просчитывать топологию, он просто переключится на запасной, заранее просчитанный.

Ранее, для того, чтобы убедиться, что порт может участвовать в передаче данных, требовались таймеры, т.е. свич пассивно ждал в течение означенного времени, слушая BPDU. Ключевой фичей RSTP стало введение концепции типов портов, основанных на режиме работы линка- full duplex или half duplex (типы портов p2p или shared, соответственно), а также понятия пограничный порт (тип edge p2p), для конечных устройств. Пограничные порты назначаются, как и раньше, командой spanning-tree portfast, и с ними все понятно- при включении провода сразу переходим к forwarding-состоянию и работаем. Shared-порты работают по старой схеме с прохождением через состояния BLK — LIS — LRN — FWD. А вот на p2p-портах RSTP использует процесс предложения и соглашения (proposal and agreement). Не вдаваясь в подробности, его можно описать так: свич справедливо считает, что если линк работает в режиме полного дуплекса, и он не обозначен, как пограничный, значит, на нем только два устройства- он и другой свич. Вместо того, чтобы ждать входящих BPDU, он сам пытается связаться со свичом на том конце провода с помощью специальных proposal BPDU, в которых, конечно, есть информация о стоимости маршрута к корневому свичу. Второй свич сравнивает полученную информацию со своей текущей, и принимает решение, о чем извещает первый свич посредством agreement BPDU. Так как весь этот процесс теперь не привязан к таймерам, происходит он очень быстро- только подключили новый свич- и он практически сразу вписался в общую топологию и приступил к работе (можете сами оценить скорость переключения в сравнении с обычным STP на видео). В Cisco-мире RSTP называется PVRST (Per-Vlan Rapid Spanning Tree).

MSTP

Чуть выше, мы упоминали о PVST, в котором для каждого влана существует свой процесс STP. Вланы это довольно удобный инструмент для многих целей, и поэтому, их может быть достаточно много даже в некрупной организации. И в случае PVST, для каждого будет рассчитываться своя топология, тратиться процессорное время и память свичей. А нужно ли нам рассчитывать STP для всех 500 вланов, когда единственное место, где он нам нужен- это резервный линк между двумя свичами? Тут нас выручает MSTP. В нем каждый влан не обязан иметь собственный процесс STP, их можно объединять. Вот у нас есть, например, 500 вланов, и мы хотим балансировать нагрузку так, чтобы половина из них работала по одному линку (второй при этом блокируется и стоит в резерве), а вторая- по другому. Это можно сделать с помощью обычного STP, назначив один корневой свич в диапазоне вланов 1-250, а другой- в диапазоне 250-500. Но процессы будут работать для каждого из пятисот вланов по отдельности (хотя действовать будут совершенно одинаково для каждой половины). Логично, что тут хватит и двух процессов. MSTP позволяет создавать столько процесов STP, сколько у нас логических топологий (в данном примере- 2), и распределять по ним вланы. Думаем, нет особого смысла углубляться в теорию и практику MSTP в рамках этой статьи (ибо теории там ого-го), интересующиеся могут пройти по ссылке.

Агрегация каналов

Но какой бы вариант STP мы не использовали, у нас все равно существует так или иначе неработающий линк. А возможно ли задействовать параллельные линки по полной и при этом избежать петель? Да, отвечаем мы вместе с циской, начиная рассказ о EtherChannel.

Иначе это называется link aggregation, link bundling, NIC teaming, port trunkinkg
Технологии агрегации (объединения) каналов выполняют 2 функции: с одной стороны, это объединение пропускной способности нескольких физических линков, а с другой — обеспечение отказоустойчивости соединения (в случае падения одного линка нагрузка переносится на оставшиеся). Объединение линков можно выполнить как вручную (статическое агрегирование), так и с помощью специальных протоколов: LACP (Link Aggregation Control Protocol) и PAgP (Port Aggregation Protocol). LACP, опеределяемый стандартом IEEE 802.3ad, является открытым стандартом, то есть от вендора оборудования не зависит. Соответственно, PAgP — проприетарная цисковская разработка.

В один такой канал можно объединить до восьми портов. Алгоритм балансировки нагрузки основан на таких параметрах, как IP/MAC-адреса получателей и отправителей и порты. Поэтому в случае возникновения вопроса: “Хей, а чего так плохо балансируется?” в первую очередь смотрите на алгоритм балансировки.

Port security

Теперь расскажем вкратце, как обеспечить безопасность сети на втором уровне OSI. В этой части статьи теория и практическая конфигурация совмещены. Увы, Packet Tracer не умеет ничего из упомянутых в этом разделе команд, поэтому все без иллюстраций и проверок.

Для начала, следует упомянуть команду конфигурации интерфейса switchport port-security, включающую защиту на определенном порту свича. Затем, с помощью switchport port-security maximum 1 мы можем ограничить количество mac-адресов, связанных с данным портом (т.е., в нашем примере, на данном порту может работать только один mac-адрес). Теперь указываем, какой именно адрес разрешен: его можно задать вручную switchport port-security mac-address адрес, или использовать волшебную команду switchport port-security mac-address sticky, закрепляющую за портом тот адрес, который в данный момент работает на порту. Далее, задаем поведение в случае нарушения правила switchport port-security violation {shutdown | restrict | protect}: порт либо отключается, и потом его нужно поднимать вручную (shutdown), либо отбрасывает пакеты с незарегистрированного мака и пишет об этом в консоль (restrict), либо просто отбрасывает пакеты (protect).

Помимо очевидной цели — ограничение числа устройств за портом — у этой команды есть другая, возможно, более важная: предотвращать атаки. Одна из возможных — истощение CAM-таблицы. С компьютера злодея рассылается огромное число кадров, возможно, широковещательных, с различными значениями в поле MAC-адрес отправителя. Первый же коммутатор на пути начинает их запоминать. Одну тысячу он запомнит, две, но память-то оперативная не резиновая, и среднее ограничение в 16000 записей будет довольно быстро достигнуто. При этом дальнейшее поведение коммутатора может быть различным. И самое опасное из них с точки зрения безопасности: коммутатор может начать все кадры, приходящие на него, рассылать, как широковещательные, потому что MAC-адрес получателя не известен (или уже забыт), а запомнить его уже просто некуда. В этом случае сетевая карта злодея будет получать все кадры, летающие в вашей сети.

DHCP Snooping
Другая возможная атака нацелена на DHCP сервер. Как мы знаем, DHCP обеспечивает клиентские устройства всей нужной информацией для работы в сети: ip-адресом, маской подсети, адресом шюза по умолчанию, DNS-сервера и прочим. Атакующий может поднять собственный DHCP, который в ответ на запрос клиентского устройства будет отдавать в качестве шлюза по умолчанию (а также, например, DNS-сервера) адрес подконтрольной атакующему машины. Соответственно, весь трафик, направленный за пределы подсети обманутыми устройствами, будет доступен для изучения атакующему — типичная man-in-the-middle атака. Либо такой вариант: подлый мошенник генерируют кучу DHCP-запросов с поддельными MAC-адресами и DHCP-сервер на каждый такой запрос выдаёт IP-адрес до тех пор, пока не истощится пул.

Для того, чтобы защититься от подобного вида атак, используется фича под названием DHCP snooping. Идея совсем простая: указать свичу, на каком порту подключен настоящий DHCP-сервер, и разрешить DHCP-ответы только с этого порта, запретив для остальных. Включаем глобально командой ip dhcp snooping, потом говорим, в каких вланах должно работать ip dhcp snooping vlan номер(а). Затем на конкретном порту говорим, что он может пренаправлять DHCP-ответы (такой порт называется доверенным): ip dhcp snooping trust.

IP Source Guard
После включения DHCP Snooping’а, он начинает вести у себя базу соответствия MAC и IP-адресов устройств, которую обновляет и пополняет за счет прослушивания DHCP запросов и ответов. Эта база позволяет нам противостоять еще одному виду атак — подмене IP-адреса (IP Spoofing). При включенном IP Source Guard, каждый приходящий пакет может проверяться на:
  • соответствие IP-адреса источника адресу, полученному из базы DHCP Snooping (иными словами, айпишник закрепляется за портом свича)
  • соответствие MAC-адреса источника адресу, полученному из базы DHCP Snooping
Включается IP Source Guard командой ip verify source на нужном интерфейсе. В таком виде проверяется только привязка IP-адреса, чтобы добавить проверку MAC, используем ip verify source port-security. Само собой, для работы IP Source Guard требуется включенный DHCP snooping, а для контроля MAC-адресов должен быть включен port security.

Dynamic ARP Inspection
Как мы уже знаем, для того, чтобы узнать MAC-адрес устройства по его IP-адресу, используется проткол ARP: посылается широковещательный запрос вида “у кого ip-адрес 172.16.1.15, ответьте 172.16.1.1”, устройство с айпишником 172.16.1.15 отвечает. Подобная схема уязвима для атаки, называемой ARP-poisoning aka ARP-spoofing: вместо настоящего хоста с адресом 172.16.1.15 отвечает хост злоумышленника, заставляя таким образом трафик, предназначенный для 172.16.1.15 следовать через него. Для предотвращения такого типа атак используется фича под названием Dynamic ARP Inspection. Схема работы похожа на схему DHCP-Snooping’а: порты делятся на доверенные и недоверенные, на недоверенных каждый ARP-ответ подвергаются анализу: сверяется информация, содержащаяся в этом пакете, с той, которой свич доверяет (либо статически заданные соответствия MAC-IP, либо информация из базы DHCP Snooping). Если не сходится- пакет отбрасывается и генерируется сообщение в syslog. Включаем в нужном влане (вланах): ip arp inspection vlan номер(а). По умолчанию все порты недоверенные, для доверенных портов используем ip arp inspection trust.

Практика

Наверное, большинство ошибок в Packet Tracer допущено в части кода, отвечающего за симуляцию STP, будте готовы. В случае сомнения сохранитесь, закройте PT и откройте заново

Итак, переходим к практике. Для начала внесем некоторые изменения в топологию — добавим избыточные линки. Учитывая сказанное в самом начале, вполне логично было бы сделать это в московском офисе в районе серверов — там у нас свич msk-arbat-asw2 доступен только через asw1, что не есть гуд. Мы отбираем (пока, позже возместим эту потерю) гигабитный линк, который идет от msk-arbat-dsw1 к msk-arbat-asw3, и подключаем через него asw2. Asw3 пока подключаем в порт Fa0/2 dsw1. Перенастраиваем транки:

msk-arbat-dsw1(config)#interface gi1/2
msk-arbat-dsw1(config-if)#description msk-arbat-asw2
msk-arbat-dsw1(config-if)#switchport trunk allowed vlan 2,3
msk-arbat-dsw1(config-if)#int fa0/2
msk-arbat-dsw1(config-if)#description msk-arbat-asw3
msk-arbat-dsw1(config-if)#switchport mode trunk
msk-arbat-dsw1(config-if)#switchport trunk allowed vlan 2,101-104
msk-arbat-asw2(config)#int gi1/2
msk-arbat-asw2(config-if)#description msk-arbat-dsw1
msk-arbat-asw2(config-if)#switchport mode trunk
msk-arbat-asw2(config-if)#switchport trunk allowed vlan 2,3
msk-arbat-asw2(config-if)#no shutdown

Не забываем вносить все изменения в документацию!



Скачать актуальную версию документа.

Теперь посмотрим, как в данный момент у нас самонастроился STP. Нас интересует только VLAN0003, где у нас, судя по схеме, петля.

msk-arbat-dsw1>en
msk-arbat-dsw1#show spanning-tree vlan 3

Разбираем по полочкам вывод команды



Итак, какую информацию мы можем получить? Так как по умолчанию на современных цисках работает PVST+ (т.е. для каждого влана свой процесс STP), и у нас есть более одного влана, выводится информация по каждому влану в отдельности, каждая запись предваряется номером влана. Затем идет вид STP: ieee значит PVST, rstp — Rapid PVST, mstp то и значит. Затем идет секция с информацией о корневом свиче: установленный на нем приоритет, его mac-адрес, стоимость пути от текущего свича до корневого, порт, который был выбран в качестве корневого (имеет лучшую стоимость), а также настройки таймеров STP. Далее- секция с той же информацией о текущем свиче (с которого выполняли команду). Затем- таблица состояния портов, которая состоит из следующих колонок (слева направо):
  • собственно, порт
  • его роль (Root- корневой порт, Desg- назначенный порт, Altn- дополнительный, Back- резервный)
  • его статус (FWD- работает, BLK- заблокирован, LIS- прослушивание, LRN- обучение)
  • стоимость маршрута до корневого свича
  • Port ID в формате: приоритет порта.номер порта
  • тип соединения

Итак, мы видим, что Gi1/1 корневой порт, это дает некоторую вероятность того, что на другом конце линка корневой свич. Смотрим по схеме, куда ведет линк: ага, некий msk-arbat-asw1.
msk-arbat-asw1#show spanning-tree vlan 3

И что же мы видим?
VLAN0003
Spanning tree enabled protocol ieee
Root ID Priority 32771
Address 0007.ECC4.09E2
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Вот он, наш корневой свич для VLAN0003.

А теперь посмотрим на схему. Ранее, мы увидели в состоянии портов, что dsw1 блокирует порт Gi1/2, разрывая таким образом петлю. Но является ли это оптимальным решением? Нет, конечно. Сейчас наша новая сеть работает точь-в-точь как старая- трафик от asw2 идет только через asw1. Выбор корневого маршрутизатора никогда не нужно оставлять на совесть глупого STP. Исходя из схемы, наиболее оптимальным будет выбор в качестве корневого свича dsw1- таким образом, STP заблокирует линк между asw1 и asw2. Теперь это все надо объяснить недалекому протоколу. А для него главное что? Bridge ID. И он неслучайно складывается из двух чисел. Приоритет- это как раз то слагаемое, которое отдано на откуп сетевому инженеру, чтобы он мог повлиять на результат выбора корневого свича. Итак, наша задача сводится к тому, чтобы уменьшить (меньше-лучше, думает STP) приоритет нужного свича, чтобы он стал Root Bridge. Есть два пути:

1) вручную установить приоритет, заведомо меньший, чем текущий:
msk-arbat-dsw1>enable
msk-arbat-dsw1#configure terminal
msk-arbat-dsw1(config)#spanning-tree vlan 3 priority ?
<0-61440> bridge priority in increments of 4096
msk-arbat-dsw1(config)#spanning-tree vlan 3 priority 4096

Теперь он стал корневым для влана 3, так как имеет меньший Bridge ID:

msk-arbat-dsw1#show spanning-tree vlan 3
VLAN0003
Spanning tree enabled protocol ieee
Root ID Priority 4099
Address 000B.BE2E.392C
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

2) дать умной железке решить все за тебя:
msk-arbat-dsw1(config)#spanning-tree vlan 3 root primary

Проверяем:

msk-arbat-dsw1#show spanning-tree vlan 3
VLAN0003
Spanning tree enabled protocol ieee
Root ID Priority 24579
Address 000B.BE2E.392C
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Мы видим, что железка поставила какой-то странный приоритет. Откуда взялась эта круглая цифра, спросите вы? А все просто- STP смотрит минимальный приоритет (т.е. тот, который у корневого свича), и уменьшает его на два шага инкремента (который составляет 4096, т.е. в итоге 8192). Почему на два? А чтобы была возможность на другом свиче дать команду spanning-tree vlan n root secondary (назначает приоритет=приоритет корневого-4096), что позволит нам быть уверенными, что, если с текущим корневым свичом что-то произойдет, его функции перейдут к этому, “запасному”. Вероятно, вы уже видите на схеме, как лампочка на линке между asw2 и asw1 пожелтела? Это STP разорвал петлю. Причем именно в том месте, в котором мы хотели. Sweet! Зайдем проверим: лампочка — это лампочка, а конфиг — это факт.

msk-arbat-asw2#show spanning-tree vlan 3
VLAN0003
Spanning tree enabled protocol ieee
Root ID Priority 24579
Address 000B.BE2E.392C
Cost 4
Port 26(GigabitEthernet1/2)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32771 (priority 32768 sys-id-ext 3)
Address 000A.F385.D799
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 20

Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/1 Desg FWD 19 128.1 P2p
Gi1/1 Altn BLK 4 128.25 P2p
Gi1/2 Root FWD 4 128.26 P2p

Теперь полюбуемся, как работает STP: заходим в командную строку на ноутбуке PTO1 и начинаем бесконечно пинговать наш почтовый сервер (172.16.0.4). Пинг сейчас идет по маршруту ноутбук-asw3-dsw1-gw1-dsw1(ну тут понятно, зачем он крюк делает — они из разных вланов)-asw2-сервер. А теперь поработаем Годзиллой из SimСity: нарушим связь между dsw1 и asw2, вырвав провод из порта (замечаем время, нужное для пересчета дерева).

Пинги пропадают, STP берется за дело, и за каких-то 30 секунд коннект восстанавливается. Годзиллу прогнали, пожары потушили, связь починили, втыкаем провод обратно. Пинги опять пропадают на 30 секунд! Мда-а-а, как-то не очень быстро, особенно если представить, что это происходит, например, в процессинговом центре какого-нибудь банка.

Но у нас есть ответ медленному PVST+! И ответ этот — Быстрый PVST+ (так и называется, это не шутка: Rapid-PVST). Посмотрим, что он нам дает. Меняем тип STP на всех свичах в москве командой конфигурационного режима: spanning-tree mode rapid-pvst

Снова запускаем пинг, вызываем Годзиллу… Эй, где пропавшие пинги? Их нет, это же Rapid-PVST. Как вы, наверное, помните из теоретической части, эта реализация STP, так сказать, “подстилает соломку” на случай падения основного линка, и переключается на дополнительный (alternate) порт очень быстро, что мы и наблюдали. Ладно, втыкаем провод обратно. Один потерянный пинг. Неплохо по сравнению с 6-8, да?

EtherChannel

Помните, мы отобрали у офисных работников их гигабитный линк и отдали его в пользу серверов? Сейчас они, бедняжки, сидят, на каких-то ста мегабитах, прошлый век! Попробуем расширить канал, и на помощь призовем EtherChannel. В данный момент у нас соединение идет от fa0/2 dsw1 на Gi1/1 asw3, отключаем провод. Смотрим, какие порты можем использовать на asw3: ага, fa0/20-24 свободны, кажется. Вот их и возьмем. Со стороны dsw1 пусть будут fa0/19-23. Соединяем порты для EtherChannel между собой. На asw3 у нас на интерфейсах что-то настроено, обычно в таких случаях используется команда конфигурационного режима default interface range fa0/20-24, сбрасывающая настройки порта (или портов, как в нашем случае) в дефолтные. Packet tracer, увы, не знает такой хорошей команды, поэтому в ручном режиме убираем каждую настройку, и тушим порты (лучше это сделать, во избежание проблем)
msk-arbat-asw3(config)#interface range fa0/20-24
msk-arbat-asw3(config-if-range)#no description
msk-arbat-asw3(config-if-range)#no switchport access vlan
msk-arbat-asw3(config-if-range)#no switchport mode
msk-arbat-asw3(config-if-range)#shutdown

ну а теперь волшебная команда
msk-arbat-asw3(config-if-range)#channel-group 1 mode on

то же самое на dsw1:
msk-arbat-dsw1(config)#interface range fa0/19-23
msk-arbat-dsw1(config-if-range)#channel-group 1 mode on

поднимаем интерфейсы asw3, и вуаля: вот он, наш EtherChannel, раскинулся аж на 5 физических линков. В конфиге он будет отражен как interface Port-channel 1. Настраиваем транк (повторить для dsw1):
msk-arbat-asw3(config)#int port-channel 1
msk-arbat-asw3(config-if)#switchport mode trunk
msk-arbat-asw3(config-if)#switchport trunk allowed vlan 2,101-104

Как и с STP, есть некая трудность при работе с etherchannel в Packet Tracer’e. Настроить-то мы, в принципе, можем по вышеописанному сценарию, но вот проверка работоспособности под большим вопросом: после отключения одного из портов в группе, трафик перетекает на следующий, но как только вы вырубаете второй порт — связь теряется и не восстанавливается даже после включения портов.

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

Материалы выпуска
Новый план коммутации
Файл PT с лабораторной.
Конфигурация устройств
STP или STP
Безопасность канального уровня
Агрегация каналов

Авторы

Марат eucariot
Максим aka gluck.

69 комментариев

avatar
Доброй ночи. На видео на 9:02 Вы настраиваете транк между dsw1 и asw2, но порт указан gig1/1, который ведет к asw1. Я так понимаю, это ошибка, или, я так понимаю, я что-то не так понимаю?
avatar
Здравствуйте. Кажется, вы правы — дома ещё пересмотрю видео. Видимо, ошибся в description. Сути это не меняет — настраивается всё аналогично.
avatar
тест
avatar
Здравствуйте. Никак не могу разобраться. у мне на msk-arbat-dsw1 команда sh spanning-tree выводит информацию лишь о виланах 1 и 2. причем если руками создать вилан на нем, то отобразятся все порты. Что я сделал не так при настройке? вроде бы делал строго по инструкции.
avatar
Прошу прощения, не понял, что значит фраза «причем если руками создать вилан на нем, то отобразятся все порты»?
Если команда VLAN X задана, то и в STP он должен быть.
avatar
прошу прощение, не порты, а интерфейсы. на видео если набрать комманду sh spanning-tree vlan 3 отображаеются всего лишь три интерфейса, а у меня вот так:
Interface Role Sts Cost Prio.Nbr Type
— — — — — — Fa0/1 Desg FWD 19 128.1 P2p
Fa0/2 Desg FWD 19 128.2 P2p
Fa0/24 Desg FWD 19 128.24 P2p
Gi1/1 Root FWD 4 128.25 P2p
Gi1/2 Desg FWD 4 128.26 P2p

т.е. все подключенные интерфейсы, хотя на Fa0/1, Fa0/2 вообще третьего вилана нет, он даже транком там не прописан
P.S.: может я проглядел, но когда вы на видео создавали на msk-arbat-dsw1 вилан 3?
avatar
Ну это же конфигурация с предыдущего выпуска. Тогда и создавал.
Без конфигурации сложно сказать. Вообще, конечно, должны быть только те интерфейсы, где настроен этот влан.
avatar
Current configuration: 1546 bytes
!
version 12.2
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
!
hostname msk-arbat-dsw1
!
!
spanning-tree mode pvst
!
interface FastEthernet0/1
switchport trunk allowed vlan 2,101,104
switchport mode trunk
!
interface FastEthernet0/2
description msk-arbat-asw3
switchport trunk allowed vlan 2,101-104
switchport mode trunk
!
interface FastEthernet0/3

interface FastEthernet0/23
!
interface FastEthernet0/24
switchport trunk allowed vlan 2-3,101-104
switchport mode trunk
!
interface GigabitEthernet1/1
description msk-arbat-asw1
switchport trunk allowed vlan 2-3
switchport mode trunk
!
interface GigabitEthernet1/2
description msk-arbat-asw2
switchport trunk allowed vlan 2-3
switchport mode trunk
!
interface Vlan1
no ip address
shutdown
!
interface Vlan2
description Management
ip address 172.16.1.2 255.255.255.0
!
ip default-gateway 172.16.1.1
!
!
line con 0
!
line vty 0 4
login
line vty 5 15
login
!
avatar
Действительно странно. Попробуйте перезагрузить устройства) Или перходите на GNS. Столько уже глюков отловили на это РТ!
avatar
понял, спасибо )
avatar
Никаких глюков. Необходимо создать влан, и инстанс:



msk-arbat-dsw1#conf 
msk-arbat-dsw1(config)#vlan 3
msk-arbat-dsw1(config-vlan)#name Servers
msk-arbat-dsw1(config-vlan)#exit
msk-arbat-dsw1#conf t
msk-arbat-dsw1(config)#spanning-tree vlan 3 root primary
avatar
у меня тоже нет третьего вилана, однако действовал я не по видео, а по текстовым инструкциям. Также хотелось бы заметить, что в московской сети на свичах виланы в лабе не прописывались. Это было домашним заданием?
avatar
Потому что не прописан vlan 3 на msk-arbat-dsw1
avatar
Port security
Увы, Packet Tracer не умеет ничего из упомянутых в этом разделе команд, поэтому все без иллюстраций и проверок.

В моей версии PT (5.3.3.0019) умеет все из этих команд. Скриншот прилагаю.

avatar
А если после того как я подключил msk-arbat-dsw1->msk-arbat-asw2, соединение msk-arbat-asw1->msk-arbat-asw2 «пропадает»(кружочек приобретает оранжевый цвет) Где я допустил ошибку?
avatar
Всё верно. Это STP блокирует избыточный линк.
avatar
Извиняюсь за преждевременную панику =)Просто на видеоролике все линки были зеленого цвета)
avatar
Ничего подобного, на видео просто название порта загораживало лампочку)))
avatar
Вообще, оранжевый вполне именно это и означает. Просто когда PVST в разных вланах по-разному могут выбираться порты. И тогда он будет зелёным
avatar
мой ответ был к начальному вопросу)))
avatar
Спасибо большое, все очень доходчиво рассказано и описано!
avatar
STP часто съедает мозг начинающим, особенно тонкости процесса распределения ролей и статусов портов.
Например, на картинке в начале поста с root/desgn/blck портами есть момент, который стоит осветить отдельно: левый нижний свич выбирает root портом «верхний» порт, хотя у «правого» порта стоимость до рута точно такая же — 38. Выбор root порта в таком случае завязан на Bridge ID свича, от которого спустился BPDU. В нашем примере верхний левый свич имел BrID меньше, чем правый нижний, именно поэтому BPDU от него, поступивший на «верхний» порт и сделал данный порт рутовым.
avatar
ухты как переклинило twitter oauth, мне выписали левый ник с датой регистрации из будущего
avatar
Вы правы, но это уже тонкости, детали. Мне кажется, их лучше будет понять в ходе работы. Описать всё в статье крайне сложно.
avatar
Здравствуйте.
Скажите какой смысл в агрегации каналов между dsw1 и asw3 (да и вообще гигабитных линков), если маршрутизатор все равно на 100мбит?
avatar
В данном случае никакой. Мы тут, скорее, рассмотрели просто вариант применения. Одной из последних статей цикла будет как раз о том, как правильно строить сети и внедрять резервирование.
avatar
А будет ли отдельно про Etherchannel и балансировки?
avatar
Отдельно не будет. Но в самом конце серии будет итоговая статья — типа best practice по построению и резервированию. Скорее всего, там этот вопрос будет затронут.

В принципе тема очень простая, чтобы посвящать ей статью.
avatar
Добрый день, подскажите — скачал проект в начале статьи с уже составленными избыточными связями и стал с ним работать, но остановился на выводе команды:
#show spanning-tree vlan 3

у меня на всех ВЛАН Spanning tree protocol RSTP — я чтото даже засомневался, сейчас конечно попробую изменить, но интересно — это задумка или случайность??
avatar
Простите, разобрался — перепутаны dsw1 и asw1. выводы почему то наоборот у них^ dsw1 — This is bridge is root
Буду думать дальше
avatar
И все таки прошу помощи: никак не могу понять — у меня порт Gi1/2 на dsw1 упорно сидит в VLAN2, в списке VLAN 3 он не оторажается
avatar
Вышлите конфигурацию на info@linkmeup.ru с подробным описанием вопроса. Пока не понимаю, о чём речь.
avatar
Доброго дня! Столкнулся вот с такой проблемой, хочу настроить агрегацию каналов в GNS3. Я так понял, что вся настройка коммутаторов заключается в присвоении порту access, dot1q (trunk), qinq.
Пинги не проходят, все порту SW3 в одном vlane (dot1q). Предполагаю это косяк GNS3. Как вы считаете?
avatar
Агрегирование настраивается на одном простом линке — то есть между двумя непосредственно подключенными узлами. Коммутатор между ними ставить, во-первых, нельзя, во-вторых, ни к чему, если того, специальным образом не требует дизайн.
avatar
SW3 — выступает на схеме, как провайдер, к которому подключен офис 1 (R4) и офис 2 (R5). Не совсем понятно «Агрегирование настраивается на одном простом линке — то есть между двумя непосредственно подключенными узлами...». Агрегация каналов предусматривает объединение несколько физических каналов в один логический, и какой смысл в настройке на одном простом линке? А что будет с другим? Как через него будет проходить траффик? не поняяяяяяяяяяяяяяяятно((((
avatar
Некорректно выразился.
«на одном простом линке» — имел ввиду не на составной линии.
Два устройства должны быть подключены непосредственно друг к другу. А у вас посередине свитч, который ничего не знает об этом Eth-транке.
avatar
И настроить свитч, который бы знал об нашем Ethernet-trunk в GNS3 нельзя.
avatar
Настройте между маршрутизаторами и проблем знать не будете.
avatar
Если есть возможность, удалите все мои предыдущии сообщения, запаниковал, бывает.

Резюмирую вопросы:
1)STP На карте не отображаются оранжевые пинги, хотя в конфигурации пишет что один порт ведет на рут второй BLK, то есть я так понимаю что все ок, и проверка рабоатет.
Не работает команда msk-arbat-dsw1(config)#spanning-tree vlan 3 root primary
То ест me меня 4099 на dsw1 и asw
И того на dsw у меня все порты desq
на asw1 один root и один Alt
на asw2 один root и один Alt
И у все приоритет 4099, как его изменить я чтото запутался, хотя бы на дефолт сбросить чтоб заново настроить

2) Не работает агрегация каналов, вчера до последнего сидел, в итоге начал сравнивать и понял что у вас в готовом примере подняты агрегаторный линк а так же линки fa0/20-24
у меня же поднят только агрегаторный линк а физические линки в состоянии DOWNб причем команда no shutdown пишет что линк поущен, команда shutdown так же пишет что линке опущен, как физически поднять линки не понятно, мне кажется должна быть rfrz то последовательност ь в агрегации каналов, пока побороть никак не могу
avatar
Простите за спешку, свежая голова решает проблемы.
Для тех кто столкнулся с подобным:
1) полностью удалите связи
2) Заново подключите физически кабеля
3) ОБЯЗАТЕЛЬНО ПРОВЕРЬТЕ чтоб состояние портов было UP, иначе включите вручную
4 После того как все интервейсы подняты — настраивайте агрегацию
avatar
Станислав, у вас ещё остались вопросы?
Если да, пишите на почту с подробным описанием вопроса. Я пока вас не понимаю.
avatar
Здравствуйте.Никак не могу разобраться с настройкой EtherChannel.Делаю все как написано, подключаю 5 линков, убираю в ручную настройки, заношу их в группу и настраиваю транковые порты… и ничего не пингутся… хочу прпинговать pto с сервером. а вот когда настраиваю на msk-arbat-dsw1 порт например fa0/2 и на msk-arbat-asw3 gig1/1 как обычно, все прекрасно работает и пингуется.
И вот ещевопрос. Я скачал ваши конфигурации и там почему то написано вот такое(и все при этом пингуется):

interface FastEthernet0/23
description port-channel1-to-dsw1
switchport access vlan 104
channel-group 1 mode on
switchport mode trunk


зачем мы прописываем access vlan, если access только для подключению к конечным устройствам.
а у меня вот аткое

interface FastEthernet0/23
description msk-arbat-dsw1
channel-group 1 mode on
switchport mode trunk
avatar
Здравствуйте. столкнулся с аналогичной ситуацией: после настройки Eth-channel отсутствовал пинг на сетевые устройства находящиеся за асв3, присутствовал лишь в пределах одного влана (172.16.16.2 <-> 172.16.6.66), соединив асв3 с дсв1 по fax/x работоспособность сети восстановилась. При прочих верных настройках сделал вывод, что некорректно реализован Eth-channel в CPT6.0

что касается
nterface FastEthernet0/23
description port-channel1-to-dsw1
switchport access vlan 104
channel-group 1 mode on
switchport mode trunk

можно предположить что пинг оставался активным из-за записи «switchport access vlan 104»
avatar
Здравствуйте, Прошу помочь разобраться со следующей задачей

Для организации резервирования физической линии в клиентские станции установлены двух портовые сетевые карты Broadcom 5720, которые настроены в режиме агрегирования каналов (Nic teaming) – один ip адрес.
Вопросы:
1) При такой сетевой организации нужно ли как то настраивать коммутаторы, т.е. нужно ли поднимать поддержку протокола STP, RSTP?
2) Если дополнительно объединить два коммутатора патч-кордом. Какие настройки потребуются?

Link_aggregation
avatar
Я не знаю, как работает NIC teaming. Если это просто Active-Standby и решение ПК принимает сам, то со стороны коммутаторов поддержка не нужна. Если это полноценный LAG, то коммутаторы в вашей схеме (два линка к разных свитчам) должны поддерживать этот функционал (MC-LAG).

Нужен STP или нет также зависит от режима работы этой карты и от того, пропускают ли сервера через себя пакеты, как коммутаторы.
avatar
Спасибо,
Вроде уже разобрался.

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

Изначально, я по ошибке настроил броадкомы в режиме агрегации (увеличение пропускной способности), хотя нужно было в режиме резервирования физической линии.
В принципе при такой организации все работало, при физическом отключении одного линка связь осуществлялась по второму линку. Но потом проявился один неприятный момент – клиент терял связь буквально на долю секунды. Я подумал, что возникают петли и решил бороться с ними при помощи STP\RSTP.
Потом я выяснил, что на коммутаторах и без меня поднят STP и далее нашел свою оплошность в настройке карточек (т.е нужно было smart load balancing and failover).

Подключение м/у коммутаторами не показал сразу т.к. думал, что оно лишнее и собирался от него отказаться, но потом поразмыслив решил оставить, т.к карточка только контролирует линию до порта коммутатора и не переключится на второй канал (на другой коммутатор) если упадет сервер или соответствующая линия связи к серверу.
avatar
Добрый день!

Вродк все настроил а STP почему то не работает. Линк между ASW1 и 2 также горит. Что делать не подскажете?
avatar
смотрите, что говорит sh spa на одном и на втором. Плюс, если делаете в ПТ, могут быть глюки ПТ.
avatar
Добрый день!

Такое состояние у меня на msk-arbat-asw1
Почему то у меня не поменялось состояние на alt interface gig1/2
Все проверил. Глюк ПТ?

Root ID Priority 4099
Address 0005.5E0B.0259
Cost 4
Port 25(GigabitEthernet1/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32771 (priority 32768 sys-id-ext 3)
Address 0000.0CE2.784E
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 20

Interface Role Sts Cost Prio.Nbr Type
— — — — — — Fa0/1 Desg FWD 19 128.1 P2p
Fa0/2 Desg FWD 19 128.2 P2p
Gi1/1 Root FWD 4 128.25 P2p
Gi1/2 Desg FWD 4 128.26 P2p
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
avatar
Спасибо авторам за труды. Вопрос по поводу DHCP snooping. Как указано выше ip dhcp snooping trust прописывается на порту который ведет к DHCP серверу. Что если роль DHCP сервера берет на себя сам коммутатор?
avatar
Хорошая документация, но не отражены два важнейших момента: vtp и cep/lldp.
Делайте статьи о траблшутинге l2 и l3
комментарий был удален
avatar
Приветствую!
Подскажите пожалуйста, как определятся на каком именно свитче будет блокироваться порт в нашем случае. В объяснении из статьи понятно, там 4-й свитч и у него root-порт выбирается по номеру, если стоимости до root'a равны. В статье у Вас на dsw1 — Gi1/2 Altn BLK 4 128.26 P2p. У меня же на asw2 — Gi0/2 Altn BLK 4 128.26 P2p. Стоимости до рута равны от обоих свитчей, т.к. все свитчи связаны гигабитными линками. MAC'и портов? Но порты на разных же всвитчах.

П.С.
Несмотря на многочисленные дифирамбы, Вам, конечно же, еще 100к +ов в карму!
avatar
Здравствуйте.
У вас BPDU от Root'a приходят на коммутаторы двумя путями: напрямую и через кольцо. Они несут информацию и о Root, и о расстоянии до него и MAC отправителя BPDU. Так что нет ничего удивительного, что у вас выбрался другой коммутатор. Он оказался более выгодным.

Спасибо)
avatar
В табличке для документации ошибоки.
1. msk-arbat-asw2
в строчке Ge1/2 msk-arbat-dsw1 дальше должны идти vlan 2,3
2. msk-arbat-asw3
первая строчка лишняя: GE1/1 msk-arbat-dsw1 мы ее заменили port-channel 1 далее
3. msk-rubl-asw1
FE0/1-FE0/15 PTO VLAN ACCESS должен быть 101, а у вас 1
FE0/20 — это Other а не administrator
FE0/24 msk-arbat-dsw1 нет еще 101 vlan`а
avatar
Странно, но у меня в GNS3 rpvst работает ужасно. Если свитчи работают по протоколу pvst — все замечательно, обещанные 20-30 секунд простоя и т.п. А при работе с rpvst после разрыва линка связь пропадает на теже 20-30 секунд, но после восстановления «физики» пинги так и не проходят (проходят через раз и с огромными задержками) либо в ответ на запрос ping выдает ответ «64 bytes from 172.16.0.4: seq=520 ttl=63 time=14903.532 ms (DUP!)» что за DUP непонятно
avatar
и почемуто типы портов между свитчами shared, хотя я изменил их статусы с duplex auto на duplex full
avatar
С Portfast'ом нужно быть осторожно иначе может возникнуть петля. Был у нас такой случай в компании, на всех access портах включили портфаст для телефонии, в итоги один умник воткнул провод из одной циски в другую и сеть начала логать, ни pvst ни rpvst не заблокировали порт. В итоги целую неделю искали проблему.
avatar
Доброго времени суток, спасибо вам большое за материал.
У меня такая проблема, после того, как aгрегировл 5 линков между msk-arbat-dsw1 и msk-arbat-asw1, из сети ПТО компьютер перестал пинговаться даже шлюз =)
avatar
Сорри оказывавется интерфейсы на c 20-24 asw3 были в состоянии down, глубочайше извиняюсь )
avatar
Здравствуйте!
Подскажите, пожалуйста, почему на msk-arbat-dsw1 у вас порты gi1/1, gi1/2, а у меня gi0/1, gi0/2? Это связано как-то с версией PT?
avatar
Здравствуйте!
Подскажите пожалуйста, по какой причине может не запускаться STP? меняю топологию сети согласно заданию (сеть из третьей части рабочая, все пингуется), когда заканчиваю настройку порт gig 0/1 на msk-arbat-asw2 не переходит в статус блокировки, остается активным, и в некоторых случаях в 3м вилане удается сделать широковещательный шторм. Вроде все перепроверил, ошибку не могу найти. несколько раз пересобирал сеть по заданию 4й части, ошибка остается.
avatar
Более, чем вероятно, что это баг РТ. Он с STP совсем плохо дружит.
avatar
Спасибо! Можно ли последующие лабораторные/практические работы делать и тренироваться в GNS?
avatar
В целом да. Только NAT будет отработать чуть более сложно — придётся сервера через виртуальные машины заводить.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.