Замечая разницу между общим количеством "дропов" на интерфейсе bond0:
bond0 Link encap:Ethernet HWaddr 00:15:17:D6:B0:14
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:9381 errors:0 dropped:6123 overruns:0 frame:0
и количеством "дропов" на интерфейсе, обрабатывающем трафик влана 3:
bond0.3 Link encap:Ethernet HWaddr 00:15:17:D6:B0:14
inet addr:192.168.32.7 Bcast:192.168.32.127 Mask:255.255.255.128
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1561 errors:0 dropped:146 overruns:0 frame:0
предполагаю:
1) как уже отмечено, скорее всего приходит немаркированный трафик (по умолчанию, native vlan на оборудовании cisco имеет номер 1, в нем пересылается служебный трафик вроде CDP и прочая)
2) также вероятно, на сервер приходит трафик в виде фреймов, маркированных (тегированных) 2 вланом. Со стороны коммутатора он разрешен, а на сервере вы его, как я понял, не обрабатываете
Как возможное решение - назначение неиспользуемого влана в качестве native vlan на стороне коммутатора, разрешение только нужных вланов на транке со стороны коммутатора (влан 3 вы используете, влан 2, предположительно, не нужен).
Наличие "дропов" на интерфейсе bond0.3, к сожалению, объяснить не могу. Вероятно, это какие-то отброшенные пакеты вроде ненужного (непрослушиваемого) мультикаста.
На всякий случай, предоставьте, пожалуйста, вывод
ethtool eth0ethtool eth1UPD:
Я попросил предоставить вывод ethtool, чтобы удостовериться в корректном режиме портов (1000Mbps, full duplex). На самом деле, о корректном режиме работы портов говорит отсутствие коллизий и crc-ошибок, но чем больше данных - тем лучше в подобных случаях.
Native VLAN не используется, отдаю в PortChanell только 2 вышеупомянутых VLAN'а.
Предоставьте, пожалуйста, вывод с коммутатора
show interface Port-channel6 switchport Если все-таки выяснится, что на интерфейсе Po6 native vlan установлен в 1, по посмотрите на коммутаторе
show cdp
show cdp interface GigabitEthernet1/3
show cdp interface GigabitEthernet1/39
Как думаете, может это как-то связано с ядром?
К сожалению, я недостаточно владею особенностями работы ядра Linux, чтобы ответить на этот вопрос. Могу лишь предложить использовать
tcpdump на интерфейсе
bond0.3. Необходимо иметь в виду, что пакет, "дропнутый" ядром, может появиться, а может и не появиться в дампе трафика, в зависимости от причины "дропа". Но вполне может быть, чтоб вы увидите чужой мультикаст, например (OSPF Hello с другого конца L2-домена как вариант). Я хочу сказать, что это может быть связано с ядром, а может - и с обстановкой в сети.
UPD2:
Здесь видно, что все-таки native vlan 1 присутствует, упорно гуглил, но так и не понял как убрать эти параметры из конфигурации..
Создайте новый (ранее неиспользуемый) влан на коммутаторе и назначьте его в качестве native, но только на этот интерфейс. Пример:
configure terminal
interface Port-channel6
switchport trunk native vlan XXXX
, XXXX-номер влана.
Еще хотелось бы поделиться наблюдением:
eth0 Link encap:Ethernet HWaddr 00:15:17:D6:B0:14
TX packets:104 errors:0 dropped:0 overruns:0 carrier:0
eth1 Link encap:Ethernet HWaddr 00:15:17:D6:B0:14
TX packets:1141 errors:0 dropped:0 overruns:0 carrier:0
Как следует из этого листинга, объем исходящего трафик с интерфейса eth1 на порядок превосходит объем трафика с интерфейса eth0. Конечно, с такими незначительными показателями торопиться с выводами не стоит, но я вам настоятельно рекомендую проверить схему с объемом трафика более гигабита. У меня есть подозрение, что, в случае, если потребители трафика находятся в другом L2-сегменте (т.е. трафик до них маршрутизируется через default gateway), то производительность может упереться в 1 Гбит/c. Если подобная ситуация будет наблюдаться, обратите внимание на строчку
# cat ./ifcfg-bond0
BONDING_OPTS="debug=1 mode=802.3ad miimon=100 xmit_hash_policy=layer2 lacp_rate=1"
Вероятно, потребуется сменить алгоритм хэширования на более чувствительный к деталям. Но об этом имеет смысл задумываться, имея результаты тестирования с нагрузкой в 1 Гбит/c и выше.
Простой
