LINUX.ORG.RU
ФорумAdmin

получить структуру линков между коммутаторами

 ,


0

2

В общем, начинаю думать о способах решения поставленной передо мой задачи о проектировании сети, чтобы в ней были резервные линии (без них было бы просто и понятно). А чтобы избежать петель, должна быть поддержка RSTP (нужна эта современная версия, чтобы шустро переключало).

Пока нашел такую «литературу»: воть.

Вопросы по RSTP:

1) Может ли RSTP (IEEE 802.1W) делать объединение портов чтобы по ним шел поток с кратным ускорением? Например, надо 3 Гбит/с через три гигабитных порта гнать на сторону... Слышал про LACP, он может дать на трех портах хотя бы 2.5-кратное увеличение пропускной способности?

2) Можно ли получить от «корневого» всю структуру сети? Какие линки куда идут, какие активны, какие порты неактивны и т.п.? Чтобы отобразить это на красивой картинке, где зеленым - линии активные, красным - отсутствующие связи и т.д.? В целях диагностики.

3) Какие самые простые симуляторы посоветуете чтобы можно было в теории погонять такую сеть? Нашел непонятные ns-3 и гуишный Packet Tracer.

Хотелось хотя бы даже самые краткие не-подобные ответы от уважаемых специалистов... :) Просто направление куда ползти.

1) [r]stp исключает петли путем запрещания использование таких линков, так что пропускную способность оно тебе не увеличит.

lacp как раз для объединения полос, но на скорость передачи данных между двумя машинами оно не сказывается.

2) по snmp можно получать состояние линков в xSTP в комплекте с cdp наверно можно постоить все дерево.

vel ★★★★★
()
Ответ на: комментарий от vel

Нету CDP, это ж сиськовый проприетарный, да? Про SNMP понял, действительно, при помощи этого протокола можно узнать и о том как RSTP настроен в данный момент. А дальше, надеюсь, хватит опилков в голове разобраться...

Про исключение линков от петель это понятно, это как бы отдельный вопрос - надо, допустим, в одну сторону гнать поток с N коммутаторов (свыше 2 Гбит/с), значит надо три линии объединить. Понятно что на скорость не сказывается, важно чтобы больше таких каналов пролезло.

I-Love-Microsoft ★★★★★
() автор топика

1. Благодаря LACP несколько параллельных линков с точки зрения RSTP будут выглядеть как один линк.
На цисках выбор линка для пакета осуществляется на основании выбираемой комбинации из mac и IP адресов и tcp/udp портов источника и назначения. Поэтому, чтобы получить больше пропускной способности одного линка между одной парой хостов, эти хосты должны отличаться чем-нибудь из вышеперечисленного (например использовать два и более соединения с разными tcp/udp портами, или виртуальные машины с собственными IP или MAC-ами в режиме бриджа).

2. STP — сравнительно простой протокол. Каждый узел знает только тех кто к нему непосредственно подключен, идентификатор корневого свича и через какой порт этот свич подключен. Чтобы увидеть всю топологию с т.з. STP надо собрать данные с каждого узла.

3. GNS3 и Packet Tracer в основном роутеры позволяют гонять.
Свичи там вроде на самом примитивном уровне.
Подозреваю, что самый простой способ будет купить 3-5 штук б/у-шных Cat2950. На ибэе вон вроде долларов по 25-40 предлагают, там где вы живёте наверняка тоже есть какой-нибудь продавец.

frob ★★★★★
()
Ответ на: комментарий от vel

[r]stp исключает петли путем запрещания использование таких линков, так что пропускную способность оно тебе не увеличит

Мощно задвинул. А что же тогда такое trunk (etherchannel в терминологии Cisco) по-твоему?

zolden ★★★★★
()
Ответ на: комментарий от zolden

stp/rstp/mstp это одно (с некоторой разницей), etherchannel/lacp/pagp это другое.

Во всех stp коммутатор блокирует передачу в дублирующие каналы.

А при аггрегировании мы выбираем в какой канал пихнуть пакет.

vel ★★★★★
()
Ответ на: комментарий от zolden

Да, не путай мягкое с тёплым.

1) По поводу сабжа - в MST/RSTP есть некое подобие распределение нагрузки, но оно работает только между разными вланами. Т.е. для одного влана петля рвется в одном месте, а для другого - в другом. В результате оба физических линка остаются рабочими и гоняют траффик. Но обычно это не то, что нужно.

Etherchannel/Bonding (он же LACP, PgAP, static) прогонит через себя столько траффика, сколько линков в него включишь, но, как уже выше сказали, нужно несколько клиентов с разных сторон чтобы хеш-алгоритм раскидал пакеты по портам.

2) Для этого юзают CDP/LLDP и т.п.

3) Зависит от оборудования.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Etherchannel/Bonding (он же LACP, PgAP, static) прогонит через себя столько траффика, сколько линков в него включишь, но, как уже выше сказали, нужно несколько клиентов с разных сторон чтобы хеш-алгоритм раскидал пакеты по портам.

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

А через 5 портов - я могу в 5 раз больше клиентов пустить? Это важный момент, потому что у меня на работе некоторые дилетанты утверждают что увеличив в 10 раз число линков, скорость увеличится лишь в 2 раза потому что так написано на сайте производителя, но мне кажется это неверное понимание написанного с их стороны и определенно бред, а грамотная настройка решит проблему.

LLDP

Спасибо, то что надо!

I-Love-Microsoft ★★★★★
() автор топика
Ответ на: комментарий от I-Love-Microsoft

При большом кол-ве клиентов с разных сторон LACP-линка скорость будет равна сумме скоростей входящих в него интерфейсов.

