Примеры настройки BGP-сессий на оборудовании различных производителей

Рассмотрим топологию ниже:

Пример топологии

У Клиента есть две PI-сети:

• 8.8.8.0/24
• 8.8.9.0/24

Предполагается защищать только одну из них - 8.8.8.0/24.

Вторая сеть всегда должна маршрутизироваться непосредственно через ISP.

Клиент подключен по отказоустойчивой схеме к двум ISP посредством двух маршрутизаторов.
От обоих ISP Клиент получает full view и анонсирует им оба префикса /24.

Для отказоустойчивого подключения к Kaspersky DDoS Protection были построены туннели с топологией full mesh, т.е. от каждого маршрутизатора Клиента до двух площадок Kaspersky DDoS Protection.

Необходимо организовать динамическую маршрутизацию таким образом, чтобы:

• трафик сети 8.8.8.0/24 симметрично маршрутизировался через Kaspersky DDoS Protection;
• трафик других сетей не был затронут;
• выбор приоритетного маршрута для исходящего трафика из сети 8.8.8.0/24 выбирался на основе BGP-атрибута MED или метрики BGP.

Оборудование Cisco

BDR1:

interface GigabitEthernet0/0

description CORE

ip address 192.168.1.1 255.255.255.0

interface GigabitEthernet0/1

description BDR2-iBGP

ip address 10.100.1.1 255.255.255.252

interface Tunnel1

description KDP1

ip address 10.42.10.2 255.255.255.252

interface Tunnel2

description KDP2

ip address 10.42.10.6 255.255.255.252

(точки терминации туннелей опущены, как несущественные в данном примере)

BGP-роутер:
AS Клиента: 10000
AS Kaspersky DDoS Protection: 209030
Получаем от Kaspersky DDoS Protection: 5.5.5.5/32 (цель получения данного анонса раскрыта в разделе Policy-Based Routing)
Анонсируем Kaspersky DDoS Protection: 8.8.8.0/24

router bgp 10000

no synchronization

bgp deterministic-med

network 8.8.8.0 mask 255.255.255.0

network 8.8.9.0 mask 255.255.255.0

neighbor 10.42.10.1 remote-as 209030 # KDP1

neighbor 10.42.10.1 route-map KDP-OUT out

neighbor 10.42.10.1 route-map KDP-IN in

neighbor 10.42.10.5 remote-as 209030 # KDP2

neighbor 10.42.10.5 route-map KDP-OUT out

neighbor 10.42.10.5 route-map KDP-IN in

neighbor 10.100.1.2 remote-as 10000 # iBGP with BDR2

Конфигурируем фильтры:

ip prefix-list PL-KDP-IN seq 10 permit 5.5.5.5/32

ip prefix-list PL-PROTECTED seq 10 permit 8.8.8.0/24

route-map KDP-IN permit 10

match ip address prefix-list PL-KDP-IN

route-map KDP-OUT permit 10

match ip address prefix-list PL-PROTECTED

Policy-Based Routing (PBR)

Применяя PBR, мы решаем одновременно несколько задач:

• изменяем маршрут только для одной сети;
• применяем вопреки наличию в таблице маршрутизации специфичных префиксов для всего Интернета (full view).

  ip access-list standard KDP-PBR

  permit 8.8.8.0 0.0.0.255

# access-list типа "standard" всегда применяется к source-адресам.

route-map KDP-PBR permit 10

match ip address KDP-PBR

set ip next-hop recursive 5.5.5.5

# 5.5.5.5/32 - префикс, который анонсируется по BGP от Kaspersky DDoS Protection. Директива "recursive" показывает, что данный next-hop не находится в connected сети.

# Будет рекурсивно найден маршрут до 5.5.5.5/32 и выбран в качестве настоящего next-hop. Т.е. один из "концов" GRE-туннелей с Kaspersky DDoS Protection.

# Политика PBR применяется к интерфейсу, который "смотрит" внутрь сети, и трафик, подлежащий маршрутизации, на данном интерфейсе является входящим

