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

С первого момента как я познакомился с оборудованием Juniper серии «M» я хотел попробовать фичу с логическими системами, т.е. создать роутер внутри роутера, но все как то руки не доходили. То времени не было, то свободной автономки с адресами.

И вот оно случилось, снова появилась свежеполученная AS с блоком адресов и я все же выкроил время для теста.

Пишу данный пост, что бы потом самому не забыть как это делалось, т.к. м.б. я тупой или жара так влияет на мозг человека, но как законектить основную систему с виртуальной я догнал не сразу, даже после того как «покурил» мануалы на juniper.net.

Дано

• Juniper M7i
• на нем уже поднят BGP с несколькими апстримами

Задача

Сделать виртуальный роутер (logical-system) внутри реального роутера, соединить их по протоколу BGP и проанонсировать новую ASку в Инет.

Connect Logical System BGP to Main system BGP.

Решение

Logical System Overview

Logical systems perform a subset of the actions of a physical router and have their own unique routing tables, interfaces, policies, and routing instances. A set of logical systems within a single router can handle the functions previously performed by several small routers.

The following are supported on logical systems:
Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (IS-IS), Routing Information Protocol (RIP), RIP next generation (RIPng), Border Gateway Protocol (BGP), Resource Reservation Protocol (RSVP), Label Distribution Protocol (LDP), static routes, various multicast protocols, and IP version 4 (IPv4) and version 6 (IPv6) are supported at the [edit logical-systems protocols] hierarchy level.
Basic Multiprotocol Label Switching (MPLS) for core provider router functionality is supported at the [edit logical-systems protocols mpls]] hierarchy level.
All policy-related statements available at the [edit policy-options] hierarchy level are supported at the [edit logical-systems policy-options] hierarchy level.
Most routing options statements available at the [edit routing-options] hierarchy level are supported at the [edit logical-systems routing-options] hierarchy level. Only the route-record statement is not supported at the [edit logical-systems routing-options] hierarchy level.
Graceful Routing Engine switchover (GRES) is supported.
You can assign most interface types to a logical system, including SONET interfaces, Ethernet interfaces, Asynchronous Transfer Mode (ATM) interfaces, ATM2 interfaces, Channelized Q Performance Processor (QPP) interfaces, aggregated interfaces, link services interfaces, and multilink services interfaces.
Source class usage, destination class usage, unicast reverse path forwarding, class of service, firewall filters, class-based forwarding, and policy-based accounting work with logical systems when you configure these features on the physical router.
Multicast protocols, such as Protocol Independent Multicast (PIM) and Distance Vector Multicast Routing Protocol (DVMRP) are supported at the [edit logical-systems logical-system-name protocols] hierarchy level. Rendezvous point (RP) and source designated router (DR) functionality for multicast protocols within a logical system is also supported.
The Bidirectional Forwarding Protocol (BFD) is supported.

The following restrictions apply to logical systems:
You can configure a maximum of 15 logical systems on one physical router.
The router has only one configuration file, which contains configuration information for the physical router and all associated logical systems. Master users can access the full configuration. However, logical system users can access only the portion of the configuration related to their particular logical system.
All configuration commits performed by a logical system user are treated as commit private. For more information on the commit private command, see the JUNOS System Basics Configuration Guide.
If a logical system experiences an interruption of its routing protocol process (rpd), the core dump output is saved in a file in the following location: /var/tmp/rpd_logical-system-name.core-tarball.number.tgz. Likewise, if you issue the restart routing command in a logical system, only the routing protocol process (rpd) for the logical system is restarted.
If you configure trace options for a logical system, the output log file is stored in the following location: /var/tmp/logical-system-name.
The following Physical Interface Cards (PICs) are not supported with logical systems: Adaptive Services PIC, ES PIC, Monitoring Services PIC, and Monitoring Services II PIC.
Sampling, port mirroring, IP Security (IPsec), and Generalized MPLS (GMPLS) are not supported.
Label-switched path (LSP) ping and traceroute for autonomous system (AS) number lookup are not supported.
If you configure multiple logical systems, you can configure a VPLS routing instance only for the first logical system configured at the [edit logical-systems logical-system-name routing-instances instance-name protocols vpls] hierarchy level.

Начинаем «курить» мануалы:

• Logical System Overview
• Configuring Logical Systems
• Example: Configuring Logical Systems

Более-менее понятно, что соединить осноной роутер (main) с виртуальным (logical-system) можно через интерфейсы. Но как ?

Читаем мануалы далее и выясняем, что сделать это можно или с помощью петли, т.е. тупо соединив проводом два физических порта  маршрутизатора (один порт будет принадлежать реальной системе, а второй порт виртуальной) или с помощью «Logical Tunnel Interface«.

Соединять с помощью провода между двумя реальными интерфейсами роутера я не мог, в виду отсутствия свободных, остается «логика»:

On M Series and T Series routers, logical tunnel interfaces allow you to connect logical systems, virtual routers, or VPN instances. The router must be equipped with a Tunnel Services PIC or an Adaptive Services Module (only available on M7i routers)

Такс и где же этот встроенный Tunnel Services PIC ?

А вот он:

root@juniper> show chassis hardware

FPC 1                                                    E-FPC
  PIC 2                   BUILTIN      BUILTIN           1x Tunnel

Что видно в интерфейсах:
root@juniper> show interfaces lt-1/2/0

Physical interface: lt-1/2/0, Enabled, Physical link is Up
  Interface index: 142, SNMP ifIndex: 191
  Type: Logical-tunnel, Link-level type: Logical-tunnel, MTU: Unlimited, Speed: 800mbps
  Device flags   : Present Running
  Interface flags: Point-To-Point SNMP-Traps
  Link flags     : None
  Physical info  : 13
  Current address: 00:1f:12:d5:a0:bc, Hardware address: 00:1f:12:d5:a0:bc
  Last flapped   : 2010-07-17 00:24:41 MSD (2w6d 10:13 ago)
  Input rate     : 3088 bps (4 pps)
  Output rate    : 3088 bps (3 pps)

