Странный синтаксис, интересно как это работает?
Разберем по порядку:
1. Комп из сети 192.168.65/24 хочет попасть в сеть 192.168.62/24. Это не его сеть, значит он отправляет пакет на мак адрес шлюза, при этом в заголовках у него адреса назначения из сети 62, а источник из 65.
2. Шлюз (это наш Trendnet) получает такой пакет и смотрит в заголовки. Видит там 62ю сеть. В обычной конфигурации он направляет ее по дефолтному маршруту. Те в сеть провайдера.
3. Сеть провайдера дропает пакет.
Нам нужно чтобы на шаге 2 роутер знал где живет 62я сеть. Указав маршрут в 192.168.62.0/24 через 192.168.65.1 мы ему как бы говорим, чтобы направить пакет в сеть 62 тебе нужно послать ARP запрос для 192.168.65.1 и подставить полученый мак в L2 заголовок и отправить пакет. Очевидно, что это не работает (Может техподдержка прокоментирует почему они хотят видеть в этой строчке именно IP текущего маршрутизатора)
Я же предлагаю, если есть такая возможность повесить secondary IP на тот же интерфейс где висит 65.1. Тогда на втором шаге роутер будет знать, что 62я сеть подключена к нему и отправлять пакеты по назначению. Маршрут же на фрибсд нужен для ответных пакетов. Т.к клиент из 62ой сети получив пакет из 65ой сети ответит так же на шлюз (см п1), и фрибсд должна знать через какой ip ей добраться до 65 сети. И скорее всего она пошлет клиенту ICMP redirect ;)
Скажем по другому: сервера ЖЖ в AS32787, которую комстар видит через некий прямой стык. Т.е следующих хоп — это сеть в которой живет ЖЖ, судя по их сайту какая-то антиДДоС площадка, вот она и режет пинги трейсы, и наверно, че-то еще.
Забыл добавить, что делают это обычно не провайдеры, а владельцы конечных ресурсов. Провайдерам от таких вещей, как ограничение ICMP на какие-то ресурсы, никакого толка, только себе дороже
Блочат обычно не весь ICMP, а только 0 и 8 тип (иногда 11 — поэтому звезды в трейсах) или на такие сообщения устанавливается рэйтлимит, чтобы разгрузить оборудование от ответов на бесполезные пинги со стороны пользователей.
ip nat overload — все выйдут с одним адресом 172.16.0.1 Либо на другом нате должен быть маршрут в сеть Net1, но, я так понимаю, что с этим натом все сложно, и управлять Вы им не можете.
Если редистрибуция линейная — то проблем быть не должно. Если кольцевая, и редистрибуция применяется в нескольких точках, то надо быть внимательным с метриками и AD протоколов.
Как отписали ниже это сетевая подсистема xena либо все-таки не включенный форвардинг. Хотя если бы форвардинг не был включен на серваке были-бы входящие пакеты, потому что tcpdump переводит интерфейс в promiscuous mode. Но то что пакеты с клиента уходят в парвильном направлении — это факт, и то что не доходят до сервака тоже.
Разберем по порядку:
1. Комп из сети 192.168.65/24 хочет попасть в сеть 192.168.62/24. Это не его сеть, значит он отправляет пакет на мак адрес шлюза, при этом в заголовках у него адреса назначения из сети 62, а источник из 65.
2. Шлюз (это наш Trendnet) получает такой пакет и смотрит в заголовки. Видит там 62ю сеть. В обычной конфигурации он направляет ее по дефолтному маршруту. Те в сеть провайдера.
3. Сеть провайдера дропает пакет.
Нам нужно чтобы на шаге 2 роутер знал где живет 62я сеть. Указав маршрут в 192.168.62.0/24 через 192.168.65.1 мы ему как бы говорим, чтобы направить пакет в сеть 62 тебе нужно послать ARP запрос для 192.168.65.1 и подставить полученый мак в L2 заголовок и отправить пакет. Очевидно, что это не работает (Может техподдержка прокоментирует почему они хотят видеть в этой строчке именно IP текущего маршрутизатора)
Я же предлагаю, если есть такая возможность повесить secondary IP на тот же интерфейс где висит 65.1. Тогда на втором шаге роутер будет знать, что 62я сеть подключена к нему и отправлять пакеты по назначению. Маршрут же на фрибсд нужен для ответных пакетов. Т.к клиент из 62ой сети получив пакет из 65ой сети ответит так же на шлюз (см п1), и фрибсд должна знать через какой ip ей добраться до 65 сети. И скорее всего она пошлет клиенту ICMP redirect ;)