[GTER] GVT usando RPF?

Tue Apr 8 06:30:45 -03 2014

Pode ser que eu esteja equivocado, mas...

Eu resolveria isso de uma forma talvez mais fácil, dropando o recebimento
de prefixos de clientes de trânsito que estejam no PTT incluindo filtro de
AS-PATH no BGP. O Wildes Oliveira colocou no Facebook (1) um método que ele
testou e está funcionando, através de communities. Não tive tempo de testar
(até por não ter ainda PTT/SP) mas assim que puder o farei.

Att,

(1)
https://www.facebook.com/groups/1385637308374593/permalink/1395873510684306/

Em 7 de abril de 2014 15:15, Douglas Fischer <fischerdouglas at gmail.com>escreveu:

> Me lembro de ter discutido com um colega aqui da lista sobre uma solução
> para isso.
>
> Eu de início não enxerguei uma solução para diferenciar na GVT(ou outra
> operadora), o que vinha do transito deles, e o que vinha de dentro do ASN
> deles mesmos(ou de primeiro salto ASN).
>
> Esse colega(se a memória não e trai, foi o R.Khul) mencionou o caso de uma
> outra operadora que também é ATM onde:
>  - O trafego intra-ASN fica dentro de um MPLS/VRF, e
>  - O que vem de fornecedores de trânsito para essa operadora em outro
> MPLS/VRF
>
>  - Para os PTTs eles entregam as rotas do primeiro MPLS/VRF, e
>  - Para os clientes de trânsito eles entregam as rotas somadas dos dois
> MPLS/VRFs, e fazem isso através de Route-Leaking.
>
> Não sei se é BEEEEEM assim, e nem o nome do santo.
> Mas era algo mais ou menos nesse rumo...
>
>
> Me lembro que fiquei tão boquiaberto com a inteligência na engenharia de
> tráfego que cheguei a montar um lab p/ testar.
>
>
> Em 7 de abril de 2014 15:03, Douglas Fischer <fischerdouglas at gmail.com
> >escreveu:
>
> > Há mais de 2 anos já houve aqui na lista,
> > uma discussão sobre esses impasses técnicos
> > acerca de Provedor de Transito coexistindo no PTT.
> >
> > Vou retomar uma análise que um colega fez e achei extremamente válida.
> > Tomemos a situação que foi citada nessa thread, um ASN conectado ao PTT
> > com trânsito GVT.
> >
> > 1 - Devido a redução de consumo de banda no link de trânsito do cliente
> > dela, ela se dá conta que está entregando praticamente tudo para aquele
> > cliente através do PTT.
> >
> > 2 - Então, para evitar perdas financeiras(redução de contrato) ela
> resolve
> > ativar o RPF(ou algum outro subterfúgio para não entregar o que é
> trânsito
> > pelo PTT.
> >
> > 3 - Com isso, a solução que o ASN em questão tem é solicitar no meu.ptt
> > que seu prefixos não sejam anunciados p/ o seu trânsito.
> >
> > Resultado direto?
> > -----------------
> >  - Os problemas com o RPF da operadora foram resolvidos!
> >
> > Resultado indireto? e provavelmente indesejado...
> > -------------------
> >  - O trafego que é originado no ASN da GVT(ou de primeiro salto ASN), que
> > viria pelo PTT mesmo que o transito desse ASN não fosse GVT passa a vir
> > pelo link de trânsito.
> >  - Dependendo da situação esse tráfego pode ser BEM significativo. Já ví
> > bater 15%.
> >
> >
> >
> > Em 7 de abril de 2014 13:06, Joéster Brondani <
> > contato at joesterbrondani.com.br> escreveu:
> >
> > Eu sempre peço filtros nos ptts para meus transitos e nunca tive maiores
> >> problemas. Mas ate um tempo atraz (nao sei como tah agora), realmente se
> >> anunciasse mais especifico ao ptt-sp por exemplo, a gvt mandava
> transito ip
> >> normal via ptt huehue...
> >>
> >> Em 7/4/2014 12:01, Eduardo Schoedler escreveu:
> >>
> >>  O negócio é abrir chamado no meu.ptt.br para filtrar os seus anúncios
> >>> para
> >>> a GVT.
> >>>
> >>>
> >>> Em 7 de abril de 2014 11:22, Douglas Fischer<fischerdouglas at gmail.com
> >>> >escreveu:
> >>>
> >>>  Creio que o que pode te ajudar nessa questão seria:
> >>>> Anunciar nos dois lados(PTT e Upstream-A e Upstram-Z) os prefixos
> menos
> >>>> específicos(Blocos inteiros).
> >>>>
> >>>> Nem que seja com prepend...
> >>>> Só isso já mata o RPF.
> >>>>
> >>>>
> >>>> Em 7 de abril de 2014 10:26, Lista<lista.gter at gmail.com>  escreveu:
> >>>>
> >>>>  Olá Juliano,
> >>>>>
> >>>>> Realmente ela está fazendo isso, e ja faz algum tempo que vem
> >>>>> implantando
> >>>>> essa questão.
> >>>>>
> >>>>>
> >>>>> Em 4 de abril de 2014 21:10, Juliano Primavesi | KingHost Hospedagem
> de
> >>>>> Sites<juliano at kinghost.com.br>  escreveu:
> >>>>>
> >>>>>  Durante esta semana, identificamos alguns problemas relacionados com
> >>>>>> operadoras com peering com GVT.
> >>>>>>
> >>>>>> Alguns casos que pegamos, solucionaram ao desligarmos o BGP com o
> PTT.
> >>>>>>
> >>>>>> Penso que a GVT possa ter implementado um filtro de RPF Check para
> >>>>>>
> >>>>> evitar
> >>>>
> >>>>> a entrega de "banda grátis" via PTT.
> >>>>>>
> >>>>>> Explico: como a maioria dos provedores utiliza rotas mais
> específicas
> >>>>>>
> >>>>> no
> >>>>
> >>>>> PTT e menos especificas em provedores de Transito, parte do trafego
> de
> >>>>>> entrada de uma operadora que esteja no PTT e não filtre os prefixos
> do
> >>>>>>
> >>>>> AS
> >>>>
> >>>>> cliente de transito, acaba passando pelo PTT ao invés de passar pelo
> >>>>>>
> >>>>> link
> >>>>
> >>>>> comercial.
> >>>>>>
> >>>>>> Uma das soluções é filtrar os prefixos no PTT; outra seria um
> filtro.
> >>>>>>
> >>>>> Como
> >>>>>
> >>>>>> os pacotes de retorno são aparentemente DROPADOS, e não
> redirecionados
> >>>>>>
> >>>>> para
> >>>>>
> >>>>>> outra rota, acredito fortemente em uma regra de RPF, já que o
> controle
> >>>>>>
> >>>>> de
> >>>>
> >>>>> sessões (outra forma de monitorar o que poderia estar passando pelo
> >>>>>>
> >>>>> PTT)
> >>>>
> >>>>> seria quase inviável (hardware).
> >>>>>>
> >>>>>> Entao acredito que se alguém ainda tem problemas com GVT,
> experimente
> >>>>>> anunciar uma rota mais especifica para ela no link comercial, com as
> >>>>>> communities "AS:1 AS:2 AS:3 AS:4 AS:5 AS:6" - já que a GVT não
> >>>>>>
> >>>>> implementa a
> >>>>>
> >>>>>> community no-export (para mim nunca funcionou).
> >>>>>>
> >>>>>> Juliano
> >>>>>>
> >>>>>> --
> >>>>>> 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
> >>>> --
> >>>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>>
> >>>>
> >>>
> >>>
> >> --
> >> This message has been scanned for viruses and
> >> dangerous content by MailScanner, and is
> >> believed to be clean.
> >>
> >>
> >> --
> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>
> >
> >
> >
> > --
> > Douglas Fernando Fischer
> > Engº de Controle e Automação
> >
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>