БАЛАНСИРОВКА НАГРУЗКИ ИНТЕРНЕТ-ТРАФИКА С ДВУМЯ ИНТЕРНЕТ-ПРОВАЙДЕРАМИ И ДВУМЯ СЕГМЕНТАМИ ЛАН

[2D-Technology Services]

Привет, участники сообщества! Я настроил отработку отказа/балансировку нагрузки на маршрутизаторе Cisco с использованием двух интернет-провайдеров и двух сегментов LAN Как показано ниже: ![2DTechnologyServices_1-1748619636913.png] С пограничного маршрутизатора: Config. track 1 ip sla 1 reachability
!
track 2 ip sla 2 reachability
!
interface FastEthernet0/0
ip address 10.0.137.54 255.255.255.0
ip nat outside
duplex full
!
interface FastEthernet1/0
ip address 172.16.0.2 255.255.255.252
ip nat outside
duplex full
!
interface Ethernet2/0.10
description FIBER-CONNECTION
encapsulation dot1Q 10
ip address 192.168.10.1 255.255.255.0
ip nat inside
ip ospf 1 area 0
!
интерфейс Ethernet2/0.20
описание MICROWAVE-CONNECTION
инкапсуляция dot1Q 20
ip адрес 192.168.20.1 255.255.255.0
ip nat внутри
ip ospf 1 область 0
!
ip nat inside source route-map FIBER-LINK interface FastEthernet0/0 overload
ip nat inside source route-map MICROWAVE-LINK interface FastEthernet1/0 overload
!
ip route 0.0.0.0 0.0.0.0 10.0.137.1 name FIBER-LINK track 1
ip route 0.0.0.0 0.0.0.0 172.16.0.1 name MICROWAVE-LINK track 2
!
ip sla 1
icmp-echo 4.2.2.2 source-ip 10.0.137.54
owner FIBER-LINK
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 172.16.0.1 source-ip 172.16.0.2
owner FIBER-LINK
ip sla schedule 2 life forever start-time now access-list 101 permit ip 192.168.20.0 0.0.0.255 any
access-list 102 permit ip 192.168.20.0 0.0.0.255 any
!
route-map MICROWAVE-LINK permit 10
match ip address 102
set ip next-hop verify-availability 172.16.0.1 1 track 2
!
route-map FIBER-LINK permit 10
match ip address 101
set ip next-hop verify-availability 10.0.137.1 1 track 1
!
!
!
event manager applet CLEARIPNAT1
event syslog pattern "%TRACKING-5-STATE: 2 ip sla 2 доступность Up->Down"
action 1.0 cli command "enable"
action 2.0 cli command "route-map MICROWAVE-LINK permit 10"
action 3.0 cli command "set ip next-hop verify-availability 10.0.137.1 1 track 1"
action 4.0 cli command "clear ip nat translation *"
event manager applet CLEARIPNAT2
event syslog pattern "%TRACKING-5-STATE: 2 ip sla 2 доступность Down->Up"
действие 1.0 команда cli "enable"
действие 2.0 команда cli "route-map MICROWAVE-LINK permit 10"
действие 3.0 команда cli "no set ip next-hop verify-availability 10.0.137.1 1 track 1"
!
end !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Тестирование !!!!!!!!!!!!! Когда один ISP не работает: EDGE_ROUTER#ping 4.2.2.2 source 192.168.20.1
Введите последовательность символов для прерывания.
Отправка 5 ICMP-эхо-сообщений по 100 байт на 4.2.2.2, таймаут 2 секунды:
пакет отправлен с исходным адресом 192.168.20.1
!!!!!
Успешность 100 процентов (5/5), минимальное/среднее/максимальное время прохождения = 204/210/216 мс EDGE_ROUTER#trace 4.2.2.2 источник 192.168.20.1
Введите последовательность символов для прерывания.
Отслеживание маршрута до b.resolvers.level3.net (4.2.2.2)
Информация VRF: (vrf in name/id, vrf out name/id)
1 10.0.137.1 12 мс 4 мс 8 мс
2 10.10.35.1 12 мс 4 мс 12 мс
3 10.10.30.254 12 мс 4 мс 8 мс
EDGE_ROUTER#trace 4.2.2.2 источник 192.168.10.1
Введите последовательность символов для прерывания.
Отслеживание маршрута к b.resolvers.level3.net (4.2.2.2)
Информация VRF: (vrf in name/id, vrf out name/id)
1 10.0.137.1 12 мс 60 мс 12 мс
2 10.10.35.1 8 мс 8 мс 12 мс
3 10.10.30.254 8 мс 12 мс 8 мс %%%%%%%%%%%%% КОГДА ОБА ИСП РАБОТАЮТ И НАХОДЯТСЯ В РАБОЧЕМ СОСТОЯНИИ %%%%%%%% EDGE_ROUTER#ping 4.2.2.2 источник 192.168.20.1
Пакет отправлен с исходным адресом 192.168.20.1
!!!!!
Успешность составляет 100 процентов (5/5), минимальное/среднее/максимальное время прохождения в обоих направлениях = 200/202/212 мс EDGE_ROUTER#trace 4.2.2.2 источник 192.168.20.1
Введите последовательность символов для прерывания.
Отслеживание маршрута к b.resolvers.level3.net (4.2.2.2)
Информация VRF: (vrf in name/id, vrf out name/id)
1 10.0.137.1 24 мс * 8 мс
2 10.0.137.1 24 мс
10.10.35.1 12 мс
10.0.137.1 24 мс
3 10.10.10.254 8 мс
10.10.35.1 24 мс
10.10.10.254 8 мс
4 10.10.10.254 20 мс
10.46.6.185 12 мс
10.10.10.254 24 мс
5 200.100.65.74 8 мс
10.46.6.185 24 мс
200.100.65.74 8 мс
6 200.100.65.74 20 мс
200.100.65.83 8 мс
200.100.65.74 20 мс
7 200.100.65.18 12 мс
200.100.65.83 24 мс
200.100.65.18 8 мс
8 200.100.65.18 28 мс
200.100.65.22 12 мс
200.100.65.18 24 мс ...Обратите внимание, что вышеуказанный трассировочный паттерн аналогичен паттерну другого сегмента LAN.

