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

Архивные статьи в категории ‘Juniper’

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.
Вместо вступления: Давненько не писал, все руки как то не доходили. 2015 год заканчивается, надо бы обновить блог :) Напишу те статьи что помню и давно хотел написать.

Итак в данной статье пойдет речь о оч.хор. фишке у Juniper, а именно возможность выполнить анонс сети по BGP от другой AS без поднятия BGP сессии с этой AS.

Зачем это может понадобиться ?

Например:

  • ваша компания поглотила другую компанию у которой есть своя AS и свои префиксы. По тем или иным причинам вы не хотите отказываться от второй AS, но и держать два border роутера не хотите
  • вам необходимо произвести работы на маршрутизаторе, который анонсирует вашу вторую AS, но в момент работ вы не хотите допустить перерыва в предоставлении сервиса пользователям
  • и т.п.

Для понимания того что нам необходимо — читаем мануал «Understanding Aggregate Routes»:

routing-options {
    aggregate {
      (defaults | route) {
      (active | passive);
      as-path    ;
      community [ community-ids ];
      discard;
      (brief | full);
      (metric | metric2 | metric3 | metric4) metric ;
      (preference | preference2 | color | color2) preference ;
      tag string;
      }
   }
}

Вот это то что нам нужно.

В кач-ве примера возьмем следующие данные:

  • основная AS: AS100
  • вторая AS: AS200
  • префикс AS200: 1.1.1.0/24

Правим конфигурацию:

[edit]
root@mx80.domain.ru# set routing-options aggregate route 1.1.1.0/24 as-path path 200 origin igp aggregator 100 2.2.2.2

Не забываем поправить BGP фильтры для анонса данной сети своим апстримам и пирам. Затем коммитим конфиг и у вас он в таблице роутинга появится как:

root@mx80.domain.ru> show route terse 1.1.1.0/24

inet.0: 568282 destinations, 569718 routes (567644 active, 0 holddown, 638 hidden)
+ = Active Route, - = Last Active, * = Both

A V Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* ? 1.1.1.0/24    A 130                        Reject

А ваши пиры получат вот такой BGP маршрут:

root@external.domain.ru> show route terse 1.1.1.0/24

inet.0: 576181 destinations, 3792790 routes (575034 active, 35 holddown, 93700 hidden)
+ = Active Route, - = Last Active, * = Both

A V Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* ? 1.1.1.0/24    B 170                                        100 200 I

Т.е. префикс 1.1.1.0/24 принадлежит AS200 и доступен по as-path AS100 -> AS200, но при этом, как мы знаем, BGP сессии между AS100 и AS200 не существует.

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

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

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (Еще не голосовали)
Loading...Loading...
Отправить на почту Отправить на почту

В продолжении предыдущей статьи Juniper и Policy-based routing ( PBR ) появилась задача когда необходимо чтобы маршруты из таблицы inet.2 (mBGP) попадали не только в нее, но и в таблицу inet.0 (eBGP).

Расскажу и покажу как это сделали мы.

Дано

  • MX80 (JUNOS 10.4R1.9)
  • апстрим с двумя BGP сессиями eBGP и mBGP

Задача

Импортировать маршруты принимаемые в сессии mBGP (роутинг таблица inet.2) в таблицу сессии eBGP (таблица inet.0).

Реализация

Состояние ДО изменений:

Для примера возьмем маршрут до подсети 11.11.11.192/28.
Посмотрим текущий маршрут до этой подсети:

juniper-MX80> show route terse 11.11.11.192
inet.2: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 11.11.11.192/28  B 170        100            >20.20.20.209   65500 I

Видим что данный маршрут находится только в таблице inet.2, это то мы и будем «исправлять».

Приступим. Как и в случае с PBR нам поможет механизм rib-groups.
Создадим rib группы:

routing-options {
    rib-groups {
        bgp-multicast-rg {
            export-rib inet.2;
            import-rib [ inet.2 inet.0 ];
        }
        bgp-unicast-rg {
            export-rib inet.0;
            import-rib inet.0;
        }
    }
}

Мы создали две rib группы: одну для unicast, другую для multicast. В rib группе multicast в import-rib мы указали, что принимаемые маршруты нужно импортировать и в таблицу inet.0.

Теперь опишем эти rib группы в protocols bgp:

