[AlKov]

Дано - сеть с порядка >500 единиц управляемого оборудования (коммутаторы). Все коммутаторы D-Link (DES-3526,DES-3200-10,DES-1100-16,DES-2108).

В "далёком" прошлом, проектируя управление сети, НЕ заложил в структуру сегментацию управления. Ну не знал я про "чудеса с хешем" на DES-3200 (да и не было их тогда в природе).

Сейчас всё управление находится в одном vlan и соотв. в одной /22 подсети, в ядро этот влан приходит на Linux роутер.

Практически ежедневно в логах "The flooding MAC is detected..", в основном во влан управления. Перечитал вдоль и поперек форум длинка и наг, решения не нашел, кроме одного - сегментировать сеть управления (хотя бы).

Теоретически все просто, а вот как сиё осуществить на живой сети удалённо??

[Negator]

1.Выбираешь влан управления.

2.Создаешь его на всех свичах, прописываешь теги на портах.

3.Выбираешь адресацию для сети управления.

4.Поднимаешь интерфейс с данный вланом на линукс роутере. Выкидываешь туда влан в теге.

5.Переводишь интерфейсы свичей в влан управления, попутно изменяя их IP адреса.

6. Profit!

[AlKov]

Вот-вот, теоретически все просто. А вот практически.. В частности этот пункт -

5.Переводишь интерфейсы свичей в влан управления, попутно изменяя их IP адреса.

как реализовать удалённо? Достаточно сделать "одно движение" и.. бегите уважаемый, к свитчу с ноутом..

[woddy]

у взрослых операторов это делается автоматически скриптами.

советую сгенерировать новые конфиги для всех 500 коммутаторов. внимательно проверить.

потом обновлять по 10-20-30 коммутаторов в день. чтоб в случае ошибки не было глобального ***еца.

[AlKov]

у взрослых операторов это делается автоматически скриптами.

Именно так и хочу сделать. Вопрос в этом -

советую сгенерировать новые конфиги для всех 500 коммутаторов.

а конкретнее в порядке действий, таких, чтобы после заливки

не было глобального ***еца.

В том порядке, что был предложен, я предполагаю, что так и будет..

P.S. Схему прилагаю.

[martin74]

а в чем проблема в смене ip интерфейса System ?

config ipif System 10.1.1.2/24 vlan manag

и все...

После этой команды свич перестает быть доступен по старому адресу, но доступен по новому.

Надо зайти по новому и изменить шлюз по умолчанию.

 

Либо сконфигурить dhcp в новом влане и переводить ipif System на dhcp...

[AlKov]

а в чем проблема в смене ip интерфейса System ?

config ipif System 10.1.1.2/24 vlan manag

и все...

После этой команды свич перестает быть доступен по старому адресу, но доступен по новому.

Надо зайти по новому и изменить шлюз по умолчанию.

Отлично! Спасибо за подсказку!

Действительно, сиё легко осуществить telnet-ом из скрипта. Но.. Только на 3100,3120,3200,3526 и возможно 2108.

А что делать с 1100-16, где даже telnet-а нет, только web? Конфиг у него сливается в бинарном виде, поэтому поправить в нем и перезалить не получится. Походу только ручками..

[martin74]

на 2108 не получится тоже ;)

 

конфиг можно на офисной железке правильный сделать, и залить обратно ;)

[AlKov]

на 2108 не получится тоже ;)

Скорее всего, что да.. В 2108 невозможно одной командой сменить IP и management vlan.

конфиг можно на офисной железке правильный сделать, и залить обратно ;)

Не прокатит тоже. В конфиге зашит МАС свитча, и даже если найти его там и изменить на нужный, то после этого потребуется править checksum бинарника. А алгоритм получения checksum неизвестен..

Тупик... Даже ручками через веб непонятно, как удалённо переконфигурить 2108 и 1100.. А их в сети более 150 шт. каждой модели. Даже с учетом того, что часть останется в "старой" vlan, снимать/ставить напляшешься.. :(

[kf72]

оптимальное количество железок в одном управляющем VLANe ? /24 или меньше ?

[dmvy]

traffic segmentation еще не внедряли? думаю он должен помочь в вашей проблеме с fdb

[s.lobanov]

оптимальное количество железок в одном управляющем VLANe ? /24 или меньше ?

 

да хоть 100500 штук, нужно говорить не о кол-ве железок, а кол-ве мак-адресов в fdb. как уже подметили выше, за счёт порт-изоляции можно добиться желаемого эффекта(уменьшение размера мак-таблицы). В контексте management влан кол-во железок не принципиально, т.к. там никто не занимается спуфингами и прочими гадостями

 

на 2108 не получится тоже ;)

Скорее всего, что да.. В 2108 невозможно одной командой сменить IP и management vlan.

конфиг можно на офисной железке правильный сделать, и залить обратно ;)

Не прокатит тоже. В конфиге зашит МАС свитча, и даже если найти его там и изменить на нужный, то после этого потребуется править checksum бинарника. А алгоритм получения checksum неизвестен..

