Почему происходит сбой разрешения DNS при изменении шлюза по умолчанию на резервный канал?

У нас есть странная проблема, я надеюсь, что кто-то может помочь с. У нас есть здание с оптоволоконным каналом и резервным каналом Comcast (коаксиальный кабель).

Система настроена так:

Fiber NID (кабель категории 6 для коммутатора) Comcast (кабель категории 6 для коммутатора) | неуправляемый коммутатор | Unbuntu Linux Box в качестве маршрутизатора (кабель Cat6 от порта WAN к коммутатору) | порт LAN для оптоволокна OLT | 4 оптоволоконных порта GPON, подключенных ко многим ONT

Мы написали сценарий bash, который каждую минуту будет проверять, работает ли основной шлюз (оптоволоконный канал), и если нет, он изменит шлюз по умолчанию на маршрутизатор Comcast 10.1.10.1. Как только основной шлюз снова включится, он автоматически переключится на него.

Мы установили то же самое во многих зданиях, и оно работает отлично, но у нас есть несколько зданий, в которых после того, как шлюз по умолчанию переключится на резервный канал Comcast, DNS большую часть времени вообще не будет разрешаться, а иногда он разрешается после того, как 4 секунды, когда большинство браузеров уже истекают.

Странно то, что если мы отсоединим кабель от OLT, который идет к порту LAN на маршрутизаторе Linux Box, DNS прекрасно разрешается из командной строки на Linux Box и с ноутбука, подключенного к порту LAN маршрутизатора Linux Box.

Если мы подключим ноутбук к порту rj45 на OLT, он странным образом получит адрес IPV6 (Comcast, даже если мы сначала отключим наш маршрутизатор Comcast). Отсюда, если мы отключим оптоволоконные порты GPON, что удалит резидентов из уравнения, Backup Comcast разрешится правильно, и все будет отлично работать, и мы не получим адрес ipv6 (мы используем только ipv4 на стороне локальной сети). Подключите оптоволоконные порты GPON для резидентов, и мгновенно DNS больше не будет разрешаться.

OLT настроен с изоляцией портов, поэтому резиденты не могут «видеть» друг друга. Мы попытались настроить ACL для блокировки всего трафика IPv6, а также всего частного ipv4 не в подсети 172.16.0.0/16, но это не сработало.

/etc/resolv.conf

сервер имен 8.8.8.8
сервер имен 8.8.4.4
сервер имен 1.1.1.1

Файл /etc/resolv.conf одинаков как в резервной, так и в основной цепи.

/etc/сеть/интерфейсы

# Этот файл описывает сетевые интерфейсы, доступные в вашей системе
# и как их активировать. Для получения дополнительной информации см. интерфейсы(5).

# петлевой сетевой интерфейс
авто вот
iFace Lo Inet Loopback


#Сетевой интерфейс LAN (правый порт)
разрешить горячее подключение enp2s0
iface enp2s0 инет статический
    адрес 172.16.1.1
    сетевая маска 255.255.0.0

######## ЗАВЕРШИТЬ НАСТРОЙКУ ЛВС ######################################### ##############

############ ОСНОВНАЯ НАСТРОЙКА WAN #################################### ##############
#WAN
разрешить горячее подключение enp3s0
iface enp3s0 инет статический
    адрес ххх.ххх.ххх.ххх
    сетевая маска 255.255.255.252
    шлюз ххх.ххх.ххх.ххх
    DNS-серверы имен 8.8.8.8 8.8.4.4 1.1.1.1

########### ЗАВЕРШИТЬ ОСНОВНУЮ НАСТРОЙКУ WAN
#Резервная схема WAN
разрешить горячее подключение enp3s0
iface enp3s0 инет dhcp
    DNS-серверы имен 8.8.8.8 8.8.4.4 1.1.1.1

####### END BACKUP WAN SETUP FAILOVER #####################################

Мы сделали tcpdump, мы увидели несколько модемов/маршрутизаторов Comcast на стороне локальной сети (мы искали MAC-адреса). Похоже, что у некоторых жителей есть Интернет Comcast, и они подключили наш ONT к своему маршрутизатору Comcast, и он просачивается в систему. Если я установлю статический IP-адрес 10.0.0.xx и подключусь к порту ONT rj45, я смогу пропинговать и перейти к чьему-то модему/маршрутизатору Comcast. После того, как мы настроим ACL, он теперь заблокирован, но у нас все еще есть та же проблема.

Подводя итог, кажется, что есть что-то (возможно, резидентные модемы/маршрутизаторы Comcast), исходящие от одного или нескольких резидентных ONT, которые мешают разрешению DNS, но только тогда, когда наша система переключила шлюз по умолчанию на наш резервный маршрутизатор Comcast. Повторюсь, это происходит только в двух из многих зданий с одинаковой настройкой. В других зданиях мы, похоже, не видим никаких "модемов/маршрутизаторов Comcast" от жильцов, по ошибке подключившихся к нашей системе.

Любые идеи?

Давненько я не работал в телекоммуникациях, но я начну.

Звучит так, будто у вас петля в сети, или, как вы говорите, жители устроили утечку. Когда кабель OLT-маршрутизатор отключен, сеть находит маршрут к Интернету до того, как сработает резервное копирование. В этом случае он находит маршрут через соединение резидентов с их маршрутизатором comcast. После того, как маршрут установлен таким образом, может случиться так, что даже если более подходящий маршрут станет доступным, когда появится резервная копия, он не сбрасывает таблицы маршрутизатора (возможно, потому, что не видит в этом необходимости).

Это может быть из-за приоритетов маршрутизации.

Проблема сбоя DNS, возможно, связана с тем, что этот порт недоступен через этот псевдомаршрут, или с таким низким приоритетом, что пакеты просто теряются. Если первоначальный поиск DNS (и здесь мои знания становятся немного ненадежными) осуществляется через UDP, возможно, только когда он возвращается к TCOP, он проходит. Но я действительно не уверен здесь.

У меня действительно была такая же проблема несколько десятилетий назад, когда мы обнаружили, что на неработающем канале кто-то установил коммутируемый канал, который автоматически подключался к внешнему миру. Единственная проблема заключалась в том, что когда основной канал вернулся, он не отключил коммутируемое соединение, и вся компания затем маршрутизировалась через этот модем 9.6K. На поиски ушла целая вечность, потому что никто не признавался в содеянном. Похоже у вас что-то похожее.