Jump to content
Калькуляторы

Непонятки с PBR на SUP32

Имеется каталист 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

 

 

 

Куда рыть!?!

Edited by sol

Share this post


Link to post
Share on other sites

В общем, решение найдено. Я сделал отдельный вилан для р2р сеточки для связи шерститонника и натилки и переписал роут-мап с next-hop в этот виланчик. И все поехало. Вот в чем тут было дело - неясно.

 

Share this post


Link to post
Share on other sites

Ну, господа CCIE ? Никто не знает что-ли?

Share this post


Link to post
Share on other sites

дайте угадаю,

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

 

Share this post


Link to post
Share on other sites

эээ, как бы... А редирект-то тут причем? Там-же ничего не редиректится?!? Там просто тарфик направляется не на тот хост (даже не на хост, а на отношение смежности), на который ему предписано таблицей роутинга а на более другой, то-же смежный. Редиректа как-бы и нет.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this