Проблема с агрегацией каналов в Oracle VM Server 3.2.8. В чем может быть проблема дропнутых пакетов на интерфейсах? Как узнать, что это за пакеты?
Замечая разницу между общим количеством "дропов" на интерфейсе 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 и выше.
Замечая разницу между общим количеством "дропов" на интерфейсе 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 и выше.