lacp, cicso 3550, 3560, помогите с настройкой
Привет, все это перепост из вопроса, который я задавал на форумах cisco, но так и не получил полезного ответа.
Привет, я пытаюсь преобразовать работающие серверы FreeBSD в двух-гигабитные лагированные ссылки из обычных гигабитных ссылок. Наши производственные серверы работают на 3560. У меня небольшая тестовая среда на 3550. Я достиг отработки отказа, но у меня проблемы с достижением увеличения скорости. Все серверы работают на картах Gig Intel (EM). Конфиги для серверов:
BSDServer:
#!/bin/sh
#bring up both interfaces
ifconfig em0 up media 1000baseTX mediaopt full-duplex
ifconfig em1 up media 1000baseTX mediaopt full-duplex
#create the lagg interface
ifconfig lagg0 create
#set lagg0's protocol to lacp, add both cards to the interface,
#and assign it em1's ip/netmask
ifconfig lagg0 laggproto lacp laggport em0 laggport em1 ***.***.***.*** netmask 255.255.255.0
Коммутаторы настроены следующим образом:
#clear out old junk
no int Po1
default int range GigabitEthernet 0/15 - 16
# config ports
interface range GigabitEthernet 0/15 - 16
description lagg-test
switchport
duplex full
speed 1000
switchport access vlan 192
spanning-tree portfast
channel-group 1 mode active
channel-protocol lacp
**** switchport trunk encapsulation dot1q ****
no shutdown
exit
interface Port-channel 1
description lagginterface
switchport access vlan 192
exit
port-channel load-balance src-mac
end
очевидно, измените 1000 на 100 и GigabitEthernet на FastEthernet для конфигурации 3550, так как у этого коммутатора 100-битные скоростные порты.
С этим конфигом на 3550 я получаю аварийное переключение и скорость 92 Мбит / с на обоих каналах одновременно, подключаясь к 2 хостам.(Протестировано с iperf) Успех. Однако это только с линией "switchport trunk encapsulation dot1q".
Во-первых, я не понимаю, зачем мне это нужно, я думал, что это только для подключения коммутаторов. Есть ли какая-то другая настройка, которая при этом включается, которая на самом деле отвечает за увеличение скорости? Во-вторых,
Этот конфиг не работает на 3560. Я получаю аварийное переключение, но не увеличение скорости. Скорость падает с гигабайта в секунду до 500 Мбит / с, когда я делаю 2 одновременных соединения с сервером с линией инкапсуляции или без нее. Следует отметить, что оба коммутатора используют балансировку нагрузки source-mac.
В моем тесте я использую Iperf. У меня есть сервер (поле отставания), настроенный как сервер (iperf -s), а клиентские компьютеры являются клиентскими (iperf -c server-ip-address), поэтому исходный mac (и IP) различны для обоих подключений.
Любые идеи / исправления / вопросы были бы полезны, поскольку переключатели концерта - это то, что мне на самом деле нужно, чтобы на них были запаздывающие ссылки. Спросите, если вам нужна дополнительная информация.
2 ответа
+1 к Джеймсу Кейпу. Большинство соединений Ethernet для увеличения скорости влияют только на несколько соединений. Один сокет обычно не распространяется на несколько интерфейсов.
Обратите внимание на использование "обычно", так как я не эксперт по связыванию ссылок.
Агрегация каналов 802.3ad (и многие другие методы многолучевого распространения) обычно разделяют трафик по нескольким каналам для каждого потока, а не для каждого пакета, и для этого есть веская причина: в каждой задержке передачи всегда будет небольшая разница ссылка на сайт. Возможно, один интерфейс имеет более эффективный драйвер, или более высокий приоритет прерывания, или или кабель немного короче, чтобы электроны могли попасть туда быстрее (серьезно). Как бы то ни было, пакеты обычно приходят к месту назначения в другом порядке, чем они были отправлены.
Множество неупорядоченных пакетов - это, как правило, плохая вещь, потому что TCP подтверждает только последний полученный пакет по порядку. Неупорядоченные пакеты приведут к тому, что TCP отправит дубликаты ACK, которые интерпретируются TCP как признак перегрузки, побуждая TCP замедляться (или даже без необходимости повторной передачи, если инициирована быстрая повторная передача TCP).
Конечно, это не проблема, если каждый разговор ограничен одной ссылкой. Никого не волнует, переупорядочивается ли пакет из одного разговора с пакетом из другого разговора.
Поэтому большинство многопутевых реализаций выбирают исходящую физическую ссылку, выполняя алгоритм хеширования для нескольких полей заголовка. Обычно поля заголовка, которые рассматриваются, представляют собой комбинацию:
- src-ip
- src-port (or possibly another identifier if not TCP/UDP)
- dst-ip
- dst-port (or possibly another identifier if not TCP/UDP)
- ip-proto
- vlan-id
Таким образом, для каждого пакета значения каждого из этих полей хэшируются вместе, и результат определяет, из какого интерфейса будет отправлен пакет. В среднем, если есть много разных потоков, одинаковое количество трафика будет в конце каждого канала. Если у вас только один поток, все эти поля будут одинаковыми для каждого пакета, поэтому каждый пакет попадает на одну и ту же ссылку.
Если у вас есть два потока, вы в основном делаете ставку 50/50, что эти два потока будут на разных каналах - это именно то, что вы видите. Если вам не повезло, вы можете снова бросить кости, изменив любую из переменных, которые рассматриваются хеш-функцией: например, попробуйте другой порт. Фактически, включив тегирование 802.1q, вы добавили vlan-id в микс, который, очевидно, изменил результат хэширования.
Кроме того, не существует стандартного способа выполнения хэширования, что означает, что если вы подключили системы от разных поставщиков (или даже разные версии программного обеспечения от одного и того же поставщика), каждая сторона может выполнять хеширование по-разному, поэтому два отдельных потока могут заканчиваться разными ссылками от сервера к коммутатору, но одной и той же ссылкой от коммутатора к серверу.
Суть в том, что 802.3ad и другие многопутевые методы на уровне пакетов обязательно основаны на потоках и отлично работают, если у вас много разных потоков, но они плохо подходят для небольшого количества больших потоков.