forum.opennet.ru - "local PBR" (7)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"local PBR"

Форумы Маршрутизаторы CISCO и др. оборудование. (Маршрутизация)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"local PBR"		+/–
Сообщение от druidman (ok) on 24-Май-10, 08:15
Здравствуйте, cisco 2800 Применяем PBR к трафику, генерируему самим роутером (ip local police route-map XXX)...и почему то все пакеты, которые не удовлетворяют условиям access-lista в route-map режутся (точнее не режутся, а не находя запись дальнейшего хопа никуда не уходят). Если я правильно понимаю, то они должны не резаться, а искать соответствия адреса назначения в стандартной таблице маршрутизации? Чтож теперь если я применяю PBR к локальному трафику мне обязательно нужно описывать кроме того что я хочу переопределить относительно таблице маршрутизации еще и все остальное??? Зачем это делать, если все это есть в локальной таблице маршрутизации?
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

local PBR, Pve1, 09:40 , 24-Май-10, (1)

local PBR, druidman, 10:40 , 24-Май-10, (2)

local PBR, Pve1, 13:17 , 24-Май-10, (3)

local PBR, druidman, 13:36 , 24-Май-10, (4)

local PBR, Pve1, 17:51 , 24-Май-10, (5)

local PBR, Pve1, 18:37 , 24-Май-10, (6)

local PBR, druidman, 06:05 , 25-Май-10, (7)

Сообщения по теме [Сортировка по времени | RSS]

1. "local PBR" +/–

Сообщение от Pve1 (ok) on 24-Май-10, 09:40

>[оверквотинг удален]
>cisco 2800
>Применяем PBR к трафику, генерируему самим роутером (ip local police route-map XXX)...и
>почему то все пакеты, которые не удовлетворяют условиям access-lista в route-map
>режутся (точнее не режутся, а не находя запись дальнейшего хопа никуда
>не уходят). Если я правильно понимаю, то они должны не резаться,
>а искать соответствия адреса назначения в стандартной таблице маршрутизации?
>Чтож теперь если я применяю PBR к локальному трафику мне обязательно нужно
>описывать кроме того что я хочу переопределить относительно таблице маршрутизации еще
>и все остальное??? Зачем это делать, если все это есть в
>локальной таблице маршрутизации?
Вообще формулировка "Применяем PBR к трафику, генерируему самим роутером (ip local police route-map XXX)" - не совсем верна.  Такое привило применяется ко всему проходящему через рутер трафику.
Покажите ваш роутмап, и чего добиться хотите объясните.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "local PBR" +/–

Сообщение от druidman (ok) on 24-Май-10, 10:40

>Вообще формулировка "Применяем PBR к трафику, генерируему самим роутером (ip local police
>route-map XXX)" - не совсем верна.  Такое привило применяется ко
>всему проходящему через рутер трафику.
>Покажите ваш роутмап, и чего добиться хотите объясните.
Разве ко всему трафику? ... хм
Но почему локальная таблица маршрутизации то не просматривается ???
хочу я следующего ,
две cisco 2811 на разных концах, у каждой по два ISP...нужно сделать максимально отказоустойчивую конфигурацию - т.е. 4 туннеля (IPSEC) (каждый с каждым).
В таблице маршрутизации используются AD для туннелей (4 туннеля каждый со своим приоритетом).
Для переключения между провайдерами (default route) используется sla monitor, получется, что если не использовать PBRдля локального трафика (чтоб туннели установились), то установившееся IPSEC туннель будет всегда один, остальные будут пытаться установиться.
Я же хочу, чтоб все туннели были постоянно установленные и при падении, скажем, tunnel0 маршрут удалялся из таблицы маршрутизации и моментально происходило переключение на туннель, далее следующий в приоритете за tunnel0:
Выдержка из конфига:
interface Tunnel0
description fa00-fa00
ip unnumbered FastEthernet0/0
ip mtu 1400
keepalive 5 3
tunnel source FastEthernet0/0
tunnel destination 10.0.0.2
tunnel mode ipsec ipv4
tunnel protection ipsec profile srv-fa00-cl-fa00
!
interface Tunnel1
description fa00-fa01
ip unnumbered FastEthernet0/0
ip mtu 1400
keepalive 5 3
tunnel source FastEthernet0/0
tunnel destination 192.168.8.2
tunnel mode ipsec ipv4
tunnel protection ipsec profile srv-fa00-cl-fa00
!
interface Tunnel2
description fa01-fa00
ip unnumbered FastEthernet0/1
ip mtu 1400
keepalive 5 3
tunnel source FastEthernet0/1
tunnel destination 192.168.8.2
tunnel mode ipsec ipv4
tunnel protection ipsec profile srv-fa00-cl-fa00
!
interface Tunnel3
description fa01-fa01
ip unnumbered FastEthernet0/1
ip mtu 1400
keepalive 5 3
tunnel source FastEthernet0/1
tunnel destination 10.0.0.2
tunnel mode ipsec ipv4
tunnel protection ipsec profile srv-fa00-cl-fa00
!
interface FastEthernet0/0
ip address 10.30.0.2 255.255.0.0
ip access-group ACL-ISP1-IN in
ip nat outside
ip nat enable
ip virtual-reassembly
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 172.16.0.60 255.255.255.0
ip access-group ACL-ISP2-IN in
ip nat outside
ip nat enable
ip virtual-reassembly
duplex auto
speed auto
-------------------
!
route-map tunnel permit 10
match ip address tun0-1
set ip next-hop 10.30.0.1
!
route-map tunnel permit 20
match ip address tun1-2
set ip next-hop 172.16.0.25
!
ip access-list extended tun0-1
permit esp host 10.30.0.2 host 10.0.0.2
permit esp host 10.30.0.2 host 192.168.8.2
permit udp host 10.30.0.2 host 10.0.0.2 eq isakmp
permit udp host 10.30.0.2 host 192.168.8.2 eq isakmp
deny   ip any any
ip access-list extended tun2-3
permit esp host 172.16.0.60 host 10.0.0.2
permit esp host 172.16.0.60 host 192.168.8.2
permit udp host 172.16.0.60 host 10.0.0.2 eq isakmp
permit udp host 172.16.0.60 host 192.168.8.2 eq isakmp
deny   ip any any
!
          -(10.30.0.2) ------   ISP1_GW(10.30.0.1)-----------
cisco1                                                                          ...cisco2
          - (172.16.0.60) ----- ISP2_GW(172.16.0.60)---------
Как только выполняю ip local policy route-map tunnel , теряется связь с циской

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

3. "local PBR" +/–

Сообщение от Pve1 (ok) on 24-Май-10, 13:17

По ip local policy route-map tunnel   - с утра фигню написал...
PBR - вам не нужен совсем. Для отказоустойчивого роутинга через тунели надо использовать протокол динамической маршрутизации, как EIGRP, OSPF.
То что вы нагородили - это какой то адский изврат.
В конкретной трабле проблема скорее такая -
permit udp host 10.30.0.2 host 10.0.0.2 eq isakmp - считается локальным трафиком, и шлется через PBR.
permit esp host 10.30.0.2 host 10.0.0.2 - Считается проходящим трафиком, а не локальным - и шлется через таблицу маршрутизации. В итоге они идут

Суть вашей задумки до конца не понял - но это в любом случае адский изврат. И делать так ни в коем случае не надо. Почитайте вообще про EIGRP, OSPF и концепцию DMVPN. Там прям показано, как что настраивать.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

4. "local PBR" +/–

Сообщение от druidman (ok) on 24-Май-10, 13:36

>[оверквотинг удален]
>и шлется через PBR.
>permit esp host 10.30.0.2 host 10.0.0.2 - Считается проходящим трафиком, а не
>локальным - и шлется через таблицу маршрутизации. В итоге они идут
>
>
>
>Суть вашей задумки до конца не понял - но это в любом
>случае адский изврат. И делать так ни в коем случае не
>надо. Почитайте вообще про EIGRP, OSPF и концепцию DMVPN. Там прям
>показано, как что настраивать.
Дело в том, что связь с циской теряется, т.е. cisca не отвечает в локальную сеть ... вообще не упомянутую в access-liste для route-mapa ... почему не просматривается локальная таблица маршрутизации????
Про динамические протоколы... дело в том, что ospf и иже с ним обмениваются анонсами уже в установленных туннелях...а чтоб установить туннели нужен PBR(конкретно в моем случае, так как при установлении некоторых туннелей пакеты должны идти отличным от дефолтного роута маршрутом) а далее OSPF или статика с AD ...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

