BGP отражатели маршрутов
Понимание BGP отражателей маршрутов
Эта тема обсуждает использование отражателей маршрутов для упрощения конфигурации и помощи в масштабирования. Еще один способ уменьшить нагрузку на отражателя маршрутов, который не находится в пути переададатора трафика, - использовать утверждение на no-install[edit protocols bgp family family-name] уровне иерархии. Начиная с Junos OS 15.1, утверждение исключает взаимодействие между daemon протоколов маршрутов (rpd) и другими компонентами в системе Junos, такой как ядро или распределенный брандмауэр-daemon no-install (dfwd). Это взаимодействие устраняется запретом на публикацию в этих компонентах любых маршрутов в связанных базах сведений о маршруте (RIBs) RPD, также известных как таблицы маршрутов.
В версиях, предшествующих выпуску 15.1 Junos OS, можно уменьшить нагрузку на отражателя маршрутов, который не находится в пути переададатора трафика, с помощью политики экспорта переад релиза-таблицы, которая отклоняет маршруты, которые были BGP.
Из-за внутреннего BGP (IBGP) полноязных сетей, большинство сетей используют отражатели маршрутов для упрощения конфигурации. Формула расчета количества сеансов, необходимого для полноячей сети, – v* (v - 1)/2, где v – это число устройств с BGP с поддержкой. Полноявая модель масштабирования не очень хорошо. С помощью отражателя маршрутов маршрутизаторы группируются в кластеры, которые идентифицируются числеными идентификаторами, уникальными для автономной системы (AS). В кластере необходимо настроить сеанс BGP от одного маршрутизатора (отражателя маршрутов) на каждый внутренний одноранговой ранг. С данной конфигурацией, IBGP полноязное требование соответствует.
Чтобы использовать отражение маршрутов в AS, необходимо назначить один или несколько маршрутизаторов в качестве отражателя маршрутов — как правило, по одному на точка присутствия (PoP). Отражатели маршрутов имеют специальную BGP возможность перенаправки маршрутов, узнаются от внутреннего одноранговых участников к другим внутренним равноправным узлам. Поэтому, вместо того, чтобы все внутренние ранги были полностью совмещены друг с другом, отражение маршрутов требует только того, чтобы отражающий маршрут был полностью совмещен со всеми внутренними однорангами. Отражачик маршрутов и все его внутренние одноранговые ранги образуют кластер, как показано Рис. 1 в.
Для некоторых Juniper Networks устройств на каждом устройстве, использующем отражающее маршруты, должна быть установлена лицензия advanced BGP feature. Сведения о лицензии см. в руководстве по установке и модернизации программного обеспечения.
Рис. 1 отображает маршрутизатор RR, настроенный в качестве отражателя маршрутов для кластера 127. Другие маршрутизаторы являются назначенными внутренними однорангами в кластере. BGP маршруты объявляются маршрутизатору RR любым из внутренних одноранговых маршрутизаторов. Затем RR перезановеряет эти маршруты всем другим равноправным узлам в кластере.
Можно настроить несколько кластеров и связать их, настроив полную сетку отражателей маршрутов Рис. 2 (см. ).
Рис. 2 отображает отражатели маршрутов RR 1, RR 2, RR 3 и RR 4 в качестве полностью совмещенных внутренних одноранговых участников. Когда маршрутизатор объявляет маршрут RR 1, RR 1 перезагружет маршрут к другим отражателям маршрутов, которые, в свою очередь, инвертируют маршрут к остальным маршрутизаторам в AS. Отражение маршрутов позволяет распространять маршрут по as без проблем масштабирования, созданных требованием полноявом.
Отражачик маршрутов, поддерживаюный несколько кластеров, не принимает маршрут с одинаковым ID кластера от не-клиентского маршрутизатора. Поэтому необходимо настроить другой кластерный ID для избыточного RR с учетом маршрутов к другим кластерам.
Однако, когда кластеры становятся большими, становится сложно масштабировать полную сетку с отражателем маршрутов, также как и полная сетка между отражателями маршрутов. Чтобы решить эту проблему, можно сгруппировать кластеры маршрутизаторов в кластеры кластеров для иерархического отражения маршрутов Рис. 3 (см.).
Рис. 3 отображает RR 2, RR 3 и RR 4 в качестве отражателей маршрутов для кластеров 127, 19 и 45 соответственно. Вместо полноты якорных отражателей маршрутов администратор сети настроил их как часть другого кластера (кластера 6), для которого RR 1 является отражателем маршрутов. Когда маршрутизатор объявляет маршрут RR 2, RR 2 перезагружет маршрут всем маршрутизаторам в собственном кластере, а затем перезагружет маршрут к RR 1. RR 1 перезагружет маршрут к маршрутизаторам в кластере, и эти маршрутизаторы распространяют маршрут вниз через свои кластеры.
См. также
Примере: Настройка отражателя маршрутов
В данном примере показана настройка отражателя маршрутов.
Требования
До настройки этого примера специальная настройка после инициализации устройства не требуется.
Обзор
Обычно внутренние BGP (IBGP) устройства с поддержкой IBGP должны быть полностью совмещенными, так как IBGP не инвертизирует обновления на другие устройства с поддержкой IBGP. Полная сетка представляет собой логическую сетку, достигаемую посредством настройки нескольких neighbor троек на каждом устройстве с поддержкой IBGP. Полная сетка не обязательно является физической полной. Обслуживание полнояренной (логической или физической) ящерых развертываниях не очень хорошо масштабется.
Рис. 4 показывает сеть IBGP с устройством A, действующим в качестве отражателя маршрутов. Устройство B и устройство C являются клиентами отражателя маршрутов. Устройства D и Device E находятся вне кластера, поэтому они не являютсяклиентами отражателя маршрутов.
На устройстве A (отражачик маршрутов) необходимо сформировать равноправные связи со всеми устройствами с поддержкой IBGP, включив в них утверждение для клиентов (Устройство B и устройство C) и неклиентов neighbor (Device D и Device E). Также следует включить утверждение cluster и идентификатор кластера. Идентификатор кластера может иметь любое 32-битное значение. В данном примере используется IP-адрес интерфейса обратной связи отражателя маршрутов.
На устройстве B и устройстве C клиентам отражателя маршрутов требуется только одно утверждение, которое формирует одноранговую связь с отражателем neighbor маршрутов, устройством А.
На устройстве D и устройстве E неклиенсам требуется утверждение для каждого неклиентского устройства neighbor (D-to-E и E-to-D). Также требуется утверждение neighbor для отражателя маршрутов (D-to-A и E-to-A). Устройства D и Device E не требуются для клиентских устройств neighbor (Device B и Device C).
Устройство D и Устройство E считаются неклиентами, так как они явно настроены в равноправных отношениях друг с другом. Чтобы заставить их быть клиентами отражателя RRroute, удалите утверждение из конфигурации устройства D и удалите утверждение из конфигурации neighbor 192.168.5.5neighbor 192.168.0.1 устройства E.
Конфигурации
- Процедуры
- Настройка отражателя маршрутов
- Настройка одноранговых клиентов
- Настройка неклиентных одноранговых узла
Процедуры
интерфейс командной строки быстрой конфигурации
Чтобы быстро настроить этот пример, скопировать следующие команды, ввести их в текстовый файл, удалить все разрывы строки, изменить все данные, необходимые для настройки сети, а затем скопировать и вкопировать команды в интерфейс командной строки на [edit] иерархии.
Устройство A
set interfaces fe-0/0/0 unit 1 description to-B set interfaces fe-0/0/0 unit 1 family inet address 10.10.10.1/30 set interfaces fe-0/0/1 unit 3 description to-D set interfaces fe-0/0/1 unit 3 family inet address 10.10.10.9/30 set interfaces lo0 unit 1 family inet address 192.168.6.5/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.6.5 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers cluster 192.168.6.5 set protocols bgp group internal-peers neighbor 192.163.6.4 set protocols bgp group internal-peers neighbor 192.168.40.4 set protocols bgp group internal-peers neighbor 192.168.0.1 set protocols bgp group internal-peers neighbor 192.168.5.5 set protocols ospf area 0.0.0.0 interface lo0.1 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.1 set protocols ospf area 0.0.0.0 interface fe-0/0/1.3 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.6.5 set routing-options autonomous-system 17
Устройство B
set interfaces fe-0/0/0 unit 2 description to-A set interfaces fe-0/0/0 unit 2 family inet address 10.10.10.2/30 set interfaces fe-0/0/1 unit 5 description to-C set interfaces fe-0/0/1 unit 5 family inet address 10.10.10.5/30 set interfaces lo0 unit 2 family inet address 192.163.6.4/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.163.6.4 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.2 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.2 set protocols ospf area 0.0.0.0 interface fe-0/0/1.5 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.163.6.4 set routing-options autonomous-system 17
Устройство C
set interfaces fe-0/0/0 unit 6 description to-B set interfaces fe-0/0/0 unit 6 family inet address 10.10.10.6/30 set interfaces lo0 unit 3 family inet address 192.168.40.4/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.40.4 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.3 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.6 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.40.4 set routing-options autonomous-system 17
Устройство D
set interfaces fe-0/0/0 unit 4 description to-A set interfaces fe-0/0/0 unit 4 family inet address 10.10.10.10/30 set interfaces fe-0/0/1 unit 7 description to-E set interfaces fe-0/0/1 unit 7 family inet address 10.10.10.13/30 set interfaces lo0 unit 4 family inet address 192.168.0.1/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.0.1 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols bgp group internal-peers neighbor 192.168.5.5 set protocols ospf area 0.0.0.0 interface lo0.4 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.4 set protocols ospf area 0.0.0.0 interface fe-0/0/1.7 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.0.1 set routing-options autonomous-system 17
Устройство E
set interfaces fe-0/0/0 unit 8 description to-D set interfaces fe-0/0/0 unit 8 family inet address 10.10.10.14/30 set interfaces lo0 unit 5 family inet address 192.168.5.5/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.5.5 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.0.1 set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.5 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.8 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.5.5 set routing-options autonomous-system 17
Пошаговая процедура
Настройка отражателя маршрутов
Пошаговая процедура
В следующем примере необходимо провести различные уровни в иерархии конфигурации. Для получения информации о навигации по интерфейс командной строки см. использование редактора интерфейс командной строки в режиме конфигурации в руководстве Junos OS интерфейс командной строки пользователя.
Чтобы настроить IBGP в сети, используя Juniper Networks устройство А в качестве отражателя маршрутов:
Настройте интерфейсы.
[edit interfaces] user@A# set fe-0/0/0 unit 1 description to-B user@A# set fe-0/0/0 unit 1 family inet address 10.10.10.1/30 user@A# set fe-0/0/1 unit 3 description to-D user@A# set fe-0/0/1 unit 3 family inet address 10.10.10.9/30 user@A# set lo0 unit 1 family inet address 192.168.6.5/32
Настройте BGP, включая идентификатор кластера и отношения соседей со всеми устройствами с поддержкой IBGP в автономной системе (AS).
Также примените политику, которая OSPF маршрутов в BGP.
[edit protocols bgp group internal-peers] user@A# set type internal user@A# set local-address 192.168.6.5 user@A# set export send-ospf user@A# set cluster 192.168.6.5 user@A# set neighbor192.163.6.4 user@A# set neighbor 192.168.40.4 user@A# set neighbor 192.168.0.1 user@A# set neighbor 192.168.5.5
Настройте статическую маршрутку или протокол внутреннего шлюза (IGP).
В данном примере OSPF.
[edit protocols ospf area 0.0.0.0] user@A# set interface lo0.1 passive user@A# set interface fe-0/0/0.1 user@A# set interface fe-0/0/1.3
Настройте политику, которая перераспределяет OSPF в BGP.
[edit policy-options policy-statement send-ospf term 2] user@A# set from protocol ospf user@A# set then accept
Настройте ID маршрутизатора и номер автономной системы (AS).
[edit routing-options] user@A# set router-id 192.168.6.5 user@A# set autonomous-system 17
Результаты
В режиме конфигурации подтвердите конфигурацию путем ввода show interfaces команд show protocols и show policy-optionsshow routing-options команд. Если в выходных данных не отображается указанная конфигурация, повторите инструкции, показанные в данном примере, чтобы исправить конфигурацию.
user@A# show interfaces
fe-0/0/0 {
unit 1 {
description to-B;
family inet {
address 10.10.10.1/30;
}
}
}
fe-0/0/1 {
unit 3 {
description to-D;
family inet {
address 10.10.10.9/30;
}
}
}
lo0 {
unit 1 {
family inet {
address 192.168.6.5/32;
}
}
}
user@A# show protocols
bgp {
group internal-peers {
type internal;
local-address 192.168.6.5;
export send-ospf;
cluster 192.168.6.5;
neighbor 192.163.6.4;
neighbor 192.168.40.4;
neighbor 192.168.0.1;
neighbor 192.168.5.5;
}
}
ospf {
area 0.0.0.0 {
interface lo0.1 {
passive;
}
interface fe-0/0/0.1;
interface fe-0/0/1.3;
}
}
user@A# show policy-options
policy-statement send-ospf {
term 2 {
from protocol ospf;
then accept;
}
}
user@A# show routing-options router-id 192.168.6.5; autonomous-system 17;
После настройки устройства войдите в commit режим конфигурации.
Повторите эти действия для каждого неклиента узел BGP в кластере, который настраивается, если другие неклиенты находятся Juniper Networks. В противном случае инструкции можно получить в документации устройства.
Настройка одноранговых клиентов
Пошаговая процедура
В следующем примере необходимо провести различные уровни в иерархии конфигурации. Для получения информации о навигации по интерфейс командной строки см. использование редактора интерфейс командной строки в режиме конфигурации в руководстве Junos OS интерфейс командной строки пользователя.
Для настройки равноправных клиентов:
Настройте интерфейсы.
[edit interfaces] user@B# set fe-0/0/0 unit 2 description to-A user@B# set fe-0/0/0 unit 2 family inet address 10.10.10.2/30 user@B# set fe-0/0/1 unit 5 description to-C user@B# set fe-0/0/1 unit 5 family inet address 10.10.10.5/30 user@B# set lo0 unit 2 family inet address 192.163.6.4/32
Настройте отношения BGP соседей с отражателем маршрутов.
Также примените политику, которая OSPF маршрутов в BGP.
[edit protocols bgp group internal-peers] user@B# set type internal user@B# set local-address 192.163.6.4 user@B# set export send-ospf user@B# set neighbor 192.168.6.5
Настройте OSPF.
[edit protocols ospf area 0.0.0.0] user@B# set interface lo0.2 passive user@B# set interface fe-0/0/0.2 user@B# set interface fe-0/0/1.5
Настройте политику, которая перераспределяет OSPF в BGP.
[edit policy-options policy-statement send-ospf term 2] user@B# set from protocol ospf user@B# set then accept
Настройте ID маршрутизатора и номер AS.
[edit routing-options] user@B# set router-id 192.163.6.4 user@B# set autonomous-system 17
Результаты
В режиме конфигурации подтвердите конфигурацию путем ввода show interfaces команд show protocols и show policy-optionsshow routing-options команд. Если в выходных данных не отображается указанная конфигурация, повторите инструкции, показанные в данном примере, чтобы исправить конфигурацию.
user@B# show interfaces
fe-0/0/0 {
unit 2 {
description to-A;
family inet {
address 10.10.10.2/30;
}
}
}
fe-0/0/1 {
unit 5 {
description to-C;
family inet {
address 10.10.10.5/30;
}
}
}
lo0 {
unit 2 {
family inet {
address 192.163.6.4/32;
}
}
}
user@B# show protocols
bgp {
group internal-peers {
type internal;
local-address 192.163.6.4;
export send-ospf;
neighbor 192.168.6.5;
}
}
ospf {
area 0.0.0.0 {
interface lo0.2 {
passive;
}
interface fe-0/0/0.2;
interface fe-0/0/1.5;
}
}
user@B# show policy-options
policy-statement send-ospf {
term 2 {
from protocol ospf;
then accept;
}
}
user@B# show routing-options router-id 192.163.6.4; autonomous-system 17;
После настройки устройства войдите в commit режим конфигурации.
Повторите эти действия для каждого узел BGP в кластере, который настраивается, если другие клиентские устройства находятся Juniper Networks. В противном случае инструкции можно получить в документации устройства.
Настройка неклиентных одноранговых узла
Пошаговая процедура
В следующем примере необходимо провести различные уровни в иерархии конфигурации. Для получения информации о навигации по интерфейс командной строки см. использование редактора интерфейс командной строки в режиме конфигурации в руководстве Junos OS интерфейс командной строки пользователя.
Для настройки неклиентных одноранговых узла:
Настройте интерфейсы.
[edit interfaces] user@D# set fe-0/0/0 unit 4 description to-A user@D# set fe-0/0/0 unit 4 family inet address 10.10.10.10/30 user@D# set fe-0/0/1 unit 7 description to-E user@D# set fe-0/0/1 unit 7 family inet address 10.10.10.13/30 user@D# set lo0 unit 4 family inet address 192.168.0.1/32
Настройте отношения BGP соседей с рефтектором RRroute и другими равноправными узлами, неклиентами.
Также примените политику, которая OSPF маршрутов в BGP.
[edit protocols bgp group internal-peers] user@D# set type internal user@D# set local-address 192.168.0.1 user@D# set export send-ospf user@D# set neighbor 192.168.6.5 user@D# set neighbor 192.168.5.5
Настройте OSPF.
[edit protocols ospf area 0.0.0.0] user@D# set interface lo0.4 passive user@D# set interface fe-0/0/0.4 user@D# set interface fe-0/0/1.7
Настройте политику, которая перераспределяет OSPF в BGP.
[edit policy-options policy-statement send-ospf term 2] user@D# set from protocol ospf user@D# set then accept
Настройте ID маршрутизатора и номер AS.
[edit routing-options] user@D# set router-id 192.168.0.1 user@D# set autonomous-system 17
Результаты
В режиме конфигурации подтвердите конфигурацию путем ввода show interfaces команд show protocols и show policy-optionsshow routing-options команд. Если в выходных данных не отображается указанная конфигурация, повторите инструкции, показанные в данном примере, чтобы исправить конфигурацию.
user@D# show interfaces
fe-0/0/0 {
unit 4 {
description to-A;
family inet {
address 10.10.10.10/30;
}
}
}
fe-0/0/1 {
unit 7 {
description to-E;
family inet {
address 10.10.10.13/30;
}
}
}
lo0 {
unit 4 {
family inet {
address 192.168.0.1/32;
}
}
}
user@D# show protocols
bgp {
group internal-peers {
type internal;
local-address 192.168.0.1;
export send-ospf;
neighbor 192.168.6.5;
neighbor 192.168.5.5;
}
}
ospf {
area 0.0.0.0 {
interface lo0.4 {
passive;
}
interface fe-0/0/0.4;
interface fe-0/0/1.7;
}
}
user@D# show policy-options
policy-statement send-ospf {
term 2 {
from protocol ospf;
then accept;
}
}
user@D# show routing-options router-id 192.168.0.1; autonomous-system 17;
После настройки устройства войдите в commit режим конфигурации.
Повторите эти действия для каждого неклиента узел BGP кластере, настраиваемом в том случае, если другие неклиенты имеют Juniper Networks. В противном случае инструкции можно получить в документации устройства.
Проверки
Подтвердим, что конфигурация работает правильно.
- Проверка BGP соседних BGP
- Проверка BGP групп
- Проверка сводной BGP информации
- Проверка сведений таблицы маршрутов
Проверка BGP соседних BGP
Цель
Проверьте, BGP ли BGP на настроенных интерфейсах и что BGP сеанс установлен для каждого адреса соседа.
Действий
В рабочем режиме введите show bgp neighbor команду.
user@A> show bgp neighbor
Peer: 192.163.6.4+179 AS 17 Local: 192.168.6.5+62857 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.163.6.4 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 6
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 5 Sent 3 Checked 19
Input messages: Total 2961 Updates 7 Refreshes 0 Octets 56480
Output messages: Total 2945 Updates 6 Refreshes 0 Octets 56235
Output Queue[0]: 0
Peer: 192.168.0.1+179 AS 17 Local: 192.168.6.5+60068 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.0.1 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 3
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 6
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 18 Sent 20 Checked 12
Input messages: Total 15 Updates 5 Refreshes 0 Octets 447
Output messages: Total 554 Updates 4 Refreshes 0 Octets 32307
Output Queue[0]: 0
Peer: 192.168.5.5+57458 AS 17 Local: 192.168.6.5+179 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.5.5 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 2
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 17 Sent 3 Checked 9
Input messages: Total 2967 Updates 7 Refreshes 0 Octets 56629
Output messages: Total 2943 Updates 6 Refreshes 0 Octets 56197
Output Queue[0]: 0
Peer: 192.168.40.4+53990 AS 17 Local: 192.168.6.5+179 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.40.4 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 1
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 5 Sent 23 Checked 52
Input messages: Total 2960 Updates 7 Refreshes 0 Octets 56496
Output messages: Total 2943 Updates 6 Refreshes 0 Octets 56197
Output Queue[0]: 0Проверка BGP групп
Цель
Проверьте правильность BGP групп.
Действий
В рабочем режиме введите show bgp group команду.
user@A> show bgp group Group Type: Internal AS: 17 Local AS: 17 Name: internal-peers Index: 0 Flags: <> Export: [ send-ospf ] Options: <Cluster> Holdtime: 0 Total peers: 4 Established: 4 192.163.6.4+179 192.168.40.4+53990 192.168.0.1+179 192.168.5.5+57458 inet.0: 0/26/16/0 Groups: 1 Peers: 4 External: 0 Internal: 4 Down peers: 0 Flaps: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 26 0 0 0 0 0
Проверка сводной BGP информации
Цель
Проверьте правильность BGP конфигурации.
Действий
В рабочем режиме введите show bgp summary команду.
user@A> show bgp summary Groups: 1 Peers: 4 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 26 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.163.6.4 17 2981 2965 0 0 22:19:15 0/6/1/0 0/0/0/0 192.168.0.1 17 36 575 0 0 13:43 0/6/1/0 0/0/0/0 192.168.5.5 17 2988 2964 0 0 22:19:10 0/7/7/0 0/0/0/0 192.168.40.4 17 2980 2964 0 0 22:19:14 0/7/7/0 0/0/0/0
Проверка сведений таблицы маршрутов
Цель
Убедитесь, что таблица маршрутов содержит маршруты IBGP.
Действий
В рабочем режиме введите show route команду.
user@A> show route
inet.0: 12 destinations, 38 routes (12 active, 0 holddown, 10 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.10.0/30 *[Direct/0] 22:22:03
> via fe-0/0/0.1
[BGP/170] 22:20:55, MED 2, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 3, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
10.10.10.1/32 *[Local/0] 22:22:03
Local via fe-0/0/0.1
10.10.10.4/30 *[OSPF/10] 22:21:13, metric 2
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 4, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
10.10.10.8/30 *[Direct/0] 22:22:03
> via fe-0/0/1.3
[BGP/170] 22:20:51, MED 2, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 3, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
10.10.10.9/32 *[Local/0] 22:22:03
Local via fe-0/0/1.3
10.10.10.12/30 *[OSPF/10] 22:21:08, metric 2
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 4, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.163.6.4/32 *[OSPF/10] 22:21:13, metric 1
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:55, MED 1, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 3, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
192.168.0.1/32 *[OSPF/10] 22:21:08, metric 1
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:51, MED 1, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 3, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.168.5.5/32 *[OSPF/10] 22:21:08, metric 2
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 00:15:24, MED 1, localpref 100, from 192.168.0.1
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 4, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.168.6.5/32 *[Direct/0] 22:22:04
> via lo0.1
[BGP/170] 22:20:51, MED 2, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 2, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.168.40.4/32 *[OSPF/10] 22:21:13, metric 2
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:55, MED 1, localpref 100, from 192.163.6.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 4, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
224.0.0.5/32 *[OSPF/10] 22:22:07, metric 1
MultiRecvПонимание отражателя маршрутов, принадлежашего к двум различным кластерам
Цель отражения маршрутов – предотвращение петель, когда BGP (IBGP) устройства маршрутов не являются полностью сетными. Для этого RS нарушают одно из правил обычной BGP работы: Они меняют маршруты, которые были наружу узел BGP другим внутренним BGP равноправным узлам.
Обычно один RR является членом только одного кластера. Рассмотрим, например, что в иерархической структуре RR RR уровня 2 может быть клиентом RR уровня 1, но не может быть клиентами друг друга.
Однако когда два RS являются клиентами друг друга и маршруты отражаются между кластерами, в список кластеров включается только один из этих кластеров. Это потому, что наличие одного кластерного ID в списке кластеров в данном случае является достаточным для предотвращения петель.
Табл. 1 суммирует правила, которые отражатели маршрутов используют при заполнении отраженного списка кластеров маршрутов с помощью кластерных ID.
Сценарий отражения маршрутов |
Конфигурации |
|---|---|
Отражение маршрута от одного из клиентов к нестандартного маршрутизатору клиент -> RR ->-клиент |
RR заполняет кластерный ID, связанный с этим клиентом, в список кластеров отраженного маршрута. |
Отражение маршрута от нестандартного маршрутизатора к клиентского маршрутизатору нестандартный RR -> RR -> клиент |
RR заполняет кластерный ID, связанный с этим клиентом, в список кластеров отраженного маршрута. |
Отражение маршрута от клиентского маршрутизатора к другому клиентский маршрутизатору, который находится в другом кластере client1 - > RR -> client2 (другой кластер) |
RR заполняет кластерный ID, связанный с client1, в список кластеров, прежде чем отражать этот кластерный ID клиенту2. Кластерный ID, связанный с клиентом 2, не добавляется. |
При отражении маршрута от клиентского маршрутизатора к нестандартному маршрутизатору, который находится в другой автономной системе. Например, при настройке яруса 2 RR и 2 BGP групп, одного для клиентов RR и другого для RR уровня 1, отражается маршрут из одной автономной системы в другую автономную систему. клиент -> RR ->-клиент (другая AS) |
RR не заполняет список кластеров кластером-ID до отражения маршрута к не-клиентской устройству, поскольку кластер-ID является специфическим для одной автономной системы. |
См. также
Примере: Настройка отражателя маршрутов, принадлежаного двум различным кластерам
В данном примере показано, как настраивать отражатели маршрутов (RS), принадлежащие к двум различным кластерам. Это не обычный сценарий, но в некоторых ситуациях может оказаться полезным.
Требования
Настройте интерфейсы устройств и внутренний протокол шлюза (IGP). Пример настройки RR, который включает интерфейс и IGP, см. пример: Настройка отражателя маршрутов.
Обзор
В данном примере устройство RR1 является отражателем маршрутов устройств R2 и устройств RR2. На отражателя маршрутов RR1 назначены два разных кластерных ID: один из них - 5.5.5.5 для RR1-R2 и 6.6.6.6 для RR1-RR2.
Устройство RR2 является рефентом маршрутов для устройства R4.
Рассмотрим Рис. 5 рисунок.
В этом примере показана BGP конфигурации устройств RR1 и Device RR2.
Конфигурации
Процедуры
интерфейс командной строки быстрой конфигурации
Чтобы быстро настроить этот пример, скопировать следующие команды, ввести их в текстовый файл, удалить все разрывы строки, изменить все данные, необходимые для настройки сети, а затем скопировать и вкопировать команды в интерфейс командной строки на [edit] иерархии.
Устройство RR1
set protocols bgp group RR1_client type internal set protocols bgp group RR1_client local-address 192.168.20.1 set protocols bgp group RR1_client cluster 5.5.5.5 set protocols bgp group RR1_client neighbor 192.168.48.1 set protocols bgp group Non_client type internal set protocols bgp group Non_client local-address 192.168.20.1 set protocols bgp group Non_client neighbor 192.168.16.1 set protocols bgp group RR1_to_RR2 type internal set protocols bgp group RR1_to_RR2 local-address 192.168.20.1 set protocols bgp group RR1_to_RR2 cluster 6.6.6.6 set protocols bgp group RR1_to_RR2 neighbor 192.168.40.1
Устройство RR2
set protocols bgp group RR2_client type internal set protocols bgp group RR2_client local-address 192.168.40.1 set protocols bgp group RR2_client cluster 7.7.7.7 set protocols bgp group RR2_client neighbor 192.168.32.1 set protocols bgp group RR2_to_RR1 type internal set protocols bgp group RR2_to_RR1 local-address 192.168.40.1 set protocols bgp group RR2_to_RR1 neighbor 192.168.20.1
Настройка устройства RR1
Пошаговая процедура
В следующем примере необходимо провести различные уровни в иерархии конфигурации. Для получения информации о навигации по интерфейс командной строки см. использование редактора интерфейс командной строки в режиме конфигурации в руководстве Junos OS интерфейс командной строки пользователя.
Для настройки устройства RR1:
Настройте равноправные отношения с устройством R2.
[edit protocols bgp group RR1_client] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set cluster 5.5.5.5 user@RR1# set neighbor 192.168.48.1
Настройте равноправные отношения с устройством R0.
[edit protocols bgp group Non_client] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set neighbor 192.168.16.1
Настройте равноправные отношения с устройством RR2.
[edit protocols bgp group RR1_to_RR2] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set cluster 6.6.6.6 user@RR1# set neighbor 192.168.40.1
Результаты
В режиме конфигурации подтвердите конфигурацию, введите show protocols команду. Если в выходных данных не отображается указанная конфигурация, повторите инструкции, показанные в данном примере, чтобы исправить конфигурацию.
user@RR1# show protocols
bgp {
group RR1_client {
type internal;
local-address 192.168.20.1;
cluster 5.5.5.5;
neighbor 192.168.48.1;
}
group Non_client {
type internal;
local-address 192.168.20.1;
neighbor 192.168.16.1;
}
group RR1_to_RR2 {
type internal;
local-address 192.168.20.1;
cluster 6.6.6.6;
neighbor 192.168.40.1;
}
}
После настройки устройства войдите в commit режим конфигурации.
Настройка устройства RR2
Пошаговая процедура
В следующем примере необходимо провести различные уровни в иерархии конфигурации. Для получения информации о навигации по интерфейс командной строки см. использование редактора интерфейс командной строки в режиме конфигурации в руководстве Junos OS интерфейс командной строки пользователя.
Для настройки устройства RR2:
Настройте равноправные отношения с устройством R4.
[edit protocols bgp group RR2_client] user@RR2# set type internal user@RR2# set local-address 192.168.40.1 user@RR2# set cluster 7.7.7.7 user@RR2# set neighbor 192.168.32.1
Настройте равноправные отношения с устройством RR1.
[edit protocols bgp group RR2_to_RR1] user@RR2# set type internal user@RR2# set local-address 192.168.40.1 user@RR2# set neighbor 192.168.20.1
Результаты
В режиме конфигурации подтвердите конфигурацию, введите show protocols команду. Если в выходных данных не отображается указанная конфигурация, повторите инструкции, показанные в данном примере, чтобы исправить конфигурацию.
user@RR2# show protocols
bgp {
group RR2_client {
type internal;
local-address 192.168.40.1;
cluster 7.7.7.7;
neighbor 192.168.32.1;
}
group RR2_to_RR1 {
type internal;
local-address 192.168.40.1;
neighbor 192.168.20.1;
}
}
После настройки устройства войдите в commit режим конфигурации.
Проверки
Подтвердим, что конфигурация работает правильно.
- Проверка кластерного ID, объявленного для маршрута 2.2.2.2
- Проверка кластерного ID, объявленного для маршрута 1.1.1.1
Проверка кластерного ID, объявленного для маршрута 2.2.2.2
Цель
Проверьте, BGP ли BGP на настроенных интерфейсах и что BGP сеанс установлен для каждого адреса соседа.
Действий
В рабочем режиме введите show route advertising-protocol bgp neighbor-address команду.
user@RR1> show route advertising-protocol bgp 192.168.40.1 active-path 2.2.2.2 extensive
inet.0: 61 destinations, 61 routes (60 active, 0 holddown, 1 hidden)
* 2.2.2.2/32 (1 entry, 1 announced)
BGP group RR1_to_RR2 type Internal
Nexthop: 192.168.48.1
Localpref: 100
AS path: [100] I
Cluster ID: 5.5.5.5
Originator ID: 192.168.48.1
Смысл
Маршрут 2.2.2.2/32 исходит от одноранговых клиентов устройства RR1, Device R2. Когда этот маршрут отправляется клиенту RR1, устройству RR2, к маршруту подключен ID кластера 5.5.5.5, который является кластерным ID для RR1-R2.
Проверка кластерного ID, объявленного для маршрута 1.1.1.1
Цель
Проверьте объявление маршрута от Устройства RR1 к устройству RR2.
Действий
В рабочем режиме введите show route advertising-protocol bgp neighbor-address команду.
user@RR1> show route advertising-protocol bgp 192.168.40.1 active-path 1.1.1.1/32 extensive
inet.0: 61 destinations, 61 routes (60 active, 0 holddown, 1 hidden)
* 1.1.1.1/32 (1 entry, 1 announced)
BGP group RR1_to_RR2 type Internal
Nexthop: 192.168.16.1
Localpref: 100
AS path: [100] I
Cluster ID: 6.6.6.6
Originator ID: 192.168.16.1Смысл
Маршрут 1.1.1.1/32 исходит от не-клиентского одноранговых устройств Device RR1, Device R0. Когда этот маршрут отправляется клиенту RR1, устройству RR2, к маршруту подключен ID кластера 6.6.6.6, который является кластерным ID для RR1-RR2.
Устройство RR1 сохраняет ID входящие кластеры от устройства RR2 при объявлении другому клиенту в другом кластере (устройство R4).
Понимание BGP отражения маршрутов
Можно настроить BGP отражения маршрутов (BGP-ORR) IS-IS и OSPF как протокол внутреннего шлюза (IGP) на отражателя маршрутов для объявления оптимального пути для BGP-ORR-групп клиентов. Это делается с использованием самой IGP метрики с точки зрения клиента, а не представления отражателя маршрутов.
Группы клиентов, которые имеют ту же или IGP топологию, могут быть сгрупп узел BGP группы. Можно настроить для optimal-route-reflection BGP-ORR в узел BGP группы. Можно также настроить один из клиентских узлов в качестве основного узла () в узел BGP группе, чтобы метрика IGP от этого основного узла была использована для выбора лучшего пути и объявления ее клиентам в одной igp-primary узел BGP группы. Дополнительно можно также выбрать другой клиентский узел в качестве резервного узла (), который используется, когда основной узел () отстает или igp-backupigp-primary недостижим.
Чтобы включить BGP-ORR, включим утверждение optimal-route-reflection на уровне edit protocols bgp group group-name иерархии []
BGP-ORR работает, только когда IGP используется для BGP маршрутов. BGP-ORR не работает, если для разрешения маршрута используется MPLSLDP/RSVP.
Чтобы BGP-ORR, префикс BGP разрешаем через IGP. В обычных сценариях VPN уровня 3, VPN уровня 2, или VPLS, или MVPN, или EVPN, префиксы разрешаются через inet.3. В inet.3 основным маршрутом для протокола следующего перехода префикса будет RSVP или LDP (а не IGP протокол, например IS-IS или OSPF). Чтобы BGP-ORR, необходимо настроить маршрутизатор на использование inet.0 для разрешения маршрутов на уровне 3 VPN, или на уровне 2 VPN, или VPLS, или MVPN, или префиксов EVPN. Это можно сделать с помощью следующих команд:
Для префикса VPN 3-го уровня:
user@host# set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0
Для VPN уровня 2 или префикса VPLS:
user@host# set routing-options resolution rib bgp.l2vpn.0 resolution-ribs inet.0
Префикс EVPN:
user@host# set routing-options resolution rib bgp.evpn.0 resolution-ribs inet.0
Для префикса MVPN:
user@host# set routing-options resolution rib bgp.mvpn.0 resolution-ribs inet.0
Другим способом является утечка IGP маршрутов в inet.3 и сделать их основными маршрутами в inet.3.
Используйте следующую интерфейс командной строки для настройки BGP-ORR:
[edit protocols bgp]
group group-name{
optimal-route-reflection {
igp-primary ipv4-address;
igp-backup ipv4-address;
}
}
См. также
Настройка BGP отражения маршрутов на отражателя маршрутов для объявления оптимального пути
Можно настроить BGP отражения маршрутов (BGP-ORR) IS-IS и OSPF как протокол внутреннего шлюза (IGP) на отражателя маршрутов для объявления оптимального пути для BGP-ORR-групп клиентов. Это делается с использованием самой IGP метрики с точки зрения клиента, а не представления отражателя маршрутов.
Чтобы включить BGP-ORR, включим утверждение optimal-route-reflection на уровне edit protocols bgp group group-name иерархии []
Группы клиентов, которые имеют ту же или IGP топологию, могут быть сгрупп узел BGP группы. Можно настроить для optimal-route-reflection BGP-ORR в узел BGP группы.
Настройка BGP-ORR:
Используйте следующие интерфейс командной строки для отслеживания и устранения неполадок конфигурации для BGP-ORR:
show bgp group- Просмотр основных и резервных конфигураций BGP-ORR.show isis bgp-orr-Просмотр метрики IS-IS BGP-ORR (RIB).show ospf bgp-orr-Просмотр метрики OSPF BGP-ORR (RIB).show ospf route- Просмотр записей в OSPF маршрутовshow route— Просмотр активных записей в таблицах маршрутов.show route advertising protocol bgp peer- Убедитесь, что маршруты объявляются в соответствии с BGP-ORR.
См. также
Обзор BGP маршрутизатора
Сервер BGP маршрутов является внешним эквивалентом BGP (EBGP) внутреннего отражателя маршрутов IBGP (IBGP), который упрощает количество сеансов EBGP, необходимых для прямой точки в сети. Серверы маршрутов EBGP прозрачны с точки зрения распространения BGP так, что маршрут, полученный от сервера маршрутов, содержит набор BGP атрибутов (NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP и Communities), если маршрут получен от одноранговых узла EBGP напрямую подключен.
Как и в IBGP-отражателях маршрутов, сервер маршрутов EBGP подключен к сети вне прямого пути перенаправки между равноправными узлами EBGP с помощью функции сервера маршрутов. Это может быть соединение через прямой физический соединение, или через сети уровня 2, такие как VPLS LAN или EVPN, или через IP-фабрику точельных соединений EBGP, обеспечивая доступность адресов обратной связи равноправных пользователей (типичные в сетях центров обработки данных).
Протокол BGP усовершенствовается, чтобы обеспечить возможность сервера маршрутов со следующими функциональными возможностями, описанными в RFC 7947:
Прозрачность атрибутов для NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP и сообществ.
Управление политикой для клиентов и несколько riBs на сервере маршрутов для смягчения сокрытия путей.
BGP программируемость использует функциональность маршрут-сервер. Расширенный BGP API (API) TOPI) ДЛЯ ФУНКЦИй сервера маршрутов улучшен bgp_route_service.proto следующим образом:
Запрограммировать сервер маршрутов EBGP.
Внедрять маршруты к определенному серверу маршрутов RIB для выборочной рекламы для групп клиентов в клиентских RIBs.
В BGP ASPI включает объект равноправного типа, который идентифицирует отдельные маршруты как bgp_route_service.proto EBGP или IBGP (по умолчанию).
Как правило, функции сервера маршрутов зависят от адрес-семейства, хотя определенная поддержка атрибутов BGP может быть зависит от адреса и семейства (например, AIGP поддерживается только для семейство адресов, помеченных как одноавстные). Функции сервера маршрутов поддерживаются для всех семейок адресов EBGP.
- BGP атрибутов
- Следующий переход
- AS-Path
- Прочие атрибуты
- BGP Route Server Client RIB
- Требования и соображения по политике
BGP атрибутов
Прозрачность атрибутов EBGP [RFC7947] для сервера маршрутов поддерживается изменением нормального распространения BGP маршрута, таким образом, что ни транзитные, ни не транзитивные атрибуты не будут лишены или изменены при распространении маршрутов.
Изменения обычного поведения EBGP контролируются конфигурацией route-server-client интерфейс командной строки конфигурацией. Конфигурация route-server-client интерфейс командной строки на уровне иерархии [] реализует поведение BGP edit protocols bgp group group-name атрибутов.
Сервер маршрутов обеспечивает прозрачность атрибутов для конфигураций EBGP в одном переходе и в несколько переходов. Поэтому конфигурация включает в себя функции сеансов с одним и нескольким
route-server-clientno-nexthop-changeпереходом. Для многоканальных BGP необходимо настроить ключевоеmultihopслово.Конфигурация
route-server-clientможет быть настроена на уровне протокола, группы или соседаedit protocol bgp[] иерархии.Конфигурация
route-server-clientприменима только когда тип группы внешний. Когда конфигурация для внутренних групп, при попытке сфиксировать ошибкуroute-server-clientконфигурации.У
route-server-clientконфигурации нет параметров.В BGP конфигурации применяется обычная
route-server-clientпривилегия доступа.
Атрибуты обрабатываются независимо по отношению к прозрачности атрибутов. Даже если сервер маршрутов не может отправить следующие переходы, они не могут быть обущены сервером маршрутов, другие атрибуты посылаются прозрачным образом, как это применимо для этих атрибутов.
Ниже приводится пример route-server-client конфигурации:
[edit]
protocols {
bgp {
group R0 {
type external;
route-server-client;
family inet {
unicast;
}
peer-as 100;
neighbor 10.0.0.1;
}
}
}
Следующий переход
Атрибут "следующий переход" нельзя изменять, введя самонастройку следующего перехода или иным образом модифицировать следующий переход, если только он не будет явно настроен посредством политики. Сервер маршрутов должен распространять BGP следующих переходов в соответствии со сторонними правилами следующего перехода RFC 4271.
Поведение следующего перехода задано для следующих сценариев маршрут-сервера:
В случае соединения LAN и WAN, когда сервер маршрутизации подключается к равноправным узлам клиента через общую подсеть LAN и WAN, полученные сторонние следующие переходы объявляются сервером маршрутов без модификации, как определено в RFC 4271.
В случае многопротоблокного соединения центра обработки данных, когда сервер маршрутов подключается к равноправным узлам клиента через многозвонное межсетевое подключение, необходимо настроить EBGP с несколькими переключениями, и поведение конфигурации интерфейс командной строки неявно внося в
no-nexthop-changeroute-server-clientконфигурацию. Полученные сторонние следующие переходы объявляются сервером маршрутов без модификации в ответ на дополнительное поведение сторонних пользователей, определенное в RFC 4271.В других случаях, таких, как двухконечные одно-переходные соединения между сервером маршрутизации и равноправными клиентами, для предотвращения объявления следующих переходов используются стандартные процедуры объявления следующего перехода, которые могут быть отклонены BGP равноправными узлами (например, большинство реализаций BGP по умолчанию отклоняет адреса следующих переходов, которые не охватываются адресом подсети в не-многоканальных сеансах.
AS-Path
As-Path нельзя изменять, введя локальный номер AS сервера маршрутов. Настройка интерфейс командной строки для одноранговых участников не подавляет в объявлениях предварительное объявление о номере route-server-client локальной AS. Кроме того, интерфейс командной строки команду интерфейс командной строки для одноранговых пользователей, которые являются клиентами сервера маршрутов, что локализованная AS не отображается в show route advertising-protocol bgp peer объявленных метриках.
Прочие атрибуты
MULTI_EXIT_DISC атрибут (необязательный, не транзитивный) должен распространяться по полученному параметру.
Все атрибуты сообщества, включая сообщества no-advertise, no-export и non-transitive extended, должны распространяться по мере их распространения.
Атрибут «IGP» (AIGP) (необязательный, не транзитивный) должен распространяться после полученного.
Прим.:Junos OS AIGP поддерживается только для BGP-LU-адресов (IPv4 и IPv6).
BGP Route Server Client RIB
RIB для клиента маршрутов — это отдельный вид BGP-RIB, который может содержать маршруты с разными маршрутами с одним и тем же местом назначения, чем другие виды. Клиенты серверов маршрутов через свои группы равноправных пользователей могут связываться с одним индивидуальным клиентом или общим rib.
Чтобы предоставить возможность объявления различных маршрутов различным клиентам для одного назначения, концептуально необходимо разрешить несколько экземпляров выбора пути BGP для одного назначения, но в разных контекстах клиента/группы.
Чтобы реализовать высокоуровневые требования к гибкому контролю политики при выборе пути для клиента/группы, BGP сервер маршрутов использует подход, не пересылающий экземпляры маршрутов (NFIs) для много экземпляров конвейера BGP, включая BGP пути, Loc-RIB и политику. Сервер маршрутов конфигурирован для группировать клиентов сервера маршрутов в BGP, настроенных в рамках отдельных экземпляров маршрутов, не переадварующихся. Этот подход использует тот факт, что BGP экземпляре маршрутов делает выбор пути и имеет RIB, отделенный от BGP, запущенных в других экземплярах маршрутов.
Требования и соображения по политике
Для распространения маршрутов между клиентами сервера маршрутов происходит утечка маршрутов между riBs экземпляров маршрутов на основе настроенных политик.
Конфигурация сервера маршрутов для управления политикой включает в себя следующие факторы:
Клиенты сервера маршрутов должны быть настроены в пределах одного и того же основного экземпляра или экземпляра маршрутов для получения одинакового представления Loc-RIB.
Клиенты сервера маршрутов должны быть настроены в пределах своих собственных экземпляров маршрутов для получения абсолютно уникальных представлений Loc-RIB.
Клиенты серверов маршрутов должны быть настроены в различных узел BGP в одной экземпляре маршрутов, чтобы иметь другую экспортную политику на одном представлении Loc-RIB.
Для получения всеми маршрутами из других таблиц по умолчанию настроенных для клиента маршрутов RIB будет настроена полноявая
instance-importinstance-anyполитика. При настройке сinstance-importпомощью политики,instance-anyсодержащей:instance-anyможет использоваться в:policy-statement ... term ... frompolicy-statement ... frompolicy-statement ... term ... topolicy-statement ... to
instance-anyне имеет параметров.Использование
instance-anyдругих политикinstance-importне оказывает никакого эффекта.
Настройка многих отдельных экземпляров маршрутов и групп равноправных пользователей влияет на масштаб и производительность.
Конфигурация BGP интерфейс командной строки на уровне иерархии [ ] разбивет экземпляр маршрутки на BGP соседа на экземпляр конфигурации и экземпляр
forwarding-contextedit protocols bgp group neighborпереададации. Конфигурация BGP интерфейс командной строки также поддерживает экземпляр без переадстройки BGP равноправных узлах, настроенных так, как если бы указанный экземпляр был любым экземпляром, способным перенаправить основной экземпляр, или экземпляром маршрутов, который не типаforwarding-contextroute-server-clientno-forwarding.