[GTER] Dúvidas design iBGP

[Douglas Fischer]

Justamente.

no iBGP(em especial com RouteReflector) o teu roteador, seja ele qual for,
vai saber que a melhor rota para aquele destino(externo) é através da
loopback daquele outro roteador.

Quem vai dizer para o primeiro roteador como chegar ao segundo roteador é o
IGP(eu iria de EIGRP flames > /dev/null), ou rota estática.


Algumas problemas que podem acontecer é quando se usa o next-hop-self mesmo
para peers do seu ASN(ou seja IGP).
Nesse caso, podem surgir muitas lambanças...




Em 19 de março de 2013 18:37, Shine <eshine at gmail.com> escreveu:

> Em tese iBGP não redistribui rotas aprendidas por IGP, assim o full mesh
> não dá nenhum problema de loop. Existem algumas limitações de design devido
> a estas características em algumas topologias.
>
> Rota estática seria uma opção, outra seria usar um outro IGP e redistribuir
> as rotas conectadas (OSPF por exemplo).
>
> Veja que RR não precisa estar na mesma rede, BGP não precisa de adjacência,
> apenas conectividade para fazer o peering. O Loopback tem vantagens pq ele
> nunca cai, ao contrário de um endereço de interface (se a interface cai, o
> endereço some). Como supostamente teremos caminhos diversos entre A,B,C e
> D, usar Loopback parece ser adequado.
>
>
>
> Em 19 de março de 2013 16:37, Discussion List Aggregator <
> dl.lagg0 at gmail.com
> > escreveu:
>
> > Estava analisando o uso de RR pois li/ouvi em algum lugar que o uso de
> full
> > mesh poderia trazer alguns problemas. Um que tive em testes foi que ao
> > fechar um sessão bom B e C o tráfego vindo de A para C estava passando
> por
> > B. Tive que filtrar os anúncios para que B não recebesse as rotas de C
> por
> > A e vice-versa. Pensando agora, isso possa ter acontecido por eu ter a
> > opção "redistribute-other-bgp" do Mikrotik habilitada em A, alguém
> poderia
> > confirmar, pois não compreendi até onde essa opção influencia no iBGP.
> >
> > No caso de usar interfaces de loopback, digamos que a loopback de A seja
> > 172.16.0.1 e de B seja 172.16.1.1. Em A terei que ter uma rota estática
> > para 172.16.1.1 apontando para o IP de B utilizado na comunicação de A e
> > vice-versa?
> >
> >
> > Em 19 de março de 2013 15:48, Shine <eshine at gmail.com> escreveu:
> >
> > > Na sua escala atual, não vejo muita vantagem em usar RR. Se "A" cai,
> > então
> > > todo seu BGP vai pro espaço, independente se é RR ou não.
> > >
> > > Em se pensar no agora, full mesh entre todos os 4 roteadores não é
> > absurdo,
> > > acho que ainda é mais simples do que criar um RR.
> > > Quando escalar, aí pensamos em migrar para RR e ter ao menos um par de
> RR
> > > para efeitos de contingência.
> > >
> > > Considere usar interfaces Loopbacks no iBGP, assim vc não fica na
> > > dependência da interface real para contingência.
> > >
> > >
> > >
> > > Em 19 de março de 2013 15:12, Discussion List Aggregator <
> > > dl.lagg0 at gmail.com
> > > > escreveu:
> > >
> > > > Boa tarde Senhores,
> > > >
> > > > Estou estudando como melhorar a comunicação entre meus roteadores.
> > > > Atualmente tenho 1 roteador (A) de borda que faz eBGP com as
> > operadoras e
> > > > iBGP com outros 3 roteadores (B,C e D) em pontos com maior
> concentração
> > > de
> > > > tráfego. Tenho conexão física entre todos os roteadores, porém em B,C
> > e D
> > > > tenho apenas uma sessão iBGP com A, sendo assim para um cliente de B
> > > chegar
> > > > até um cliente C ele passa por A.
> > > >
> > > > Estive lendo a respeito de design iBGP e, como atualmente são 4
> > > roteadores,
> > > > poderia fazer um full mesh entre eles. Porém pensando em
> escalabilidade
> > > > futura seria melhor partir para Route Reflector.
> > > >
> > > > No caso de route reflector, é possível manter a mesma estrutura
> usando
> > A
> > > > como route reflector? No cenário atual cada sessão iBGP está em uma
> > vlan
> > > > com rede /30, é necessário mudar todos para a mesma vlan e rede para
> o
> > > > tráfego de B para C vá direto?
> > > > --
> > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
Douglas Fernando Fischer
Engº de Controle e Automação