ISP`s IT Аутсорсинг
Быстрый переход: Главная блога Главная сайта Форум
Если Вы чего то недопоняли или не нашли - задайте
вопрос на нашем форуме и мы попробуем Вам помочь.
Subnets.ru Регистрация IP и Автономных систем mega-net.ru

Метки статьи: ‘PBR’

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

Я уже писал об использовании PBR на оборудовании Cisco, а в этой статье мы будем это делать на Juniper.

PBR предоставляет механизм реализации пересылки (forwarding)/ маршрутизации (routing) пакетов данных, основанный на политике, представляющей собой набор правил, определенной администраторами сети. Это предоставляет более гибкий механизм для обработки пакетов на маршрутизаторах, дополняя существующий механизм, предоставленный протоколами маршрутизации.

Дано

  • ISP#1 (10.0.0.1/30), подключение по BGP
  • ISP#2, подключение по BGP
  • Juniper MX240

Задача

Настроить BGP сессии с двумя ISP`ами, а так же обеспечить работу статически пророученную на нас ISP#1 небольшую реальную подсеть, для примера скажем это будет 128.1.1.0/24.

Реализация

Если не применить PBR политику к статически пророученной ISP#1 подсети, то при передаче пакетов будут использовать маршруты, которые были получены по BGP от двух ISP`ов и пакеты от реальной подсети ISP#1 могут уходить в канал через ISP#2, что в большинстве случаях работать не будет, в виду того что ISP#2 не выпустит чужие подсети через свою инфрастуктуру или вы получите не симметричную трассу. К сожалению мы по своей работе сталкиваемся с провами, которые не осуществляют фильтрацию чужих подсетей, что развязывает руки DDoS`ерам… когда при атаках они подделывают SRC адреса. Я искренне надеюсь, что ты (читатель) осуществляешь фильтрацию перед тем как «выплюнуть» пакет из своей сети в свой внешний канал.

Немного теории по названиям роут таблиц в Junos`е:

JUNOS default routing tables Name

  • inet.0IPv4 unicast routes. BGP, IS-IS, OSPF, and RIP store their routing information in this table and use the routes in this table when advertising routes to their neighbors. Configured static routes are also stored in this table.
  • inet.1Multicast forwarding cache. DVMRP and PIM store their routing information in this table.
  • inet.2Used by MBGP to provide reverse path forwarding (RPF) checks.
  • inet.3Traffic engineering paths. Stores path and label information.
  • inet6.0IPv6 unicast routes.
  • iso.0ISO routes for IS-IS.
  • mpls.0MPLS label-switched path (LSP) next hops.

 

В реализации задачи нам поможет механизм rib-groups:

rib-groups group-name {
     import-policy [ policy-names ];
     import-rib [ routing-table-names ];
     export-rib routing-table-name;
}

А так же interface-routes:

interface-routes {
     rib-group group-name;
}

Приступим к настойке и для начала создадим rib группу, в конфиге получим:

root@mx240# show routing-options
interface-routes {
    rib-group inet isp1-static-group;
}
rib-groups {
    isp1-static-group {
        import-rib [ inet.0 isp1-static.inet.0 ];
    }
}

Затем создадим routing-instance isp1-static в которой и укажем default на ISP#1:

root@mx240# show routing-instances
isp1-static {
    instance-type forwarding;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop 10.0.0.1;
        }
    }
}

Теперь нам надо как то match`ить пакеты где source адресом выступает статически пророученная подсеть реальников 128.1.1.0/24 и перенапралять их в routing-instance isp1-static.
В этом нам поможет firewall filter:

root@mx240# show firewall filter isp1-static-subnets
term match {
    from {
        source-address {
            128.1.1.0/24;
        }
    }
    then {
        routing-instance isp1-static;
    }
}
term default {
    then accept;
}

Этим мы добиваемся того, что пакеты из подсети 128.1.1.0/24 будут маршрутизироватся по таблице isp1-static, а все остальные подсети будут использовать таблицу по умолчанию inet.

Что нам осталось сделать ?
Осталось применить наш filter на Layer-3 интерфейсе роутера откуда у нас поступают пакеты от клиентов с source адресом этой подсети.
В моем примере это vlan 3, т.к. именно за данным интерфейсом находится ещё один роутер, для клиентов в подсети 128.1.1.0/24:

root@mx240# show routing-options static
route 128.1.1.0/24 {
    next-hop 172.16.1.2;
    retain;
}

Применим filter:

root@mx240# show interfaces irb
unit 3 {
    family inet {
        filter {
            input isp1-static-subnets;
        }
        address 172.16.1.3/29;
    }
}

