.
Существует в природе технология Etherchannel (у других вендоров называется trunk), которая объединяет несколько (до 8) линков в общую группу, притворяющуюся логически одним интерфейсом. При этом исходящий трафик через EC балансируется на нем при помощи вычисления хэша от каких-либо данных фрейма (например, mac или ip адресов получателя или отправителя). Чаще всего алгоритм вычисления хэша один для всего устройства и всех это устраивает.
Однако, бывают иногда задачи, в которых надо, чтобы на одном EC балансировка работала по одному алгоритму, а на другом - по другому. Самая, пожалуй, популярная задача - это подключение кластера абонентских шейперов, на которых провайдер режет абонентам IPoE полосу: в самом деле, если трафик одного абонента будет проходить через несколько шейперов параллельно, абонент получит не X мегабит полосы, а до 8*X, что обрадует абонента, но никак не обрадует оператора. Так что нужно, чтобы трафик, входящий во внутренние порты кластера, балансировался по src ip, а во внешние - по dst ip. Многие включают такой кластер между двумя разными устройствами, что имеет множество недостатков, но работает.
При этом существует такая замечательная и популярная у операторов платформа - Cisco 7600/Catalyst 6500. Добрая компания Cisco сделала так, чтобы в этой платформе можно было (при соблюдении определенных условий типа наличия DFC на лайнкарте) включать алгоритм балансировки для шасси и для лайнкарты независимо. И возрадовался я, и полез использовать эту прекрасную возможность.
После долгой непродуктивной борьбы выяснилось то самое волшебное. Оказывается, решение о балансировке трафика на выходе из любого EC принимается не на той лайнкарте, через которую этот трафик выходит, а на той, через которую он входит в маршрутизатор. Волшебная логика, не правда ли? :)
Причем, что немаловажно, найти в документации эту "незначительную" особенность теоретически можно, если уже знать, что она такая есть, да и то непросто.
Beware, Cisco! :)
read more at pLuto - Juick
rss2lj