Привет, все это репост вопроса, который я задал на форумах cisco, но так и не получил полезного ответа.
Привет, я пытаюсь преобразовать серверы FreeBSD на работе в двухгигабитные линки с задержкой из обычных гигабитных линков. Наши производственные серверы находятся на 3560. У меня есть небольшая тестовая среда на 3550. Я достиг отказоустойчивости, но у меня проблемы с увеличением скорости. На всех серверах установлены гигабитные карты 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. У меня есть сервер (lagg box), настроенный как сервер (iperf -s), а клиентские компьютеры являются клиентскими (iperf -c server-ip-address), поэтому исходный Mac (и IP) различны для обоих подключений.
Любые идеи / исправления / вопросы были бы полезны, так как переключатели концертов - это то, что мне действительно нужно, чтобы ссылки lagg. Спросите, нужна ли вам дополнительная информация.
+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 и другие многопутевые методы на уровне пакетов обязательно основаны на потоках и отлично работают, если у вас много разных потоков, но они не подходят для небольшого количества больших потоков.