Получается, что все что нам нужно для выполнения задачи присутствует.

Прочитав Configuring Logical Tunnel Interfaces меня напрягли слова:

To connect two logical systems, you configure a logical tunnel interface on both logical systems.

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

Смотрю на картинку  в примере настройки (Example: Configuring Logical Systems) и вижу что опять же виртуальные роутеры соединяются с реальными, но нигде реальные роутеры не соединяются с виртуальнфми внутри себя. Так делать нельзя ? Хм… как минимум странно.

Зрим в пример туннельного интерфейса:

lt-fpc/pic/port {
     unit logical-unit-number {
          encapsulation encapsulation;
          peer-unit unit-number; # peering logical system unit number
          dlci dlci-number;
          family (inet | inet6 | iso | mpls);
    }
}

Хм…. вроде все понятно, а вроде и нет ? Что такое peer-unit и какой номер указывать ? Читаем о peer-unit:

Syntax
peer-unit unit-number;
Hierarchy Level
[edit interfaces interface-name unit logical-unit-number],
[edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number]
Release Information

Statement introduced before JUNOS Release 7.4.
Description

Configure a peer relationship between two logical systems.
Options

unit-number—Peering logical system unit number.
Usage Guidelines

See Configuring Logical Tunnel Interfaces.
Required Privilege Level

interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration

Стало понятнее ? Мне нет….

Дальнейшее «курение» мануалов просветления в этом вопросе не принесло. Практика, попытки сделать хоть что то, тоже. Все они заканчивались выводом разнообразных ошибок при коммите (commit), например:

peer-unit needs to be configured for logical tunnel interface
error: configuration check-out failed

encapsulation needs to be configured for logical tunnel interface
error: configuration check-out failed

Или о том что интерфейсы реальной системы пересекаются с виртуальной:

Interface lt-1/2/0.1 is also configured at the top-level
error: configuration check-out failed

Либо реальная система не видела виртуальную (не было пинга).

Ну что ж, обратимся к великому гуглу ! Но толи я не так искал, тли не так читал 🙂 не знаю, но ответа на свой вопрос я по прежнему не получил.

Листая форум на juniper.net, а затем  повторное прочтение Configuring Logical Tunnel Interfaces навели меня на мысль о том, что нужно и в реальном (main) роутере и в виртуальном настраивать именно туннельный интерфейс и «натравливать» их друг на друга.

Ну что ж, попробуем. Начнем с интерфейсов.

Для начала создадим наш логический роутер (для примера имя ему дадим virtual-bgp-router), переходим в режим конфигурации и начинаем:

[edit]
root@juniper# set logical-systems virtual-bgp-router

Затем создадим наш туннельный интерфейс, я возьму номер 999, вы ессно можете указать любой понравившийся вам номер юнита, которого ещё нет на этом интерфейсе:

[edit]
root@juniper# set logical-systems virtual-bgp-router interfaces lt-1/2/0 unit 999

Зададим инкапсуляцию:

[edit]
root@juniper# set logical-systems virtual-bgp-router interfaces lt-1/2/0 unit 999 encapsulation ethernet

Зададим с каким юнитом основного (main) роутера  мы будем соединяться:

[edit]
root@juniper# set logical-systems virtual-bgp-router interfaces lt-1/2/0 unit 999 peer-unit 333

Добавим IP-адрес на интерфейс:

[edit]
root@juniper# set logical-systems virtual-bgp-router interfaces lt-1/2/0 unit 999 family inet address 192.168.1.2/24

Так, с виртуалкой  пока закончили, теперь нужно реальному роутеру объяснить что к чему. Настроим туннельный  интерфейс и на нем.

[edit]
root@juniper# set interfaces lt-1/2/0 unit 333

Создали  unit 333, тот юнит, который мы указали при создании туннельного интерфейса в логическом роутере, в кач-ве peer-unit.

Затем все действия точно такие же как делали выше, зададим инкапсуляцию:

[edit]
root@juniper# set  interfaces lt-1/2/0 unit 333 encapsulation ethernet

Зададим с каким юнитом виртуального роутера мы будем соединяться:

[edit]
root@juniper# set interfaces lt-1/2/0 unit 333 peer-unit 999

Добавим IP-адрес на интерфейс:

[edit]
root@juniper# set interfaces lt-1/2/0 unit 333 family inet address 192.168.1.1/24

Ну вот, в первом приближении и все. Коммитим конфигурацию и смотрим, все ли работает как надо.

Для начала проверим есть ли у нас пинг с реального роутера на виртуальный:

[edit]
root@juniper# run ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=0.910 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.802 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.839 ms
^C
— 192.168.1.2 ping statistics —
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.802/0.850/0.910/0.045 ms

Затем наоборот, из виртуального на реальный:
[edit]
root@juniper# run ping logical-system virtual-bgp-router 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.932 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.842 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.866 ms
^C
— 192.168.1.1 ping statistics —
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.842/0.880/0.932/0.038 ms

Пинг в наличии ! А значит и все остальное, по нашей задаче BGP пиринг между реальной системой и виртуальной, уже можно воплощать в жизнь.

Как поднимать BGP на Juniper в этой статье я расписывать не буду, т.к. уже делал это в статье «Настройка протокола BGP на оборудовании Juniper«, скажу лишь что в виртуальном роутере все настраивается точно так же как и в реальном, т.е. переходим в режиме редактирования в «ветку» своего виртуального роутера:

[edit]
root@juniper# edit logical-systems virtual-bgp-router

Забываем о том, что это виртуалка и настраиваем так же как обычный роутер. Т.е. поехали:

