Вопрос или проблема
Существует система Oracle Linux 7 с непробиваемым ядром 5.4.17-2136.304.4.1.el7uek.x86_64 (что является весьма актуальным для системы, похожей на RHEL7, которая обычно использует ядро на базе 3.10).
Сетевые интерфейсы имеют несколько адресов, настроенных как алиасы (я понимаю, что алиасы нужны только для древнего ifconfig, но тем не менее); некоторые из IP-адресов исторические, но не все, и системе по-прежнему необходимо иметь несколько адресов:
root@bccdb:network-scripts# ip addr show dev bond0.610
15: bond0.610@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 192.168.221.195/24 brd 192.168.221.255 scope global bond0.610
valid_lft forever preferred_lft forever
inet 192.168.221.2/24 brd 192.168.221.255 scope global secondary bond0.610:1
valid_lft forever preferred_lft forever
inet 192.168.221.134/24 brd 192.168.221.255 scope global secondary bond0.610:2
valid_lft forever preferred_lft forever
Существует проблема с кэшем маршрутизации и подсказками (адрес, который система использует при исходящих соединениях).
Адрес .195 был активирован первым, поэтому он был преобразован в маршрут локальной сети (192.168.221.0/24 dev bond0.610 proto kernel scope link src 192.168.221.195). Но системе следует использовать .134 по умолчанию.
Мы обновили этот маршрут с помощью ip route change 192.168.221.0/24 dev bond0.610 proto kernel scope link src 192.168.221.134), и ip route теперь показывает правильный маршрут. Но когда я запрашиваю конкретные IP-адреса, он по-прежнему использует старую подсказку источника:
root@bccdb:network-scripts# ip route get 8.8.8.8
8.8.8.8 via 192.168.221.1 dev bond0.610 src 192.168.221.195 uid 0
cache
И он фактически использует этот адрес источника для любых адресов назначения кроме маршрутов, которые мы устанавливаем вручную с помощью ip route add <target-host> dev bond0.610 src 192.168.221.134 (и, если адрес находится в другой сети, с добавленным via 192.167.221.1), где <target-host> — это адрес целевого хоста (/32).
ip route show cache не показывает ничего.
Общий кэш был удален в Linux 3.6, и у нас установлена гораздо новее версия. Есть некоторые объяснения в кэше маршрутизации в последних версиях ядра Linux, но нет предложений по управлению этим кэшем.
Я нашел это предложение, но ip route flush cache не помог.
Как очистить этот кэш?
Это была важная система, и поскольку решение не пришло до начала рабочего времени, мы просто перезапустили интерфейс с помощью ifdown bond0.610, а затем ifup bond0.610, что также привело к очистке таблицы маршрутов (для этого интерфейса). Это привело к отключению на около 5 секунд, что едва приемлемо для этого сервера.
Ответ или решение
Чтобы очистить кэш маршрутизации в системе Linux, нужно понимать несколько моментов о том, как работает маршрутизация в новых версиях ядра. В частности, начиная с версии 3.6, общее состояние маршрутизации больше не хранится в маршрутизаторе, как это было раньше, что может привести к путанице и проблемам с адресами источников.
В вашем случае вы работаете с Oracle Linux 7 и обнаружили, что система использует ошибочный исходный IP-адрес для исходящих соединений, несмотря на то, что маршрут был изменен. Как вы заметили, использование команды ip route flush cache не дало ожидаемого результата, так как в новых версиях ядра эта команда не влияет на поведение системы.
Возможные подходы для решения проблемы:
-
Перезапуск сетевого интерфейса (как вы уже сделали):
Перезапуск интерфейсаbond0.610с помощью командifdownиifupбыл актуальным решением, которое привело к сбросу маршрутов и кэша, но с небольшим даунтаймом. Хотя это и неприемлемо для критичных систем, это часто самый быстрый способ применить изменения, когда другие методы не срабатывают.ifdown bond0.610 ifup bond0.610 -
Явная установка маршрута:
Вы можете попробовать явно установить маршрут с исходным адресом, который вы хотите использовать. Ваша команда для изменения маршрута уже была верной, но убедитесь, что не осталось других статических маршрутов, конфликтующих с желаемым поведением.ip route add 0.0.0.0/0 via 192.168.221.1 dev bond0.610 src 192.168.221.134 -
Проверка дополнительных настроек:
Убедитесь, что в файле сетевых конфигураций (например,/etc/sysconfig/network-scripts/route-bond0.610) нет специальных направлений, которые перенастраивают маршрут -
Использование Policy Routing:
Рассмотрите возможность использования policy routing, настроив таблицы маршрутизации. Это может позволить указать, какой IP-адрес использовать для исходящих соединений в зависимости от источника пакета.Например, добавьте дополнительную таблицу маршрутизации и используйте правила:
echo "200 myTable" >> /etc/iproute2/rt_tables ip route add default via 192.168.221.1 dev bond0.610 table myTable ip rule add from 192.168.221.134 table myTable
Заключение
Ваша проблема может быть связана не только с кэшем маршрутизации, но и с конфигурацией маршрутов и интерфейсов. Поэтому рекомендую попробовать вышеупомянутые методы. Если проблема продолжит возникать, то дальнейшая диагностика, например, анализ логов системы и сетевых пакетов с помощью tcpdump, может помочь выявить корень проблемы.
Также стоит задуматься над долгосрочными изменениями в конфигурации сети, что может позволить избежать подобных ситуаций в будущем.