# (исходящим со стороны Защищаемых серверов):

interface GigabitEthernet0/0

description CORE

ip policy route-map KDP-PBR

Оборудование Juniper

BDR1:

interfaces {

ge-0/0 {

description CORE;

unit 0 {

family inet {

address 192.168.1.1/24;

}

}

}

ge-0/1 {

description BDR2-iBGP;

unit 0 {

family inet {

address 192.168.1.1/24;

}

}

}

gr-0/2 {

unit 0 {

description KDP1;

tunnel {

source x.x.x.x;

destination y.y.y.y;

}

family inet {

address 10.42.10.2/30;

}

}

unit 1 {

description KDP2;

tunnel {

source x.x.x.x;

destination y.y.y.y;

}

family inet {

address 10.42.10.6/30;

}

}

}

(точки терминации туннелей опущены, как несущественные в данном примере)

BGP-роутер:
AS Клиента: 10000
AS Kaspersky DDoS Protection: 209030
Получаем от Kaspersky DDoS Protection: 5.5.5.5/32
Анонсируем Kaspersky DDoS Protection: 8.8.8.0/24

protocols {

bgp {

group KDP {

type external;

import KDP-IN;

export KDP-OUT;

peer-as 209030;

neighbor 10.42.10.1 {

description KDP-1;

}

neighbor 10.42.10.5 {

description KDP-1;

}

family inet {

unicast {

rib-group RIB-KDP;

/* Импорт маршрутов в альтернативную таблицу. Подробнее в разделе по FBF*/

}

}

}

group iBGP {

type internal;

peer-as 10000;

neighbor 10.100.1.2 {

description iBGP with BDR2;

}

}

}

}

Конфигурируем фильтры:

policy-options {

prefix-list PL-KDP-IN {

5.5.5.5/32;

}

prefix-list PL-PROTECTED {

8.8.8.0/24;

}

policy-statement KDP-IN {

term ACCEPT {

from {

prefix-list PL-KDP-IN;

}

then {

accept;

}

then reject;

}

policy-statement KDP-OUT {

term ACCEPT {

from {

prefix-list PL-PROTECTED;

}

then {

accept;

}

then reject;

}

}

Policy-Based Routing (PBR)

Policy-Based Routing (PBR) в терминологии Cisco соответствует термину Filter-Based Forwarding (FBF) в терминологии Juniper.
Применяя PBR мы решаем одновременно несколько задач:

• изменяем маршрут только для одной сети;
• применяем вопреки наличию в таблице маршрутизации специфичных префиксов для всего Интернета (full view).

Создаем альтернативную таблицу маршрутизации. Вносим в нее маршрут по умолчанию, указывающий на IP-адрес 5.5.5.5. Маршрут до данного IP-адреса ранее был передан из Центра очистки по установленным BGP-сессиям.

routing-instances {

RIB-KDP {

instance-type forwarding;

routing-options {

static {

route 0.0.0.0/0 next-hop 5.5.5.5 resolve;

}

}

}

}

Импорт connected-маршрутов, политика импорта из BGP.

routing-options {

rib-groups {

FBF-GROUP {

import-rib [ inet.0 RIB-KDP.inet.0];

import-policy KDP-IN;

}

interface-routes {

rib-group inet FBF-GROUP;

}

}

Правила firewall:

firewall {

family inet {

filter KDP-FBF {

term FBF {

from {

source-prefix-list {

PL-PROTECTED;

}

}

then {

routing-instance RIB-KDP;

}

then accept;

}

}

}

}

Политика PBR применяется к интерфейсу, который «смотрит» внутрь сети. Трафик, поступающий на данный интерфейс, является входящим. С точки зрения Защищаемых ресурсов, данный трафик исходящий. Выполняем необходимую конфигурацию:

interfaces {

ge-0/0 {

unit 0 {

description CORE;

family inet {

filter input KDP-FBF;

}

}

}

}