gul_tech (gul_tech) wrote,
gul_tech
gul_tech

Categories:

Ужасы spanning-tree

Давненько ничего сюда не постил, сорри. Материалов достаточно, просто руки не доходят.
Постараюсь не уходить так надолго.

Пока свежо в памяти, расскажу, что у нас приключилось совсем недавно (а точнее - позавчера).

Ничто не предвещало беды, когда port-channel из нескольких 10GE интерфейсов (между cat6500 и extreme x650) упал с сообщением

Jan 17 16:07:01.581 marmot: %PM-SP-4-ERR_DISABLE: channel-misconfig error detected on Po2, putting Po2 in err-disable state

при том, что последнее изменение конфигурации этого шеститонника было за три дня до этого. Потом (через полминуты) он поднимался по autorecover и через пару минут падал опять с тем же сообщением. Пересоздание этого port-channel ситуацию не изменило. В дебаге тоже ничего путного.

На поиск причин и методов устранения ушло около часа.
Как оказалось, один из клиентов начал слать странные bpdu, а поскольку он был включен в x650, на его порту bpdu не фильтровались, а проходили дальше на 6500. А 6500 при этом укладывал port-channel со столь странной диагностикой.

Открыл для себя команду "no spanning-tree etherchannel guard misconfig". Точнее, это sha90w мне её открыл (и заодно себе). Всем рекомендую.

Выводы:
1. STP - зло. Если его использование необходимо, BPDU должны ходить только в пределах собственной сети, и фильтроваться на всех клиентских портах в обе стороны (не лениться делать это через mac acl, где более простых способов нет). Хотя даже в этом случае нельзя быть полностью спокойным.
2. Реализация L2 в Cisco IOS мягко говоря странная.

Приведу ещё один пример, на этот раз гипотетической ситуации, демонстрирующей эти два вывода.
Допустим, мы купили L2-транспорт у стороннего оператора, q-in-q. И этот оператор (по нашей просьбе или по своей инициативе) прописал для нас туннелирование bpdu, "l2protocol-tunnel stp" на каталистах. Мы аккуратно прописали bpdufilter на клиентских портах и используем stp на этом линке.

И тут один из наших клиентов прислал нам туннелированный bpdu-пакет (а фактически, произвольный пакет на мультикастовый мак 01:00:0c:cd:cd:d0). Этот пакет прошёл наш bpdufilter, потому что это не bpdu, и ушёл в этот транспорт. Тамошний каталист, туннелирующий bpdu, обнаруживает уже туннелированный пакет. Вместо того, чтобы его дропнуть, он что-то не очень внятное сообщает в лог и закрывает порт по err-disable, хоть там 8*10GE и 1000 виланов. И не сообщает, в каком вилане ему пришёл вызвавший такую его реакцию пакет. И этот errdisable не отключается.

Фактически имеем примерно то же самое, что в реальном позавчерашнем случае: незащищённость от активности с клиентских портов, крайне скудная диагностика свича и сложность диагностировать проблему вручную, укладывание всего порта (в т.ч. port-channel) из-за одного неожиданного пакета по err-disable вместо того, чтобы просто дропнуть этот пакет, на cisco ios (другие вендоры за этим не замечены).

Как-нибудь при случае расскажу ещё о всяких интересных граблях на mstp (из-за чего мы сейчас используем только pv-stp).
Tags: cisco, stp
Subscribe
  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 5 comments