sol Опубликовано 5 марта, 2011 (изменено) · Жалоба Имеется каталист 6500 с SUP32. На интерфейсе условно "бекбона" собирается трафик от клиентов. И с белыми адресами и с серыми. Собирается от кучи соседнего оборудования. Маршруты собираются средствами OSPF. interface Vlan100 description BBone ip address XX.XX.XX.22 255.255.255.240 no ip redirects no ip unreachables ip pim sparse-mode ip policy route-map NAT-GRAY ip ospf authentication ip ospf authentication-key 7 XXXXXXXXXXXXXXXXXXX ! interface Vlan102 description Link to Border-1 ip address XX.XX.XX.2 255.255.255.252 no ip redirects no ip unreachables Стоит задача завернуть трафик с серых сетей на натилку. Натилка живет в этом-же "бекбоне" Адрес ХХ.ХХ.ХХ.19 Пишу роут-мап route-map NAT-GRAY permit 10 match ip address graynets set ip next-hop ХХ.ХХ.ХХ.19 ip access-list standard graynets permit 10.0.0.0 0.255.255.255 permit 192.168.0.0 0.0.255.255 permit 172.16.0.0 0.15.255.255 И вешаю на Vlan100. В этот момент начинаются дропы у клиентов с серой адресацией. Дамп на натилке показал, что некоторые пакеты до нее просто не доходят. Делал на ней tcpdump -e -n -i vlan100 icmp[icmptype] = icmp-echo or icmp[icmptype] = icmp-echoreply а на тестовом хосте ping ya.ru И вот что я вижу. Трафик тестового хоста приходит с одной из свичек, сидящих своим vlan100 в этом бекбоне. Конкретно с XX.XX.XX.21 17:09:35.096897 00:0c:31:66:c8:00 > 00:11:11:a8:c4:18, ethertype IPv4 (0x0800), length 74: [ТЕСТОВЫЙ ХОСТ] > 93.158.134.3: ICMP echo request, id 512, seq 52008, length 40 - Запрос от серого хоста 17:09:35.096915 00:11:11:a8:c4:18 > 00:11:bc:81:38:00, ethertype IPv4 (0x0800), length 74: [XX.XX.XX.19] > 93.158.134.3: ICMP echo request, id 512, seq 52008, length 40 - Заначеный запрос 17:09:35.098146 00:11:bc:81:38:00 > 00:11:11:a8:c4:18, ethertype IPv4 (0x0800), length 74: 93.158.134.3 > [XX.XX.XX.19]: ICMP echo reply, id 512, seq 52008, length 40 - Ответ Яндекса 17:09:35.098164 00:11:11:a8:c4:18 > 00:0c:31:66:c8:00, ethertype IPv4 (0x0800), length 74: 93.158.134.3 > [ТЕСТОВЫЙ ХОСТ]: ICMP echo reply, id 512, seq 52008, length 40 - Разначеный ответ яндекса. Так бывает когда все хорошо и трафик идет по статическому default маршруту на свичке XX.XX.XX.21, смотрящему на натилку. 17:09:35.096897 00:11:bc:81:38:00 > 00:11:11:a8:c4:18, ethertype IPv4 (0x0800), length 74: [ТЕСТОВЫЙ ХОСТ] > 93.158.134.3: ICMP echo request, id 512, seq 52008, length 40 - Запрос от серого хоста 17:09:35.096915 00:11:11:a8:c4:18 > 00:11:bc:81:38:00, ethertype IPv4 (0x0800), length 74: [XX.XX.XX.19] > 93.158.134.3: ICMP echo request, id 512, seq 52008, length 40 - Заначеный запрос 17:09:35.098146 00:11:bc:81:38:00 > 00:11:11:a8:c4:18, ethertype IPv4 (0x0800), length 74: 93.158.134.3 > [XX.XX.XX.19]: ICMP echo reply, id 512, seq 52008, length 40 - Ответ Яндекса 17:09:35.098164 00:11:11:a8:c4:18 > 00:0c:31:66:c8:00, ethertype IPv4 (0x0800), length 74: 93.158.134.3 > [ТЕСТОВЫЙ ХОСТ]: ICMP echo reply, id 512, seq 52008, length 40 - Разначеный ответ яндекса. А так, когда потери... Когда происходит потеря 1-го пинга то эти 4 строки просто не появляются. Т.е. изначальный запрос не доходит/не попадает под роут-мап. XX.XX.XX.22 00:11:bc:81:38:00 XX.XX.XX.20 00:11:11:a8:c4:18 XX.XX.XX.21 00:0c:31:66:c8:00 Куда рыть!?! Изменено 5 марта, 2011 пользователем sol Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 5 марта, 2011 · Жалоба В общем, решение найдено. Я сделал отдельный вилан для р2р сеточки для связи шерститонника и натилки и переписал роут-мап с next-hop в этот виланчик. И все поехало. Вот в чем тут было дело - неясно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 9 марта, 2011 · Жалоба Ну, господа CCIE ? Никто не знает что-ли? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 9 марта, 2011 · Жалоба дайте угадаю, no ip redirects убивает затею? To enable the sending of Internet Control Message Protocol (ICMP) redirect messages if the Cisco IOS software is forced to resend a packet through the same interface on which it was received, use the ip redirects command in interface configuration mode. To disable the sending of redirect messages, use the no form of this command. http://www.cisco.com/en/US/docs/ios/12_3/i....html#wp1081518 ну и ... http://en.wikipedia.org/wiki/ICMP_Redirect_Message Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 9 марта, 2011 · Жалоба эээ, как бы... А редирект-то тут причем? Там-же ничего не редиректится?!? Там просто тарфик направляется не на тот хост (даже не на хост, а на отношение смежности), на который ему предписано таблицей роутинга а на более другой, то-же смежный. Редиректа как-бы и нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дегтярев Илья Опубликовано 9 марта, 2011 · Жалоба на sup 720 тоже самое. Если делать pbr в тот же вилан, откуда пришел пакет - ужасные дропы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