[Royalty]

Привет! Спасибо за ответ. Однако после изменений проблема по-прежнему остается...
Отслеживание до 4.2.2.2, похоже, колеблется между ссылками: В своем предыдущем сообщении я упомянул, что трафик, генерируемый маршрутизатором,
не
зависит от PBR. Для этого
необходимо
применить
локальный PBR
. Чтобы ускорить процесс, я приведу ниже пример конфигурации, в которой будут повторно использованы (но необходимо повторно создать) существующие маршрутные карты, примененные к интерфейсам LAN. Обратите внимание, что это не отражает передовой опыт и полную производственную конфигурацию: route-map ROUTER-POLICY permit 10
match ip address 102
set ip next-hop verify-availability 172.16.0.1 1 track 2
set ip next-hop verify-availability 10.0.137.1 2 track 1
!
route-map ROUTER-POLICY permit 20
match ip address 101
set ip next-hop verify-availability 10.0.137.1 1 track 1
set ip next-hop verify-availability 172.16.0.1 2 track 2
!
ip local policy route-map ROUTER-POLICY Что касается остальной части конфигурации, я надеялся и рад видеть, что была применена команда «match interface». Единственная проблема заключается в том, что вы немного неправильно поняли логику. Вам нужно применить команду «match interface» к интерфейсам выхода. Помните, что в данном случае NAT применяется в точке выхода, т. е. после того, как решение о маршрутизации уже принято. Ниже приведен пример изменений, которые вам нужно внести. Надеюсь, это будет понятно: ip access-list standard NAT-ACL
10 permit 192.168.10.0 0.0.0.255
20 permit 192.168.20.0 0.0.0.255
!
route-map FIBER-LINK permit 10
match ip address NAT-ACL
match interface FastEthernet0/0
!
route-map MICROWAVE-LINK permit 10
match ip address NAT-ACL
match interface FastEthernet1/0 В приведенном выше примере мы сообщаем маршрутизатору, что он должен выполнять NAT-преобразование трафика независимо от подсети источника, но применять правильный адрес преобразования на основе выходного интерфейса, выбранного для потока, который определяется PBR. Таким образом мы можем обеспечить отказоустойчивость. Вы также должны убедиться, что интерфейс FastEthernet0/0 ВСЕГДА использует маршрут из своего собственного интерфейса для достижения 4.2.2.2. В противном случае вы получите поведение, которое я описал в своем первом посте, когда объект отслеживания 1 выйдет из строя и останется в таком состоянии на неопределенный срок. Либо это, либо вы окажетесь в ситуации, когда объект отслеживания 1 будет постоянно переключаться между состояниями «вверх» и «вниз», что приведет к серьезным проблемам с прерывистой связью. Опять же, это не лучшая практика, и это можно было бы сделать в Local PBR, но в качестве примера: ip route 4.2.2.2 255.255.255.255 10.0.137.1 Наконец, вернемся к EEM. Вы можете использовать это для очистки преобразования ip nat. Теоретически, с конфигурацией, которую я предоставил, вы должны быть в состоянии пережить сбои в восходящем направлении на оптоволоконном соединении и сбой прямого/следующего прыжка на микроволновом соединении и все равно иметь полное переключение на резервный канал: апплет диспетчера событий CLEAR_FIBER_NAT_TRANS
отслеживание событий 1 состояние любое
действие 1.0 команда cli «enable»
действие 1.1 команда cli «clear ip nat translation *»
! апплет
диспетчера событий CLEAR_MICROWAVE_NAT_TRANS
отслеживание событий 2 состояние любое
действие 1.0 команда cli «enable»
действие 1.1 команда cli «clear ip nat translation *» Сообщите, как у вас дела!