Т.е. да, поставив 5 гигабитных портов ты получишь примерно 5 гигабит.

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

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Т.е. да, поставив 5 гигабитных портов ты получишь примерно 5 гигабит.

Спасибо, очень ценные сведения! :)

I-Love-Microsoft ★★★★★
() автор топика
Ответ на: комментарий от blind_oracle

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

В свежих версиях выдаёт 256, но позволяет объединять только 8 линков всё равно. БОльшее количество вариантов хэша позволяет улучшить равномерность распределения трафика по числу линков неравному степени двух.
Видимо считается, что если надо больше восьми линков, то целесообразнее использовать более быстрый интерфейс.

Возможно производитель неведомого свича ненапрасно пишет про 2 гигабита. Это может быть искусственное ограничение на количество линков в канале или (чем чорт не шутит) ограничение связанное с производительностью свича как такового.

frob ★★★★★
()
Ответ на: комментарий от frob

Не отходя от кассы, поинтересуюсь... Предполагаю что есть некая часть прозвучавшего в этой теме протокола, которая отвечает за информирование о загрузке порта, т.е. например через порт идет 358 Мбит/с и я могу получить эту цифру с помощью специального запроса.

P.S. Вот есть даже библиотека Net-SNMP и прочие... Буду изучать, наверняка SNMP или какой-то другой протокол позволяет собирать с комутаторов инфу кто куда сколько шлет.

I-Love-Microsoft ★★★★★
() автор топика
Ответ на: комментарий от I-Love-Microsoft

В случае циски вариантов пока два с половиной: сделать snmpget на нужные OID-ы или зайти в CLI/дать команду/отпарсить выхлоп (можно заскриптовать/за-expect-ить). Ну и половинка — настроить snmp trap на какое-то пороговое значение.

В случае нециски можно предположить как минимум один вариант из первых двух. Сложности будут если управление только через веб-морду, а snmp не поддерживается или не поддерживается конкретно IF-MIB (или аналог).

frob ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

наверняка SNMP или какой-то другой протокол позволяет собирать с комутаторов инфу кто куда сколько шлет.

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

blind_oracle ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

P.S. Вот есть даже библиотека Net-SNMP и прочие...

На самом деле, для того чтобы начать во всё это втыкать тебе нужен snmpwalk и какая-нибудь железка доступная по SNMP. Я кое-какие из своих проверок делал подцепив GNS3 через tun.

Ну и есть всякие nagios и прочие. Возможно кто-то из них умеет карту построить по собранным данным. (Коммерсы такое умеют точно — HP NNM, например или CiscoWorks/Cisco Prime).

frob ★★★★★
()
Ответ на: комментарий от frob

А пока, чтобы тренироваться, есть ли дистр линукса, который будучи установлен на виртуальную машину - будет вести себя как коммутатор? Чтобы настраивался, чтобы портами виртуальных сетевых карт управлял, давал статистику по SNMP и т.д.? Может есть такие, есть же для NAS, может и такое есть. Пока нашел Cumulus для реального железа...

blind_oracle vel

I-Love-Microsoft ★★★★★
() автор топика
Ответ на: комментарий от I-Love-Microsoft

Да возьми живой коммутатор, проще же будет. SNMP-статистику кстати можешь снимать и просто с компа (загрузку сетевых интерфейсов, памяти, CPU и т.п.).

anonymous
()
Ответ на: комментарий от I-Love-Microsoft

Вряд-ли. Есть GNS, есть Packet Tracer, есть софт от Cisco ASA подпиленый для работы в виртуалке, выбирай.

Можно попробовать Vyatta, но это скорее роутер.

Еще можно купить каталист какой-нибудь (2950/2960) за три копейки, они нынче крайне дешевы, особенно на ебаях.

blind_oracle ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Самое близкое чего видел — Nexus 1000v (его вроде даже недавно предлагали триал на два месяца), но... оно не умеет STP =)

В свичах (по крайней мере у циски) много чего реализовано «в железе». Соответственно забабахать более-менее «полноценную» (т.е. такую, чтобы можно было чего-нибудь серьёзно потестировать) версию софтового эмулятора весьма проблематично.
Делать только control plane свича настолько менее полезно, что возможно просто не имеет смысла.

Идея взять для игр несколько 2950-ых хороша тем, что когда-то довольно дорогая железяка уже не поддерживается циской, поэтому всякие «Энтерпрайзы» от них поизбавлялись, уронив цену у старьёвщиков до «пятипортовых свичей для дома для семьи». При этом железка вполне ещё рабочая (ну может вентиляторы придётся смазать или поменять), а по фичам вполне уделывает «продвинутые» модели производителей ориентированных на «домашних» пользователей.
Ну и «дополнительный бонус» — цисок в мире много, чуток освоить их CLI лишним не будет (впрочем это можно и на эмуляторе роутера сделать).

frob ★★★★★
()
15 октября 2014 г.
Ответ на: комментарий от frob

Спустя столько времени отвечу: большое спасибо за ответы! :)

Всё верно, всё уже получило реализацию в моих проектах. Всё именно так как написано Вами. Эмуляция не потребовалась т.к. есть живое железо - а на нём и LLDP и LACP и RSTP и SNMP и прочая чертовщина :)

+ LACP реально увеличивает скорость кратно. Проверял на трех 100-мегабитных линиях :) Реально ровно в три раза увеличилось, причем действительно, чем больше клиентов тем равномернее (по очевидной причине).

I-Love-Microsoft ★★★★★
() автор топика
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)
Ответ на: комментарий от I-Love-Microsoft

На здоровье!

Ещё в VTP палочкой потыкайте, только в продакшн не пускайте.

frob ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.