Пусть у вас есть маршрутизатор cisco. Требуется, чтобы при трассировке маршрута, проходящего через этот роутер, ответ от него приходил с некоторого заданного адреса (например, 1.1.1.1)

Например:
trace X.X.X.X

1) t t t 10.1.1.1
2) t t t 192.168.1.1
3) t t t 1.1.1.1 (это данный роутер)
4) t t t 212.111.90.33

и т.д.

думаю это можно сделать с помощью Loopback интерфейcа.
Прописать на loopback'e IP 1.1.1.1 и роут-мапами или c помощью OSPF, BGP и т.д, можно заворачивать трафик на этот интерфейс.

еще можно через ip local policy route- map ...

route-map test permit 10
set interface loopback 0

ip local policy route-map test

не совсем уверен в правильности синтаксиса ибо консоли под рукой нет
но в общем решение видится следующим образом:


conf t
ip access-list ext ICMP_TTLEXCEED
permit icmp any any ttl-exceed
exit
route-map TO_LOOPBACK perm 10
match ip addr ICMP_EXCEED
set int lo0
exit
int lo0
ip addr 1.1.1.1 255.255.255.255
exit
route-map REPLACE_SRCIP perm 10
match ip addr ICMP_EXCEED
exit
ip local policy TO_LOOPBACK
ip nat ins source route-map REPLACE_SRCIP interface Loopback0 overload
int fa0/0
ip addr 10.7.0.1 255.255.255.0
ip nat outside
exit

Практически верно, но так работать не будет.
Для ната надо не только ip nat outside, но и ip nat inside интерфейс. Локальный трафик рутера не будет транслироваться. И ещё: мне кажется, что не получится странслировать в адрес интерфейса, который не ip nat outside, хотя тут могу заблуждаться.

Правильный ход такой:

ACL ICMP_EXEEDED perm icmp any any ttl-exeeded

Route-map TOLOOP0 10
match ACL ICMP_EXEEDED
set int loop 0

Route-map TOLOOP1 10
match ACL ICMP_EXEEDED
set int loop 1

int loop 0
ip address (не важно какой)
ip policy route-map TOLOOP1
ip nat inside

int loop 1
ip address 1.1.1.1/32
ip nat outside

ip local policy route-map TOLOOP0

Т.е. трансляцию делаем между интерфейсами loop. Это правильно и с т.з. производительности: остальной трафик даже проверяться НАТом не будет

ЗЫ Спасибо за участие

Я на CiscoExpo предложил вариант решения с ip-unnumbered интерфейсами.
С serial все просто. Оно работает!
А вот с FastEthernet пришлось помучаться. Решил через Tunnel-интерфейс:

interface Fastethernet 0/0
ip address 10.5.1.1 255.255.255.0

interface Tunnel0
tunnel source fastethernet0/0
tunnel destination 10.5.1.3
ip unnumbered

Ну, и конечно, протокол динамическаой маршрутизации поднять, только fastethernet в network не включать, а то он более предпочтительный, чем tunnel.

Поправка.

В ip unnumbered надо, конечно, указать интерфейс loopback0.

Дополнение.

Мое решение чисто академическое. В production-сети я бы не стал его внедрять. Сами понимаете, накладные расходы на GRE, второй заголовок IP. Опять же CEF не работает на туннельном интерфейсе ...

Задачки вообще оторваны от жизни. Они скорее на понимание и широту взгляда.

ЗЫ В предложенной на ЦЭ топологии Ваше решение проходит, а вот если взять 2 fastethernet, то мне кажется при traceroute "дальнего" интерфейса маршрутизатора с loop0 (1.1.1.1), отвечать всё же будет он не с 1.1.1.1, а с адреса ближнего fastethernet

Вчера один коллега предложил поднять VRF, для разделения трафика по туннельным интерфейчас и по реальным адресам интерфейсов

сегодня проверил решение:
создается
1. пул ната POOL,
2. ACL, в который входит интерфейс роутера.

динамик нат ACL в POOL

На интерфейс, с которого будет от отвечать ttl-exceeded - ip nat outside. Как известно, в отсутствии инсайдов, будет транслироваться траффик самого роутера.

проверил на железе.

С уважением,
Илья

Хм, про "как известно" - видимо не мне. Я не знал, спасибо!