[Royalty]

Привет,
@2D-Technology Services
, Редактировать: Подводя итог большинству проблем, с которыми, по-моему, вы сталкиваетесь Что касается основного вопроса о том же трассировочном шаблоне...
Трафик, генерируемый маршрутизатором (ваши трассировки/пинги из CLI), вообще не соответствует PBR. Вам нужна глобальная конфигурационная команда «ip local policy route-map <route-map>», чтобы дать маршрутизатору указание применять PBR также к самоинициированному трафику.
Расширенные ACL
101
и
102
определяют одну и ту же подсеть (192.168.
20
.0/24). Предполагается, что ACL 101 должен быть 192.168.
10
.0/24?
PBR не применяется к интерфейсам e2/0.10 и e2/0.20 на стороне LAN, поэтому трафик LAN не сопоставляется и не проходит PBR.
Операция IP SLA 1, на которую ссылается команда track, может вызвать флаги маршрута или отказ объекта отслеживания, который никогда не сможет восстановиться.
Переключение EEM довольно интересно для экспериментов. Но оно добавляет ненужную сложность... Я бы порекомендовал несколько других руководств, в которых есть довольно много примеров по Dual ISP NAT с PBR. На самом деле вам даже не нужно использовать PBR для маршрутизации трафика. Вам придется изменить/дополнить некоторые настройки, включая некоторые из вещей, которые я приведу ниже по другим вопросам. 1.
В данном случае я не думаю, что ваши трассировки маршрутов проходят по ожидаемым маршрутам, поскольку маршрутизация на основе политик (PBR) не применяется к трафику, генерируемому локально маршрутизатором. Это сравнимо с ситуациями, когда ACL применяются к интерфейсам с помощью команды «access-group» в исходящем направлении — трафик, генерируемый самим маршрутизатором, не обрабатывается и пропускается, независимо от того, произошло бы совпадение. Что же происходит при генерации трассировок/пингов с самого маршрутизатора в разных обстоятельствах? Поскольку оба статических маршрута имеют AD 1, оба вставляются в таблицы RIB и CEF. В этом случае оптоволоконная линия всегда должна выбирать выход через оптоволоконную линию, если есть маршрут ECMP (равной стоимости) к 4.2.2.2. Если есть один маршрут, который лучше, он будет выбран вместо него. Однако в данном случае с маршрутом ECMP к 4.4.4.2 (два статических маршрута по умолчанию), когда оптоволоконная линия связи потеряна, она должна пытаться отправить трафик через микроволновую линию связи, даже если он исходит от IP-адреса интерфейса оптоволоконной линии связи. Другой пример: когда вы получаете трассировки маршрутов с внутренних интерфейсов LAN, таких как e2/0.x, таблица CEF будет использовать хеш-бакеты для назначения одних и тех же потоков одному и тому же следующему прыжку. Таким образом, трассировки из одного источника в одно и то же место назначения всегда будут проходить через одну из выбранных интернет-связей. После выбора связи поток должен оставаться на этой связи. Поскольку решение принимает CEF, «оптическая LAN» может попытаться пройти через микроволновую связь и т. д. Если вы хотите, чтобы трассировки, исходящие из e2/0.20, проходили по микроволновой связи, а e2/0.10 — по оптоволоконной связи, вам нужно применить «локальный PBR» глобально к маршрутизатору (это повлияет только на трафик, инициированный маршрутизатором). Редактировать: 2.
Поскольку ваши списки доступа 101 и 102 одинаковы (192.168.20/24), единственный трафик, который может быть подвергнут NAT, — это трафик, исходящий из 192.168.20.0/24. Таким образом, трафик от клиентов в подсети 192.168.10.0/24 не должен иметь подключения, поскольку они не могут выполнить NAT. Они могут иметь подключение, потому что это лаборатория, но в реальном мире интернет-провайдер, конечно, обычно отфильтровывает это и использует BCP 38 для блокировки подделки источника IP. Я не уверен, насколько вы моделируете? 3.
Я думаю, что PBR необходимо применять на интерфейсах со стороны LAN. Маршрутная карта «Fiber link» должна быть прикреплена к e2/0.10. Маршрутная карта «Microwave link» должна быть прикреплена к e2/0.20 с помощью «ip policy route-map <route-map_name> 4.
Результатом того, что маршрутизатор следует только таблице RIB и CEF, является то, что если у вас произошел сбой вверх по потоку где-то, кроме непосредственно подключенного канала, сбой может быть обнаружен, устранен, обнаружен, устранен и так далее в цикле. Например, если кабельное соединение 4.2.2.2 становится недоступным из-за сбоя вверх по потоку (кабель, напрямую соединяющий пограничный маршрутизатор и маршрутизатор ISP, по-прежнему исправен), пинги начнут проваливаться, объект отслеживания выйдет из строя. Поскольку статический маршрут по умолчанию отслеживает объект отслеживания, статический маршрут будет удален из RIB. Он больше никогда не сможет достичь 4.2.2.2, поскольку маршрут удален и будет добавлен обратно только после успешного выполнения нескольких пингов. Если пинги могут достичь 4.2.2.2 через микроволновую линию связи как следующий лучший маршрут, объект отслеживания вернется в рабочее состояние, а исходный статический маршрут по умолчанию через оптоволоконную линию связи вернется в RIB. Однако сбой вверх по потоку все еще не устранен, поэтому он снова выходит из строя и возвращается к микроволновой связи. Вероятно, это будет происходить каждые 60 секунд, поскольку это период опроса по умолчанию для IP SLA, а частота не задана в конфигурации? В любом случае это плохо. Здесь будет работать маршрут /32 к 4.2.2.2. Но для изоляции маршрута только для IP-адреса источника интерфейса оптоволоконного соединения, я думаю, необходимо использовать локальный PBR. Опять же, это, вероятно, не происходит в лаборатории, если не моделируется правильная фильтрация. С моей точки зрения, здесь пропущено довольно много вещей, но, надеюсь, это некоторые указания в правильном направлении?

