Search
Write a publication
Pull to refresh
0
0
ghostonthewire @ghostonthewire

User

Send message
>остро стоял вопрос об одновременной работе нескольких устройств одновременно
Может быть «об одновременной работе нескольких устройств» или «о работе нескольких устройств одновременно» было бы достаточно?
1. Вместо sh caller, удобней использовать sh users т.к. присутствует колонка Peer address.
2. У вас что-то не так с таблицей иллюстрирующей вывод команды sh pppoe session: там должно быть по две строчки на сессию.
По ссылке, которую я дал можно прочитать: «By default, loop guard is disabled.» Далее я повторил это по-русски.
Я ничего не писал про PortFast, речь шла про Loop Guard.

PortFast, опять-таки не «детектит петли», а безусловно переводит порт в Forwarding, миную Listening и Learning, всё.
Немного смущает терминология «коммутатор зафиксировал петлю в сети», a la Cosmopolitan. Начнем с того, что петли никакой нет и фиксировать ее никто не мог. В реальность технология Loop Guard придумана для того, чтобы в ситуации если коммутатор перестал получать BPDU на non-designated порт, вместо того, чтобы переводить его в состояние Forwarding, блокирует его на случай однонаправленой потери линка, предотвращая таким образом образование кольца на L2.

Так что утверждение «когда они огребают такое количество широковещательного трафика, они воспринимают это как broadcast-storm» не соответствует действительности в Вашем случае — такая функциональность возможна, но если бы она сработала, сообщение об ошибке было бы другое.

Мне в этой истории непонятны два вопроса:
1. Куда делось BPDU, отсутствие которого спровоцировало Loop Guard ошибку? 6000 мелких пакетов настолько забили транк?
2. Насколько я понимаю, аксесс-коммутаторы соединены одним транком с центральным устройством. Зачем при таком сценарии включать на единственном рут-порте Loop Guard, который по умолчанию выключен на всех портах (во всяком случае на всех железках, которые я видел)? Или все-таки были избыточные соединения?
IP-адреса, даже если они из одной подсети лучше распределять с учетом bit boundary: 192.168.100.0/29, 192.168.100.16/29, etc. Таким образом легче будет вычленять и представлять в виде CIDR группы адресов, например, для списков доступа. К тому же, потом можно будет выделить этот блок в отдельный сегмент, сменив только маску. Для небольшой сети это не критично, но привычка полезная.
Спасибо! Правда тут же выявился баг — на изображении с измененным размером появилась <a href=«b23.ru/6vc»">черная полоса. Баг оказался где-то на границе xorg и firefox (у меня 3.0.3), так что пользователям винды и мака можно не беспокоиться. Где точно я не понял — невнимательно читал тикет. Тем не менее, он устраняется добавлением в xorg.conf (секцию «Device») следующей строки:
Option "XaaNoOffscreenPixmaps"
Как это действие скажется на производительности X-сервера — не ясно, но черных полос больше нет.
Почта была UUCP, кстати.

Information

Rating
Does not participate
Registered