juniper — можжевельник (англ.)

Продолжаем готовить настойку из можжевельника. О том, как мы начинали, можно почитать здесь и здесь. Сегодня же немного потрогаем такую удобную штуку, как Virtual Routers, и подумаем, как ее применить с наибольшей пользой.

Содержание:

Часть 1: Знакомство
Часть 2: IPSec
Часть 3: Virtual Routers

В Juniper есть тип сущностей Routing Instance, предназначенный для манипуляций с трафиком (маршрутизации и инкапсуляции). RI позволяют «разделить» один роутер на несколько поменьше, при этом каждый instance будет обрабатывать трафик «по-своему», независимо от других и с разными возможностями. Это полезно для организации всевозможных VPN, когда нужно изолировать друг от друга нескольких клиентов и разрулить их по разным правилам. При этом информацией о VPN можно обмениваться с другими роутерами (например, при организации MPLS VPN).

Типы Routing Instances

* Forwarding — Служит для построения специальных filter-based forwarding applications (ну или policy-based routing в терминологии Cisco). При этом интерфейсы не привязываются к RI, а остаются в дефолтном RI.
* Layer 2 virtual private network (VPN) — Используется для организации MPLS L2VPN.
* Nonforwarding — Все маршруты и интерфейсы помещаются в основной routing instance, но при этом можно «делить» основную таблицу маршрутизации на несколько поменьше.
* VPN routing and forwarding (VRF) — Используется для организации L3VPN. Содержит в себе не только таблицу маршрутизации (routing table), но и таблицу коммутации (forwarding table). При этом трафик с интерфейса отображается в RI один-к-одному, что позволяет передавать метки маршрутизации и принимать их, получая распределенный VPN. Используя протоколы динамической маршрутизации (BGP, OSPF или ISIS) можно организовать об��ен информацией между PE (provider edge) и CE (client edge) таким образом, что каждый из них будет получать (и отдавать) маршруты только внутри «своего» VPN.
* Virtual router — Похож на VRF, но не имеет таких опций как VRF import, VRF export, VRF target, или route distinguisher. Соответственно, не годится для создания L3VPN, т.к. отдельная таблица маршрутизации «живет» только в пределах одного роутера. За счет простоты используется гораздо чаще, чем его «старший брат».
* Virtual private LAN service (VPLS) — Сущность для организации многоточечного распределенного L2VPN поверх MPLS. Для клиента будет выглядеть как виртуальный свич, к портам которого подключены его пограничные (CE) устройства.

На все это великолепие сразу мы смотреть не будем, а займемся только VR. Что же это вообще такое? Из описания видно, что это немножко упрощенная версия VRF, по сути — VRF-lite из мира Cisco. Поддерживаются logical tunnels и rib-groups для обмена маршрутами и связи VR между собой. Само собой, протоколы маршрутизации (ospf, bgp, isis) настраиваются отдельно для каждого VR. Для каждого VR требуется своя Security zone (в zone нельзя помещать интерфейсы из разных VR).

Зачем все это надо? Ровно затем же, зачем обычно делают VRF — изоляция сетей (клиентов) друг от друга и упрощение маршрутизации. Например, можно разделить маршрутизацию филиалов, IPSec-туннелей к заказчикам и маршрутизацию служебных устройств и трафика самого роутера (дефолтной таблицы маршрутизации). Бонусом (весомым!) получаем удобство в составлении routing table, security policies, а также избавляемся от распухания ospf database.

Коротенько опишем содержание VR

— таблица маршрутизации;
— интерфейсы;
— настройки протокола маршрутизации (например, OSPF, ISIS, BGP);
— настройки routing-options (например static)

Ограничения VR

— Dynamic VPN or remote access VPN inside VR
— Public key infrastructure (PKI) inside VR
— Chassis cluster active/active with VPN inside VR
Как видим, ограничения или касаются весьма экзотических конфигураций (например, PKI), или вещей, которые в нашем случае не поддерживаются аппаратно (работа в active/active возможна только в старших версиях SRX, предназначенных для ЦОДов). Ограничение на Dynamic VPN, конечно, обидное (есть такое в планах), но пережить его можно.

А что же нам с этими VR делать?

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

GRE

Тут возможны два сценария: когда сам gre расположен в VR:

set interfaces gr-0/0/0 unit 1 description cs3925-1-smr--tun13
set interfaces gr-0/0/0 unit 1 point-to-point
set interfaces gr-0/0/0 unit 1 tunnel source 192.168.0.13
set interfaces gr-0/0/0 unit 1 tunnel destination 192.168.0.21
set interfaces gr-0/0/0 unit 1 tunnel routing-instance destination BRANCH_VR
set interfaces gr-0/0/0 unit 1 family inet mtu 1448
set interfaces gr-0/0/0 unit 1 family inet address 192.168.77.12/31

Либо когда в VR только интерфейсы, поверх которых строится GRE-туннель:

set interfaces gr-0/0/0 unit 8 description cs3925-1-smr--tun15
set interfaces gr-0/0/0 unit 8 point-to-point
set interfaces gr-0/0/0 unit 8 tunnel source 1.2.3.4
set interfaces gr-0/0/0 unit 8 tunnel destination 2.3.4.2
set interfaces gr-0/0/0 unit 8 family inet mtu 1446
set interfaces gr-0/0/0 unit 8 family inet address 192.168.77.26/31

set routing-instances BRANCH_VR routing-options static route 2.3.4.2/32 next-table inet.0
set routing-instances BRANCH_VR routing-options static route 192.168.0.21/32 next-hop 192.168.0.14

IPSec

