Коммутационные каналы HP Procurve 1800 Switch-to-Switch и LACP (а также VLAN!)

Коммутационные каналы HP Procurve 1800 Switch-to-Switch и LACP (а также VLAN!)

Я рассматриваю возможность соединения двух (а возможно и трех) коммутаторов HP Procurve 1800 вместе с помощью транков или LACP. Я не могу найти никаких существенных ответов на свои вопросы через Google или здесь.

Я нашел этот вопросЧто означает транкинг «сервер-коммутатор» в коммутаторе Procurve?но ответ на вопрос, кажется, таков: а) Транкинг может означать что угодно; и б) LACP определен. ВопросКакой вариант предпочтительнее: Trunk или LACP?не отвечает - и это не коммутатор-коммутатор, а коммутатор-сервер.

Я также нашел этот вопросВопрос по проектированию локальной сети с HP Procurveно это также не дает ответа на поставленный выше вопрос:Какой вариант предпочтительнее: Trunk или LACP?В любом случае этот вопрос актуален для HP Procurve 2510, а не для HP 1800.

Ни один из этих вопросов, похоже, не описывает нашу точную ситуацию. Есть три коммутатора (все HP 1800):

SW1(VLAN1) <-> SW2(VLAN1) <-> SW3(VLAN1)
               SW2(VLAN6) <-> SW3(VLAN6)

Все коммутаторы — HP 1800-24G (версия оборудования R01) со следующими версиями программного обеспечения:

  • SW1: ПБ.03.01
  • SW2: ПБ.03.01
  • SW3: ПБ.03.04

Все соединения между коммутаторами SW2 и SW3 разрешают только помеченные пакеты и не имеют PVID (согласно рекомендациям справочной документации). Другие порты являются либо VLAN 1, либо VLAN 6 и разрешают все пакеты. Все порты автосогласуются, за исключением случайных настроек 100 Мбит Full Duplex; все остальные — 1 Гбит, ни один из них не имеет 10 Мбит.

Проблема в том, что SW2, похоже, не отвечает на пинги быстро и часто теряет пакеты (как показывает мониторинг с хоста мониторинга на SW3). Другие коммутаторы в порядке и отвечают соответствующим образом. Соединение между хостами, похоже, в порядке. HTTP-ответ от SW1 и SW2 на их интерфейсах управления кажется медленным — медленнее, чем у SW3.

Я подозреваю, что есть узкое место в трафике, и хотел бы создать более крупный канал. Пинги отправляются на IP-адрес коммутатора, а соединения с портом HTTP также показывают медленное время отклика. Предположительно, соединения (HTTP и ICMP) находятся на VLAN1, поскольку там должен быть IP, а VLAN1 в любом случае является управляющей VLAN.

Из прочтения других вопросов, похоже, что "транк" позволит объединить трафик для обеих VLAN на одном проводе - сократив два соединения до одного, или заставив трафик проходить по нескольким проводам для нескольких VLAN. Также похоже, что транки можно объединить с LACP, но желательно ли это?

Мои вопросы:

  1. Что предпочтительнее в этой ситуации: транк или LACP? Почему?
  2. Что HP называет «транком» в данной ситуации?
  3. Как следует поступать с VLAN в этой ситуации?
  4. Пытаюсь ли я решить не ту проблему?
  5. Поможет ли обновление прошивки?

В любом случае я хотел бы получить ответ на все вопросы.

ОБНОВЛЯТЬЯ забыл упомянуть, что я нашелэта веб-страницачто показалось полезным, но также не ответило на мои вопросы напрямую. Похоже (из ответов там), что транкинг предназначен для связи коммутатор-коммутатор, а LACP — для связи сервер-коммутатор.

решение1

LACP — это протокол управления агрегацией каналов. Он предназначен для автоматической и динамической настройки агрегации каналов, когда доступно более одного канала, а другая сторона также использует LACP. Обычно онявляетсяиспользуется с избыточным соединением сервер-коммутатор, поскольку статическая настройка с агрегацией каналов нарушит соединение сервера до тех пор, пока не будут загружены драйверы сетевой карты (где реализована агрегация каналов), тем самым фактически нарушая возможности управления сервером до загрузки или сетевой загрузки.

Для межсоединений коммутаторов обычно предпочтительнее статическая конфигурация, хотя я бы отнес это исключительно к вопросу вкуса.

«Агрегация каналов» и «транкинг» обычно используются как синонимы. Существует определенный стандарт IEEE для LA (802.3ad), и до стандартизации появилось множество фирменных расширений поставщиков, большинство из которых реализованы даже в более новых моделях коммутаторов по причинам обратной совместимости.

Если вы настраиваете агрегацию каналов или группу каналов (LAG/TG), вам следует определить те же VLAN в качестве членов группы для коммутаторов с обеих сторон. Вам следует определять более одного пути (т. е. более одного соединения LAG) между двумя коммутаторами, только если вы a) точно знаете, что делаете, и b) включили STP на обоих подключенных коммутаторах.

Если вы просто подозреваете узкое место в пропускной способности, используйте счетчики статистики портов ваших коммутаторов, чтобы проверить это - вполне возможно, что использование пропускной способности окажется нормальным, и ваша проблема совсем в другом. В основном коммутаторы имеют довольно медленные ЦП и быстрые ASIC, способные выполнять большую часть обработки без какой-либо нагрузки на ЦП. Некоторые операции все еще будут потреблять циклы ЦП, одна из которых довольно "популярна" - это прием широковещательных или многоадресных пакетов. Если ваша сеть генерирует много широковещательного/многоадресного трафика, обработка и отбрасывание пакетов может перегрузить ЦП коммутатора сверх разумного. Опять же, проверьте счетчики, чтобы увидеть, не наблюдается ли в сети чрезмерное количество широковещательных пакетов.

решение2

В операционной системе HP ProVision термин «транк» имеет иное значение, чем термин Cisco «транк».

  • Интерфейсы, не соответствующие стандарту 802.1Q (например, компьютеры или принтеры), известны какНЕОТМЕЧЕННЫЙс ProVision и в Cisco в качествеДОСТУПпорт.
  • Интерфейсы 802.1Q (такие как коммутатор-коммутатор, коммутатор-сервер и коммутатор-телефоны VoIP) известны какОТМЕЧЕНОпорт с ProVision, и Cisco являетсяСТВОЛпорт.
  • Агрегированные интерфейсы известны какСТВОЛпорт с ProVision, ноЭфирный каналс Cisco.

Связанный контент