2.2 Filter-Based Forwarding

2. Load Balancing и Filter-Based Forwarding

2.2 Filter-Based Forwarding

При стандартной маршрутизации, когда маршрутизатор получает пакет, он анализирует сеть назначения в этом пакете и выбирает next-hop в Forwarding Table, через который достижима сеть назначения. Применяя Filter-Based Forwarding можно изменить эту логику работы, тем самым добавив некоторую гибкость при маршрутизации. Filter-Based Forwarding позволяет переопределить путь пересылки пакета, основываясь на различных параметрах.

Аналогом указанной технологии является Policy-Based Routing (PBR) в Cisco.

Принцип стандартной маршрутизации:

2-2-1

для пакетов в сеть назначения 172.19.25.1/32 в Forwarding Table маршрутизатора протоколом маршрутизации установлен next-hop ISP A.


Filter-Based Forwarding (FBF)

Filter-Based Forwarding позволяет маршрутизатору принимать решение о пересылке трафика на основании неких критериев в дополнение к префиксу назначения. Входящие пакеты классифицируются фильтром, применённым на входящем интерфейсе маршрутизатора, и на основании этого фильтра принимается решение о дальнейшем пути пересылки пакетов к сети назначения:

2-2-2

маршрутизатор R1 анализирует входящие пакеты и, на основании критерия «source address» пакета (в дополнение к префиксу назначения), отправляет пакеты из сети 172.25.0.0/24 через ISP A, а пакеты из сети 172.25.1.0/24 через ISP B.

Filter-Based Forwarding поддерживается для IPv4 и IPv6.


Настройка Filter-Based Forwarding

Для настройки Filter-Based Forwarding необходимо выполнить 3 шага:

2-2-3

Произведём настройку Filter-Based Forwarding для следующей топологии:

2-2-4

т.е. R1 должен отправлять пакеты из сети 172.25.0.0/24 через ISP A, а пакеты из сети 172.25.1.0/24 через ISP B.

1. Создаём фильтр

[edit firewall]
user@R1# show
family inet {
     filter MY-MATCH-FILTER {
          term MATCH-SUBNET-A {
               from {
                    source-address {
                         172.25.0.0/24;
                    }
               }
               then {
                    routing-instance ISP-A;
               }
          }
          term MATCH-SUBNET-B {
               from {
                    source-address {
                         172.25.1.0/24;
                    }
               }
               then {
                    routing-instance ISP-B;
               }
          }
     }
}

В конфигурации 2 критерия выбора source-address, один для пакетов из сети 172.25.0.0/24, другой — для пакетов из сети 172.25.1.0/24.

Каждому критерию выбора соответствует действие — в нашем случае это направление выбранного нами трафика в соответствующий Routing Instance: пакеты из сети 172.25.0.0/24 направляются в routing-instance ISP-A, а пакеты из сети 172.25.1.0/24 направляются в routing-instance ISP-B для принятия решения о маршрутизации этих пакетов.

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

2. Создаём Routing Instances

На предыдущем шаге была произведена классификация трафика и отправка этого трафика в соответствующие Routing Instances. Значит теперь необходимо создать эти Routing Instances:

[edit routing-instances]
user@R1# show
ISP-A {
     instance-type forwarding;
     routing-options {
          static {
               route 0.0.0.0/0 next-hop 172.20.0.2;
          }
     }
}
ISP-B {
     instance-type forwarding;
     routing-options {
          static {
          route 0.0.0.0/0 next-hop 172.20.1.2;
          }
     }
}

Теперь пакеты, попадающие в Routing Instance ISP-A «увидят» таблицу маршрутизации этого Routing Instance, в которой присутствует маршрут по-умолчанию через next-hop 172.20.0.2 (т.е. через ISP A). Аналогично, пакеты, попадающие в Routing Instance ISP-B «увидят» таблицу маршрутизации этого Routing Instance, в которой присутствует маршрут по-умолчанию через next-hop 172.20.1.2 (т.е. через ISP B). Однако в таблицах маршрутизации этих Routing Instances есть только маршрут по-умолчанию и нет маршрута до next-hop’ов (т.е. IP адресов провайдеров 172.20.0.2 и 172.20.1.2), поэтому необходимо создать RIB Group.

