Я новичок в BGP, так что это определенно обучающее упражнение. Я ухожу от пространства PA, предоставленного на 2 маршрутизируемых восходящих каналах, к моему собственному IP-пространству и множеству адресов для моего транзита.
Для начала будет только единый транзитный провайдер - и они предоставили 2 кабельных разветвителя RJ45 с разными / 30 VLAN на каждом - для подключения к каждому из моих коммутаторов Juniper EX3200.
Я намереваюсь использовать только маршруты по умолчанию на данный момент - а пока мне нужно продолжать использовать маршрутизированные восходящие каналы и пространство PA - при сохранении другой таблицы маршрутизации для нового шлюза / сети BGP.
Существует 2 восходящих канала (ge-0/0/0 и ge-0/0/1), на которых находится моя VLAN связующего блока WAN (vlan4000). VRRP работает в этой VLAN, и все мои IP-адреса маршрутизируются от моего провайдера на этот виртуальный IP-адрес. Затем внутренние маршруты проходят напрямую через интерфейсы VLAN L3. IP-адрес шлюза (т.е. виртуальный IP-адрес маршрутизатора моего провайдера) в vlan4000 действует как мой маршрут по умолчанию.
Так что я знаю, что мне, вероятно, потребуется запустить две таблицы маршрутизации (VRF), чтобы отделить IP-адреса BGP от «других» IP-адресов - и, возможно, выполнить пересылку на основе фильтров для выбора правильного шлюза.
Я довольно подробно читал оба,
Для понимания конфигурации требуется.
Исходя из моего (ограниченного) понимания, я думаю, что мне нужно ...
По сути, я не уверен в том, как два EX3200 запускают свои сеансы BGP. Поскольку у каждого есть свои собственные IP-адреса (идентификаторы маршрутизатора) в двух отдельных VLAN - это похоже на два отдельных сеанса BGP - и мне нужно будет условно маршрутизировать между каждым шлюзом по умолчанию BGP, если какой-либо из них выйдет из строя?
У кого-нибудь есть примеры конфигураций, с чего начать?
Коммутаторы EX могут выполнять VRF-Lite для поддержки нескольких таблиц маршрутизации. Для начала вы можете взглянуть на эту статью базы знаний Juniper:
http://kb.juniper.net/InfoCenter/index?page=content&id=KB14926
Что вам нужно, так это поддержка BGP для VRF / виртуального маршрутизатора. Для этого вам потребуется лицензия AFL на коммутаторы EX. Вот таблица функций программного обеспечения для серии EX, которая всегда полезна:
Если вы установили лицензию, вы можете настроить экземпляр маршрутизации и протокол BGP под ним:
routing-instances {
test {
instance-type virtual-router;
protocols {
bgp {
local-as 65565;
}
}
}
Сеансы eBGP (внешний BGP для вашего провайдера) обычно выполняются между интерфейсными IP-адресами. Таким образом, вы настраиваете свой IP-адрес в / 30 на интерфейсе (повторите для второго восходящего канала на другом коммутаторе) и устанавливаете сеанс BGP с IP-адресом маршрутизатора провайдера. Попросите вашего провайдера объявить вам маршрут по умолчанию.
Вы должны подключить два коммутатора и передать между ними протокол iBGP (внутренний BGP), чтобы они оба получали информацию о маршрутизации друг от друга.
Если один исходящий канал не работает или сеанс BGP прерывается, ваш коммутатор автоматически переключится на другой исходящий канал.
Общая информация о BGP на коммутаторах EX находится здесь:
Это всего лишь короткий ответ. Имейте в виду, что маршрутизация BGP - это очень обширная тема, и ее легко нанести ущерб не только вашей сети, но и сети вашего провайдера или, в крайнем случае, даже всему миру. Я бы посоветовал получить профессиональную помощь для начальной настройки.
Спасибо @Sebastian за то, что направил меня на правильный путь. Я хотел продолжить это с помощью того, что я изучил / реализовал на одном EX3200 в лаборатории. Это рабочая конфигурация.
Единственный элемент, который мне не хватает в моих первоначальных запросах, - это то, как высокая доступность будет работать для шлюза по умолчанию в соединении BGP, но я думаю, что iBGP будет соответствовать этим требованиям.
Я мог бы добавить еще один экземпляр маршрутизации, чтобы имитировать второй коммутатор, а затем запустить физическую магистраль между интерфейсами, назначенными каждому экземпляру. Затем запустите eBGP и iBGP на обоих.
Я установил два экземпляра маршрутизации, чтобы изолировать две сети (IP-адреса PA и IP-адреса BGP) и шлюзы.
vlan.10 и vlan.20 служили восходящими линиями BGP, vlan.3999 для IP-адресов / 22, которые мы объявляем через наш ASN.
vlan.30 это существующее / 24 пространства PA - со статическим маршрутом к главному шлюзу на vlan.40
Вы можете видеть, что экземпляр BGP был настроен специально для этого экземпляра маршрутизации, поэтому он не используется совместно с другой таблицей маршрутизации.
routing-instances {
transit-bgp {
instance-type virtual-router;
interface vlan.10;
interface vlan.20;
interface vlan.3999;
routing-options {
router-id x.x.x.50;
autonomous-system xxxxx;
}
protocols {
bgp {
group bgp1 {
type external;
peer-as xxxxx;
neighbor x.x.x.109 {
import import-route-transit1;
export export-route;
}
}
group bgp2 {
type external;
peer-as xxxxx;
neighbor x.x.x.113 {
import import-route-transit2;
export export-route;
}
}
}
}
}
transit-pa {
instance-type virtual-router;
interface vlan.30;
interface vlan.40;
routing-options {
static {
route 0.0.0.0/0 next-hop x.x.x.1;
}
}
}
}
Итак, вланы были назначены следующим образом
vlans {
bgp1 {
vlan-id 10;
l3-interface vlan.10;
}
bgp2 {
vlan-id 20;
l3-interface vlan.20;
}
liveips {
vlan-id 3999;
l3-interface vlan.3999;
}
routedips {
vlan-id 30;
l3-interface vlan.30;
}
routedgw {
vlan-id 40;
l3-interface vlan.40;
}
}
Затем, чтобы убедиться, что двум каналам BGP было отдано предпочтение (если одна из них выйдет из строя), были настроены политики для изменения local-preference. Также была создана политика для экспорта определенных маршрутов, которые будут объявляться через BGP.
policy-options {
policy-statement export-route {
term local-routes {
from {
route-filter x.x.x.0/22 exact;
}
then accept;
}
}
policy-statement import-route-transit1 {
term default {
then {
local-preference 220;
next policy;
}
}
}
policy-statement import-route-transit2 {
term default {
then {
local-preference 200;
next policy;
}
}
}
}
На этом этапе все было идеально, и обе таблицы маршрутизации работали согласованно, но полностью изолированно. Т.е. не было общих / просочившихся маршрутов между собой. Поэтому я настроил пересылку на основе фильтров, чтобы разрешить распределение маршрутов.
Сначала я использовал входной фильтр на vlan интерфейс
interfaces {
vlan {
unit 10 {
family inet {
address x.x.x.110/30;
}
}
unit 20 {
family inet {
address x.x.x.114/30;
}
}
unit 30 {
family inet {
filter {
input transit-pa-int;
}
address x.x.x.50/24;
}
}
unit 30 {
family inet {
address x.x.x.1/24;
}
}
unit 3999 {
family inet {
filter {
input transit-bgp-int;
}
address x.x.x.1/22;
}
}
}
}
Которые использовали следующие правила брандмауэра
firewall {
family inet {
filter transit-pa-int {
term one {
from {
destination-address {
x.x.x.0/22;
}
}
then {
routing-instance transit-bgp;
}
}
term default {
then {
routing-instance transit-pa;
}
}
}
filter transit-bgp-int {
term one {
condition {
destination-address {
x.x.x.0/24;
}
}
then {
routing-instance transit-pa;
}
}
term default {
then {
routing-instance transit-bgp;
}
}
}
}
}