Jump to content

Recommended Posts

Posted

Здравствуйте!

Есть проблема, а точнее, большая проблема...

Проблема в том, что при проэктировке сети было решено использовать топологию кольцо для свичей доступа :)

Итак, что имеем:

3627g или 3426g --> 3526 --> 3526 --> 3200 --> 3200 --> 3526 --> 3200 --> 3200c1 --> 3526 --> и обратно в тот-же дгс.

Таких веток много, 10 штук на дгс, длинна веток от 8 до 16 свичей.

В продакшене запущено одно кольцо уже пару месяцев для проверки, и вроде все работает нормально, но...!

Хотелось бы узнать, какие грабли могут неожиданно появиться?

В проэкте по десять колец на один дгс, начитался тут всякого, и про проблемы с RSTP во время прошивки свича, и проблемы с ism vlan. И у кого-то даже вся сеть колом встает после грозы :)

И самое главное, это конфиг RSTP. У длинков стандартный конфиг разный. На 3627 параметр TX Hold Count равен трем. На остальных свичах - 6. Сейчас таймеры стоят по умолчанию. Стоит ли как-то подправить таймеры???

Posted (edited)

умею готовить RSTP на длинках до 40 коммутаторов в кольце

если нужна будет помощь или удаленная настройка с нуля, за небольшое вознаграждение, то в ЛС :)

Edited by mcdemon
Posted

Если по 10 колец, то вам лучше смотреть в сторону ERPS. Но, на сколько я помню, 3526 его не поддерживает :(

На д-линках такого нет :(

вообще оптимально на практике не более 7 коммутаторов в кольце

оптика была брошена еще в 2004 году! Запаса по волокнам нет вообще. А докупать, тем более с долларом в 65, очень дорого.

умею готовить RSTP на длинках до 40 коммутаторов в кольце

если нужна будет помощь или удаленная настройка с нуля, за небольшое вознаграждение, то в ЛС :)

Спасибо, но хотелось бы самому. Не просто так же я на этой ветке форума :)

Posted

На д-линках такого нет :(

Только вчера его настраивал на DGS-3612G/DES-3200-28 C1/DGS-3120-24SC. На 3200 A/B ревизии тоже есть. Его не только на 3526, а их пора уже на свалку
Posted

нужно сильно изолировать кольца друг от друга. мы каждое кольцо заворачиваем в QinQ. При этом на 3627 делаем интерфейс на этом qinq и даем подсеть. Это позволило делать vlan на порт и удобно запоминать. подсеть 10.4.61.0/24. значит заворачиваем в тэг 1061. Внтури нумерация такая: 2310 (где 23 - это последний октет ip-адреса коммутатора 10.4.61.23, а 10 - номер порта)

 

на BRAS видим, что абонент в интерфейсе 2/15 vlanid 1061:2310. сразу понимаем, что коммутатор 10.4.61.23, порт 10.

Vlan управления в кольце default. на 3627 соответственно 1061 и untagged в кольцо.

 

Про Igmp multicast vlan можно сделать тоже финт: включить все транк порты как source и отключить data learning forward. тогда конечно мультикаст будет во всем кольце, но при обрыве услуга сохранится.

Posted

встречал такое решение, при аналогичной топологии(плюс/минус) :

Каждое кольцо(доступа) отдельный сегмент rstp( с желательным расставленнием приоритета на концах кольца(обязательно на мой взгляд, это запрет приема с абонентских портов пакетов могущих изменять топологию ) ), а коммутаторы 3627g,3426 в отдельный сегмент mstp(кольцо минимум из двух комков, так же с расставленными приоритетами).

 

Насчет таймингов сильно не заморачивайся , лучше увеличь на комках , на которых по дефолту меньшие значения, до дефолта больших значений с других комков, если на 2 сек увеличится время перестройки топологии это не критично

Posted (edited)

Можно ещё на коммутаторах доступа вообще не включать RSTP. Включать только на 3627, один порт у вас станет Designated, другой Backup.

Есть основные плюсы и минусы:

+ настраивается просто

+ работает быстро

- 50% полосы всегда простаивает

 

Если 3627в какой-либо глобальной топологии не участвует - можно использовать ERPS.

Edited by g3fox
Posted

Можно ещё на коммутаторах доступа вообще не включать RSTP.

Это если коммуаторы будут прозрачно форвардить стп пакеты...

 

Да, разумеется. А в чём сложность?

На длинках 3028, 3526, 3200-28 всех версий и серий проверено - работает.

 

Правда, не совсем прозрачно. Похоже, что BPDU пакеты, вне зависимости от того включено ли STP на моммутаторе, ходят через софт.

Т.к. если в цепочке зависает коммутатор таким образом, что аппаратно всё работает (транзитный трафик ходит), а сам он никак не реагирует на тыканья палочкой, то BPDU через него не проходят и начинается веселье.

Бывает невероятно редко, и чуть чаще в грозу.

 

Мы с такими ситуациями боремся с помощью traffic_control для broadcast в режиме shutdown.

Posted

Да, разумеется. А в чём сложность?

Ну я сталкивался с тем, что далеко не все свичи это умеют.

 

А, тогда понятно. Я, наоборот, с таким не сталкивался.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.