Настройка ничем не отличается от обычной. Главное — правильно определить external interface, который тоже может быть в другом VR. После этого добавляем st0 в нужный VR, настраиваем маршрутизацию и policy. В нашем случае 10.6.6.0/24 это сеть за ipsec-шлюзом нашего партнера.

set routing-instances VR1 instance-type virtual-router
set routing-instances VR1 interface ge-0/0/1.0
set routing-instances VR1 interface st0.0
set routing-instances VR1 routing-options static route 10.6.6.0/24 next-hop st0.0

NAT

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

Routing

С маршрутизацией внутри VR все довольно просто: protocol (routing-options в случае статической маршрутизации) задаются прямо в настройках VR. Интереснее, когда нам нужно обмениваться маршрутами между VR. Тут нам на помощь приходят:

a. Статическая маршрутизация.
Работает только в одну сторону (нельзя настроить «встречные» маршруты между VR).

admin@jpsrx550# show routing-instances SAMPLE_VR routing-options static
route a.b.c.d/32 next-table inet.0;

Тут мы указываем VR, что адрес a.b.c.d следует искать в дефолтной таблице маршрутизации (inet.0).

b. rib-groups
Позволяют импортировать таблицы маршрутизации из одного VR в другой. Причем не полностью, а именно те части, которые нужны. Например, static routes, interface routes (direct connected сети) или маршруты из динамического протокола маршрутизации.

set routing-options rib-groups IPSEC_to_default_RIB import-rib IPSEC_VR.inet.0
set routing-options rib-groups IPSEC_to_default_RIB import-rib inet.0
set routing-instances IPSEC_VR routing-options static rib-group IPSEC_to_default_RIB

set routing-options rib-groups default_to_IPSEC_RIB import-rib inet.0
set routing-options rib-groups default_to_IPSEC_RIB import-rib IPSEC_VR.inet.0
set protocols ospf rib-group default_to_IPSEC_RIB

При этом можно настраивать «встречную» маршрутизацию между VR (разными rib-groups), или, к примеру, в одну сторону сделать static route, а в обратную — rib-group. Импортированные таким способом маршруты воспринимаются VR «как родные», т.е. их можно будет, например, экспортировать в OSPF/BGP.

c. logical-tunnels
Вариант прозрачный в реализации и удобный в некоторых случаях (например, когда нужно обменяться BGP-таблицами между разными VR). Создаются виртуальные интерфейсы, на вид — совсем как настоящие. Их можно добавлять в security zone, routing-instances, к ним можно применять policies, вешать адреса и т.д. Но трафик при этом не выходит из маршрутизатора.

Настройка довольно проста. Обратите внимание, при конфигурировании lt указывается id соседа. Т.е. туннелей может быть больше двух (что логично).

Длинный кусок конфига

interfaces {
    lt-0/0/0 {
        unit 1 {
            encapsulation ethernet;
            peer-unit 2;
            family inet {
                address 10.20.30.1/30;
            }
        }
        unit 2 {
            encapsulation ethernet;
            peer-unit 1;
            family inet {
                address 10.20.30.2/30;
            }
        }
    }
policy-options {
    policy-statement p1 {
        from {
            instance R1;
            protocol direct;
        }
        then accept;
    }
    policy-statement p2 {
        from {
            instance R2;
            protocol direct;
        }
        then accept;
    }
}
security {
    zones {
        security-zone Z1 {
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                ge-0/0/1.0;
                lt-0/0/0.1;
            }
        }
        security-zone Z2 {
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                ge-0/0/2.0;
                lt-0/0/0.2;
            }
        }
    }
    policies {
        from-zone Z1 to-zone Z1 {
            policy Z1-Z1 {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone Z2 to-zone Z2 {
            policy Z2-Z2 {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
    }
    flow {
        traceoptions {
            file lt-testing;
            flag basic-datapath;
            packet-filter 1 {
                source-prefix 192.168.1.2/32;
                destination-prefix 192.168.2.2/32;
            }
        }
    }
}
routing-instances {
    R1 {
        instance-type virtual-router;
        interface lt-0/0/0.1;
        interface ge-0/0/1.0;
        protocols {
            ospf {
                traceoptions {
                    file R1;
                    flag all;
                }
                export p1;
                area 0.0.0.0 {
                    interface lt-0/0/0.1;
                }
            }
        }
    }
    R2 {
        instance-type virtual-router;
        interface lt-0/0/0.2;
        interface ge-0/0/2.0;
        protocols {
            ospf {
                export p2;
                area 0.0.0.0 {
                    interface lt-0/0/0.2;
                }
            }
        }
    }
}

Из минусов — нужно создавать интерфейсы, добавлять их в VR, security-zone, учитывать при настройке динамической маршрутизации и т.д.

Вот, собственно, и все. Буду рад ответить на вопросы и замечания в комментариях.

Ссылки(некоторые из них могут быть доступны только при наличии сервисного контракта):
Junos OS Routing Protocols Configuration Guide PDF Document
Junos OS Security Configuration Guide PDF Document
Junos OS MPLS Configuration Guide for Security Devices PDF Document
Example: Configuring an st0 Interface in a Virtual Router
[SRX] Static NAT using Virtual-Routing Instance
[SRX] Configuration of the GRE tunnel in a routing-instance
[SRX] Configuration Example: Destination NAT two destinations to same IP address and distinguish based on source address
[SRX, J Series] Example — Importing Routes to and from virtual routers on SRX and J Series
Understanding Logical Tunnel Interface (lt-0/0/0) on SRX branch series platforms

КДПВ взята отсюда

Настойка можжевельника: готовим Juniper SRX. Часть 3: Virtual Routers