protocols {
    bgp {
        family inet {
            unicast {
                rib-group bgp-unicast-rg;
            }
            multicast {
                rib-group bgp-multicast-rg;
            }
        }
    }
}

Ну и сами BGP пиры, один eBGP, другой mBGP:

protocols {
    bgp {
        log-updown;
        local-as 65000;
        group ebgp {
            type external;
            no-advertise-peer-as;
            neighbor 10.10.10.229 {
                description eBGP_peer;
                import bgp-import;
                family inet {
                    unicast;
                }
                export bgp-export;
                peer-as 65500;
            }
        }
        group mbgp {
            type external;
            no-advertise-peer-as;
            neighbor 20.20.20.209 {
                description mBGP_peer;
                import bgp-mcast-import;
                family inet {
                    multicast;
                }
                export bgp-mcast-export;
                peer-as 65500;
            }
        }
    }
}

После commit`а смотрим появился ли маршрут в таблице inet.0:

juniper-MX80> show route terse 11.11.11.192

inet.0: 51 destinations, 51 routes (44 active, 0 holddown, 7 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 11.11.11.192/28  B 170        100            >20.20.20.209   65500 I

inet.2: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 11.11.11.192/28  B 170        100            >20.20.20.209   65500 I

А вот теперь мы видим что наш маршрут присутствует в двух таблицах, что нам и было надо.

Ссылки

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

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

 

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

Я уже писал об использовании 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)
Loading...Loading...
Отправить на почту Отправить на почту

Один из наших читателей (пожелавший остаться анонимом) прислал нам по мылу конфигурацию для схемы с Juniper MX80, в которой прокидывается vlan через trunk проходящий через 80тые Juniper`ы.
Спасибо ему за инфу, т.к. она точно будет полезна всем кто столкнется с подобной задачей.

Топология

MX80-client [ge-1/0/2] <—> [ge-1/0/4] MX80-1 [ge-1/0/1] <—> [ge-1/0/7] MX80-2 [ge-1/1/1] <—> [ge-2/0/0] M120-client

Описание топологии

Access port   <—>    (Trunk port back to back)  <—>    Access port

IP-адрес на MX80-client (слева) — 200.200.200.1/30
IP-адрес на M120-client  (справа) — 200.200.200.2/30

Конфиги

MX80-1

root@MX80-1# show interfaces ge-1/0/1
flexible-vlan-tagging;
native-vlan-id 100;
encapsulation flexible-ethernet-services;
unit 2 {
    encapsulation vlan-bridge;
    vlan-id 10;
}
root@MX80-1# show interfaces ge-1/0/4
encapsulation ethernet-bridge;
unit 0 {
    family bridge;
}
root@MX80-1# show bridge-domains
DEV {
    domain-type bridge;
    vlan-id 10;
    interface ge-1/0/1.2;
    interface ge-1/0/4.0;
}

MX80-2

root@MX80-2# show interfaces ge-1/0/7
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 2 {
    encapsulation vlan-bridge;
    vlan-id 10;
}
root@MX80-2# show interfaces ge-1/1/1
encapsulation ethernet-bridge;
unit 0 {
    family bridge;
}
root@MX80-2# show bridge-domains
DEV {
     domain-type bridge;
     vlan-id 10;
     interface ge-1/0/7.2;
     interface ge-1/1/1.0;
}

MX80-client

root@MX80-client# show interfaces ge-1/0/2
unit 0 {
    family inet {
        address 200.200.200.1/30;
    }
}
root@MX80-client# run show interfaces ge-1/0/2
Physical interface: ge-1/0/2, Enabled, Physical link is Up
Interface index: 160, SNMP ifIndex: 514
Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, BPDU Error:
None, MAC-REWRITE Error: None, Loopback: Disabled,
Source filtering: Disabled, Flow control: Enabled, Auto-negotiation:
Enabled, Remote fault: Online, Speed-negotiation: Disabled,
Auto-MDIX: Enabled
Device flags   : Present Running
Interface flags: SNMP-Traps Internal: 0x0
Link flags     : None
CoS queues     : 8 supported, 8 maximum usable queues
Current address: 80:71:1f:c2:05:62, Hardware address: 80:71:1f:c2:05:62
Last flapped   : 2011-01-19 13:12:48 UTC (17:20:05 ago)
Input rate     : 0 bps (0 pps)
Output rate    : 0 bps (0 pps)
Active alarms  : None
Active defects : None