[MHM Cisco World]

Я не вижу, чтобы вы использовали PBR в исходном посте? Это один из моментов, на которые отвечает вам ИИ. MHM

[2D-Technology Services]

Здравствуйте, Royalty. Спасибо за ответ. Однако после изменений проблема по-прежнему остается... Отслеживание до 4.2.2.2, похоже, колеблется между ссылками: EDGE_ROUTER(config)#do trace 4.2.2.2 source 192.168.20.1
Введите последовательность символов для прерывания.
Отслеживание маршрута до b.resolvers.level3.net (4.2.2.2)
Информация VRF: (vrf в имени/id, vrf из имени/id)
1 *
172.16.0.1 16 мс *
2 10.0.137.1 24 мс * 24 мс
3 *
10.10.101.1 24 мс *
4 10.10.101.254 20 мс * 28 мс
5 *
10.74.6.185 20 мс *
6 112.100.65.74 28 мс * 20 мс
7 * EDGE_ROUTER(config)#
EDGE_ROUTER(config)#
EDGE_ROUTER(config)#do trace 4.2.2.2 source 192.168.10.1
Введите последовательность символов для прерывания.
Отслеживание маршрута к b.resolvers.level3.net (4.2.2.2)
Информация VRF: (vrf in name/id, vrf out name/id)
1 *
10.0.137.1 4 мс *
2 10.10.101.1 0 мс
10.0.137.1 20 мс
10.10.101.1 8 мс
3 10.10.101.1 20 мс
10.10.101.254 28 мс
10.10.101.1 16 мс
4 10.74.6.185 8 мс
10.10.101.254 20 мс
10.74.6.185 8 мс
5 10.74.6.185 20 мс
112.100.65.74 12 мс !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! EDGE_ROUTER#sh run | sec route-map
ip policy route-map FIBER_LINK-LAN
ip policy route-map MICROWAVE-LAN
ip nat inside source route-map FIBER_LINK-LAN interface FastEthernet0/0 overload
ip nat inside source route-map MICROWAVE-LAN interface FastEthernet1/0 overload
route-map MICROWAVE-LAN permit 10
match ip address 102
set ip next-hop verify-availability 172.16.0.1 1 track 2
set ip next-hop verify-availability 10.0.137.1 2 track 1
route-map FIBER_LINK-LAN permit 10
match ip address 101
set ip next-hop verify-availability 10.0.137.1 1 track 1
set ip next-hop verify-availability 172.16.0.1 2 track 2
route-map MICROWAVE-LINK разрешить 10
совпадение IP-адрес 106
совпадение интерфейс Ethernet2/0.20
route-map FIBER-LINK разрешить 10
совпадение IP-адрес 105
совпадение интерфейс Ethernet2/0.10
EDGE_ROUTER#
EDGE_ROUTER#
EDGE_ROUTER#sh run | sec access
access-list 101 permit ip 192.168.10.0 0.0.0.255 any
access-list 102 permit ip 192.168.20.0 0.0.0.255 любой
access-list 105 разрешить ip 192.168.10.0 0.0.0.255 любой
access-list 106 разрешить ip 192.168.20.0 0.0.0.255 любой
EDGE_ROUTER#
EDGE_ROUTER#
EDGE_ROUTER#
EDGE_ROUTER#sh run | sec ip route
ip route 0.0.0.0 0.0.0.0 10.0.137.1 name FIBER-LINK track 1
ip route 0.0.0.0 0.0.0.0 172.16.0.1 name MICROWAVE-RADIO track 2 DGE_ROUTER#sh run int Ethernet2/0.10
Создание конфигурации... Текущая конфигурация: 194 байта
!
интерфейс Ethernet2/0.10
описание FIBER-CONNECTION
инкапсуляция dot1Q 10
ip адрес 192.168.10.1 255.255.255.0
ip nat внутри
ip политика маршрутизации FIBER_LINK-LAN
ip ospf 1 область 0
конец EDGE_ROUTER#
EDGE_ROUTER#
EDGE_ROUTER#
EDGE_ROUTER#sh run int Ethernet2/0.20
Создание конфигурации... Текущая конфигурация: 197 байт
!
интерфейс Ethernet2/0.20
описание MICROWAVE-CONNECTION
инкапсуляция dot1Q 20
IP-адрес 192.168.20.1 255.255.255.0
IP NAT внутри
IP-политика маршрутная карта MICROWAVE-LAN
IP OSPF 1 область 0
конец