Все приготовления сделаны, теперь можно commit`ить конфигурацию и проверять её работу.
Посмотрим маршруты в созданной нами routing-instance isp1-static:

root@mx240> show route table isp1-static.inet.0
isp1-static.inet.0: 10 destinations, 10 routes (9 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 1d 18:51:33
                    > to 10.0.0.1 via irb.800
....skiped....

Как мы можем видеть наш default в данной таблице присутствует и таким образом все пакеты с SRC-адресом из подсети 128.1.1.0/24 будут отправлены через интерфейс на ISP#1 10.0.0.1.

Ссылки

 

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

 

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 4, среднее: 4,00 из 5)
Загрузка...
Отправить на почту Отправить на почту

Policy-based routing — это более гибкий механизм маршрутизации пакетов, чем обычная адресная маршрутизация (destination routing).

Его главная особенность состоит в том, что перед маршрутизацией все пакеты проходят через
маршрутную карту (route-map), которая определяет, какие пакеты маршрутизировать и какой роутер будет следующим исходя из IP-адреса источника (source — source routing). Вы можете включить policy-based routing если хотите, чтобы некоторые пакеты были направлены по пути, отличному от очевидно самого короткого пути (the obvious shortest path), то есть пути взятого из таблицы маршрутизации.

Необходимость применения данного метода разнообразна, например когда необходимо маршрутизировать несколько подсетей в два и более канала от двух разных провайдеров т.к. каждый провайдер дал свою подсеть, а default gateway на cisco смотрит только на одного из провайдеров.

Допустим что:
У нас имеется cisco catalyst 3560G c IOS advanced ip services
интерфейс для стыка с провайдером «пров-1» vlan 10, IP-адресация 1.1.1.0/30
выделенная подсеть для раздачи под юзеров 192.168.241.0/26
IP-адрес 192.168.241.1 висит на vlan 20

интерфейс для стыка с провайдером «пров-2» vlan 11, IP-адресация 2.2.2.0/30
выделенная подсеть для раздачи под юзеров 10.0.18.0/26
IP-адрес 10.0.18.1 висит на vlan 21

при этом роутинг по умолчанию на cisco указан на «пров-1»

ip route 0.0.0.0 0.0.0.0 1.1.1.1

Соответственно получаем ситуацию когда подсеть выделенная от пров-2 будет улетать в канал от пров-1 и работать не будет. В этой ситуации нам и поможет policy-based routing

Как разрешить эту проблему используя policy-based routing:
Switch> enable
Switch# configure terminal
Switch(config)# ip routing
Switch(config)# sdm prefer routing
Switch(config)# exit
Switch# wri
Switch# reload

После того как cisco перезагрузится:

Создаем standart access-list (например номер 11) где описываем подсеть выделенную пров-2:
Switch> enable
Switch# configure terminal
Switch(config)# ip access-list standard 11
Switch(config-std-nacl)# permit 10.0.18.0 0.0.0.63
Switch(config-std-nacl)# exit

Далее создаем маршрутную карту указывая в ней созданный access-list как то что нужно матчить (match):

Switch(config)# route-map TEST permit 10
Switch(config-route-map)# matсh ip address 11
Switch(config-route-map)# set ip next-hop 2.2.2.1
Switch(config-route-map)# exit

Так мы создали маршрутную карту route-map с именем TEST, которая матчит IP-адреса из подсети пров-2 и выставляет как next-hop IP-адрес пров-2, теперь осталось её применить.

Заходим на интерфейс cisco на котором висит IP-адрес 10.0.18.1, который будет выступать в качестве default gateway для пользователей в этой подсети:

Switch(config)# int vlan 21
Switch(config-if)# ip policy route-map TEST
Switch(config-if)# exit
Switch(config-if)# exit
Switch# wri

Вот и все. Таким образом все пакеты приходящие от подсети 10.0.18.0/26 на интерфейс vlan 21 будут «улетать» в правильный канал, а именно канал от пров-2.

Командой Switch# debug ip policy вы можете включить режим, который поможет вам
определить, что делает policy-based routing — попадают ли пакеты под
соответствующие правила и информацию о маршрутизации пакета.


Внимание !!!
Внимательно отнеситесь к включению этого режима, так как он может дать на выходе очень много информации, что неблагоприятно отразится на работе вашего маршрутизатора. Используйте этот режим при низком трафике через маршрутизатор, или укажите список доступа, который будет ловить интересующие вас пакеты.


Посмотреть содержание маршрутной карты можно командой:
Switch# show route-map TEST

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Николаев Дмитрий (virus (at) subnets.ru)
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 6, среднее: 4,33 из 5)
Загрузка...
Отправить на почту Отправить на почту