Сети для самых маленьких. Часть четвертая. L2 и STP
19
613928
80
I think that I shall never see
A graph more lovely than a tree.
A tree whose crucial propertеу
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” и происходит так:
- Корневой свич посылает BPDU с полем Root Path Cost, равным нулю
- Ближайший свич смотрит на скорость своего порта, куда BPDU пришел, и добавляет стоимость согласно таблице
Скорость порта Стоимость STP (802.1d) 10 Mbps 100 100 Mbps 19 1 Gbps 4 10 Gbps 2 - Далее этот второй свич посылает этот 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-адреса получателей и отправителей и порты. Поэтому в случае возникновения вопроса: “Хей, а чего так плохо балансируется?” в первую очередь смотрите на алгоритм балансировки.
Практика
Наверное, большинство ошибок в 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. Есть два пути:
- Вручную установить приоритет, заведомо меньший, чем текущий:
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 - Дать умной железке решить все за тебя:
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, да?
L2 security
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.
EtherChannel/EtherTrunk/LAG
Помните, мы отобрали у офисных работников их гигабитный линк и отдали его в пользу серверов? Сейчас они, бедняжки, сидят, на каких-то ста мегабитах, прошлый век! Попробуем расширить канал, и на помощь призовем 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 — Марат Сибгатулин (inst, tg, in)
- Макс Gluck
Оставайтесь на связи
Пишите нам: info@linkmeup.ru
Канал в телеграме: t.me/linkmeup_podcast
Канал на youtube: youtube.com/c/linkmeup-podcast
Подкаст доступен в iTunes, Google Подкастах, Яндекс Музыке, Castbox
Сообщество в вк: vk.com/linkmeup
Группа в фб: www.facebook.com/linkmeup.sdsm
Добавить RSS в подкаст-плеер.
Пообщаться в общем чате в тг: https://t.me/linkmeup_chatПоддержите проект:
19
613928
80
Ещё статьи
80 коментариев
Здравствуйте. при настроке ip addresa f1/1 для озерков пишет % 172.168.2.4 overlaps with FastEthernet1/0.4. помогите решить эту проблему
Доброго Вам времени суток. Будьте добры, ответье на вопрос. Что будет если заблокируется native vlan по stp (pvst)? Коммутатор не сможет построить дерево?
Привет! Столкнулся с багой в практике STP, во время просмотра видео, когда не блокируется линк и сеть ложится под штормом. Решилось все перезапуском PT, но долго провозился в поисках косяка. Про перезапуск узнал из спойлера в начале раздела «Практика», когда начал читать статью, после видео. Поместите пжлст этот кусок в начало статьи, ибо будь он там, не пришлось бы ломать голову из-за баги!) Спасибо!)
Большое спасибо за Ваши статьи.
Можете повторно выложить материалы выпуска.
Нашел очепятку в эпиграфе
в строчке, где должно быть:
«A tree whose crucial property»
🙂
Спасибо за статью. На будущее стоит добавить еще про MRST (multiprocces RSTP). Данный функционал пользуется спросом у операторов и поддерживается, например, на коммутаторах агрегации Raisecom http://www.raisecom.su/equipment/ethernet_switches/optswitchfege2plus/
Если кратко, MRST позволяет на портах одного устройства создавать несколько независимых STP/RSTP/MSTP колец, так что перестроения в рамках одного кольца не приводят к перестроению других колец.
правильно ли я понял? что
1 Заблокированный (резервный) линк назначается автоматический устройствами то есть выбирается корневое устройство root bridge(switch) далее от него идут dessigneted порты этот же корневое устройство рассылает BPDU пакеты по этим dessigned портам то есть на все порты (так как у корневого устройства все порты в dessigneted?) внутри этих BPDU пакетов содержатся priority ID и MAC адрес устройства (в случаи если priority одниковый то корневой опред по mac адресу) далее мы задали самый низкий приоритет, эти пакеты попадают на другие устройства в сегменте где сравнивается приоритет корневого устройства с приоритетом текущим,(в данном примере у корневого устройства приоритет меньше он указывает этим самым на то что текущее устройство не может быть корневым)
2 не понятно про dessigneted порты это порты (алтернатива) которые введут к корневому устройству (root Bridge?) или они служат только для передачи данных и пакетов BPDU, просто у вас на картинке switch с mac адресом 333333 подключенный к ноутбуку так же имеет designeted порт и как выбирается blocked порт вы сказали по самому меньшему порту в слове меньше вы иммете ввиду Cost то есть скорость порта?
3 насчет агрегирование портов получается в них не может быть петли так как они действуют как один физический канал? и приходящий broadcast кадр не может быть разослан на соседние порты так как они действуют как один физ канал связи ну то есть broadcast идущий по этим 5 агрегированным портам с asw3 на dsw1 не может быть разослан на другие порты так как он считает что это 1 физ канал и в обратку откуда он пришел он не может передать brodcast
Спасибо за понимание Лабу я зделал все правильно читая текстовую версию надеюсь я все понял правильно если что подравьте или укажите где я чего не догнал
Добрый день, Максим. Спасибо за статьи, очень круто, особенно о таких темах, как MPLS. У меня вот какой вопрос возник, относительно роли портов 802.1d и 802.1w, в статье вы пишите, что Alternate Port добавили только в 802.1w и большинство источников тому подтверждение. Но IEEE 802.1D-1998 гласит следующие:
Доступ к IEEE 802.1D-1990 к сожалению закрыт и требует платной подписки, поэтому посмотреть какие там были определены роли портов, не получается. Буду благодарен за любые комментарии относительно этой странной ситуации, поскольку тут существует какое-то объяснение явно, не могут все ошибаться, явно, но с другой стороны и стандарт тоже не может ошибаться.
Здравствуйте!
Подскажите пожалуйста, по какой причине может не запускаться STP? меняю топологию сети согласно заданию (сеть из третьей части рабочая, все пингуется), когда заканчиваю настройку порт gig 0/1 на msk-arbat-asw2 не переходит в статус блокировки, остается активным, и в некоторых случаях в 3м вилане удается сделать широковещательный шторм. Вроде все перепроверил, ошибку не могу найти. несколько раз пересобирал сеть по заданию 4й части, ошибка остается.
Здравствуйте!
Подскажите, пожалуйста, почему на msk-arbat-dsw1 у вас порты gi1/1, gi1/2, а у меня gi0/1, gi0/2? Это связано как-то с версией PT?
Доброго времени суток, спасибо вам большое за материал.
У меня такая проблема, после того, как aгрегировл 5 линков между msk-arbat-dsw1 и msk-arbat-asw1, из сети ПТО компьютер перестал пинговаться даже шлюз =)
С Portfast’ом нужно быть осторожно иначе может возникнуть петля. Был у нас такой случай в компании, на всех access портах включили портфаст для телефонии, в итоги один умник воткнул провод из одной циски в другую и сеть начала логать, ни pvst ни rpvst не заблокировали порт. В итоги целую неделю искали проблему.
Странно, но у меня в 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 непонятно
В табличке для документации ошибоки.
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`а
Приветствую!
Подскажите пожалуйста, как определятся на каком именно свитче будет блокироваться порт в нашем случае. В объяснении из статьи понятно, там 4-й свитч и у него root-порт выбирается по номеру, если стоимости до root’a равны. В статье у Вас на dsw1 — Gi1/2 Altn BLK 4 128.26 P2p. У меня же на asw2 — Gi0/2 Altn BLK 4 128.26 P2p. Стоимости до рута равны от обоих свитчей, т.к. все свитчи связаны гигабитными линками. MAC’и портов? Но порты на разных же всвитчах.
П.С.
Несмотря на многочисленные дифирамбы, Вам, конечно же, еще 100к +ов в карму!
Support Computer Literacy For College Students — Support. Essay my. best custom college papers. has anyone used dissertation writing services, Buy compare and contrast essay in apa format ready in hours. free essay buy compare and contrast essay in apa format ready in hours. Buy compare and contrast essay in apa format ready in hours Write. Pay someone to do my accounting homework Buy compare and contrast essay in apa format ready in hours: Persuasive essay papers Help on science Order an urgent order of the work. You may calculate the final document is printed writing reflective essay and practical subjects. Seeking help from the negative thoughts such as the United Kingdom, Australia, New Zealand, Canada and others. You need to keep our price most affordable compared to other writing papers, Make my lab report for safe New York. Feel free to get your paper and relieve your daily stress, I cant write my essay. Why do our customers order essays so often, and feel confident that their paper will not be spotted anywhere online, on their friend’s laptop, or in an academic journal? The reason is that all our «buy essay» papers are written individually for a particular customer. Our essay writing service does not hold a database of prewritten papers; each paper is checked for plagiarism by special software, and our writers are forbidden to distribute work to any third parties, or they are put under evaluation.
Хорошая документация, но не отражены два важнейших момента: vtp и cep/lldp.
Делайте статьи о траблшутинге l2 и l3
Спасибо авторам за труды. Вопрос по поводу DHCP snooping. Как указано выше ip dhcp snooping trust прописывается на порту который ведет к DHCP серверу. Что если роль DHCP сервера берет на себя сам коммутатор?
ЗЫ в видео нормально воспринимается
такое ощущение будто с видео брали эту блювотину. Дайте ссылку на книгу, в которой описывается с практическими примерами в эмуляторах
Вообще плохо воспринимается, но, му, бе… вы рассказ чтоли пишите?
Студенты понаписали не читаемого текста…
Добрый день!
Такое состояние у меня на 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
Добрый день!
Вродк все настроил а STP почему то не работает. Линк между ASW1 и 2 также горит. Что делать не подскажете?
Спасибо,
Вроде уже разобрался.
На рисунке, я не показал, что коммутаторы связаны м/у собой и каждый сервер тоже должен был подключен к двум коммутаторам, как и клиенты.
Изначально, я по ошибке настроил броадкомы в режиме агрегации (увеличение пропускной способности), хотя нужно было в режиме резервирования физической линии.
В принципе при такой организации все работало, при физическом отключении одного линка связь осуществлялась по второму линку. Но потом проявился один неприятный момент – клиент терял связь буквально на долю секунды. Я подумал, что возникают петли и решил бороться с ними при помощи STP\RSTP.
Потом я выяснил, что на коммутаторах и без меня поднят STP и далее нашел свою оплошность в настройке карточек (т.е нужно было smart load balancing and failover).
Подключение м/у коммутаторами не показал сразу т.к. думал, что оно лишнее и собирался от него отказаться, но потом поразмыслив решил оставить, т.к карточка только контролирует линию до порта коммутатора и не переключится на второй канал (на другой коммутатор) если упадет сервер или соответствующая линия связи к серверу.
Здравствуйте, Прошу помочь разобраться со следующей задачей
Для организации резервирования физической линии в клиентские станции установлены двух портовые сетевые карты Broadcom 5720, которые настроены в режиме агрегирования каналов (Nic teaming) – один ip адрес.
Вопросы:
1) При такой сетевой организации нужно ли как то настраивать коммутаторы, т.е. нужно ли поднимать поддержку протокола STP, RSTP?
2) Если дополнительно объединить два коммутатора патч-кордом. Какие настройки потребуются?
Здравствуйте.Никак не могу разобраться с настройкой 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
Настройте между маршрутизаторами и проблем знать не будете.
И настроить свитч, который бы знал об нашем Ethernet-trunk в GNS3 нельзя.
Станислав, у вас ещё остались вопросы?
Если да, пишите на почту с подробным описанием вопроса. Я пока вас не понимаю.
Если есть возможность, удалите все мои предыдущии сообщения, запаниковал, бывает.
Резюмирую вопросы:
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 то последовательност ь в агрегации каналов, пока побороть никак не могу
Вышлите конфигурацию на info@linkmeup.ru с подробным описанием вопроса. Пока не понимаю, о чём речь.
Доброго дня! Столкнулся вот с такой проблемой, хочу настроить агрегацию каналов в GNS3. Я так понял, что вся настройка коммутаторов заключается в присвоении порту access, dot1q (trunk), qinq.
Пинги не проходят, все порту SW3 в одном vlane (dot1q). Предполагаю это косяк GNS3. Как вы считаете?
Простите, разобрался — перепутаны dsw1 и asw1. выводы почему то наоборот у них^ dsw1 — This is bridge is root
Буду думать дальше
Добрый день, подскажите — скачал проект в начале статьи с уже составленными избыточными связями и стал с ним работать, но остановился на выводе команды:
#show spanning-tree vlan 3
у меня на всех ВЛАН Spanning tree protocol RSTP — я чтото даже засомневался, сейчас конечно попробую изменить, но интересно — это задумка или случайность??
А будет ли отдельно про Etherchannel и балансировки?
Здравствуйте.
Скажите какой смысл в агрегации каналов между dsw1 и asw3 (да и вообще гигабитных линков), если маршрутизатор все равно на 100мбит?
STP часто съедает мозг начинающим, особенно тонкости процесса распределения ролей и статусов портов.
Например, на картинке в начале поста с root/desgn/blck портами есть момент, который стоит осветить отдельно: левый нижний свич выбирает root портом «верхний» порт, хотя у «правого» порта стоимость до рута точно такая же — 38. Выбор root порта в таком случае завязан на Bridge ID свича, от которого спустился BPDU. В нашем примере верхний левый свич имел BrID меньше, чем правый нижний, именно поэтому BPDU от него, поступивший на «верхний» порт и сделал данный порт рутовым.
Спасибо большое, все очень доходчиво рассказано и описано!
А если после того как я подключил msk-arbat-dsw1->msk-arbat-asw2, соединение msk-arbat-asw1->msk-arbat-asw2 «пропадает»(кружочек приобретает оранжевый цвет) Где я допустил ошибку?
В моей версии PT (5.3.3.0019) умеет все из этих команд. Скриншот прилагаю.
Здравствуйте. Никак не могу разобраться. у мне на msk-arbat-dsw1 команда sh spanning-tree выводит информацию лишь о виланах 1 и 2. причем если руками создать вилан на нем, то отобразятся все порты. Что я сделал не так при настройке? вроде бы делал строго по инструкции.
тест
Доброй ночи. На видео на 9:02 Вы настраиваете транк между dsw1 и asw2, но порт указан gig1/1, который ведет к asw1. Я так понимаю, это ошибка, или, я так понимаю, я что-то не так понимаю?
Тут другая логика.)
Вы потратили время, нашли проблему, разобрались лучше с stp и pt 🙂 Вклад в своё развитие)
Исправлено! 🙂 Спасибо
Исправлено! 🙂 Спасибо
В целом да. Только NAT будет отработать чуть более сложно — придётся сервера через виртуальные машины заводить.
Спасибо! Можно ли последующие лабораторные/практические работы делать и тренироваться в GNS?
Более, чем вероятно, что это баг РТ. Он с STP совсем плохо дружит.
Сорри оказывавется интерфейсы на c 20-24 asw3 были в состоянии down, глубочайше извиняюсь )
и почемуто типы портов между свитчами shared, хотя я изменил их статусы с duplex auto на duplex full
Здравствуйте.
У вас BPDU от Root’a приходят на коммутаторы двумя путями: напрямую и через кольцо. Они несут информацию и о Root, и о расстоянии до него и MAC отправителя BPDU. Так что нет ничего удивительного, что у вас выбрался другой коммутатор. Он оказался более выгодным.
Спасибо)
Здравствуйте. столкнулся с аналогичной ситуацией: после настройки 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»
смотрите, что говорит sh spa на одном и на втором. Плюс, если делаете в ПТ, могут быть глюки ПТ.
Я не знаю, как работает NIC teaming. Если это просто Active-Standby и решение ПК принимает сам, то со стороны коммутаторов поддержка не нужна. Если это полноценный LAG, то коммутаторы в вашей схеме (два линка к разных свитчам) должны поддерживать этот функционал (MC-LAG).
Нужен STP или нет также зависит от режима работы этой карты и от того, пропускают ли сервера через себя пакеты, как коммутаторы.
Некорректно выразился.
«на одном простом линке» — имел ввиду не на составной линии.
Два устройства должны быть подключены непосредственно друг к другу. А у вас посередине свитч, который ничего не знает об этом Eth-транке.
Простите за спешку, свежая голова решает проблемы.
Для тех кто столкнулся с подобным:
1) полностью удалите связи
2) Заново подключите физически кабеля
3) ОБЯЗАТЕЛЬНО ПРОВЕРЬТЕ чтоб состояние портов было UP, иначе включите вручную
4 После того как все интервейсы подняты — настраивайте агрегацию
SW3 — выступает на схеме, как провайдер, к которому подключен офис 1 (R4) и офис 2 (R5). Не совсем понятно «Агрегирование настраивается на одном простом линке — то есть между двумя непосредственно подключенными узлами…». Агрегация каналов предусматривает объединение несколько физических каналов в один логический, и какой смысл в настройке на одном простом линке? А что будет с другим? Как через него будет проходить траффик? не поняяяяяяяяяяяяяяяятно((((
Агрегирование настраивается на одном простом линке — то есть между двумя непосредственно подключенными узлами. Коммутатор между ними ставить, во-первых, нельзя, во-вторых, ни к чему, если того, специальным образом не требует дизайн.
И все таки прошу помощи: никак не могу понять — у меня порт Gi1/2 на dsw1 упорно сидит в VLAN2, в списке VLAN 3 он не оторажается
Потому что не прописан vlan 3 на msk-arbat-dsw1
у меня тоже нет третьего вилана, однако действовал я не по видео, а по текстовым инструкциям. Также хотелось бы заметить, что в московской сети на свичах виланы в лабе не прописывались. Это было домашним заданием?
Ну это же конфигурация с предыдущего выпуска. Тогда и создавал.
Без конфигурации сложно сказать. Вообще, конечно, должны быть только те интерфейсы, где настроен этот влан.
Отдельно не будет. Но в самом конце серии будет итоговая статья — типа best practice по построению и резервированию. Скорее всего, там этот вопрос будет затронут.
В принципе тема очень простая, чтобы посвящать ей статью.
В данном случае никакой. Мы тут, скорее, рассмотрели просто вариант применения. Одной из последних статей цикла будет как раз о том, как правильно строить сети и внедрять резервирование.
Вы правы, но это уже тонкости, детали. Мне кажется, их лучше будет понять в ходе работы. Описать всё в статье крайне сложно.
ухты как переклинило twitter oauth, мне выписали левый ник с датой регистрации из будущего
мой ответ был к начальному вопросу)))
Вообще, оранжевый вполне именно это и означает. Просто когда PVST в разных вланах по-разному могут выбираться порты. И тогда он будет зелёным
Ничего подобного, на видео просто название порта загораживало лампочку)))
Извиняюсь за преждевременную панику =)Просто на видеоролике все линки были зеленого цвета)
Всё верно. Это STP блокирует избыточный линк.
Никаких глюков. Необходимо создать влан, и инстанс:
понял, спасибо )
Действительно странно. Попробуйте перезагрузить устройства) Или перходите на GNS. Столько уже глюков отловили на это РТ!
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
!
прошу прощение, не порты, а интерфейсы. на видео если набрать комманду 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?
Прошу прощения, не понял, что значит фраза «причем если руками создать вилан на нем, то отобразятся все порты»?
Если команда VLAN X задана, то и в STP он должен быть.
Здравствуйте. Кажется, вы правы — дома ещё пересмотрю видео. Видимо, ошибся в description. Сути это не меняет — настраивается всё аналогично.