The OpenNET Project / Index page

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




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
Как при помощи route-map отфильтровать GRE траффик?, !*! sergjack, 06-Фев-07, 14:59  [смотреть все]
Есть два маршрутизатора А и Б
Каждый присоединен к интернет двумя интерфейсами. Между собой маршрутизаторы связаны парой туннелей.

Маршрутизатор А

int fa0/1.102
ip add 1.2.3.4 255.255.255.252


int fa0/1.103
ip add 2.3.4.5 255.255.255.252

int tun0
ip add 172.16.0.1 255.255.255.0
tun source fa0/1.102
tun dest 3.4.5.6

int tun1
ip add 172.16.1.1 255.255.255.0
tun source fa0/1.103
tun dest 4.5.6.7

ip route 0.0.0.0 0.0.0.0 1.2.3.3


Маршрутизатор Б

int fa0/1.102
ip add 3.4.5.6 255.255.255.252


int fa0/1.103
ip add 4.5.6.7 255.255.255.252

int tun0
ip add 172.16.0.1 255.255.255.0
tun source fa0/1.102
tun dest 1.2.3.4

int tun1
ip add 172.16.1.1 255.255.255.0
tun source fa0/1.103
tun dest 2.3.4.5

ip route 0.0.0.0 0.0.0.0 3.4.5.6

Соответственно по одному дефолтному маршруту.

Необходимо, чтобы tun1 взаимодействовал именно по второму провайдеру.
Вариант с прописыванием статических маршрутов не подходит.
Есть свои мысли по поводу policy routing, но не хочу пока озвучивать, чтобы не сбивать с толку, хочу услышать свежих мыслей.

  • Как при помощи route-map отфильтровать GRE траффик?, !*! fantom, 20:56 , 06-Фев-07 (1)
    А чем статика неподходит?
    ip route 2.3.4.5 255.255.255.255 <IPвторого прова>
    Ну или роут-мап.
    • Как при помощи route-map отфильтровать GRE траффик?, !*! sergjack, 22:38 , 06-Фев-07 (2)
      >А чем статика неподходит?
      >ip route 2.3.4.5 255.255.255.255 <IPвторого прова>
      >Ну или роут-мап.

      Статика не подходит тем, что в реальности все чуть посложнее.
      Используется DMVPN и таких удаленных маршрутизаторов за 30 штук
      Плюс у удаленных маршрутизаторов достаточно часто меняются IP адреса, так что статика - не решение.

      Вот я и бьюсь над роут-мапой, которая если пакет имеет source адрес одного провайдера, то отправлять пакет на next-hop одного, если другого - то на next-hop другого.
      Роут мапу я прикрутил как ip local policy route-map, и создается впечатление, что все работает (трейс правильно ходит, туннели поднимаются), до тех пор, пока не падает один из провайдеров.
      Просто то ли пакеты не подпадают под local policy, то ли при формировании GRE пакета ему уже надо обязательно знать на какой next-hop его надо отправить.


      • Как при помощи route-map отфильтровать GRE траффик?, !*! fantom, 11:41 , 07-Фев-07 (3)
        А если падает один из провайдеров, отваливается ВСЕ или только линк, через него ходящий?

        Кроме того, обратные маршруты совпадают или нет? если пакет ушел на провайдера 1 есть ли уверенность что ответ придет тоже через провайдера 1 а не провайдера 2????

        Что показывают трейсы с другой стороны туннеля?

        • Как при помощи route-map отфильтровать GRE траффик?, !*! sergjack, 12:10 , 07-Фев-07 (4)
          >А если падает один из провайдеров, отваливается ВСЕ или только линк, через
          >него ходящий?
          >
          >Кроме того, обратные маршруты совпадают или нет? если пакет ушел на провайдера
          >1 есть ли уверенность что ответ придет тоже через провайдера 1
          >а не провайдера 2????
          >
          >Что показывают трейсы с другой стороны туннеля?


          Если роут-мапы прикручены с обеих сторон - то все работает правильно.
          Трэйсы с указанием соответствующенго source интерфейса идут правильно.
          На сам маршрутизатор можно попасть по внешнему IP через любого из провайдеров, даже если вообще убрать ip route 0.0.0.0 0.0.0.0

          А вот с GRE что-то не так. Толи они не подпадают под локальную политику или в момент формирования пакета маршрутизатору уже нужно знать, куда пакет отправить.

          Вот мой вариант:

          ip local policy route-map isp

          route-map isp permit 10
          match ip address bcl
          set interface GigabitEthernet0/1.20
          set ip next-hop 1.2.3.4

          !
          route-map isp permit 20
          match ip address smart
          set interface GigabitEthernet0/1
          set ip next-hop 2.3.4.5

          ip access-list extended bcl
          permit ip 1.2.3.2 0.0.0.3 any

          ip access-list extended smart
          permit ip 2.3.4.4 0.0.0.3 any

          При этом циска доступна извне (могу попасть телнетом) и по адресу 1.2.3.4 и по адресу 2.3.4.5 даже при отстутствии DG или одного из провайдеров.
          Кроме того, устанавливаются IPSEC и ISAKMP туннели, а вот траффик внутри туннелей не идет.





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

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