5. "local PBR" +/–

Сообщение от Pve1 (ok) on 24-Май-10, 17:51

Мдаа.... идею понял))))
Но все же, я бы сделал по другому:
Без  PBR.
1.)Описать все 4 тунеля(прямые, и крест-накрест).
2.)Далее создать статические маршруты для 2-х тунелей с привязкой по IP SLA что бы, было так:
         fa0/0 (ISP1) ----(tunel1)---- fa 0/0 (ISP3)
Роeтер 1                                               Роутер 2
         fa0/1 (ISP2) ----(tunel2)---- fa0/1 (ISP4)
Если один из провайдеров/интерфейсов падает - маршрут должен изыматься SLA tracking-ом из таблицы маршрутизации. Иначе работать не станет.
3.) написать аксесс листы на внешних интерфейсах (направление out) маршрутизаторов, блокирующих ESP/IKE сессии с адреса соседнего интерфейса. Т.е. что бы роутер не мог маршрутизировать тунельный трафик с одного интерфейса через другой.
При этом получим:
1. При работоспособности всех провайдеров/интерфейсов - будем иметь 2 рабочих тунеля.
2. При падении любых 1-2 провайдеров - всегда будем иметь 1 рабочий тунель.
Далее поднимаем протокол маршрутизации...
И главное - все просто, CPU не грузится PBR-ом. Меньше трафика хавают hellow пакеты.
В вашем же варианте - скорее всего дело в следующем
1. IKE сессии действительно подпадают под local policy
2. ESP сессии, в которые инкапсулируется проходящий трафик - подпадают под global policy.
При этом, что интересно - маршрутизация происходит до процесса инкапсуляции в ESP.
Т.е. ваши роутмапы - мертвому припарка...
Как правильно решить данную задачку - даже и не соображу... но надо ли оно? Есть ведь  вышеуказанный вариант. Разница только в 2 активных туннелях вместо 4-х.
А по недоступности - стало быть ваш роутмап ответный трафик рутера заворачивает...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

6. "local PBR" +/–

Сообщение от Pve1 (ok) on 24-Май-10, 18:37

Подзабыл совсем...  аксесс листы к трафику самого рутера тож вроде не применяются...
Так что наверное придется ненужные тунели дропить все той же ip local policy.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

7. "local PBR" +/–

Сообщение от druidman (ok) on 25-Май-10, 06:05

