[GTER] Problema com OSPF Multihop

Rinaldo Vaz rinaldo at anid.com.br
Wed Jun 12 16:22:15 -03 2013


>O que o Samyr precisa, não é iBGP. É eBGP.

Julião,
Confesso que ainda tenho duvidas se entendi a necessidade dele rs.

Pelo que entendi, A recebe o link de internet e D fornece trânsito para
algum cliente (que não aparece no exemplo). Se for isso mesmo é um iBGP que
vai fazer o router A conhecer as rotas aprendidas pelo router D e
anuncia-las para internet.

Caso não hajam clientes (AS Pŕoprio) estabelecendo BGP com router D a
solução é muito mais simples que todas:

Solução: Router A distribuir rota padrão via OSPF e nada mais. e o BGP só
estar ativo em router A

*mikrotik at routerA>* /routing ospf instance set
distribute-default=always-as-type-2

De qualquer forma "*multihop" *não de aplica à esse caso.

É importante lembrar que MPLS não substitui o OSPF (endendam IGP qualquer),
pois esse depende totalmente que haja conectividade IP entre todos os
routers da nuvem que precisa ser garantida pelo OSPF, ISIS, EIGRP, RIP ou
ROTEAMENTO ESTÁTICO



Abs





Em 12 de junho de 2013 10:35, Juliao Braga <juliao at braga.eti.br> escreveu:

> Rinaldo,
>
> O que o Samyr precisa, não é iBGP. É eBGP.
>
> A par de algumas informações, tais como, localização física do A e D, o
> problema dele é resolvido, no cenário atual, como o Bruno recomendou
> (deixando passar apenas a rota default). E, não há necessidade de
> injetar as rotas anunciadas, no OSPF.
>
> Mas a sua recomendação do MPLS, em minha opinião pessoal é extremamente
> importante, principalmente se os provedores pensarem na substituição do
> OSPF (apesar de não ser necessário, exceto pela eficiência). MPLS é
> usado no mundo todo, por pequenos médios e grandes provedores. Além
> disto, numa implementação simples já entrega uma série de facilidades
> que torna o tráfego na topologia interna muito mais eficiente do que o
> OSPF, imagino. Se for uma implementação corajosa, com RSVP, os recursos
> são impactantes, o que compensa o esforço da complexidade, que envolve a
> Engenharia de Tráfego, cujo exercício, o administrador do provedor só
> tem a ganhar.
>
> []s, Julião
>
> Em 12/06/2013 00:57, Rinaldo Vaz escreveu:
> > Samyr,
> >
> > O multihop não existe em sessões iBGP. Apesar de vc poder marcar essa
> opção
> > ela não tem absolutame nenhuma influência.
> >
> > Apenas eBGP utilizan de fato o recurso multihop e suas variáveis são
> > ajustar o TTL para oferecer uma "certa" segurança em virtude de
> tentativas
> > spoofadas de estabelecer eBGP com você.
> >
> > OSPF+multihop na prática só seria aplicável se você falasse OSPF com seu
> > fornecedor de link (eBGP) no lado WAN, coisa muito pouco provável que
> > aconteça um dia.
> >
> > Em resumo, next hops recursivos no iBGP são uma preocupaçao do OSPF e a
> > funcão multihop simplesmente não tem funcionalidade quando uma sessão é
> > iBGP (embora você consiga habilitar essa opção no mikrotik)
> >
> > Abs
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
Rinaldo Vaz
Chefe de operações do NOC
Associação Nacional para Inclusão Digital
Tim - 083 99975736
INOC - 28135*100

*********************************************************
Dias 13,14,15,16 e 17 de maio de 2013
Curso Avançado na sede da ANID em João Pessoa-PB
anid.com.br/cursobgp
*********************************************************



More information about the gter mailing list