Obrigado @Sebastian por me colocar no caminho certo. Eu queria acompanhar isso com o que aprendi / implementado até agora com um único EX3200 em um laboratório. Esta é uma configuração de trabalho.
O único bit que estou perdendo das minhas solicitações originais foi como a alta disponibilidade funcionará para o gateway padrão na conexão BGP - mas acho que o iBGP vai se encaixar nessa conta.
Eu poderia adicionar outra instância de roteamento para imitar um segundo switch - depois, executar um tronco físico entre as interfaces atribuídas a cada instância. Em seguida, abra o eBGP e o iBGP em ambos.
Eu configurei duas instâncias de roteamento para isolar as duas redes (IPs de PA e IPs de BGP) e gateways.
vlan.10 e vlan.20 serviram como uplinks do BGP, vlan.3999 é para os / 22 IPs que estamos anunciando sobre o nosso ASN.
vlan.30 é um / 24 de espaço PA existente - com uma rota estática para o gateway principal em vlan.40
Você pode ver que a instância do BGP foi configurada especificamente nessa instância de roteamento - portanto, ela não é compartilhada entre a outra tabela de roteamento.
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;
}
}
}
}
Assim, as vlans foram atribuídas da seguinte forma
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;
}
}
Em seguida, para certificar-se de que os dois links BGP foram preferidos (caso um deles falhe), as políticas foram configuradas para alterar o local-preference . Uma política também foi criada para exportar rotas específicas para serem anunciadas pelo 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;
}
}
}
}
Neste ponto - tudo estava perfeito e ambas as tabelas de roteamento trabalhavam em harmonia - mas completamente isoladas. Ie. não havia rotas compartilhadas / vazadas entre si. Por isso, configurei um encaminhamento baseado em filtro para permitir que as rotas sejam distribuídas.
Primeiro, usei um filtro de entrada na interface 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;
}
}
}
}
Que usaram as seguintes regras de firewall
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;
}
}
}
}
}