- Вопрос или проблема
- Ответ или решение
- Как определить причины массовых потерь пакетов между физическим интерфейсом и виртуальным мостом
- 1. Обзор конфигурации сети
- 2. Анализ статистики потерь пакетов
- 3. Рассмотрение производительности хоста и ресурсов
- 4. Тестирование и изоляция проблемы
- 5. Ниже приведены рекомендации по дополнительным проверкам
- Заключение
Вопрос или проблема
Надеюсь, у вас все хорошо.
Я в данный момент сталкиваюсь с серьезной проблемой.
У меня есть окружение, всего один коммутатор, с подключенными 2 хостами Proxmox.
Оба хоста Proxmox используют идентичное оборудование и подключены к коммутатору с помощью LACP с 2 соединениями в объединении.
WAN-соединение подключено к Cisco C3850 через порт доступа на VLAN 2100.
На хостах Proxmox задействованы ВМ для предоставления доступа в интернет и сервисов. В данном случае это устройство OPNsense с пропускным интерфейсом vmbr0, выполняющее маршрутизацию между VLAN 3 (доверенные устройства) и VLAN 2100 (WAN).
Сейчас я сталкиваюсь со следующей проблемой.
Иногда, когда я использую голосовые сервисы или приложения и говорю, люди все еще могут слышать меня, но я их совсем не слышу. Начинает заикаться, они звучат как роботы, и я вижу огромные потери пакетов в OPNsense.
(Я заказал второй исправный WAN-канал, потому что считал, что первый WAN-канал был неисправен, но это не подтвердилось, когда я подключил физический хост к WAN-каналу. Так что та же проблема и с новым WAN.)
Это происходит довольно случайно в такие тяжелые вспышки, но всегда есть какой-то “шум” с постоянными потерями пакетов.
Я проверил статистику коммутатора Cisco и статистику bond0 на Proxmox, и они в порядке.
ethtool -S на уровне драйвера также не показывает никаких потерь. Но в самом сетевом стеке Linux, enp7s0 имеет некоторые потери, enp8s0 не имеет, bond0 имеет несколько, а vmbr0 имеет огромные!
Во время загрузки потери увеличиваются примерно на 10000 пакетов в секунду.
Как я могу диагностировать эту проблему? При перемещении ВМ на другой хост проблема сохраняется. Она также возникает с OpenWrt VM вместо OPNsense, так что это не ограничивается только ВМ.
С физическими устройствами, такими как физический OPNsense, все в порядке, даже с подключенным объединением.
Оборудование довольно мощное с материнской платой Gigabyte MC12 серверного класса и Ryzen 5900X на обоих машинах, обе используют 64 ГБ ECC памяти и почти без нагрузки.
Что может быть проблемой? У меня сейчас нет идей, поскольку я считаю физическую сеть стабильной.
Спасибо заранее!
Теперь следуют некоторые статистические данные о моем Proxmox-машине с 20 часами работы.
ip -s link show dev для всех сетевых устройств.
enp7s0
2: enp7s0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
link/ether d8:5e:d3:69:d2:3c brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped missed mcast
575842237 5271571 0 13401 0 4036793
TX: bytes packets errors dropped carrier collsns
1590672 12828 0 0 0 0
bond0
14: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP mode DEFAULT group default qlen 1000
link/ether d8:5e:d3:69:d2:3c brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped missed mcast
8648538202 36785886 0 26848 0 8083302
TX: bytes packets errors dropped carrier collsns
6548328868 25839452 0 0 0 0
vmbr0
15: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether d8:5e:d3:69:d2:3c brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped missed mcast
9229290098 33579578 0 2226906 0 3499408
TX: bytes packets errors dropped carrier collsns
4890727799 23396693 0 0 0 0
Ответ или решение
Как определить причины массовых потерь пакетов между физическим интерфейсом и виртуальным мостом
Столкнувшись с проблемой массы потерь пакетов в сетевой инфраструктуре, состоящей из двух хостов Proxmox, подключенных к переключателю Cisco C3850, важно тщательно подойти к диагностике. Ваша ситуация, которая характеризуется периодическими потерями пакетов при использовании голосовых сервисов, требует комплексного анализа.
1. Обзор конфигурации сети
Для начала необходимо пересмотреть вашу текущую сетевую конфигурацию. Важно удостовериться, что все параметры сетевых интерфейсов и мостов установлены оптимально:
- Линейная скорость: Проверьте, что каждый интерфейс (например, enp7s0 и enp8s0) настроен на оптимальную скорость, соответствующую их физическим возможностям и используя правильный MTU (Maximum Transmission Unit).
- Конфигурация LACP: Убедитесь, что агрегация канала (LACP) настроена корректно как на уровне других хостов, так и на уровне Cisco Switch, чтобы исключить любые несоответствия.
2. Анализ статистики потерь пакетов
Из предоставленной вами статистики заметно, что интерфейсы enp7s0, bond0 и vmbr0 сообщают о значительных потерях пакетов. Следует осуществить более детальное расследование:
- Интерфейс enp7s0: Потери пакетов составляют 13401, что не критично, но является сигналом о потенциальной нагрузке.
- Bond0: Общее количество потерь здесь выше — 26848, что говорит о более сложных проблемах на уровне агрегации.
- Vmbr0: Здесь наблюдается наибольшее количество потерь — 2226906. Это указывает на возможную проблему конфигурации виртуального моста или неправильную маршрутизацию между VLAN.
3. Рассмотрение производительности хоста и ресурсов
Учитывая признаки накладной нагрузки (или, возможно, конфликты в ресурсах), стоит обратить внимание на следующие аспекты:
- Производительность ЦП и ОЗУ: Хорошая аппаратная база (Gigabyte MC12 и Ryzen 5900X с 64 ГБ ECC памяти) предоставляет надежные ресурсы, но при запуске большого количества ВМ может возникнуть конкурентная нагрузка на ресурсы.
- Мониторинг: Используйте инструменты, такие как
htopилиatop, для оценивания текущей загрузки системы и нахождения "узких мест".
4. Тестирование и изоляция проблемы
Следующий шаг — изоляция проблемы:
- Перемещение ВМ: Вы уже переместили ВМ на другой хост, и проблема сохранилась. Это указывает на общие настройки сети, а не на специфическую проблему с хостом.
- Физическое оборудование: Поскольку физические устройства не показывают подобных проблем, убедитесь, что прошивки и драйверы на ваших Proxmox хостах и виртуальных маршрутизаторах актуальны.
5. Ниже приведены рекомендации по дополнительным проверкам
- QoS на оборудовании: Проверьте настройки качества обслуживания на Cisco C3850 и убедитесь, что пакеты не отбрасываются из-за переопределенного QoS.
- Логи и аудит: Анализируйте логи (например,
/var/log/syslogна Proxmox) для выявления возможных ошибок или предупреждений, которые могут указывать на проблемы с сетью или взаимодействием между виртуальными устройствами. - Загрузка VMs: Если возможно, временно отключите ненужные ВМ и посмотрите, изменится ли ситуация с потерей пакетов. Это может помочь локализовать проблему, если она связана с перегрузкой на уровне виртуализации.
Заключение
Учитывая особенности вашей ситуации, очистка статистики, внимательное изучение логов, а также проверки на уровне оборудования и конфигурации, помогут вам pinpoint (подсветить) источники проблем. Если все вышеперечисленные шаги не дадут результатов, возможно, стоит рассмотреть и альтернативные решения, такие как пересмотр архитектуры сети или использование другого подхода к виртуализации. Очень важно обеспечить стабильность и надежность вашей сетевой инфраструктуры для обеспечения качественного пользовательского опыта.