Тупик... Даже ручками через веб непонятно, как удалённо переконфигурить 2108 и 1100.. А их в сети более 150 шт. каждой модели. Даже с учетом того, что часть останется в "старой" vlan, снимать/ставить напляшешься.. :(

 

 

Да получится на самом деле. Поднимаете в старом влане новый шлюз, меняете IP, потом заходите на него по новому IP, меняете vlan, после чего убираете новый шлюз в старом vlan и поднимаете новый шлюз в новом влане.

 

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

[AlKov]

как уже подметили выше, за счёт порт-изоляции можно добиться желаемого эффекта(уменьшение размера мак-таблицы).

Гм.. И что от чего тут "изолировать"?? Это же "аплинки", где в одном физическом порту кроме management vlan "поднимаются" еще и клиентские vlan-ы! Если сделать traffic segmentation до самого "ядра", то придется ВЕСЬ локальный трафик гнать через ядро. ИМХО, это еще большее зло, от которого стараюсь максимально уходить. traffic segmentation есть, но только на уровне "подъезда" (DES-1100-16) и "дома" (DES-3200-10), "выше" - отсутствует. (Дополнил схему соотв. комментариями)

Да получится на самом деле. Поднимаете в старом влане новый шлюз, меняете IP, потом заходите на него по новому IP, меняете vlan, после чего убираете новый шлюз в старом vlan и поднимаете новый шлюз в новом влане.

Идея в общем понятна. Завтра с утречка подумаю насчет реализации (вечер, "котелок" почти не варит :-)).

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

Дык давно уж нарисовано на perl (Net::Telnet). Вот только снова с DES-1100-16 затык - нет у него телнета, здесь придется крепко поизвращаться, особенно с авторизацией.. :(

[s.lobanov]

Гм.. И что от чего тут "изолировать"?? Это же "аплинки", где в одном физическом порту кроме management vlan "поднимаются" еще и клиентские vlan-ы! Если сделать traffic segmentation до самого "ядра", то придется ВЕСЬ локальный трафик гнать через ядро. ИМХО, это еще большее зло, от которого стараюсь максимально уходить. traffic segmentation есть, но только на уровне "подъезда" (DES-1100-16) и "дома" (DES-3200-10), "выше" - отсутствует. (Дополнил схему соотв. комментариями)

 

Интересно, а как в вашей L2-помойке(не обижайтесь, но судя по описанию, у вас именно так) абоненты в одном подъезде обмениваются локальным трафиком? У вас же там порт-изоляция(traffic_seg).

 

Запомните правило - чем меньше L2-сегмент, тем меньше проблем.

 

Дык давно уж нарисовано на perl (Net::Telnet). Вот только снова с DES-1100-16 затык - нет у него телнета, здесь придется крепко поизвращаться, особенно с авторизацией.. :(

 

Ну добавить к вашим надстройкам над Net::Telnet ещё сотню строк кода на WWW:Curl наверное не самая сложная задача.

[AlKov]

Интересно, а как в вашей L2-помойке(не обижайтесь, но судя по описанию, у вас именно так) абоненты в одном подъезде обмениваются локальным трафиком? У вас же там порт-изоляция(traffic_seg).

Это Вы типа прикалываетесь, или действительно не видите? ;)

В принципе, можно не отвечать, давайте лучше по теме.

Запомните правило - чем меньше L2-сегмент, тем меньше проблем.

Дык как бы с пелёнок это уяснил, и именно этим сейчас и занимаюсь и не только в mgmt vlan.

 

P.S. Занимаюсь сейчас реализацией этого

Поднимаете в старом влане новый шлюз, меняете IP, потом заходите на него по новому IP, меняете vlan, после чего убираете новый шлюз в старом vlan и поднимаете новый шлюз в новом влане.

как-бы избежать этого многократного дёрганья интерфейсов?

[NiTr0]

как-бы избежать этого многократного дёрганья интерфейсов?

Кэп намекает: сменить IP пачкой, потом - сменить вланы той же пачкой. Да и подергать не проблема в общем-то на стороннем тазике, в который заведены вланы. Хуже никому от этого не станет. Ессно, на тазике OSPF и т.п. не заводить - дабы меньше сеть дергать.

[AlKov]

Кэп намекает: ..

Хотелось увидеть не очевидное решение.

Но похоже, в данном случае оно одно единственное..

[s.lobanov]

Кэп намекает: ..

Хотелось увидеть не очевидное решение.

Но похоже, в данном случае оно одно единственное..

 

Так а чем решение, предложенное NiTr0 плохо, что вы ещё какие-то варианты?

[kf72]

...да хоть 100500 штук, нужно говорить не о кол-ве железок, а кол-ве мак-адресов в fdb. как уже подметили выше, за счёт порт-изоляции можно добиться желаемого эффекта(уменьшение размера мак-таблицы). В контексте management влан кол-во железок не принципиально, т.к. там никто не занимается спуфингами и прочими гадостями

 

AlKov у вас управление и абоненты сидят в одном 3-м влане?

может тогда абонентов выпнуть в другие вланы, а управление не трогать? у меня ~200 управляемых железок мак адресов во влане управления. центральная циска не умеет TrafSegm и делить его на вланы начал "для души".

абоненты влан на дом / влан на абонента. 60/40.

но тогда локальный трафик побежит через центральный Л3 однозначно. и сколько его у вас? может вы его зря боитесь ?

[s.lobanov]

kf72

Какая у вас cisco?

[AlKov]

AlKov у вас управление и абоненты сидят в одном 3-м влане?

Нет конечно же! Абоненты в 4-х vlan: 4 "района", 4 подсети соответственно.

абоненты влан на дом / влан на абонента. 60/40.

но тогда локальный трафик побежит через центральный Л3 однозначно. и сколько его у вас? может вы его зря боитесь ?

Локальный траф между абонентами "группы домов" одного влан бегает "внутри" DES-3526, между "группами домов" - через "район из группы домов" (DGS-3100) соответственно. Локальный траф между влан - через роутер. Через него же и Интернет.

Планирую "разделить" 4 влан на 2 двумя DGS-3120 (по 2 влан на каждый), на них поднять "локальные" шлюзы и гонять всю локалку через эту пару. Через роутер гнать только Интернет. А "Интернету" суммарно уже за 600М и в перспективе не менее 800. Соответственно, намечаются "узкие" места (1G порты). Вот и хочется максимально разгрузить их для Инета, "очистив" от локального трафика и не поднимая для этого в ядро локальный "мусор".

Собственно трафа в "локалке" не особо много (суммарно менее 1G), да и "локалка" не зря в кавычках - это очень кастрированное понятие. В-основном там бегает только локальный торрент, ну еще особо продвинутые могут гонять что-нибудь tcp/udp по "верхним" портам (выше 32000), всё остальное вырезано ACL-ами на DES-3200 и DES-3526. Локальные сайты/форум не считаю - там вообще "копейки".

И вот с недавних пор стал доставать этот пресловутый "The flooding MAC is detected.." и почему-то в 90% случаев именно в управляющем влан.

Есть конечно подозрение, что дело не столько в отсутствии сегментации, сколько в самих "флудерах", т.к. в логах практически одни и те же "клиенты" (преимущественно DES-2108) и лишь иногда проскакивают МАС-и абонентов (в своих влан естественно).

Но сначала решил всё же навести порядок в структуре сети и только после этого заняться конкретными "персонами".

Так а чем решение, предложенное NiTr0 плохо, что вы ещё какие-то варианты?

Да нормальное решение, именно "очевидное", именно оно и пришло в голову первым. Просто решил на всякий случай поинтересоваться, а вдруг есть что-то более оригинальное и менее "напряжное"? ;)

