При выводе этой команды [1]ciscosh ip ro 192.168.97.2 у вас должен быть тот же туннель, что и в первом трайсе, или добавлен анонс маршрутов через оба туннелая.
У вас маршрут в 10.0.0.0/8 с Cisco 2 идет в Tunnel1 | 172.16.1.1 | 10.10.10.10
А обратный в 192.168.97.0/24 с Cisco 1 идет в Tunnel0 | 172.16.1.3 | 31.44.89.89
1. Почему такая большая сетка анонсируется 10.0/8
2. Если делаете trace, то делаете с адресом источника, а так этот вывод бессмыслен, он идет с loopback, а вам надо с туннельного интерфейса.
3. Где обратный trace, у вас здесь показан только в одну сторону
Откуда куда делаете trace(IP)? Примерно по такому шаблону можете искать решение:
Смотрите последний IP по трассировке->заходите на него, делаете sh ip route [ip]->смотрим куда должен уйти пакет->заходим на следующий IP, если так дошли до хоста назначения то все норм, пакет до dest доходит. Теперь в обратном порядке только в качестве dest используем начальный source IP
Если с теорией проблемы не большие, то зачем спрашивать как обеспечить связность 2 сетей? Сама постановка твоего вопроса говорит о том, что ты не понимаешь что хочешь спросить. Если утрировать и ответить на твой вопрос, то для обеспечения L3 связности сетей А и Б достаточно одного маршрутизатора, неважно программного или аппаратного, не привязывайся к слову server если не понимаешь его значения. До практики тебе очень далеко.
Вот тебе хорошие мануалы:
google.com
yandex.ru
habrahabr.ru
linkmeup.ru/sdsm/
ИЛИ если DMVPN не используется, то в зависимости о топологии вашей сети выберите как должен происходить обмен Hello пакетами
(config-if)#ip ospf network
Если broadcast L2 сеть на туннельных интерфейсах, то на туннельном интерфесе:
ip ospf network broadcast
Если это P-t-P NBMA link'и то на туннельном интерфесе:ip ospf network point-to-point
Всем спасибо. Выяснилось, что у провайдера там активное транзитное устройство GPON(bridge), которое на старой прошивке некорректно отрабатывает данные фреймы, пока остановился на [no keepalive] на интерфейсе
Всем спасибо. Выяснилось, что у провайдера там активное транзитное устройство GPON(bridge), которое на старой прошивке некорректно отрабатывает данные фреймы, пока остановился на [no keepalive] на интерфейсе
Всем спасибо. Выяснилось, что у провайдера там активное транзитное устройство GPON(bridge), которое на старой прошивке некорректно отрабатывает данные фреймы, пока остановился на [no keepalive] на интерфейсе
Все верно, ту же информацию нашел и я, что это фрейм для проверки работоспособности протокола. И у него SRC mac = DST mac, но в таком случае если коммутатор выплевывает данный фрейм из своего интерфейса, то устройство обрабатывающее фреймы на другой стороне должно вернуть его в том же виде(SRC mac = DST mac) и соответственно errdisable потушить интерфейс из-за петли. Или это фрейм должен как-то измениться/обработаться?
errdisable говорит что петля, убираю keepalive, STP молчит, шторма нет . Это не может быть L3 мультикаст, так как это комок. Если, как вы говорите, это L2 мультикаст, то SRC mac = Switch mac, DST mac = FF::FF, тогда все логично
Но нашел инфу что это фрейм SRC=DST, поле Ethernet type = 0x9000. В таком случае если коммутатор выплевывает данный фрейм из своего интерфейса, то устройство обрабатывающее фреймы на другой стороне должно вернуть его в том же виде(SRC mac = DST mac) и соответственно errdisable потушить интерфейс из-за петли. Или это фрейм должен как-то измениться/обработаться?
Точка удаленная, можно сделать mirroring, но это наврятли что-то даст, трафик я и так знаю какой ходит. Я хочу понять, как keepalive должен отрабатываться корректно если у него в L2 SRC mac = DST mac
У вас маршрут в 10.0.0.0/8 с Cisco 2 идет в Tunnel1 | 172.16.1.1 | 10.10.10.10
А обратный в 192.168.97.0/24 с Cisco 1 идет в Tunnel0 | 172.16.1.3 | 31.44.89.89
У вас для туннеля между Cisco 1 и Cisco 2?