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

Метки статьи: ‘Juniper’

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

В продолжении предыдущей статьи 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...
Отправить на почту Отправить на почту

Сегодня ночью обнаружилось, что один из апстрим каналов начал играть в «ванька-встанька».

BGP сессия падала, поднималась, снова падала, снова поднималась и так до бесконечности.

В логах BGP читалось:

Sep  9 00:26:59.219845 RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer XX.XX.XX.141 (External AS XXXX) changed state from Established to Idle (event RecvUpdate)
Sep  9 00:27:03.460183 bgp_read_v4_update:8189: NOTIFICATION sent to XX.XX.XX.141 (External AS XXXX): code 3 (Update Message Error) subcode 11 (AS path attribute problem)
Sep  9 00:27:39.219859 RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer XX.XX.XX.141 (External AS XXXX) changed state from OpenConfirm to Established (event RecvKeepAlive)

В messages:

Sep  9 00:27:33  rpd[1153]: XX.XX.XX.141 (External AS XXXX) Received BAD update for family inet-unicast(1), prefix 212.118.142.0/24

Полез разбираться, читаем:
BGP Notification Message Error Codes and Error Subcodes

Table 142: BGP Notification Message Error Codes  

Error
Code
Value
Code Name Description
1 Message Header
Error
A problem was detected either
with the contents or length of the BGP header. The Error Subcode
provides more details on the nature of the problem.
2 Open
Message Error
A problem was
found in the body of an Open message. The Error Subtype field
describes the problem in more detail. Note that authentication failures
or inability to agree on a parameter such as hold time are included
here.
3 Update Message
Error
A problem was found in the body
of an Update message. Again, the Error Subtype provides
more information. Many of the problems that fall under this code are
related to issues detected in the routing data or path attributes sent
in the Update message, so these messages provide feedback about
such problems to the device sending the erroneous data.
4 Hold
Timer Expired
A message was
not received before the hold time expired.
See
the description of the Keepalive message for details on this timer
.
5 Finite State
Machine Error
The BGP finite state machine
refers to the mechanism by which the BGP software on a peer moves from
one operating state to another based on events (
see
the TCP finite state machine description for some background on this
concept
). If an event occurs that is unexpected
for the state the peer is currently in, it will generate this error.
6 Cease Used when a
BGP device wants to break the connection to a peer for a reason not
related to any of the error conditions described by the other codes.

Table 143: BGP Notification Message Error Subcodes  

Error
Type
Error
Subcode Value
Subcode
Name
Description
Message
Header Error (Error Code 1)
1 Connection Not
Synchronized
The expected value in the Marker
field was not found, indicating that the connection has become unsynchronized.
See
the description of the Marker field
.
2 Bad
Message Length
The message
was less than 19 bytes, greater than 4096 bytes, or not consistent with
what was expected for the message type.
3 Bad Message
Type
The Type field of the
message contains an invalid value.
Open
Message Error (Error Code 2)
1 Unsupported
Version Number
The device
does not “speak” the version number its peer is trying to
use.
2 Bad Peer AS The router doesn’t recognize
the peer’s autonomous system number or is not willing to communicate
with it.
3 Bad
BGP Identifier
The BGP Identifier
field is invalid.
4 Unsupported
Optional Parameter
The Open message contains
an optional parameter that the recipient of the message doesn’t understand.
5 Authentication
Failure
The data in
the Authentication Information optional parameter could not be
authenticated.
6 Unacceptable
Hold Time
The router refuses to open a
session because the proposed hold time its peer specified in its Open
message is unacceptable.
Update
Message Error (Error Code 3)
1 Malformed
Attribute List
The overall
structure of the message’s
path
attributes
is incorrect, or an attribute
has appeared twice.
2 Unrecognized
Well-Known Attribute
One of the mandatory well-known
attributes was not recognized.
3 Missing
Well-Known Attribute
One of the
mandatory well-known attributes was not specified.
4 Attribute Flags
Error
An attribute has a flag set to
a value that conflicts with the attribute’s type code.
5 Attribute
Length Error
The length
of an attribute is incorrect.
6 Invalid Origin
Attribute
The Origin attribute has
an undefined value.
7 AS
Routing Loop
A routing loop
was detected.
8 Invalid Next_Hop
Attribute
The Next_Hop attribute
is invalid.
9 Optional
Attribute Error
An error was
detected in an optional attribute.
10 Invalid Network
Field
The Network Layer Reachability
Information
field is incorrect.
11 Malformed
AS_Path
The AS_Path
attribute is incorrect.

Такс… приехали…

При помощи своего апстрима удалось выяснить что действительно мне и многим другим другим поднасрал Saudi Telecom и анонсируемый им префикс 212.118.142.0/24.
О чем свидетельствуют мои логи, рассказ апстрима о проблемах и у других его клиентов, а так же:  Saudi Telecom sending route with invalid attributes 212.118.142.0/24:

anyone else getting a route for 212.118.142.0/24 with invalid
attributes? Seems this is (again) causing problems with some (older)
routers/software.

Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
6-Resolve tree 2
AS path: 6453 39386 25019 I Unrecognized Attributes: 39
bytes
AS path: Attr flags e0 code 80: 00 00 fd 88 40 01 01 02
40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40 05 04
00 00 00 64
Accepted Multipath

-Jonas

Ответ:

Exactly the same here.

Sep 8 20:24:04 BBD-RC02 rpd[1334]: Received BAD update from
94.228.128.57 (External AS 41887), aspath_attr():3472
PA4_TYPE_ATTRSET(128) => 1 times IGNORED, family inet-unicast(1), prefix
212.118.142.0/24

Bye,
Raymond.

Смотрим инфу в RIPE:

% Information related to '212.118.140.0/22AS25019'
route: 212.118.140.0/22
descr: Saudi Arabia backbone and local registry address space / STC
remarks: for any Abuse or Spamming Please send an e-mail to abuse@saudi.net.sa
origin: AS25019
mnt-by: saudinet-stc
source: RIPE # Filtered

% Information related to '212.118.140.0/22AS39891'
route: 212.118.140.0/22
descr: Saudi Arabia backbone and local registry address space / STC
origin: AS39891
mnt-by: saudinet-stc
source: RIPE # Filtered

О как, за двумя ASками данный префикс числится. Красавцы, чего тут сказать.

Отфильтровав этот префикс к чертям собачьим, BGP сессия сразу же перестала падать. Вечером та же участь постигла и другого апстрима.

Т.к. к вечеру я уже реально задолбался, то взял отфильтровал нафиг по as-path обе аски  AS39891 и AS25019. Пусть саудовский телеком идет лесом и уже научится пользоваться BGP фильтрами.

Вот так один «олень» может доставить гемороя многим во всем мире.

З.Ы. Junos:

    JUNOS Base OS Software Suite [9.4R1.8]
    JUNOS Kernel Software Suite [9.4R1.8]

Пролеме точно подвержены Junos`ы версии 9.4 и ниже, update JunOS`а ждет меня и не только меня :)



Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 1, среднее: 5,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...
Отправить на почту Отправить на почту