Есть Cisco 2811 в качестве пограничного маршрутизатора.

Она как-то криво пропускает через себя ICMP-пакеты tracerout-a. Так, например, вот что видит человек, трассирующий хост за WAN из LAN:

# traceroute ya.ru
traceroute: Warning: ya.ru has multiple addresses; using 87.250.251.8
traceroute to ya.ru (87.250.251.8), 30 hops max, 40 byte packets
1  192.168.0.1 (192.168.0.1)  0.969 ms  1.392 ms  1.639 ms
2  ###.###.###.### (###.###.###.###)  6.052 ms * *
3  cisco1.krasnodar.gldn.net (194.186.8.161)  139.643 ms * *
4  pe-l.krasnodar.gldn.net (194.186.10.93)  40.152 ms * *
5  * * *
6  * * p-l.Rostov-na-Donu.gldn.net (194.186.10.81)  37.214 ms
7  * p-l.Moscow.gldn.net (194.67.30.57)  46.119 ms *
8  pe-l.moscow.gldn.net (194.186.80.134)  56.654 ms * *
9  cat03.Moscow.gldn.net (194.186.158.193)  45.366 ms * *
10  cat02.moscow.gldn.net (195.239.10.190)  79.604 ms * *
11  * * *
12  ix2-m9.yandex.net (193.232.244.93)  137.516 ms *  198.609 ms
13  * * *
14  * ya.ru (87.250.251.8)  48.952 ms *

При этом сами пинги никуда не пропадают:
# ping  ya.ru -fc 50
PING ya.ru (213.180.204.8) 56(84) bytes of data.
--- ya.ru ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 700ms
rtt min/avg/max/mdev = 42.303/94.081/147.654/28.271 ms, pipe 12, ipg/ewma 14.300/66.818 ms

Вот что видит человек, трассирующий хост за LAN из WAN:
#traceroute 2.2.2.2
1 80.72.225.1 (80.72.225.1) 0.430 ms 0.314 ms 0.505 ms
2 80.72.224.122 (80.72.224.122) 4.829 ms 4.094 ms 3.839 ms
3 83.69.67.50 (83.69.67.50) 6.375 ms 5.958 ms 6.943 ms
4 83.69.67.54 (83.69.67.54) 8.917 ms 10.460 ms 7.842 ms
5 1.1.1.1 (1.1.1.1) 62.696 ms 44.746 ms 37.936 ms
6 1.1.1.1 (1.1.1.1) 17.511 ms !X * 12.124 ms !X

Здесь 2.2.2.2 - машина за cisco 2811, а 1.1.1.1 - IP самой 2811. то есть, в первый раз она отвечает нормально
ICMP: time exceeded (time to live) sent to 80.72.225.4 (dest was 2.2.2.2)
, а во второй - вместо того, чтобы отправить пакет дальше на 2.2.2.2, она отвечает
ICMP: dst (2.2.2.2) administratively prohibited unreachable sent to 80.72.225.4

(эти строчки я взял из debug ip icmp)

Простые пинги (а я так понимаю, что от Traceroute они отличаются только большим TTL) и в этом случае нормально проходят.

Ситуация не зависит от того, применяется NAT или нет, какие входные-выходные интерфейсы.

Я так подозреваю, что где-то в циске при прохождении пакета через нее TTL меняется более одного раза. У кого-нибудь есть идеи? Конфиг циски очень здоровый, так что выкладывать лучше буду частями, если захотите на что-то конкретно взялянуть, пишите.

Заранее благодарен за любую помощь.

• Не работает Traceroute через маршрутизатор,Xela, 12:18 , 06-Сен-07
  • Не работает Traceroute через маршрутизатор,Alan_2004, 14:02 , 09-Сен-07

tracertoute это не только ICMP, но и UDP на высоких портах.

>tracertoute это не только ICMP, но и UDP на высоких портах.

Спасибо, я об этом не знал. Теперь быстро нашел проблему в ACL, которая мешала прохождению UDP вовнутрь (т.е., трассированию извне).

Но трассирование изнутри - это у меня оказывется совсем другая проблема. сейчас к стыду обнаружил, что хосты без NAT трассируют нормально, т.е. проблема все-таки в NAT. Оно наверное и логично - уходит по UDP на один хост, а возвращается ICMP с другого хоста. Но ведь как-то у людей работает. Может, есть какие-то настройки режимов NAT? Вот мои:

interface FastEthernet0/0.13
encapsulation dot1Q 13
ip address x.x.x.x 255.255.255.252
no ip redirects
ip nat outside
ip virtual-reassembly
ip policy route-map MAP_NetUP
no ip mroute-cache
no snmp trap link-status
!
interface FastEthernet0/1.4
encapsulation dot1Q 4
ip address 192.168.0.33 255.255.255.224
ip access-group ACL_admin_in in
no ip redirects
ip nat inside
ip virtual-reassembly
ip policy route-map ISP
no ip mroute-cache
no snmp trap link-status
!
!
ip nat pool BGPNAT #.#.#.0 #.#.#.0 netmask 255.255.0.0
ip nat inside source list ACL_BGP_NAT pool BGPNAT overload
!
!
ip access-list extended ACL_BGP_NAT
deny   ip host 192.168.1.24 any
deny   ip host 192.168.1.125 any
permit ip 192.168.0.0 0.0.255.255 any
!

Два наблюдения:
1) от специфичности пула BGPNAT это не зависит, пробовал #.#.#.2, то же самое
2) Когда на Fa0/0.13 (nat outside) ставишь no ip unreachables, в трейсе вообще ничего дальше cisco 2811 нет, одни звезды. А без него - картина приведена в первом посте.