[edit]
root@juniper# set protocols bgp local-as 12345

где «12345»  есть наша свежеполученная AS, затем настраиваем BGP пир (создаем BGP соседа  192.168.1.1 (реальный роутер) и т.д. и т.п.

После того как вы закончите с настройкой протокола BGP на виртуальном роутере, не забудьте создать BGP соседа (192.168.1.2) и в реальном роутере.

По итогу получаем самое обычное взаимоотношение по протоколу BGP между реальным роутером и виртуальным 😉

Реальный роутер видит по BGP виртуальный и получает от него один свой префикс от новой ASки:
root@juniper> show bgp summary | match 192.168.1.2

192.168.1.2 12345 2629 77689 0 0 01:40:19 1/1/1/0 0/0/0/0

Ну и наборот, виртуальный видит реальный роутер, который сгружает ему full-view таблицу:
root@juniper> show bgp summary logical-system virtual-bgp-router

Groups: 1 Peers: 1 Down peers: 0

Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.1.1         54321      77697       2639       0       0    01:44:37 323070/323070/323070/0  0/0/0/0

З.Ы. Внутри виртуального роутера можно создавать и реальные интерфейсы этого роутера, таким образом вы можете связать виртуальный роутер с любой внешней железкой.

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

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

Рассмотрим пример настройки протокола BGP на оборудовании Cisco Systems.

В основном принципе настройка на Cisco ничем не отличается от настройки BGP на FreeBSD используя Quagga.

Для примера возьмем немного другую ситуацию чем в предыдущей статье, итак:

AS100 — наш номер ASки

5.5.0.0/20 — анонсируемый нами префикс (наш блок адресов)

AS200 — наш апстрим, который отдает нам full-view (полную таблицу маршрутов)

AS300 — наш privat peer (приватный пир), который отдает нам маршруты в свою AS и своего клиента AS400.

С чего начать ?

С настройки интерфейсов конечно.

GigabitEthernet3/0 — AS200
GigabitEthernet3/1 — AS300

Зайдите на router телнетом и перейдите в enable режим.

cisco# conf t
cisco(config)# interface GigabitEthernet3/0
cisco(config-if)# ip address 1.1.1.2 255.255.255.252
cisco(config-if)# interface GigabitEthernet3/1
cisco(config-if)# ip address 2.2.2.10 255.255.255.252
cisco(config-if)# exit

Добавим маршруты, сначала отправим туда, откуда не возвращаются :), маршруты в «серые сети»:

cisco(config)# ip route 10.0.0.0 255.0.0.0 Null0 254
cisco(config)# ip route 172.16.0.0 255.240.0.0 Null0 254
cisco(config)# ip route 192.168.0.0 255.255.0.0 Null0 254

Затем добавим маршрут на свой полный блок:

cisco(config)# ip route 5.5.0.0 255.255.240.0 Null0 254

Протокол BGP не будет анонсировать префикс, пока сам не узнает маршрут до него.
Именно для этого мы и создали этот маршрут, который будет присутствовать в таблице маршрутизации всегда.
Вы можете пророутить внутрь своей сети как полный блок (тогда маршрут в Null0 (нуль ноль) можно и не добавлять) так и его, побитые на подсети, части.  Например подсети по /21:

cisco(config)# ip route 5.5.0.0 255.255.248.0 10.0.0.2
cisco(config)# ip route 5.5.0.0 255.255.248.0 10.0.0.3

Где:

• 10.0.0.2
• 10.0.0.3

маршрутизаторы внутри сети. Ессно, что они должны быть доступны с маршрутизатора BGP.

Роутер всегда отправляет пакеты по маршруту с лучшим совпадением по маске, именно поэтому маршрут в Null0 и два маршрута, которые мы сделали выше, будут прекрасно сосуществовать и пакеты будут идти на хосты 10.0.0.2 и 10.0.0.3, т.к. у них более точное совпадение по маске.

Приступим к созданию необходимых route-map. Сначала начнем со всего «серого» (адресов и номеров AS).

Создадим необходимые prefix-list и as-path access-list.

Маршрут в default:
cisco(config)# ip prefix-list bogons description bogus nets
cisco(config)# ip prefix-list bogons seq 15 permit 0.0.0.0/8 le 32

Затем остальное:
cisco(config)# ip prefix-list bogons seq 20 permit 127.0.0.0/8 le 32
cisco(config)# ip prefix-list bogons seq 25 permit 192.0.2.0/24 le 32
cisco(config)# ip prefix-list bogons seq 30 permit 10.0.0.0/8 le 32
cisco(config)# ip prefix-list bogons seq 35 permit 172.16.0.0/12 le 32
cisco(config)# ip prefix-list bogons seq 40 permit 192.168.0.0/16 le 32
cisco(config)# ip prefix-list bogons seq 45 permit 169.254.0.0/16 le 32
cisco(config)# ip prefix-list bogons seq 50 permit 192.42.172.0/24 le 32
cisco(config)# ip prefix-list bogons seq 55 permit 198.18.0.0/15 le 32
cisco(config)# ip prefix-list bogons seq 60 permit 192.88.99.0/24 le 32
cisco(config)# ip prefix-list bogons seq 65 permit 224.0.0.0/4 le 32
cisco(config)# ip prefix-list bogons seq 70 permit 240.0.0.0/4 le 32

