Читаем статью http://xgu.ru/wiki/Cisco_PBR и возникает несколько вопросов если изменить немного конфигурацию, а именно в обоих строчках роутмапа ставим один и тот же ACL:

route-map POLICY permit 10
match ip address odd
set ip next-hop verify-availability 192.168.1.5 1 track 1
route-map POLICY permit 20
match ip address odd
set ip next-hop verify-availability 192.168.2.6 2 track 2

 

Суть в том - что хотим сделать полноценный резерв. И в случае когда первый next-hop не работает - трафик по тому же ACL полностью отправлялся по другому ACL

а когда первый nexthop доступен - то весь трафик отправляется на первый next-hop

 

Но если Мы правильно понимаем работу route-map - то пакеты которые попали в acl в 10ом правиле route-map уже не попадут в 20ое правило, даже при условии что next-hop там не доступен. И все пакеты будут обработаны стандартной таблицой маршрутизации.

 

Есть ли у кого идеи как реализовать схему:

один ACL, если первый next-hop доступен - весь трафик отправляем на него, если первый next-hop не доступен - отправляем весь трафик на второй next-hop, и вот только если оба next-hop не доступны - то только тогда отправляем трафик по стандартной таблице маршрутизации.

Изменено пользователем artplanet

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

http://www.cisco.com/c/en/us/support/docs/ip/ip-routed-protocols/48003-pbrtracking.html

 

route-map POLICY permit 10
match ip address odd
set ip next-hop verify-availability 192.168.1.5 1 track 1
route-map POLICY permit 20
match ip address odd
set ip next-hop verify-availability 192.168.2.6 2 track 2
route-map POLICY permit 30
match ip address odd

должно помочь

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

эхххх....

на 6500 шасси есть подобная команда

(config-route-map)#set ip next-hop ?
 A.B.C.D              IP address of next hop
 dynamic              application dynamically sets next hop
 encapsulate          Encapsulation profile for VPN nexthop
 peer-address         Use peer address (for BGP only)
 recursive            Recursive next-hop
 self                 Use self address (for BGP only)
 verify-availability  Verify if nexthop is reachable

а вот на 4900m на которые мы решили перейти нет команды.

 

config-route-map)#set ip next-hop ?       
 A.B.C.D       IP address of next hop
 dynamic       application dynamically sets next hop
 peer-address  Use peer address (for BGP only)
 recursive     Recursive next-hop
 self          Use self address (for BGP only)

 

софт System image file is "bootflash:/cat4500e-entservicesk9-mz.152-2.E6.bin"

как я понял на 49xx серии можно забыть о verify-availability и аналогов нет ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

а статику с треками даёт нарисовать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

статика не катит - так как нужен именно PBR - то есть нужно отправлять не весь трафик - а определенный (по source ip)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

это понятно. просто вы можете указать next-hop - ип который статиком заворачивается за определенный next-hop, который имеет трек уже.

ну аля

route-map PBR permit 10
match ip address odd
set ip next-hop 1.1.1.1

ip route 1.1.1.1 255.255.255.255 192.168.1.5 track 1 10
ip route 1.1.1.1 255.255.255.255 192.168.2.6 track 2 20

последнее - приоритет. за точность не ручаюсь - лень лезть в мануалы.

 

ну и, конечно, не факт что всё это взлетит :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

хз как такое переварит пару миллионов пакетов в секунду, нужно будет стенд сделать

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

начинаем поднимать стенд, итак, если PBR Имеет такой вид:

show route-map TEST-PBR
route-map TEST-PBR, permit, sequence 10
 Match clauses:
   ip address (access-lists): TEST-PBR 
 Set clauses:
   ip next-hop 10.10.128.1
 Policy routing matches: 21 packets, 1260 bytes

 

то трасса идет

 1 80.87.207.152 0 msec 0 msec 0 msec
 2 10.10.128.1 [AS 1299] 0 msec 0 msec 0 msec

второй прыжок верный

 

А вот если мы делаем PBR вида

route-map TEST-PBR, permit, sequence 10
 Match clauses:
   ip address (access-lists): TEST-PBR 
 Set clauses:
   ip next-hop 192.168.1.1
 Policy routing matches: 21 packets, 1260 bytes

и просто прописываем статик роут:

ip route 192.168.1.1 255.255.255.255 10.10.128.1

 

то трассирвока становится:

 1 80.87.207.152 0 msec 0 msec 0 msec
 2 80.87.207.155 [AS 1299] 0 msec 0 msec 0 msec

то есть 2 прыжок не верный и статик роут просто игнорируется. Видимо для nexthop требуется наличие arp записи

в тоже время трасса до ip 192.168.1.1 имеет вид:

 1 80.87.207.152 0 msec 4 msec 0 msec
 2 10.10.128.1 [AS 1299] 0 msec 0 msec 0 msec

 

так что получается что next-hop на тот хост который доступен через статик роут не получится сделать

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

пока что видится только один вариант

event manager applet InternetSupremet
event syslog pattern "ip sla 1 reachability Up->Down"
action 1.0 cli command "clear ip nat translation *"

 

через подобное извращение программировать нужный next hop в PBR

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

хм, на asr9k в принципе такая же логика - next-hop должен быть directly-connected и иметь arp запись.

ну значит только вариант с извратом через EEM

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

через EEM получилось реализовать то что было нужно - но это изврат. Но работать будет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Но если Мы правильно понимаем работу route-map - то пакеты которые попали в acl в 10ом правиле route-map уже не попадут в 20ое правило, даже при условии что next-hop там не доступен. И все пакеты будут обработаны стандартной таблицой маршрутизации.

 

Есть ли у кого идеи как реализовать схему:

один ACL, если первый next-hop доступен - весь трафик отправляем на него, если первый next-hop не доступен - отправляем весь трафик на второй next-hop, и вот только если оба next-hop не доступны - то только тогда отправляем трафик по стандартной таблице маршрутизации.

 

почему бы не

route-map POLICY permit 10
match ip address odd
set ip next-hop verify-availability 192.168.1.5 1 track 1
set ip next-hop verify-availability 192.168.2.6 2 track 2

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

а обновив софт с 152-2.E6.bin до 152-4.E2.bin verify-availability появился.

интересно с чего такие изменения.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Почитайте release notes к IOS, они для 49й постоянно допиливают какие-то полезные мелочи. Правда и неприятные баги в работавших фичах добавляются, например на 152-4.E в IPv6 BGP-сессии префиксы от не-Cisco соседа не принимались.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Странно, если бы там это не работало, но речь в топике про 4900

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

vurd

действительно. заглянул на форум мысли развлечь от авраала за чашкой чая.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!


Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.


Войти
Подписчики 0