Subnets.ru blog

Задача

Необходимо создать внутри одного физического роутера отдельную роутинг таблицу для одного клиента и двух его апстримов.

Иными словами нужно что бы эти три пира «жили» в своей таблице маршрутизации и не имели отношения к основной таблице маршрутизации.
Каждая таблица будет «жить» по своим законам и трафик будет ходить по своим маршрутам.

Имеем

• Juniper M10i
• JUNOS 10.1R1.8

Решение

Решить эту задачу нам поможет  routing-instances.

Благодаря им мы можем создать несколько таблиц маршрутизации и явным образом указать для каких интерфейсов роутера её использовать.

Читаем доку: Configuring Routing Instances

Первый возникающий вопрос это какого типа routing-instances нам нужен ? Смотрим описание:

• forwarding—Provide support for filter-based forwarding, where interfaces are not associated with instances. All interfaces belong to the default instance. Other instances are used for populating RPD learned routes. See Configuring Filter-Based Forwarding.
• l2vpn—Provide support for Layer 2 VPNs. For more detailed information about configuring VPNs, see the JUNOS VPNs Configuration Guide.
• layer2-control—(MX Series routers only) Provide support for RSTP or MSTP in customer edge interfaces of a VPLS routing instance. For more detailed information about configuring RSTP and MSTP, see the JUNOS MX Series Ethernet Services Routers Layer 2 Configuration Guide
• no-forwarding—This is the default routing instance. Do not create a corresponding forwarding instance.
• virtual-router—Similar to a VPN routing and forwarding instance type, but used for non-VPN-related applications. There are no VRF import, VRF export, VRF target, or route distinguisher requirements for this instance type.
• virtual-switch—(MX Series routers only) Provide support for Layer 2 bridging. Use this routing instances type to isolate a LAN segment with its Spanning Tree Protocol (STP) instance and separates its VLAN identifier space. For more detailed information about configuring a virtual switch, see the JUNOS MX Series Ethernet Services Routers Layer 2 Configuration Guide and the JUNOS MX Series Ethernet Services Routers Solutions Guide.
• vpls—Virtual private local-area network (LAN) service. Use this routing instance type for point-to-multipoint LAN implementations between a set of sites in a VPN. For more information about configuring VPLS, see the JUNOS VPNs Configuration Guide.
• vrf—VPN routing and forwarding instance. Provides support for Layer 3 VPNs, where interface routes for each instance go into the corresponding forwarding table only. For more information about configuring VPNs, see the JUNOS VPNs Configuration Guide.

To configure a routing instance type, include the instance-type statement:

routing-instances {
     routing-instance-name {
           interface interface-name;
           instance-type (forwarding | l2vpn | layer2-control | no-forwarding | virtual-router | virtual-switch | vpls | vrf);
     }
}

Если вы общались с железом от Cisco, то первое что вам бросится в глаза, так это знакомое слово VRF (либо вы уже слышали/настраивали VRF-lite).

В моем случае мне походит тип virtual-router, т.к. VPN`а у меня нет, а все что мне нужно это создать вторую, отдельную от основной, таблицу маршрутизации, которая будет действовать только в пределах данного роутера.

Приступим

Исходные данные для нашего VRF:
VRF апстрим #1:

• подключен к физическому интерфейсу: ge-0/0/1.0
• ASN: 100
• IP-адрес: 1.1.1.1/30

VRF апстрим #2:

• подключен к физическому интерфейсу: ge-0/0/2.0
• ASN: 200
• IP-адрес: 2.2.2.1/30

VRF клиент #1:

• подключен к физическому интерфейсу: ge-0/1/0.0
• ASN: 300
• IP-адрес: 3.3.3.2/30

Назовем наш VRF именем test, а наш номер AS будет 400.

Обращаю ваше внимание так это на то, что конфигурацию протокола BGP у основного роутера мы не трогаем, т.е. никаких изменений туда вносить не надо.
Подмечу, что конфигурацию самих физических интерфейсов и policy-statement (роут мапов) для пиров в нашем VRF нужно производить в режиме конфигурирования основного роутера, а не в routing-instances test.

Заходим в режим конфигурирования:

root@juniper> configure

Затем перейдем в уровень routing-instances:

root@juniper# edit routing-instances

После чего нам нужно задать имя нашего routing-instance (допустим test) и задать в нем остальные настройки, в том числе настройки протокола BGP.

[edit routing-instances]
root@juniper# set test description «test routing table»

Зададим тип  routing-instance:

[edit routing-instances]
root@juniper# set test instance-type virtual-router

Затем укажем какие интерфейсы роутера помещать в данный instance (в моем случае это будет три интерфейса, т.к. три пира и каждый в своем интерфейсе, это могут быть как целиком физические интерфейсы, так и вланы):

[edit routing-instances]
root@juniper# set test  interface ge-0/0/1.0
root@juniper# set test  interface ge-0/0/2.0
root@juniper# set test  interface ge-0/1/0.0

Дальнейшая настройка routing-instance ничем не отличается от настройки основного роутера. Те же секции, те же команды. Не буду далее описывать каждую команду и покажу что мы должны получить на выходе по нашему routing-instance test:
[edit]
root@juniper# show routing-instances test

test {
    description "test routing table";
    instance-type virtual-router;
    interface ge-0/0/1.0;
    interface ge-0/0/2.0;
    interface ge-0/1/0.0;
    routing-options {
        router-id 1.1.1.2;
        autonomous-system 400;
    }

    protocols {
        bgp {
            path-selection always-compare-med;
            traceoptions {
                file bgp_vrf.log size 1m files 10;
            }
            log-updown;
            remove-private;
            local-as 400;
            group upstreams {
                type external;
                no-advertise-peer-as;
                neighbor 1.1.1.1 {
                    description VRF_Upstream_1;
                    import vrf-upstream-1-in;
                    export vrf-customer;
                    remove-private;
                    peer-as 100;
                }
                neighbor 2.2.2.1 {
                    description VRF_Upstream_2;
                    import vrf-upstream-2-in;
                    export vrf-customer;
                    peer-as 200;
                }
            }
            group customers {
                neighbor 3.3.3.2 {
                    description VRF_client_1;
                    import vrf-client-in;
                    export vrf-client-out;
                    peer-as 300;
                }
            }
        }
    }
}

Собственно на этом конфигурация VRF и закончена. Как видно из конфига мы настроили BGP протокол внутри VRF`а где апстримов поместили в группу upstreams, а нашего клиента в группу customers.

Теперь остается настроить сами физические интерфейсы и создать полиси-мапы (vrf-upstream-1-in, vrf-customer, vrf-upstream-2-in, vrf-customer, vrf-client-in, vrf-client-out).

Напоминаю, что это делается в режиме «глобального» конфигурирования роутера, а не в routing-instance test.

Что мы должны увидеть после коммита данного конфига ?

По команде:

[edit]
root@juniper# run show bgp summary

мы увидим что появилась ещё одна роутинг таблица, в которой перечислены наши VRF пиры.

Так же можно посмотреть что там с маршрутами в нашей routing-instance test:

[edit]
root@juniper# run show route table test.inet.0

Несколько заметок, например запустив пинг до нашего VRF клиента командой:

[edit]
root@juniper# run ping 3.3.3.2

не удивляйтесь что пинга нет, даже при наличии линка на физическом интерфейсе и не торопитесь с выводами, что физика не работает или с той стороны не настроен IP-адрес, просто вы забыли о том, что вы выполняете эту команду из основного роутера, а ведь физический интерфейс в сторону VRF-клиента принадлежит routing-instance test и основной роутер действительно не знает маршрут в эту подсеть.

Меняем команду на:

[edit]
root@juniper# run ping 3.3.3.2 routing-instance test
и вот он наш пинг:

PING 3.3.3.2 (3.3.3.2): 56 data bytes
64 bytes from 3.3.3.2: icmp_seq=0 ttl=255 time=0.660 ms
64 bytes from 3.3.3.2: icmp_seq=1 ttl=255 time=0.647 ms
^C
--- 3.3.3.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.647/0.653/0.660/0.007 ms

т.е. мы явно сказали роутеру какой instance использовать для отправки пакетов до хоста 3.3.3.2.

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

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

Похожие статьи:

Не найдено