Странно, но после выполнения этого шага в таблицах маршрутизации ISP-A и ISP-B не появился маршрут в 0/0 (таблица пустая). Вероятно связано это с тем, что недоступен next-hop для маршрута в 0/0.

3. Создаём RIB group

[edit routing-options]
user@R1# show
interface-routes {
     rib-group inet MY-RIB-GROUP;
}
rib-groups {
     MY-RIB-GROUP {
          import-rib [inet.0  ISP-A.inet.0  ISP-B.inet.0];
     }
}

С помощью этой RIB group импортируются «интерфейсные маршруты» из таблицы маршрутизации inet.0 в таблицы маршрутизации ISP-A.inet.0 и ISP-B.inet.0 2-ух созданных ранее Routing Instances: ISP-A и ISP-B.

Просмотрев таблицы маршрутизации ISP-A.inet.0 и ISP-B.inet.0 можно увидеть, что в них появились «интерфейсные маршруты» маршруты и маршрут в 0.0.0.0/0:

2-2-5

Осталось только применить созданный на 1-ом шаге фильтр на интерфейс, в который «входят» пакеты из сетей 172.25.0.0/24 и 172.25.1.0/24:

[edit interface ge-0/0/1]
user@R1# show
unit 0 {
     family inet {
          filter {
               input MY-MATCH-FILTER;
          }
          address 172.25.0.1/24;
          address 172.25.1.1/24;
     }
}

Следует отметить, что фильтр применяется на входящий интерфейс в направлении input.

Проверить, что созданный и применённый Filter-Based Forwarding работает, можно запустив трассировку либо с конечных устройств, либо с маршрутизатора R1, указав в качестве источника трассировки IP адрес из подсети 172.25.0.0/24 и 172.25.1.0/24.

Следует акцентировать внимание на некоторые моменты:

  • Для настройки Filter-Based Forwarding тип Routing Instance должен быть forwarding (instance-type forwarding)
  • При использовании Filter-Based Forwarding такие технологии, как Unicast Reverse-Path Forwarding (URPF) и Source-Class Usage Filter Matching не будут поддерживаться на интерфейсе, на котором настроен Filter-Based Forwarding
  • При настройке маршрутизации в Routing Instance, в качестве next-hop’а может быть не IP адрес, а другая таблица маршрутизации (route 0.0.0.0/0 next-table inet.0)

Используемый в конфигурации RIB group для обмена маршрутной информацией между таблицами маршрутизации использовался в ранних версиях JunOS и имеет ряд недостатков:

  • плохое интуитивное восприятие конфигурации
  • комплексные требования к конфигурированию
  • избыточность экспортируемой и импортируемой маршрутной информации между таблицами
  • настройка per-protocol

Обмен маршрутной информацией между таблицами маршрутизации на роутере, помимо использования RIB group, начиная с релиза JunOS 5.4 можно ещё выполнить используя опцию instance-import.

При использовании опции instance-import отпадает необходимость в настройке RIB group на шаге 3 нашего примера. Необходимо только добавить Routing Policy и немного изменить настройку Routing Instance (на шаге 2). Рассмотрим на примере для ISP-A-IMPORT.

Добавляем Routing Policy:

[edit policy-options]
user@R1# show
policy-statement ISP-A-IMPORT {
     from instance master;
     then accept;
}

политикой указываем импорт маршрутной информации из таблицы маршрутизации master (т.е. inet.0), хотя можно импортировать из любой таблицы (указав имя Routing Instance вместо master),

и добавляем всего одну строку в конфигурацию Routing Instance:

[edit routing-instances]
user@R1# show
ISP-A {
     instance-type forwarding;
     routing-options {
          static {
               route 0.0.0.0/0 next-hop 172.20.0.2;
          }
          instance-import ISP-A-IMPORT
     }
}

т.е. instance-import указывает импортировать маршрутную информацию в таблицу маршрутизации настраемого Routing Instance (т.е. ISP-A) согласно routing policy с именем ISP-A-IMPORT.

К оглавлению

Добавить комментарий