[paul driver]

Здравствуйте,
используйте приложенный файл, и все будет в порядке. Пожалуйста, оцените и отметьте как принятое решение, если вы нашли какую-либо из предоставленной информации полезной.
Это поможет другим участникам форума найти ценный ответ и расширит глобальную сеть сообщества.
С уважением,
Пол

[2D-Technology Services]

трек 1 ip sla 1 доступность
!
трек 2 ip sla 2 доступность
!
интерфейс FastEthernet0/0
ip адрес 10.0.137.54 255.255.255.0
ip nat outside
duplex full
!
интерфейс FastEthernet1/0
ip адрес 172.16.0.2 255.255.255.252
ip nat outside
duplex full
!
interface Ethernet2/0.10
description FIBER-CONNECTION
encapsulation dot1Q 10
ip address 192.168.10.1 255.255.255.0
ip nat inside
ip policy route-map FIBER_LINK-LAN
ip ospf 1 area 0
!
интерфейс Ethernet2/0.20
описание MICROWAVE-CONNECTION
инкапсуляция dot1Q 20
ip адрес 192.168.20.1 255.255.255.0
ip nat внутри
ip политика route-map MICROWAVE-LAN
ip ospf 1 область 0
!
ip nat inside source route-map FIBER-LINK interface FastEthernet0/0 overload
ip nat inside source route-map MICROWAVE-LINK interface FastEthernet1/0 overload
!
ip sla 1
icmp-echo 4.2.2.2 source-ip 10.0.137.54
owner FIBER-LINK
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 172.16.0.1 source-ip 172.16.0.2
owner FIBER-LINK
ip sla schedule 2 life forever start-time now
access-list 101 permit ip 192.168.10.0 0.0.0.255 any
access-list 102 permit ip 192.168.20.0 0.0.0.255 any
!
route-map MICROWAVE-LAN permit 10
match ip address 102
set ip next-hop verify-availability 172.16.0.1 1 track 2
set ip next-hop verify-availability 10.0.137.1 2 track 1
!
route-map FIBER_LINK-LAN permit 10
match ip address 101
set ip next-hop verify-availability 10.0.137.1 1 track 1
set ip next-hop verify-availability 172.16.0.1 2 track 2
!
route-map MICROWAVE-LINK permit 10
match ip address 102
match interface Ethernet2/0.20
!
route-map FIBER-LINK permit 10
match ip address 101
match interface Ethernet2/0.10

