Pull to refresh
22
0
Send message
Т. е. притащил домой ноут с работы — воткнул, не работает? Надо звонить, объясняться, привязывать новый мак? А если это случилось ночью? Сколько времени я должен потратить, что бы оно заработало?
Говорите, кол-во обращений в техподдержку уменьшилось? Первый бы от вас сбежал как клиент. Нормальная схема только одна — пользователь подключил шнурок — все заработало. Порт девайса = то, что авторизует пользователя и только он.
Нормальный подход тут был бы с 82 опцией дхцп. Пользователь получил ип — знаем с какого порта, какой-бы ип не был получен, трафик посчитаем нужному абоненту. Пользователь не получил ип авторматом? Выставил вручную, еще что-то? Сеть у него не заработала.
Да, знакомо. Еще одна фишка при попадании в такое болото — даже если человек спец, когда он понимает наконец, что хорош не тот, кто способен увидеть проблему и решить ее, не результативный по факту, а умеющий бесконечные отчеты в нужном русле заполнять — он не то, что бы забивает на все, он может начать подходить к делу так. Фирме это нафиг не надо (допустим новая некая технология), но так как ей вообще «по-чесноку» ничего не надо, я хоть с ней поразбираюсь. А когда все в этом болоте доходит до ручки, становится или совсем убыточно или при определенной специфике рушится и случаются крайне неприятные вещи, типа аварий, а то и похуже, разаражается гром и молнии сверху, меняют команду, приходят манагеры новые, неуспевшие развалить свои текующие «болота» и все начинается по новой.
Речь не о петле через впн-тунели, если появится петля на свиче? Любая поясняющая картинка сильно упростила бы дело, но как понял — какие-то свичи есть, к ним что-то подключено, раз «Нет. Он как раз про VPN ничего и не знает.» Вот там и может появится источник широковещательного шторма. Может это не будет петля в виде патчкорта из порта в порт. Может это будет неисправность свича в виде замыкания rx на tx или просто широковещательный флуд. Все это пойдет через мосты по тунелям на другие площадки. То, что этого не было до сих пор, не значит что вероястностью этого можно легко пренебречь. Я знал такие истории, когда тоже люди считали достаточно надуманной проблему и это сходило с рук годами. Зато когда это «выстреливает» — мало не кажется.
На сторм-контрол навели вот эти ваши слова

«Дело в том, что когда они огребают такое количество широковещательного трафика, они воспринимают это как broadcast-storm». Справедливости ради надо отметить, что раз сторм-контрола не было, как вы убедительно сказали, значит и «воспринимают» тут ни при чем. Опять же не для придирок, а для ясности картины. Т.к. случай, имхо, интересный.
Вы только не подумайте, что я придираюсь :) Просто интересно разобраться до конца. Итак. Сторм-контрол реально не клал порт, как я понимаю. Он зарезал по некой уставке броадкасты/мультикасты. Таким образом и бпду перестали ходить, попав под это дело, правильно мыслю? Перестали ходить бпду, луп гуард положил порт. Упал порт, пошли уже друие процессы. А какова была уставка сторм-контрола, не вспомните? Тоже интересно.
И потом. Блочились аксессные порты или алпинки, не совсем понял. Ну и «Loop guard blocking port» — loop гуард это вообще-то защитная фишка именно для stp, что бы блочить порт, если бпду-шки перестали получать. Сторм-контролу вообще по барабану причина шторма. Петля там или просто хост трафик генерит. И опять же — луп гуард надо настраивать вручную.
Если же клался клиентский порт — то почему он не фаст? Обычный ап/даун фаста не дает события изменения топологии.
Почитал. Можно у вас получить пару комментариев?
1. А на цисках был классический STP вместо рапид? RSTP вообще-то в случае измения топологии себя иначе ведет, там это называется синхронизацией, на таймеры вообще не завязано, отрабатывает от миллисек до максимум 1-2 сек для всего домена.
2. Не знаю как 2950, а 2960 как и упомянутые 3560 порт по шторму кладут только если это настроить. По дефолту просто срезают пакеты выше планки, ну и в лог и если настроено — трап. Почему порт клался, а не просто резались пакеты выше лимита?
Кстать, указанная вами модель телесина умеет сторм-контрол как по броадкасту так и по мультикасту. И даже по дестинейшн локап фэйл ака анкновн юникаст.

www.alliedtelesis.com/manuals/S109V110WEBa/PdfManual/S109V110WEBa.pdf

Так что свич хоть и веб-базед, а вполне себе много чего умеет.
При шаред влан нельзя одному маку светиться в разных влан-ах. При этой реализации таблица общая. Тут не в баге прошивки дело, а просто в знании.
Все равно не совсем понял этот изврат, если коротко, то на одном свиче получились закольцованные порты, но в разных влан-ах? Опять же, если свич svl — так делать нельзя, мак-и будут между портами скакать. Только на индепендент реализациях так можно делать. И это даже не баг, это если угодно фича.
Возможно. Тут тогда вопрос в том, реально ли это были две разных сетевухи, или она одна с поддержкой 802.1q. Если одна и она работает транком, то можно себе представить эту проблему в случае SVL, а не IVL. Мак на влан-ах у сервера будет один (ну или на влан-е и нативный), а для SVL это не есть хорошо, как раз эффекты неприятные начнутся.
Таким образом все в ареа0? Или все же вы тут подразумеваете зоны-лепестки?
Что значит обратным ходом, если не секрет?
Спасибо за ответ. Это действительно короче в смысле конфигруации. Тем более если эту редистрибьюцию не надо фильтровать вообще.
А можно глупый вопрос. Не с точки зрения красоты и правильности дизайна, а с точки зрения практических проблем. Что будет, если будет только ареа0 а все остальное пойдет как редистрибьют коннектед с л3 устройств площадок, т. е. все маршруты будут внешними.
Да это уже все поняли :)
А чего бы вам, раз нельзя поменять инфраструктуру, место работы не поменять? Не, я понимаю, всякие бывают обстоятельства. Но все же интересно.
А на клиентском источник флуда оставлять принято? Нужно и то и то.
Более умные L2 коммутаторы как раз проблему очень даже могут решить. В случае старттопика это был скорее всего флуд с широковещанием как по L2 так и по L3. Банальный PACL мог бы помочь. Для корпоративных сетей централизация сервисов с одной стороны и душение межпользовательского общения в рамках сегмента с другой — нормальное дело и для этого как раз нужны умные свичи. А в условиях изоляции клиентского порта тем или иным способом всяким флудам негде разгуляться или на крайняк сильно ограничивается область действия и соответсвенно последствия.
Как бэ это был год, когда классический stp для свича было уже круто и ничего другого еще просто не было. А на счет правильно — от чего же. Только от того, что топология без петель? Ну так его и учили за это юзеры, кривыми руками эти петли устраивавшие. На счет же стабильности — любые вариации на тему stp имеют свои риски, не даром это надо уметь готовить и недаром вендоры городят свои защитные механизмы в духе root guard, loop guard да и тот же storm-control как фича «последней надежды» так же крайне рекомендуется. Однако без stp риски еще больше и опять же недаром это часто включено по умолчанию.
Да часто люди говорят — у нас обычные свичи, ниче не умеют. Ну прямо мыльницы. Уточнишь — умеют и 802.1q и stp и еще из минимального набора. При этом управляющий влан не настроен, конфиг дефолтовый. Раз один человек рассказал, как он попробовал включить stp и сеть пропала на полминуты (что логично :), если вспомнить о значении таймеров). Он застремался и все вернул в зад :)

Information

Rating
Does not participate
Registered
Activity