Теперь «серые» номера AS`ок:
cisco(config)# ip as-path access-list 1 permit _6451[2-9]_
cisco(config)# ip as-path access-list 1 permit _645[2-9][0-9]_
cisco(config)# ip as-path access-list 1 permit _64[6-9][0-9][0-9]_
cisco(config)# ip as-path access-list 1 permit _65[0-9][0-9][0-9]_

Создадим маршрутную карту на IN для AS200 (нашего апстрима).
Запрещаем маршруты с «серыми» номерами AS в as-path, то что матчит (разрешает (permit)) наш as-path access-list, то запрещает наша следующая маршрутная карта:

cisco(config)# route-map map-AS200-in deny 100
cisco(config-route-map)# description — filter private ASs
cisco(config-route-map)# match as-path 1
cisco(config-route-map)# exit

Теперь по маршруту по умолчанию и «серым» сетям, логика действия как и в пред. случае, запрещаем то что permit в prefix-list bogons:

cisco(config)# route-map map-AS200-in deny 110
cisco(config-route-map)# description — — filter bogons
cisco(config-route-map)# match ip address prefix-list bogons
cisco(config-route-map)# exit

Ну и последнее, т.к. мы хотим принимать от AS200 full-view (т.е. полную таблицу), то:

• разрешаем все остальные маршруты
• выставляем local-preference по умолчанию внутри своей AS

cisco(config)# route-map map-AS200-in permit 200
cisco(config-route-map)# description — permit any else, set default loc-pref
cisco(config-route-map)# set local-preference 100
cisco(config-route-map)# exit

Создадим маршрутную карту на OUT для AS200 (нашего апстрима). Эта маршрутная карта нужна нам для того, чтобы наша AS анонсировала только свой префикс. Если маршрутной карты на OUT не будет, то ваша AS будет анонсировать всем своим соседям все известные ей маршруты и вы, сами того не желая, дадите возможность прогонять через вас трафик.
Но прежде создадим префикс лист со своим префиксом:

cisco(config)# ip prefix-list own-prefixes permit 5.5.0.0/20

Вот теперь вернемся к маршрутке на OUT:

cisco(config)# route-map map-AS200-out permit 100
cisco(config-route-map)# description — permit our prefixes
cisco(config-route-map)# match ip address prefix-list own-prefixes
cisco(config-route-map)# exit
Т.к. в конце маршрутки по умолчанию идет неявный deny, то все остальные префиксы (маршруты) будут запрещены.

Настало время приступить к маршрутным картам для нашего private peer`а.
Т.к. от него мы собираемся получать только маршруты принадлежащие ему (AS300) и его клиенту (AS400), то будет проще, разрешим только необходимые префиксы, а все остальное запретим:

cisco(config)# ip prefix-list peer-prefixes permit 11.11.0.0/21
cisco(config)# ip prefix-list peer-prefixes permit 12.12.0.0/21

Теперь можно создать маршрутную карту на IN, в которой разрешим необходимые префиксы и поднимем loc-pref, на данные префиксы, чтобы маршруты полученные от этого пира имели приоритет над маршрутами к этим префиксам полученными от других апстримов/пиров:

cisco(config)# route-map map-AS300-in permit 100
cisco(config-route-map)# description — — permit peer prefix
cisco(config-route-map)# match ip address prefix-list peer-prefixes
cisco(config-route-map)# set local-preference 200
cisco(config-route-map)# exit

Ну и тут не обойдется без маршрутной карты на OUT:

cisco(config)# route-map map-AS300-out permit 100
cisco(config-route-map)# description — permit our prefixes
cisco(config-route-map)# match ip address prefix-list own-prefixes
cisco(config-route-map)# exit

Зачем мы создали две маршрутные карты на OUT с разными названиями, но с одинаковым содержимым ?
Ответ прост. Если, в последствии, нам нужно будет, например добавить community к своему маршруту или оглашать свой блок меньшими подсетями, то все равно придется делать разные маршрутные карты, вот поэтому сделаем это сразу, чтобы потом не изменять конфигурацию bgp, а просто подправить маршрутную карту.

Закончим подготовку перед настройкой BGP:

cisco(config)# ip classless
cisco(config)# ip routing
cisco(config)# ip subnet-zero

Подготовку мы сделали, теперь можно переходить непосредственно к настройке и запуску BGP.

cisco(config)# router bgp 100
cisco(config-router)# no synchronization
cisco(config-router)# bgp log-neighbor-changes
cisco(config-router)# bgp deterministic-med

Объявим наш префикс:
cisco(config-router)# network 5.5.0.0 mask 255.255.240.0

Пропишем наего апстрима AS200:
cisco(config-router)# neighbor 1.1.1.1 remote-as 200
cisco(config-router)# neighbor 1.1.1.1 description AS200-upstream
cisco(config-router)# neighbor 1.1.1.1 send-community
cisco(config-router)# neighbor 1.1.1.1 version 4
cisco(config-router)# neighbor 1.1.1.1 soft-reconfiguration inbound
cisco(config-router)# neighbor 1.1.1.1 route-map map-AS200-in in
cisco(config-router)# neighbor 1.1.1.1 route-map map-AS200-out out

Пропишем нашего private peer`а:
cisco(config-router)# neighbor 2.2.2.9 remote-as 300
cisco(config-router)# neighbor 2.2.2.9 description AS300-private-peer
cisco(config-router)# neighbor 2.2.2.9 send-community
cisco(config-router)# neighbor 2.2.2.9 version 4
cisco(config-router)# neighbor 2.2.2.9 soft-reconfiguration inbound
cisco(config-router)# neighbor 2.2.2.9 route-map map-AS300-in in
cisco(config-router)# neighbor 2.2.2.9 route-map map-AS300-out out

Заканчиваем:
cisco(config-router)# distance bgp 180 200 200
cisco(config-router)# no auto-summary
cisco(config-router)# exit
cisco(config)# exit
cisco# wri

После запуска посмотрите, что все настроенные BGP сессии поднялись. Команда:
cisco# show ip bgp summary

Так же стоит взгянуть что именно мы огласили нашему апстриму:
cisco# show ip bgp neighbors 1.1.1.1 advertised-routes

И нашему private peer`у:
cisco# show ip bgp neighbors 2.2.2.9 advertised-routes