Logical interface ge-1/0/2.0 (Index 71) (SNMP ifIndex 656)
Flags: SNMP-Traps 0x0 Encapsulation: ENET2
Input packets : 30
Output packets: 9
Protocol inet, MTU: 1500
Flags: Sendbcast-pkt-to-re
Addresses, Flags: Is-Preferred Is-Primary
Destination: 200.200.200.0/30, Local: 200.200.200.1,
Broadcast: 200.200.200.3
Protocol multiservice, MTU: Unlimited

M120-client

root@M120# show interfaces ge-2/0/0
unit 0 {
    family inet {
        address 200.200.200.2/30;
    }
}
root@M120# run show interfaces ge-2/0/0
Physical interface: ge-2/0/0, Enabled, Physical link is Up
Interface index: 143, SNMP ifIndex: 523
Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, Loopback:
Disabled, Source filtering: Disabled, Flow control: Enabled,
Auto-negotiation: Enabled, Remote fault: Online
Device flags   : Present Running
Interface flags: SNMP-Traps Internal: 0x4000
Link flags     : None
CoS queues     : 8 supported, 8 maximum usable queues
Current address: 00:19:e2:67:f3:fc, Hardware address: 00:19:e2:67:f3:fc
Last flapped   : 2011-01-19 18:32:34 UTC (17:19:47 ago)
Input rate     : 0 bps (0 pps)
Output rate    : 0 bps (0 pps)
Active alarms  : None
Active defects : None

Logical interface ge-2/0/0.0 (Index 87) (SNMP ifIndex 310)
Flags: SNMP-Traps Encapsulation: ENET2
Input packets : 7
Output packets: 2430
Protocol inet, MTU: 1500
Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 200.200.200.0/30, Local: 200.200.200.2,
Broadcast: 200.200.200.3

Проверка ICMP запросами

root@M120# run ping 200.200.200.1
PING 200.200.200.1 (200.200.200.1): 56 data bytes
64 bytes from 200.200.200.1: icmp_seq=0 ttl=64 time=0.541 ms
64 bytes from 200.200.200.1: icmp_seq=1 ttl=64 time=0.499 ms
64 bytes from 200.200.200.1: icmp_seq=2 ttl=64 time=0.496 ms
64 bytes from 200.200.200.1: icmp_seq=3 ttl=64 time=0.505 ms
^C
--- 200.200.200.1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.496/0.510/0.541/0.018 ms
root@MX80-client# run ping 200.200.200.2
PING 200.200.200.2 (200.200.200.2): 56 data bytes
64 bytes from 200.200.200.2: icmp_seq=0 ttl=64 time=0.652 ms
64 bytes from 200.200.200.2: icmp_seq=1 ttl=64 time=0.511 ms
64 bytes from 200.200.200.2: icmp_seq=2 ttl=64 time=0.445 ms
64 bytes from 200.200.200.2: icmp_seq=3 ttl=64 time=0.504 ms
^C
--- 200.200.200.2 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.445/0.528/0.652/0.076 ms

Таблица MAC адресов на MX80`ых расположенных в центре по топологии

root@MX80-1# run show bridge mac-table
MAC flags (S -static MAC, D -dynamic MAC,
SE -Statistics enabled, NM -Non configured MAC)

Routing instance : default-switch
Bridging domain : DEV, VLAN : 10
MAC                 MAC      Logical
address             flags    interface
00:19:e2:67:f3:fc   D        ge-1/0/1.2
80:71:1f:c2:05:62   D        ge-1/0/4.0
root@MX80-2# run show bridge mac-table
MAC flags (S -static MAC, D -dynamic MAC,
SE -Statistics enabled, NM -Non configured MAC)

Routing instance : default-switch
Bridging domain : DEV, VLAN : 10
MAC                 MAC      Logical
address             flags    interface
00:19:e2:67:f3:fc   D        ge-1/1/1.0
80:71:1f:c2:05:62   D        ge-1/0/7.2
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 2, среднее: 5,00 из 5)
Loading...Loading...
Отправить на почту Отправить на почту

Задача

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

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

Имеем

  • 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)

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