Edited August 14, 2012 by AlKov

[kf72]

kf72Какая у вас cisco?

сейчас (года два) 6509 sup2. ,когда была 3550-48 на ней включал swi protected, все абоненты сидели в одном влане /16 и сетку нехило колбасило.

делал как здесь, а потом переделывал "на многовланов"

 

Alkov - подумайте о L3 "молотилке" трафика. ваш гигабит локалки разбросанный на несколько портов даже на шине 24гбит/сек не будет ее сильно напрягать. И порт для интернета будет занят только интернетом.

 

имхается мне, что вам гадят плохие порты. по этой причине ВСЕ 2108 поснимал принципиально, битые порты на 3026 вырезаю группами по 4 (где-то была тема), а влан управления делаю один на 7-10 домов.

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

Edited August 15, 2012 by kf72

[AlKov]

Alkov - подумайте о L3 "молотилке" трафика. ваш гигабит локалки разбросанный на несколько портов даже на шине 24гбит/сек не будет ее сильно напрягать. И порт для интернета будет занят только интернетом.

Так именно это я и хочу сделать. Только вместо одной "молотилки" (DGS-3120-24SC) поставить две (два vlan будет жевать одна, два - другая). Между ними сделать "перемычку" с доп. vlan, по которой будет бегать траф между vlan 1-2 и 3-4, "аплинки" DGS-3120 будут смотреть в роутер.

имхается мне, что вам гадят плохие порты. по этой причине ВСЕ 2108 поснимал принципиально

Согласен. Но поснимать ВСЕ 2108 у меня, к сожалению, не прокатит. Доказать необходимость замены оборудования в моей "конторе" возможно только при наличии "веских причин" (сгорел НАПРОЧЬ в грозу, например). :( Явных "флудерастов" потихоньку куда-нибудь сбагрю, а вот остальной кактус придется жевать до посинения.

[Negator]

уберите длинки с L3

и не придется городить огород с 2 "молотилками"

[kf72]

... Между ними сделать "перемычку" с доп. vlan, по которой будет бегать траф между vlan 1-2 и 3-4, "аплинки" DGS-3120 будут смотреть в роутер...

не мучайте себя и абонентов. возьмите С3550 сделайте влан для абонентов на подъезд (влан на коммутатор) в тестовом районе.

Edited August 15, 2012 by kf72