Идея интересная...в общем то, наверно, не нужно постоянно 4 туннеля - учитывая, что 99,9 процентов времени будет работать один
Вариант я попробую, и отпишусь...
с local PBR так и не понятно, не может ответ в локальную сеть никуда заворачиваться, он не попадает под действие списков доступа для маршрутной карты, т.е. вывод один - глобальная таблица маршрутизации не просматривается, а трафик, не найдя соответствия в local PBR просто дропится - я понимаю, что чудес не бывает, может битый иос...буду разбираться.
В любом случае - большое спасибо :)))

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "local PBR"		+/–
Сообщение от Pve1 (ok) on 24-Май-10, 09:40
>[оверквотинг удален] >cisco 2800 >Применяем PBR к трафику, генерируему самим роутером (ip local police route-map XXX)...и >почему то все пакеты, которые не удовлетворяют условиям access-lista в route-map >режутся (точнее не режутся, а не находя запись дальнейшего хопа никуда >не уходят). Если я правильно понимаю, то они должны не резаться, >а искать соответствия адреса назначения в стандартной таблице маршрутизации? >Чтож теперь если я применяю PBR к локальному трафику мне обязательно нужно >описывать кроме того что я хочу переопределить относительно таблице маршрутизации еще >и все остальное??? Зачем это делать, если все это есть в >локальной таблице маршрутизации? Вообще формулировка "Применяем PBR к трафику, генерируему самим роутером (ip local police route-map XXX)" - не совсем верна. Такое привило применяется ко всему проходящему через рутер трафику. Покажите ваш роутмап, и чего добиться хотите объясните.
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	2. "local PBR"		+/–
	Сообщение от druidman (ok) on 24-Май-10, 10:40
	>Вообще формулировка "Применяем PBR к трафику, генерируему самим роутером (ip local police >route-map XXX)" - не совсем верна. Такое привило применяется ко >всему проходящему через рутер трафику. >Покажите ваш роутмап, и чего добиться хотите объясните. Разве ко всему трафику? ... хм Но почему локальная таблица маршрутизации то не просматривается ??? хочу я следующего , две cisco 2811 на разных концах, у каждой по два ISP...нужно сделать максимально отказоустойчивую конфигурацию - т.е. 4 туннеля (IPSEC) (каждый с каждым). В таблице маршрутизации используются AD для туннелей (4 туннеля каждый со своим приоритетом). Для переключения между провайдерами (default route) используется sla monitor, получется, что если не использовать PBRдля локального трафика (чтоб туннели установились), то установившееся IPSEC туннель будет всегда один, остальные будут пытаться установиться. Я же хочу, чтоб все туннели были постоянно установленные и при падении, скажем, tunnel0 маршрут удалялся из таблицы маршрутизации и моментально происходило переключение на туннель, далее следующий в приоритете за tunnel0: Выдержка из конфига: interface Tunnel0 description fa00-fa00 ip unnumbered FastEthernet0/0 ip mtu 1400 keepalive 5 3 tunnel source FastEthernet0/0 tunnel destination 10.0.0.2 tunnel mode ipsec ipv4 tunnel protection ipsec profile srv-fa00-cl-fa00 ! interface Tunnel1 description fa00-fa01 ip unnumbered FastEthernet0/0 ip mtu 1400 keepalive 5 3 tunnel source FastEthernet0/0 tunnel destination 192.168.8.2 tunnel mode ipsec ipv4 tunnel protection ipsec profile srv-fa00-cl-fa00 ! interface Tunnel2 description fa01-fa00 ip unnumbered FastEthernet0/1 ip mtu 1400 keepalive 5 3 tunnel source FastEthernet0/1 tunnel destination 192.168.8.2 tunnel mode ipsec ipv4 tunnel protection ipsec profile srv-fa00-cl-fa00 ! interface Tunnel3 description fa01-fa01 ip unnumbered FastEthernet0/1 ip mtu 1400 keepalive 5 3 tunnel source FastEthernet0/1 tunnel destination 10.0.0.2 tunnel mode ipsec ipv4 tunnel protection ipsec profile srv-fa00-cl-fa00 ! interface FastEthernet0/0 ip address 10.30.0.2 255.255.0.0 ip access-group ACL-ISP1-IN in ip nat outside ip nat enable ip virtual-reassembly duplex auto speed auto ! interface FastEthernet0/1 ip address 172.16.0.60 255.255.255.0 ip access-group ACL-ISP2-IN in ip nat outside ip nat enable ip virtual-reassembly duplex auto speed auto ------------------- ! route-map tunnel permit 10 match ip address tun0-1 set ip next-hop 10.30.0.1 ! route-map tunnel permit 20 match ip address tun1-2 set ip next-hop 172.16.0.25 ! ip access-list extended tun0-1 permit esp host 10.30.0.2 host 10.0.0.2 permit esp host 10.30.0.2 host 192.168.8.2 permit udp host 10.30.0.2 host 10.0.0.2 eq isakmp permit udp host 10.30.0.2 host 192.168.8.2 eq isakmp deny ip any any ip access-list extended tun2-3 permit esp host 172.16.0.60 host 10.0.0.2 permit esp host 172.16.0.60 host 192.168.8.2 permit udp host 172.16.0.60 host 10.0.0.2 eq isakmp permit udp host 172.16.0.60 host 192.168.8.2 eq isakmp deny ip any any ! -(10.30.0.2) ------ ISP1_GW(10.30.0.1)----------- cisco1 ...cisco2 - (172.16.0.60) ----- ISP2_GW(172.16.0.60)--------- Как только выполняю ip local policy route-map tunnel , теряется связь с циской
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	3. "local PBR"		+/–
	Сообщение от Pve1 (ok) on 24-Май-10, 13:17
	По ip local policy route-map tunnel - с утра фигню написал... PBR - вам не нужен совсем. Для отказоустойчивого роутинга через тунели надо использовать протокол динамической маршрутизации, как EIGRP, OSPF. То что вы нагородили - это какой то адский изврат. В конкретной трабле проблема скорее такая - permit udp host 10.30.0.2 host 10.0.0.2 eq isakmp - считается локальным трафиком, и шлется через PBR. permit esp host 10.30.0.2 host 10.0.0.2 - Считается проходящим трафиком, а не локальным - и шлется через таблицу маршрутизации. В итоге они идут Суть вашей задумки до конца не понял - но это в любом случае адский изврат. И делать так ни в коем случае не надо. Почитайте вообще про EIGRP, OSPF и концепцию DMVPN. Там прям показано, как что настраивать.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	4. "local PBR"		+/–
	Сообщение от druidman (ok) on 24-Май-10, 13:36
	>[оверквотинг удален] >и шлется через PBR. >permit esp host 10.30.0.2 host 10.0.0.2 - Считается проходящим трафиком, а не >локальным - и шлется через таблицу маршрутизации. В итоге они идут > > > >Суть вашей задумки до конца не понял - но это в любом >случае адский изврат. И делать так ни в коем случае не >надо. Почитайте вообще про EIGRP, OSPF и концепцию DMVPN. Там прям >показано, как что настраивать. Дело в том, что связь с циской теряется, т.е. cisca не отвечает в локальную сеть ... вообще не упомянутую в access-liste для route-mapa ... почему не просматривается локальная таблица маршрутизации???? Про динамические протоколы... дело в том, что ospf и иже с ним обмениваются анонсами уже в установленных туннелях...а чтоб установить туннели нужен PBR(конкретно в моем случае, так как при установлении некоторых туннелей пакеты должны идти отличным от дефолтного роута маршрутом) а далее OSPF или статика с AD ...
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	5. "local PBR"		+/–
	Сообщение от Pve1 (ok) on 24-Май-10, 17:51
	Мдаа.... идею понял)))) Но все же, я бы сделал по другому: Без PBR. 1.)Описать все 4 тунеля(прямые, и крест-накрест). 2.)Далее создать статические маршруты для 2-х тунелей с привязкой по IP SLA что бы, было так: fa0/0 (ISP1) ----(tunel1)---- fa 0/0 (ISP3) Роeтер 1 Роутер 2 fa0/1 (ISP2) ----(tunel2)---- fa0/1 (ISP4) Если один из провайдеров/интерфейсов падает - маршрут должен изыматься SLA tracking-ом из таблицы маршрутизации. Иначе работать не станет. 3.) написать аксесс листы на внешних интерфейсах (направление out) маршрутизаторов, блокирующих ESP/IKE сессии с адреса соседнего интерфейса. Т.е. что бы роутер не мог маршрутизировать тунельный трафик с одного интерфейса через другой. При этом получим: 1. При работоспособности всех провайдеров/интерфейсов - будем иметь 2 рабочих тунеля. 2. При падении любых 1-2 провайдеров - всегда будем иметь 1 рабочий тунель. Далее поднимаем протокол маршрутизации... И главное - все просто, CPU не грузится PBR-ом. Меньше трафика хавают hellow пакеты. В вашем же варианте - скорее всего дело в следующем 1. IKE сессии действительно подпадают под local policy 2. ESP сессии, в которые инкапсулируется проходящий трафик - подпадают под global policy. При этом, что интересно - маршрутизация происходит до процесса инкапсуляции в ESP. Т.е. ваши роутмапы - мертвому припарка... Как правильно решить данную задачку - даже и не соображу... но надо ли оно? Есть ведь вышеуказанный вариант. Разница только в 2 активных туннелях вместо 4-х. А по недоступности - стало быть ваш роутмап ответный трафик рутера заворачивает...
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	6. "local PBR"		+/–
	Сообщение от Pve1 (ok) on 24-Май-10, 18:37
	Подзабыл совсем... аксесс листы к трафику самого рутера тож вроде не применяются... Так что наверное придется ненужные тунели дропить все той же ip local policy.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	7. "local PBR"		+/–
	Сообщение от druidman (ok) on 25-Май-10, 06:05
	Идея интересная...в общем то, наверно, не нужно постоянно 4 туннеля - учитывая, что 99,9 процентов времени будет работать один Вариант я попробую, и отпишусь... с local PBR так и не понятно, не может ответ в локальную сеть никуда заворачиваться, он не попадает под действие списков доступа для маршрутной карты, т.е. вывод один - глобальная таблица маршрутизации не просматривается, а трафик, не найдя соответствия в local PBR просто дропится - я понимаю, что чудес не бывает, может битый иос...буду разбираться. В любом случае - большое спасибо :)))
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору