Heggi Опубликовано 4 июля, 2012 · Жалоба Сначала о проблеме. Изредка стали происходить необъяснимые аномалии - отваливание всего и вся на несколько десятков секунд. В ядре - кошка 6504. Мониторинг cpu/memory/портов/логов ничего аномального не показывает, но падает все (управление, инет, мониторинг оборудования), а так как все это идет разными путями (но все через циску) - виновник определенно циска. Схема сети - звезда, общих vlan нет (на каждый луч даже свой вилан управления) Но вероятнее всего что-то все-таки откуда-то прилетает (что и откуда не понятно... когда по нубству устроили броадкаст шторм - там CPU ушло в полочку - а тут ничего такого и рядом не лежало) Собственно вопрос: Как правильно конфигурировать порты, отталкиваясь от базовой конфигурации, чтобы отфильтровать максимум проблем, которые могут придти с этой стороны? interface GigabitEthernet1/1 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 70,115 switchport mode trunk P.S. Не понятен еще один момент, 1 vlan не разрешен, однако #sh vlan VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 1 default active Gi1/1, Gi3/17, Gi3/18, Gi4/24 Он не используется, но может быть источником проблем... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 4 июля, 2012 · Жалоба bpdufilter enable, no cdp enable на портах - где они не нужны включить поглубже режимы отладки Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 4 июля, 2012 · Жалоба и нейтив влан указывать какой-нить не используемый. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Rivia Опубликовано 4 июля, 2012 (изменено) · Жалоба Ну тогда уж убедиться, что с обеих сторон фулл-дуплекс. Помню один раз выловили неприятную проблемку как раз на чужом 65хх, патчкорд с гигабитного модуля 65хх шел на 100 мбитный порт нашего устройства и как результат они состыковывались на 100 мбит/с халф-дуплекс, соответственно с коллизиями и потерями, но при этом каталист упорно показывал 100 мбит/с фулл-дуплекс. Изменено 4 июля, 2012 пользователем Rivia Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Heggi Опубликовано 4 июля, 2012 · Жалоба Ну тогда уж убедиться, что с обеих сторон фулл-дуплекс. Помню один раз выловили неприятную проблемку как раз на чужом 65хх, патчкорд с гигабитного модуля 65хх шел на 100 мбитный порт нашего устройства и как результат они состыковывались на 100 мбит/с халф-дуплекс, соответственно с коллизиями и потерями, но при этом каталист упорно показывал 100 мбит/с фулл-дуплекс. В нашем случае все порты - SFP, оптика, 1 Gbit Единственный медный на CPU используется для подключения СОРМ. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sexst Опубликовано 4 июля, 2012 · Жалоба На порту режем броадкаст и мультикаст по проценту от ширины линка. Указываем только разрешенные вланы. Первый вообще принято гасить. Иначе он по умолчанию включен на всех интерфейсах, где обратное явно не прописано. Как уже сказано, включаем фильтры и вообще глобально отключаем все неиспользуемые протоколы. Но падает управление это одно. А падает связь сквозь нее это другое и вряд ли связано с броадкастом и подобными проблемами, она же аппаратно форвардит и от полки на проце не зависит. На моей практике исключение было только когда циску завалило по процессору и ospf по таймауту отсыхал периодически. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...