The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]




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

    Вообще формулировка "Применяем PBR к трафику, генерируему самим роутером (ip local police route-map XXX)" - не совсем верна.  Такое привило применяется ко всему проходящему через рутер трафику.
    Покажите ваш роутмап, и чего добиться хотите объясните.  

    • local PBR, !*! druidman, 10:40 , 24-Май-10 (2)
      >Вообще формулировка "Применяем 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 , теряется связь с циской

      • local PBR, !*! Pve1, 13:17 , 24-Май-10 (3)
        По 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. Там прям показано, как что настраивать.

        • local PBR, !*! druidman, 13:36 , 24-Май-10 (4)
          >[оверквотинг удален]
          >и шлется через 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 ...

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

            Мдаа.... идею понял))))

            Но все же, я бы сделал по другому:
            Без  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-х.

            А по недоступности - стало быть ваш роутмап ответный трафик рутера заворачивает...

            • local PBR, !*! Pve1, 18:37 , 24-Май-10 (6)
              Подзабыл совсем...  аксесс листы к трафику самого рутера тож вроде не применяются...
              Так что наверное придется ненужные тунели дропить все той же ip local policy.
              • local PBR, !*! druidman, 06:05 , 25-Май-10 (7)
                Идея интересная...в общем то, наверно, не нужно постоянно 4 туннеля - учитывая, что 99,9 процентов времени будет работать один
                Вариант я попробую, и отпишусь...
                с local PBR так и не понятно, не может ответ в локальную сеть никуда заворачиваться, он не попадает под действие списков доступа для маршрутной карты, т.е. вывод один - глобальная таблица маршрутизации не просматривается, а трафик, не найдя соответствия в local PBR просто дропится - я понимаю, что чудес не бывает, может битый иос...буду разбираться.
                В любом случае - большое спасибо :)))



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру