Академический Документы
Профессиональный Документы
Культура Документы
Сетевые технологии,
Системное администрирование
Tutorial
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
Все выпуски
6. Сети для самых маленьких. Часть шестая. Динамическая маршрутизация
5. Сети для самых маленьких: Часть пятая. NAT и ACL
4. Сети для самых маленьких: Часть четвёртая. STP
3. Сети для самых маленьких: Часть третья. Статическая маршрутизация
2. Сети для самых маленьких. Часть вторая. Коммутация
1. Сети для самых маленьких. Часть первая. Подключение к оборудованию cisco
0. Сети для самых маленьких. Часть нулевая. Планирование
Широковещательный шторм
Часто, для обеспечения стабильности работы сети в случае проблем со связью
между свичами (выход порта из строя, обрыв провода), используют избыточные
линки (redundant links) — дополнительные соединения. Идея простая — если
между свичами по какой-то причине не работает один линк, используем запасной.
Вроде все правильно, но представим себе такую ситуацию: два свича соединены
двумя проводами (пусть будет, что у них соединены fa0/1 и fa0/24).
STP
Основная задача STP — предотвратить появление петель на втором уровне. Как
это сделать? Да просто отрубить все избыточные линки, пока они нам не
понадобятся. Тут уже сразу возникает много вопросов: какой линк из двух (или
трех-четырех) отрубить? Как определить, что основной линк упал, и пора
включать запасной? Как понять, что в сети образовалась петля? Чтобы ответить
на эти вопросы, нужно разобраться, как работает STP.
Что все это такое и зачем оно нужно, объясню чуть ниже. Так как устройства не
знают и не хотят знать своих соседей, никаких отношений (смежности/соседства)
они друг с другом не устанавливают. Они шлют BPDU из всех работающих портов
на мультикастовый ethernet-адрес 01-80-c2-00-00-00 (по умолчанию каждые 2
секунды), который прослушивают все свичи с включенным STP.
Такой подход таит в себе довольно серьезную проблему. Дело в том, что, при
равных значениях Priority (а они равные, если не менять ничего) корневым
выбирается самый старый свич, так как мак адреса прописываются на
производстве последовательно, соответственно, чем мак меньше, тем устройство
старше (естественно, если у нас все оборудование одного вендора). Понятное
дело, это ведет к падению производительности сети, так как старое устройство,
как правило, имеет худшие характеристики. Подобное поведение протокола
следует пресекать, выставляя значение приоритета на желаемом корневом свиче
вручную, об этом в практической части.
Роли портов
После того, как коммутаторы померились айдями и выбрали root bridge, каждый из
остальных свичей должен найти один, и только один порт, который будет вести к
корневому свичу. Такой порт называется корневым портом (Root port). Чтобы
понять, какой порт лучше использовать, каждый некорневой свич определяет
стоимость маршрута от каждого своего порта до корневого свича. Эта стоимость
определяется суммой стоимостей всех линков, которые нужно пройти кадру,
чтобы дойти до корневого свича. В свою очередь, стоимость линка определяется
просто- по его скорости (чем выше скорость, тем меньше стоимость). Процесс
определения стоимости маршрута связан с полем BPDU “Root Path Cost” и
происходит так:
1. Корневой свич посылает BPDU с полем Root Path Cost, равным нулю
2. Ближайший свич смотрит на скорость своего порта, куда BPDU пришел, и
добавляет стоимость согласно таблице
10 Mbps 100
100 Mbps 19
1 Gbps 4
10 Gbps 2
И вот уже после того, как выбраны корневые и назначенные порты, оставшиеся
блокируются, таким образом разрывая петлю.
Состояния портов
Чуть раньше мы упомянули состояние блокировки порта, теперь поговорим о том,
что это значит, и о других возможных состояниях порта в STP. Итак, в обычном
(802.1D) STP существует 5 различных состояний:
Portfast
Для таких случаев используется особый режим порта — portfast. При подключении
устройства к такому порту, он, минуя промежуточные стадии, сразу переходит к
forwarding-состоянию. Само собой, portfast следует включать только на
интерфейсах, ведущих к конечным устройствам (рабочим станциям, серверам,
телефонам и т.д.), но не к другим свичам.
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), соберем таблицу с основными
фактами:
В уже сложившейся топологии только корневой свич Все свичи шлют BPDU в
шлет BPDU, остальные ретранслируют соответствии с hello-
таймером (2 секунды по
умолчанию)
Состояния портов
Роли портов
Механизмы работы
Как мы видим, в 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-адреса получателей и
отправителей и порты. Поэтому в случае возникновения вопроса: “Хей, а чего так
плохо балансируется?” в первую очередь смотрите на алгоритм балансировки.
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, каждый приходящий пакет может проверяться на:
Практика
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
msk-arbat-dsw1>en
msk-arbat-dsw1#show spanning-tree vlan 3
собственно, порт
его роль (Root- корневой порт, Desg- назначенный порт, Altn- дополнительный,
Back- резервный)
его статус (FWD- работает, BLK- заблокирован, LIS- прослушивание, LRN-
обучение)
стоимость маршрута до корневого свича
Port ID в формате: приоритет порта.номер порта
тип соединения
Итак, мы видим, что Gi1/1 корневой порт, это дает некоторую вероятность того,
что на другом конце линка корневой свич. Смотрим по схеме, куда ведет линк: ага,
некий msk-arbat-asw1.
И что же мы видим?
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
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
Проверяем:
VLAN0003
Address 000B.BE2E.392C
Cost 4
Port 26(GigabitEthernet1/2)
Address 000A.F385.D799
Aging Time 20
--------
Но у нас есть ответ медленному PVST+! И ответ этот — Быстрый PVST+ (так и
называется, это не шутка: Rapid-PVST). Посмотрим, что он нам дает. Меняем тип
STP на всех свичах в москве командой конфигурационного режима: spanning-tree
mode rapid-pvst
Снова запускаем пинг, вызываем Годзиллу… Эй, где пропавшие пинги? Их нет,
это же Rapid-PVST. Как вы, наверное, помните из теоретической части, эта
реализация STP, так сказать, “подстилает соломку” на случай падения основного
линка, и переключается на дополнительный (alternate) порт очень быстро, что мы
и наблюдали. Ладно, втыкаем провод обратно. Один потерянный пинг. Неплохо по
сравнению с 6-8, да?
EtherChannel
msk-arbat-asw3(config-if-range)#channel-group 1 mode on
то же самое на 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
Безопасность канального уровня
Агрегация каналов
Все выпуски
6. Сети для самых маленьких. Часть шестая. Динамическая маршрутизация
5. Сети для самых маленьких: Часть пятая. NAT и ACL
4. Сети для самых маленьких: Часть четвёртая. STP
3. Сети для самых маленьких: Часть третья. Статическая маршрутизация
2. Сети для самых маленьких. Часть вторая. Коммутация
1. Сети для самых маленьких. Часть первая. Подключение к оборудованию cisco
0. Сети для самых маленьких. Часть нулевая. Планирование
Широковещательный шторм
Часто, для обеспечения стабильности работы сети в случае проблем со связью
между свичами (выход порта из строя, обрыв провода), используют избыточные
линки (redundant links) — дополнительные соединения. Идея простая — если
между свичами по какой-то причине не работает один линк, используем запасной.
Вроде все правильно, но представим себе такую ситуацию: два свича соединены
двумя проводами (пусть будет, что у них соединены fa0/1 и fa0/24).
STP
Основная задача STP — предотвратить появление петель на втором уровне. Как
это сделать? Да просто отрубить все избыточные линки, пока они нам не
понадобятся. Тут уже сразу возникает много вопросов: какой линк из двух (или
трех-четырех) отрубить? Как определить, что основной линк упал, и пора
включать запасной? Как понять, что в сети образовалась петля? Чтобы ответить
на эти вопросы, нужно разобраться, как работает STP.
Что все это такое и зачем оно нужно, объясню чуть ниже. Так как устройства не
знают и не хотят знать своих соседей, никаких отношений (смежности/соседства)
они друг с другом не устанавливают. Они шлют BPDU из всех работающих портов
на мультикастовый ethernet-адрес 01-80-c2-00-00-00 (по умолчанию каждые 2
секунды), который прослушивают все свичи с включенным STP.
Такой подход таит в себе довольно серьезную проблему. Дело в том, что, при
равных значениях Priority (а они равные, если не менять ничего) корневым
выбирается самый старый свич, так как мак адреса прописываются на
производстве последовательно, соответственно, чем мак меньше, тем устройство
старше (естественно, если у нас все оборудование одного вендора). Понятное
дело, это ведет к падению производительности сети, так как старое устройство,
как правило, имеет худшие характеристики. Подобное поведение протокола
следует пресекать, выставляя значение приоритета на желаемом корневом свиче
вручную, об этом в практической части.
Роли портов
После того, как коммутаторы померились айдями и выбрали root bridge, каждый из
остальных свичей должен найти один, и только один порт, который будет вести к
корневому свичу. Такой порт называется корневым портом (Root port). Чтобы
понять, какой порт лучше использовать, каждый некорневой свич определяет
стоимость маршрута от каждого своего порта до корневого свича. Эта стоимость
определяется суммой стоимостей всех линков, которые нужно пройти кадру,
чтобы дойти до корневого свича. В свою очередь, стоимость линка определяется
просто- по его скорости (чем выше скорость, тем меньше стоимость). Процесс
определения стоимости маршрута связан с полем BPDU “Root Path Cost” и
происходит так:
1. Корневой свич посылает BPDU с полем Root Path Cost, равным нулю
2. Ближайший свич смотрит на скорость своего порта, куда BPDU пришел, и
добавляет стоимость согласно таблице
10 Mbps 100
100 Mbps 19
1 Gbps 4
10 Gbps 2
Если имеют место одинаковые стоимости (как в нашем примере с двумя свичами
и двумя проводами между ними — у каждого пути будет стоимость 19) —
корневым выбирается меньший порт.
И вот уже после того, как выбраны корневые и назначенные порты, оставшиеся
блокируются, таким образом разрывая петлю.
*На картинке маршрутизаторы выступают в качестве коммутаторов. В реальной
жизни это можно сделать с помощью дополнительной свитчёвой платы.
Состояния портов
Чуть раньше мы упомянули состояние блокировки порта, теперь поговорим о том,
что это значит, и о других возможных состояниях порта в STP. Итак, в обычном
(802.1D) STP существует 5 различных состояний:
Portfast
Для таких случаев используется особый режим порта — portfast. При подключении
устройства к такому порту, он, минуя промежуточные стадии, сразу переходит к
forwarding-состоянию. Само собой, portfast следует включать только на
интерфейсах, ведущих к конечным устройствам (рабочим станциям, серверам,
телефонам и т.д.), но не к другим свичам.
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), соберем таблицу с основными
фактами:
В уже сложившейся топологии только корневой свич шлет BPDU, Все свичи шлют BPDU в
остальные ретранслируют соответствии с hello-таймер
секунды по умолчанию)
Состояния портов
Роли портов
— корневой (root), участвует в пересылке данных, ведет к корневому — корневой (root), участвуе
свичу пересылке данных
— назначенный (designated), тоже работает, ведет от корневого свича — назначенный (designated)
— неназначенный (non-designated), не участвует в пересылке данных работает
— дополнительный (alternat
участвует в пересылке данн
— резервный (backup), тоже
участвует
Механизмы работы
Если не-корневой свич не получает hello- пакеты от корневого в Начинает действовать, если
течение Max Age, он начинает новые выборы получает BPDU в течение 3
интервалов
Последовательное прохождение порта через состояния Blocking (20 Быстрый переход к Forward
сек) — Listening (15 сек) — Learning (15 сек) — 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 не умеет ничего из упомянутых в этом разделе команд, поэтому все
без иллюстраций и проверок.
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, каждый приходящий пакет может проверяться на:
Практика
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
msk-arbat-dsw1>en
msk-arbat-dsw1#show spanning-tree vlan 3
собственно, порт
его роль (Root- корневой порт, Desg- назначенный порт, Altn- дополнительный,
Back- резервный)
его статус (FWD- работает, BLK- заблокирован, LIS- прослушивание, LRN-
обучение)
стоимость маршрута до корневого свича
Port ID в формате: приоритет порта.номер порта
тип соединения
Итак, мы видим, что Gi1/1 корневой порт, это дает некоторую вероятность того,
что на другом конце линка корневой свич. Смотрим по схеме, куда ведет линк: ага,
некий msk-arbat-asw1.
И что же мы видим?
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
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
Проверяем:
VLAN0003
Address 000B.BE2E.392C
Cost 4
Port 26(GigabitEthernet1/2)
Address 000A.F385.D799
Aging Time 20
--------
Но у нас есть ответ медленному PVST+! И ответ этот — Быстрый PVST+ (так и
называется, это не шутка: Rapid-PVST). Посмотрим, что он нам дает. Меняем тип
STP на всех свичах в москве командой конфигурационного режима: spanning-tree
mode rapid-pvst
Снова запускаем пинг, вызываем Годзиллу… Эй, где пропавшие пинги? Их нет,
это же Rapid-PVST. Как вы, наверное, помните из теоретической части, эта
реализация STP, так сказать, “подстилает соломку” на случай падения основного
линка, и переключается на дополнительный (alternate) порт очень быстро, что мы
и наблюдали. Ладно, втыкаем провод обратно. Один потерянный пинг. Неплохо по
сравнению с 6-8, да?
EtherChannel
msk-arbat-asw3(config-if-range)#channel-group 1 mode on
то же самое на 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
Безопасность канального уровня
Агрегация каналов