[2D-Technology Services]

ip access-list standard NAT-ACL
10 permit 192.168.10.0 0.0.0.255
20 permit 192.168.20.0 0.0.0.255 Действительно ли мне нужны несколько наборов ACL (NAT_ACL , 101 и 102 ) или достаточно одного, чтобы реализовать это решение?

[paul driver]

Здравствуйте
[, @2D-Technology Services]
@Royalty.
Я считаю, что вы на правильном пути в своей конфигурации, однако, похоже, что некоторые вещи нуждаются в доработке. @Royalty
прав в отношении маршрутных карт (NAT и PBR), но для NAT используйте дополнительный ACL, чтобы включить обе подсети LAN, а для PBR RM я бы также предложил включить фактические следующие прыжки для отработки отказа, И вам нужно основать маршрут на трафике, проходящем через rtr
, а не
исходящем из него. Также рекомендую включить
булево
выражение
And
, а затем связать его с отслеживанием ip sla и основным статическим маршрутом по
умолчанию. Что касается вашего ip sla 1 probe, вы можете изменить его, чтобы направить вверх по потоку к ip подключенного интерфейса, иначе вы можете потенциально заблокировать половину вашего трафика, если/возникнет сбой на ISP1, поскольку он не сможет восстановиться, так как маршрут по умолчанию недоступен, или, как предлагается, использовать локальный PBR, но вам нужно убедиться, что
ТОЛЬКО
локальный маршрут по политике используется в одном направлении, поэтому я бы предложил использовать дополнительную карту маршрутов и обнулить любую возможность утечки маршрута через isp 2.
Наконец, работает ли OSPF на этом rtr, или это исторический факт, связанный с тем, что вы показываете статическую маршрутизацию по умолчанию? Возможное решение вашей проблемы см. в приложенном файле.
(Приношу извинения, если вы видите несколько копий этого сообщения, у меня проблема с дублированием моей учетной записи!) Пожалуйста, оцените и отметьте как принятое решение, если вы нашли какую-либо из предоставленной информации полезной.
Это поможет другим участникам форума найти ценный ответ и расширит глобальную сеть сообщества.
С уважением,
Пол

[balaji.bandi]

хороший пример и результаты тестирования: https://www.balajibandi.com/?p=1643 BB
=====Preenayamo Vasudevam=====
***** Оценить все полезные ответы *****
Как обратиться за помощью к сообществу Cisco

[davidmubarak]

Хорошая статья — спасибо за подробности. То, что вы видите, когда оба интернет-провайдера работают (traceroute показывает чередующиеся следующие прыжки), — это классическое асимметричное/многопутевое поведение: при наличии обоих маршрутов по умолчанию маршрутизатор распределяет нагрузку трафика между двумя восходящими каналами, поэтому разные пакеты или потоки к одному и тому же пункту назначения проходят через разных интернет-провайдеров, и вы видите несколько восходящих прыжков в трассировке. Само по себе это не является ошибкой, но может привести к путанице в трассировке и нарушить работу устройств с отслеживанием состояния или сервисов, чувствительных к обратному пути.