Можно взглянуть и что мы от них получили:
cisco# show ip bgp neighbors 1.1.1.1 received-routes
cisco# show ip bgp neighbors 2.2.2.9 received-routes

После того как вы убедились, что все соответствует задуманному можно расслабиться и выпить пива 🙂

---

Заметка:
После каждого изменения route-map, в процессе работы, чтобы изменения вступили в силу необходимо оборвать (clear`нуть) BGP сессию с сосседом. Для того чтобы этого не делать и существует команда soft-reconfiguration inbound при настройке neighbor. Она заставляет роутер хранить маршруты полученные от соседа не только после обработки вашими route-map, но и до этого.
Тем самым вы не обрываете сессию с соседом, а роутер просто берет сохраненные у себя маршруты, которые пришли от соседа и сохранены в первозданном виде ДО обработки вашими route-map и снова прогоняет их через уже измененную route-map.
Например вы изменили route-map map-AS200-in, значит нуна клирнуть сессию с соседом IP-адрес 1.1.1.1.
cisco# clear ip bgp 1.1.1.1 soft in

---

Заметка:
Если вы хотите принимать от BGP соседа маршруты не более определенной маски, то необходимо создать prefix-list с указанием le или ge:

• eq — Matches the exact prefix length
• ge — Matches a prefix length that is equal to or greater than the configured prefix length
• le — Matches a prefix length that is equal to or less than the configured prefix length

Например: принимать все маршруты с любым префиксом, но не более /24:
cisco(config)# ip prefix-list prefix-range seq 5 permit 0.0.0.0/0 le 24
cisco(config)# route-map peer-in permit 200
cisco(config-route-map)# match ip address prefix-list prefix-range

---

Полезные ссылки:

• Online BGP tools (as-set, access-list, prefix-list, etc.)
  
• Список Looking Glass
• Программы для BGP

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

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

Все вы, у кого есть своя ASка, получили письмо от RIPE:

From: Andrew de la Haye <noreply@ripe.net>
Subject: 32-bit AS Numbers: A Change Is Coming!

Dear Colleagues,

As of 1 January 2009, the RIPE NCC will begin assigning 32-bit (or four-byte) ASN Numbers (ASNs) by default. This is in accordance with a global
policy agreed on in all Regional Internet Registry (RIR) communities.

When requesting an ASN after 1 January, LIR staff should ensure that 32-bit ASNs will be compatible with their existing networks. Some network
operators may experience difficulties configuring BGP sessions if their or their upstream providers' equipment is not compliant with the new
32-bit standard.

If you believe your network will encounter problems with 32-bit ASNs, it will be possible to specifically request a 16-bit ASN.

For more information, please see, "32-bit Autonomous System Numbers: A Guide for LIRs":
http://www.ripe.net/news/asn-32-guide.html

If you have any questions regarding 32-bit ASNs, please send an email to <contact@ripe.net>.

Regards,
Andrew de la Haye
Chief Operations Officer, RIPE NCC

Один знакомый бросил ссылочку на интересную статейку и мы решили запостить и у нас:

Understanding 4-Byte Autonomous System Numbers

Итак, вы в качестве пограничного маршрутизатора своей AS выбрали маршрутизатор Juniper.

Поздравляю вас ! Вы сделали отличный выбор ! 😉

В этой статье я постараюсь рассказать как настроить протокол BGP на оборудовании этого производителя.

Это не how-to на все случаи в жизни, а пример, с которого можно хоть как-то начать постигать замечательное железо от Juniper.

В качестве примера буду использовать:

Наша автономная система: AS100

Наш префикс: 1.1.0.0/20

Схема подключения:

Два апстрима: AS200 (2.2.2.1/30) и AS300 (3.3.3.1/30)

И один прямой пиринг с AS400 (4.4.4.1/30)

Будем подразумевать, что соответствующие IP интерфейсы на маршрутизаторе вы уже настроили. Пример настройки интерфейсов можно посмотреть в этой статье и сделать по аналогии.

Настройка протокола BGP начинается с секции protocols.

Войдем в режим конфигурации:

root@juniper> configure

перейдем в раздел protocols bgp

[edit]
root@juniper# edit protocols bgp

Начнем с того, что укажем номер своей автономной системы:

[edit protocols bgp]
root@juniper# set local-as 100

Зададим логирование изменений состояния «соседей» (peer):

[edit protocols bgp]
root@juniper# set log-updown

Воспользуемся следующей опцией, чтобы оглашать лучший маршрут даже если в таблице маршрутизации он не является активным маршрутом:

[edit protocols bgp]
root@juniper# set advertise-inactive

Зададим route flap damping (так называемые «хлопающие» маршруты):

Т.к. это пограничный маршрутизатор, а значит «серые» сети не должны выходить за его пределы, выполним следущее (discard):

[edit routing-options]
root@juniper# set route 10.0.0.0/8 discard

[edit routing-options]
root@juniper# set route 172.16.0.0/12 discard

[edit routing-options]
root@juniper# set route 192.168.0.0/16 discard

Не будем «насиловать» лишними маршрутами своих апстримов и будем им оглашать весь блок /20 целиком. Для этого сделаем агрегирование:

[edit routing-options]
root@juniper# set aggregate route 1.1.0.0/20 discard

Посмотрим что получилось в этой секции:

[edit routing-options]
root@juniper# show

Настало время создать маршрутные карты. Начнем с per-flow-load-balancing.

Перейдем в другую секцию:

[edit routing-options]
root@juniper# top

[edit]
root@juniper# edit policy-options

Создадим для per-flow-load-balancing:

[edit policy-options]
root@juniper# set policy-statement per-flow-load-balancing term balance then load-balance per-packet

Приступим к дефолтным маршрутным картам для соседей.

Для начала bogus-reject:

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 127.0.0.0/8 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 10.0.0.0/8 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 172.16.0.0/12 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 192.168.0.0/16 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 169.254.0.0/16 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 224.0.0.0/4 orlonger

[edit policy-options]
root@juniper# set policy-statement bogus-reject from route-filter 240.0.0.0/4 orlonger

Так мы задали список маршрутов, теперь укажем что мы с ними хотим сделать, в т.ч., и не принимать такие маршруты:

[edit policy-options]
root@juniper# set policy-statement bogus-reject then reject

Создадим default-route-reject для запрета приема default gateway по протоколу BGP:

[edit policy-options]
root@juniper# set policy-statement default-route-reject from route-filter 0.0.0.0/0 exact

[edit policy-options]
root@juniper# set policy-statement default-route-reject then reject

Создадим bogus-ases для запрета приема «серых» (private) номеров AS:

[edit policy-options]
root@juniper# set policy-statement bogus-ases from as-path grey-as

[edit policy-options]
root@juniper# set policy-statement bogus-ases then reject

[edit policy-options]
root@juniper# set policy-statement as-path grey-as 64512-65535

Пришло время для карт для соседей. В маршрутных картах на in (input) вы можете «играться» с теми или иными маршрутами приходящими от соседей. Фильтровать что-то, поднимать local-prefence и т.п. Для примера покажу как поднять local-prefence на маршрутах, для которых ваш апстрим является origin (т.е. те маршруты, которые принадлежат его AS).

Итак Prov-1-in:

[edit policy-options]
root@juniper# set policy-statement Prov-1-in term own-as from as-path prov-1-as

[edit policy-options]
root@juniper# set policy-statement Prov-1-in term own-as then local-preference 200

[edit policy-options]
root@juniper# set policy-statement Prov-1-in term own-as then accept

Теперь создадим as-path:

[edit policy-options]
root@juniper# set as-path prov-1-as «.*200»

Т.к. orign AS для маршрута всегда находится в конце as-path, то я и задал регулярное выражение которое ищет AS200 в конце as-path. Подробнее о регулярных выражениях читайте в технической документации по вашей версии JUNOS. Вы можете использовать не только as-path, но и префиксы которые принадлежат данному апстриму. Это на ваш выбор. Я выбрал as-path потому, что бы каждый раз не лазать и не изменять конфиг когда у этого апстрима появится новый блок IP-адресов.

Теперь зададим последний этап обработки приходящих от этого апстрима маршутов и действий с ними. Т.к. у нас full-view, то логично, что мы разрешим все остальное:

[edit policy-options]
root@juniper# set policy-statement Prov-1-in term final-accept then accept

Тут же вы можете выставить default local-preference для этого апстрима:

[edit policy-options]
root@juniper# set policy-statement Prov-1-in term final-accept then local-preference 100

Проделайте тоже самое и для Prov-2-in подставив туда его значения создав policy-statement Prov-2-in и as-path с AS300.

Для примера для нашего прямого пира AS400 мы создадим маршрутку с его префиксами, а не с as-path:

[edit policy-options]
root@juniper# set policy-statement Peer-1-in term own-prefix from prefix-list-filter peer-1-prefix exact

[edit policy-options]
root@juniper# set policy-statement Peer-1-in term own-prefix then accept

Поднимем local-preference для этих маршрутов выше, чем все остальное:

[edit policy-options]
root@juniper# set policy-statement Peer-1-in term own-prefix then local-preference 210

Теперь запретим все остальное (т.к. как я уже говорил это прямой пир, а не апстрим, а раз так то принимаем только те префиксы, которые ему принадлежат):

[edit policy-options]
root@juniper# set policy-statement Peer-1-in term final-reject then reject

Ну и осталось создать peer-1-prefix который мы прописали выше и указать в нем префиксы, которые принадлежат AS400, допустим это будут префиксы:

• 195.128.0.0/16
• 77.87.224.0/21

[edit policy-options]
root@juniper# set prefix-list peer-1-prefix 195.128.0.0/16

[edit policy-options]
root@juniper# set prefix-list peer-1-prefix 77.87.224.0/21

Итак с приемом маршрутов разобрались, приступим к оглашению наших. Эта задача состоит из двух частей:

• оглашение агрегированного маршрута для апстримов
• оглашение разделенного блока /20 для прямого пира

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

Начнем с AS200 (первый апстрим) и как мы условились апстримам мы оглашаем агрегированный маршрут:

[edit policy-options]
root@juniper# set policy-statement Prov-1-out term my-prefix from protocol aggregate

[edit policy-options]
root@juniper# set policy-statement Prov-1-out term my-prefix from policy our-CIDR-blocks-aggregated

[edit policy-options]
root@juniper# set policy-statement Prov-1-out term my-prefix then accept

Создадим сам фильтр policy our-CIDR-blocks-aggregated:

[edit policy-options]
root@juniper# set policy-statement our-CIDR-blocks-aggregated term AS100-prefix from route-filter 1.1.0.0/20 exact

[edit policy-options]
root@juniper# set policy-statement our-CIDR-blocks-aggregated term AS100-prefix then accept

Т.к. на данном этапе мы всем апстримам оглашаем одно и тоже, то создайте Prov-2-out сами.

Теперь нужно сделать out для нашего прямого пира и оглашать мы ему будем две сети /21:

[edit policy-options]
root@juniper# set policy-statement Peer-1-out term AS100-prefix from protocol static

[edit policy-options]
root@juniper# set policy-statement Peer-1-out term AS100-prefix from policy our-CIDR-blocks

[edit policy-options]
root@juniper# set policy-statement Peer-1-out term AS100-prefix then accept

[edit policy-options]
root@juniper# set policy-statement Peer-1-out term final-reject then reject

[edit policy-options]
root@juniper# set policy-statement our-CIDR-blocks term AS100-prefixes from route-filter 1.1.0.0/21 exact

[edit policy-options]
root@juniper# set policy-statement our-CIDR-blocks term AS100-prefixes from route-filter 1.1.8.0/21 exact

[edit policy-options]
root@juniper# set policy-statement our-CIDR-blocks term AS100-prefixes then accept

Ну вот вроде на первый взляд и все. Проверим все ли в порядке:

[edit policy-options]
root@juniper# commit check

Если в ответ вы получили сообщение:

configuration check succeeds

значит ошибок в конфигурации нет и вы можете применять её на маршрутизаторе. Сделаем это и добавим комментарий к этому конфигу:

[edit policy-options]
root@juniper# commit comment «My first configuration»

Juniper может хранить до 50-ти «закомиченных» конфигураций и вы всегда можете откатываться к любой их них, поэтому я рекомендую всегда добавлять комментарий к конфигу, чтобы потом различать их 🙂

Посмотреть состояние всех соседей можно командой:

[edit policy-options]
root@juniper# run show bgp summary

Т.к. мы все ещё находимся в режиме конфигурирования нам приходится добавлять ключевое слово run чтобы команда show отработала не на конфигурации.

Если мы выйдем из режима конфигурирования:

[edit policy-options]
root@juniper# exit

то тут слово run добавлять уже не нужно:

root@juniper> show bgp summary

Другие команды для просмотра состояний соседей, пришедших/отправленных им маршрутах и т.п. я рассмотрю в другой статье.

Мануал, по всем командам, вы можете прочитать в технической документации по вашей версии Junos на сайте производителя: www.juniper.net

Рекомендую полистать книгу:

JUNOS Cookbook

By Aviva Garrett

………………………………………..

Publisher: O’Reilly

Pub Date: April 2006

Print ISBN-10: 0-596-10014-0

Print ISBN-13: 978-0-59-610014-8

Pages: 682

Заранее прошу прощения за оЧепЯтки и неточности. По мере нахождения багов и замечаний статья будет изменяться.

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

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

Русская версия новости

Двое специалистов по IT-безопасности, Антон Капела (Anton Kapela) из 5Nines Data и Алекс Пилосов (Alex Pilosov) из Pilosoft, продемонстрировали методику, позволяющую тайно перехватывать интернет-трафик и даже модифицировать его на пути к адресату, пишет Wired. Это позволяет сделать протокол интернет-маршрутизации BGP (Border Gateway Protocol, протокол граничного шлюза)

Эксперты уже назвали обнаруженную «дырку» одной из самых крупных в Интернете и сравнивают ее с недавно обнаруженной DNS-уязвимостью, теоретически позволявшей злоумышленнику перенаправлять пользователя вместо нужного на любой сайт.

BGP является одним из основных интернет-протоколов и обеспечивает обмен информацией о маршрутах между целыми автономными системами, а не отдельными маршрутизаторами. Капела и Пилосов показали на конференции DefCon, как можно перехватить трафик, направляющийся в сеть конференции, переправить его в контролируемую ими систему в Нью-Йорке, а затем доставить обратно. Их схема не использует ошибок протокола — лишь его нормальные возможности.

Как пишет Wired, ранее перехватывать интернет-трафик, используя уязвимость BGP, были способны только разведывательные агентства. Они знали о недостатках протокола с 1998 года, с тех пор как эксперт по безопасности Пейтер Затко (Peiter Zatko) рассказал о ней Конгрессу и предположил, что может за полчаса нарушить работу всего Интернета, используя обнаруженную уязвимость.

---

Английская версия новости

Two security researchers have demonstrated a new technique to stealthily intercept internet traffic on a scale previously presumed to be unavailable to anyone outside of intelligence agencies like the National Security Agency.

The tactic exploits the internet routing protocol BGP (Border Gateway Protocol) to let an attacker surreptitiously monitor unencrypted internet traffic anywhere in the world, and even modify it before it reaches its destination.

The demonstration is only the latest attack to highlight fundamental security weaknesses in some of the internet’s core protocols. Those protocols were largely developed in the 1970s with the assumption that every node on the then-nascent network would be trustworthy. The world was reminded of the quaintness of that assumption in July, when researcher Dan Kaminsky disclosed a serious vulnerability in the DNS system. Experts say the new demonstration targets a potentially larger weakness.

«It’s a huge issue. It’s at least as big an issue as the DNS issue, if not bigger,» said Peiter «Mudge» Zatko, noted computer security expert and former member of the L0pht hacking group, who testified to Congress in 1998 that he could bring down the internet in 30 minutes using a similar BGP attack, and disclosed privately to government agents how BGP could also be exploited to eavesdrop. «I went around screaming my head about this about ten or twelve years ago…. We described this to intelligence agencies and to the National Security Council, in detail.»

The man-in-the-middle attack exploits BGP to fool routers into re-directing data to an eavesdropper’s network.

Anyone with a BGP router (ISPs, large corporations or anyone with space at a carrier hotel) could intercept data headed to a target IP address or group of addresses. The attack intercepts only traffic headed to target addresses, not from them, and it can’t always vacuum in traffic within a network — say, from one AT&T customer to another.

The method conceivably could be used for corporate espionage, nation-state spying or even by intelligence agencies looking to mine internet data without needing the cooperation of ISPs.

BGP eavesdropping has long been a theoretical weakness, but no one is known to have publicly demonstrated it until Anton «Tony» Kapela, data center and network director at 5Nines Data, and Alex Pilosov, CEO of Pilosoft, showed their technique at the recent DefCon hacker conference. The pair successfully intercepted traffic bound for the conference network and redirected it to a system they controlled in New York before routing it back to DefCon in Las Vegas.

The technique, devised by Pilosov, doesn’t exploit a bug or flaw in BGP. It simply exploits the natural way BGP works.

«We’re not doing anything out of the ordinary,» Kapela told Wired.com. «There’s no vulnerabilities, no protocol errors, there are no software problems. The problem arises (from) the level of interconnectivity that’s needed to maintain this mess, to keep it all working.»

The issue exists because BGP’s architecture is based on trust. To make it easy, say, for e-mail from Sprint customers in California to reach Telefonica customers in Spain, networks for these companies and others communicate through BGP routers to indicate when they’re the quickest, most efficient route for the data to reach its destination. But BGP assumes that when a router says it’s the best path, it’s telling the truth. That gullibility makes it easy for eavesdroppers to fool routers into sending them traffic.

Here’s how it works. When a user types a website name into his browser or clicks «send» to launch an e-mail, a Domain Name System server produces an IP address for the destination. A router belonging to the user’s ISP then consults a BGP table for the best route. That table is built from announcements, or «advertisements,» issued by ISPs and other networks — also known as Autonomous Systems, or ASes — declaring the range of IP addresses, or IP prefixes, to which they’ll deliver traffic.

The routing table searches for the destination IP address among those prefixes. If two ASes deliver to the address, the one with the more specific prefix «wins» the traffic. For example, one AS may advertise that it delivers to a group of 90,000 IP addresses, while another delivers to a subset of 24,000 of those addresses. If the destination IP address falls within both announcements, BGP will send data to the narrower, more specific one.

To intercept data, an eavesdropper would advertise a range of IP addresses he wished to target that was narrower than the chunk advertised by other networks. The advertisement would take just minutes to propagate worldwide, before data headed to those addresses would begin arriving to his network.

The attack is called an IP hijack and, on its face, isn’t new.

But in the past, known IP hijacks have created outages, which, because they were so obvious, were quickly noticed and fixed. That’s what occurred earlier this year when Pakistan Telecom inadvertently hijacked YouTube traffic from around the world. The traffic hit a dead-end in Pakistan, so it was apparent to everyone trying to visit YouTube that something was amiss.

Pilosov’s innovation is to forward the intercepted data silently to the actual destination, so that no outage occurs.

Ordinarily, this shouldn’t work — the data would boomerang back to the eavesdropper. But Pilosov and Kapela use a method called AS path prepending that causes a select number of BGP routers to reject their deceptive advertisement. They then use these ASes to forward the stolen data to its rightful recipients.

«Everyone … has assumed until now that you have to break something for a hijack to be useful,» Kapela said. «But what we showed here is that you don’t have to break anything. And if nothing breaks, who notices?»

Stephen Kent, chief scientist for information security at BBN Technologies, who has been working on solutions to fix the issue, said he demonstrated a similar BGP interception privately for the Departments of Defense and Homeland Security a few years ago.

Kapela said network engineers might notice an interception if they knew how to read BGP routing tables, but it would take expertise to interpret the data.

A handful of academic groups collect BGP routing information from cooperating ASes to monitor BGP updates that change traffic’s path. But without context, it can be difficult to distinguish a legitimate change from a malicious hijacking. There are reasons traffic that ordinarily travels one path could suddenly switch to another — say, if companies with separate ASes merged, or if a natural disaster put one network out of commission and another AS adopted its traffic. On good days, routing paths can remain fairly static. But «when the internet has a bad hair day,» Kent said, «the rate of (BGP path) updates goes up by a factor of 200 to 400.»

Kapela said eavesdropping could be thwarted if ISPs aggressively filtered to allow only authorized peers to draw traffic from their routers, and only for specific IP prefixes. But filtering is labor intensive, and if just one ISP declines to participate, it «breaks it for the rest of us,» he said.

«Providers can prevent our attack absolutely 100 percent,» Kapela said. «They simply don’t because it takes work, and to do sufficient filtering to prevent these kinds of attacks on a global scale is cost prohibitive.»

Filtering also requires ISPs to disclose the address space for all their customers, which is not information they want to hand competitors.

Filtering isn’t the only solution, though. Kent and others are devising processes to authenticate ownership of IP blocks, and validate the advertisements that ASes send to routers so they don’t just send traffic to whoever requests it.

Under the scheme, the five regional internet address registries would issue signed certificates to ISPs attesting to their address space and AS numbers. The ASes would then sign an authorization to initiate routes for their address space, which would be stored with the certificates in a repository accessible to all ISPs. If an AS advertised a new route for an IP prefix, it would be easy to verify if it had the right to do so.

The solution would authenticate only the first hop in a route to prevent unintentional hijacks, like Pakistan Telecom’s, but wouldn’t stop an eavesdropper from hijacking the second or third hop.

For this, Kent and BBN colleagues developed Secure BGP (SBGP), which would require BGP routers to digitally sign with a private key any prefix advertisement they propagated. An ISP would give peer routers certificates authorizing them to route its traffic; each peer on a route would sign a route advertisement and forward it to the next authorized hop.

«That means that nobody could put themselves into the chain, into the path, unless they had been authorized to do so by the preceding AS router in the path,» Kent said.

The drawback to this solution is that current routers lack the memory and processing power to generate and validate signatures. And router vendors have resisted upgrading them because their clients, ISPs, haven’t demanded it, due to the cost and man hours involved in swapping out routers.

Douglas Maughan, cybersecurity research program manager for the DHS’s Science and Technology Directorate, has helped fund research at BBN and elsewhere to resolve the BGP issue. But he’s had little luck convincing ISPs and router vendors to take steps to secure BGP.

«We haven’t seen the attacks, and so a lot of times people don’t start working on things and trying to fix them until they get attacked,» Maughan said. «(But) the YouTube (case) is the perfect example of an attack where somebody could have done much worse than what they did.»

ISPs, he said, have been holding their breath, «hoping that people don’t discover (this) and exploit it.»

«The only thing that can force them (to fix BGP) is if their customers … start to demand security solutions,» Maughan said.

Ссылки:

• lenta.ru
• Версия на английском языке