Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    info@proxmox.su
    +7 (495) 320-70-49
    Заказать звонок
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Телефоны
    +7 (495) 320-70-49
    Заказать звонок
    0
    0
    0
    Аспро: ЛайтШоп
    • +7 (495) 320-70-49
      • Назад
      • Телефоны
      • +7 (495) 320-70-49
      • Заказать звонок
    • info@proxmox.su
    • Москва, Бакунинская улица, 69с1
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Proxmox Виртуальная Среда
    [ОШИБКА] Сеть работает выборочно, не могу понять почему.

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    [ОШИБКА] Сеть работает выборочно, не могу понять почему., Proxmox Виртуальная Среда
     
    lifeboy
    Guest
    #1
    0
    13.06.2022 22:38:00
    У меня есть четыре узла с LAN-адресами 192.168.131.1, .2, .3 и .4. Все они настроены одинаково, за исключением последнего октета IP-адреса. То есть NodeA имеет .1, NodeB — .2, NodeC — .3, и так далее. Например, NodeB:  
     
    vmbr0 — это LAN, и он же LAN на гостевой системе pfSense. vmbr1 — шлюз в интернет. Это позволяет запускать гостя pfSense на любом узле и при этом обеспечивать как интернет, так и доступ ко всему, что открыто через pfSense. Также я подключаюсь к гостю pfSense по OpenVPN для удалённого доступа.

    Однако с воскресенья вечером, как будто ни с того ни с сего, NodeB перестал видеть pfSense, и pfSense тоже не может достучаться до NodeB. При этом у NodeA, C и D всё нормально. Более того, я могу достучаться до NodeB с NodeA, C и D. pfSense видит NodeA, C и D и все запущенные там гости, но не видит ничего на NodeB (что вполне логично, ведь он не может достучаться до моста vmbr0 на NodeB).  
    Тем не менее pfSense "знает" только про LAN-мост в сеть 192.168.131.0/24 через vmbr0. Если не имеет специальной информации о NodeB, как может получиться, что NodeB оффлайн, а A, C и D работают нормально?  

    У меня есть второй гость pfSense (используется как CARP failover) с точно таким же поведением. Их LAN-адреса 192.168.131.252 (первичный) и 192.168.131.253 (резервный). Они пингуют друг друга по этим адресам, но ни один из них не может пинговать 192.168.131.2 (LAN-мост NodeB). Похоже, что где-то стоит блокировщик IP-адресов. Если бы только один файрвол вел себя так, я бы заподозрил что-то с pfSense, но раз оба ведут себя одинаково, это явно указывает на проблему с NodeB.

    Есть ли в Proxmox что-то, что может блокировать трафик? Нет, файрвол Proxmox не используется.  

    Есть идеи, как найти причину?  

    P.S. Просмотрел syslog. В один момент всё работает нормально, а в следующий — Proxmox Backup Server недоступен (таймаут). Больше никаких признаков проблемы нет.
     
     
     
    lifeboy
    Guest
    #2
    0
    20.08.2022 14:12:00
    Снял пометку «решено» с этой темы, так как так и не смог понять, почему это случилось изначально... Два дня назад был сбой теста постоянного тока, и теперь вдруг проблема с NodeB вернулась. NodeB может общаться в «LAN» через vmbr0 с другими хостами в сети 192.168.131.0/24, он также может достучаться до гостей на самом NodeB, но не может связаться с гостями на других узлах. Он не может достучаться ни до одного из экземпляров pfSense. pfSense не пингует NodeB. В ARP-таблице pfSense1 нет записи для 192.168.131.2, но она есть для других узлов. pfSense2 (который находится в режиме CARP standby) на данный момент не имеет ARP-записей для каких-либо узлов. Значит, скорее всего, это не проблема с ARP-кэшем (я его уже чистил). Я проверял syslog, сравнивал конфигурации, но так и не понял, в чём дело.
     
     
     
    lifeboy
    Guest
    #3
    0
    20.08.2022 15:14:00
    Я на самом деле сейчас проверил, поменял конфигурационные файлы местами: 0000:18:00.1 теперь называется eth1, а 0000:19:00.0 — eth2, но результат остался прежним. Код:  
    ls -la /sys/class/net/eth*  
    lrwxrwxrwx 1 root root 0 20 авг 15:07 /sys/class/net/eth0 -> ../../devices/pci0000:17/0000:17:00.0/0000:18:00.0/net/eth0  
    lrwxrwxrwx 1 root root 0 20 авг 15:07 /sys/class/net/eth1 -> ../../devices/pci0000:17/0000:17:02.0/0000:19:00.0/net/eth1  
    lrwxrwxrwx 1 root root 0 20 авг 15:07 /sys/class/net/eth2 -> ../../devices/pci0000:17/0000:17:00.0/0000:18:00.1/net/eth2
     
     
     
    lifeboy
    Guest
    #4
    0
    20.08.2022 14:38:00
    Вот странное открытие.  
    Код:  
    root@FT1-NodeA:~# udevadm info /sys/class/net/eth0 | grep ID_PATH  
    E: ID_PATH=pci-0000:18:00.0  
    E: ID_PATH_TAG=pci-0000_18_00_0  
    root@FT1-NodeA:~# udevadm info /sys/class/net/eth1 | grep ID_PATH  
    E: ID_PATH=pci-0000:18:00.1  
    E: ID_PATH_TAG=pci-0000_18_00_1  
    root@FT1-NodeA:~# udevadm info /sys/class/net/eth2 | grep ID_PATH  
    E: ID_PATH=pci-0000:19:00.0  
    E: ID_PATH_TAG=pci-0000_19_00_0  

    Код:  
    root@FT1-NodeB:~# udevadm info /sys/class/net/eth0 | grep ID_PATH  
    E: ID_PATH=pci-0000:18:00.0  
    E: ID_PATH_TAG=pci-0000_18_00_0  
    root@FT1-NodeB:~# udevadm info /sys/class/net/eth1 | grep ID_PATH  
    root@FT1-NodeB:~# udevadm info /sys/class/net/eth2 | grep ID_PATH  

    Словно eth1 и eth2 отсутствуют на NodeB. Но...  

    Код:  
    root@FT1-NodeA:~# ls -la /sys/class/net/eth*  
    lrwxrwxrwx 1 root root 0 Aug 19 03:40 /sys/class/net/eth0 -> ../../devices/pci0000:17/0000:17:00.0/0000:18:00.0/net/eth0  
    lrwxrwxrwx 1 root root 0 Aug 19 03:40 /sys/class/net/eth1 -> ../../devices/pci0000:17/0000:17:00.0/0000:18:00.1/net/eth1  
    lrwxrwxrwx 1 root root 0 Aug 19 03:40 /sys/class/net/eth2 -> ../../devices/pci0000:17/0000:17:02.0/0000:19:00.0/net/eth2  

    Код:  
    root@FT1-NodeB:~# ls -la /sys/class/net/eth*  
    lrwxrwxrwx 1 root root 0 Aug 20 13:35 /sys/class/net/eth0 -> ../../devices/pci0000:17/0000:17:00.0/0000:18:00.0/net/eth0  
    lrwxrwxrwx 1 root root 0 Aug 20 13:35 /sys/class/net/eth1 -> ../../devices/pci0000:17/0000:17:02.0/0000:19:00.0/net/eth1  
    lrwxrwxrwx 1 root root 0 Aug 20 13:35 /sys/class/net/eth2 -> ../../devices/pci0000:17/0000:17:00.0/0000:18:00.1/net/eth2  

    eth1 и eth2, похоже, перепутались на NodeB. Хотя я переименовал порты одинаково на обоих узлах.  

    Код:  
    FT1-NodeA:~# cat /etc/systemd/network/10-rename-enp24s0f1.link  
    [Match]
    Path=pci-0000:18:00.1  
    [Link]
    Name=eth1  

    FT1-NodeA:~# cat /etc/systemd/network/10-rename-enp25s0f0np0.link  
    [Match]
    Path=pci-0000:19:00.0  
    [Link]
    Name=eth2  

    Код:  
    FT1-NodeB:~# cat /etc/systemd/network/10-rename-enp24s0f1.link  
    [Match]
    Path=pci-0000:18:00.1  
    [Link]
    Name=eth1  

    FT1-NodeB:~# cat /etc/systemd/network/10-rename-enp25s0f0np0.link  
    [Match]
    Path=pci-0000:19:00.0  
    [Link]
    Name=eth2  

    Так почему же система меняет местами eth1 и eth2? Файл переименования явно говорит наоборот. Есть идеи?
     
     
     
    lifeboy
    Guest
    #5
    0
    20.08.2022 15:59:00
    Я изучаю https://wiki.debian.org/NetworkInterfaceNames, чтобы попытаться найти решение.
     
     
     
    lifeboy
    Guest
    #6
    0
    20.08.2022 17:10:00
    Это буквально ошибка в именовании. Если я просто добавлю eth1 в мост vmbr0 и использую eth2 для corosync, узел работает нормально. Подожду, кто сможет объяснить, иначе отправлю баг-репорт в Debian. Или это стоит сделать в Proxmox?
     
     
     
    lifeboy
    Guest
    #7
    0
    25.12.2022 13:26:00
    Сегодня утром перезагрузка узла, который давно не перезагружался, вызвала те же симптомы, о которых здесь сообщали. До меня дошло, что это может быть связано с новой версией ядра, при которой и происходит эта подмена портов. При дальнейшем расследовании вот что обнаружил. NodeA работал на ядре 5.15.35-1-pve. Установлено последнее ядро, но перезагрузка не проводилась. Сейчас NodeA запущен на ядре 5.15.83-1-pve. Физические порты eth1 и eth2 теперь поменялись местами. Поскольку я не устанавливал и не запускал промежуточные версии ядра, точно сказать, когда именно появилась эта ошибка, не могу. Это баг. Куда мне про это пожаловаться?
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

    Конфиденциальность Оферта
    © 2026 Proxmox.su
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры