[GTER] RES: RES: BGP - como trabalhar anuncios p/ ASN com quem eu não faço peering?

[Eduardo Meyer]

bom dia srs

2011/2/10 Antonio Carlos Pina <antoniocarlospina at gmail.com>:
> E é um sonho que dificilmente você verá implementado na ALOG ;-), e o motivo é simples: gestão da qualidade.
>
> Suponha que um de nossos links esteja com 70% de utilização e você resolva manipular as comunidades para que todo seu trafego entre por este link. Suponha que dezenas de clientes façam o mesmo e esse link chegue a 90%...todos os clientes do datacenter poderão ser afetados por esta decisão.

pina obrigado por apontar, mas me indique por gentileza onde eu estou
errando a ideia...

a partir do momento que voces repassam uma community especifica minha,
liberando somente meu asn de origem para usa-la, as manipulacoes que
eu poderei fazer são associadas a aquelas que eu ja faco pra voces,
prepend por exemplo, e nada alem disso ja que localpref, como o nome
sugere, fica local...

então se eu mandar prepend modificado, ele será, claro, um prepend de
degradação de caminho, tendo como consequência a diminuição de
qualquer possível gargalo, dada diminuição de do best path bgp, não o
aumento de demanda...

lembrando que eu não quero repasse dos meus anuncios aos seus
upstreams diretos mas exclusivamente aos seus neighbors de transito, e
referente a rotas de transito, o que faz com que meu primeiro pedido
naquele chamado, que voces tenham uma community pra identificar seus
vizinhos de transito, como tem a ctbc que enviou (ou tentou) a
politica pra lista, e tantos outros, torna-se mais um quesito de
seguranca pra voce, pois voce pode montar o "route map" pro meu pedido
garantindo que o repasse da minha community se de apenas a sua
community de transit peers;

a intenção do meu pedido não é dar preferencia a alog, ao contrário, é
degrada-la, para alguns circuitos, onde eu eventualmente possa ter
caminhos "não tão bons" mas "mais baratos"...

mas voltando ao ponto, ainda que isso fosse um limite técnico, que no
meu entender não é, e ainda que eu realmente pudesse realmente saturar
qualquer circuito seu com esse pedido, o que eu não posso pois por
padrão te envio meus anuncios "com qualidade maxima" (sem prepend e
demais quesitos decisão RDE zerados), a única mudança que eu posso
querer que voce repasse a um peer específico é diferente dessa, no
entanto, qualquer coisa diferente do "melhor que posso" é "um pouco
pior do que posso"...

portanto tecnicamente já não vejo como o que eu pedir influenciar de
forma negativa no seu transito, no sentido de aumento de throughput,
mas ainda que fosse possível, esse pedido é um pedido entre eu,
cliente, e voces, portanto se houvesse limitação técnica ela poderia
ser facilmente sanada em um acordo comercial onde eu me comprometeria
a não repassar anuncios que não fossem de degradação de bgp as-path; é
desnecessário ja que tecnicamente isso pode ser garantido, mas uma
segurança adicional a voces, estamos dispostos; não quero isso como
política "genérica" sem que vocês homologuem e tenham certeza funcione
pra todos da mesma forma, técnica.

ja que o pessoal da ctbc ta de olho, deem uma lida com carinho, pq
assim que meu comercial liberar o mesmo pedido sera feito...

voltando ao ponto técnico, pina, prepend como o nome sugere, não
permite (mais uma vez me informem se eu estiver errado) que eu diminua
meu ou seu ASN no as-path, permite apenas que eu "append", ou seja se
seu link upstream estiver gargalado e sua engenharia decidir degradar
ele, eu não vou poder "melhorar" sou vou poder fazer mais prepend
ainda...

e no mais, sua engenharia pode me usar de cliente-homologacao pra ter
certeza que tao politica não seria danosa... a não ser talvez pro seu
comercial, ja que minha intenção como eu disse é de degradação do
circuito, não melhoria, mas o cliente tem seu direito de usar o
contratado, e evitar gargalar o circuito, por melhor q seja ele,
escolhendo caminhos "nao tao bons" so que mais baratos...

aguardo considerações

>
> Banda é um recurso finito e deve ser gerido no interesse de todos os clientes.

oba!

um motivo a mais pra deixar eu degradar meu proprio as-path pra todos
seus peers: economizar a banda da alog ;-)

>
> Abs
>
> Enviado via ALOG Hosted Exchange Mobile
>
> Em 10/02/2011, às 19:26, Eduardo Meyer <dudu.meyer at gmail.com> escreveu:
>
>> 2011/2/10 Antonio Carlos Pina <antoniocarlospina at gmail.com>:
>>> Olá Eduardo,
>>>
>>> A ALOG implementa somente blackhole e no-export, o que não impede que uma necessidade sua seja avaliada e implementada.
>>>
>>> Se houver um chamado aberto no suporte, posso solicitar a Engenharia de Redes que verifique.
>>>
>>> Grato.
>>
>> Pina,
>>
>> agradeço muito, pedi pro meu supervisor solicitar junto a engenharia,
>> na ALOG o ticket é o AT174402, caso queira acompanhar; fiz 2 pedidos
>> básicos e um outro que é meu sonho:
>>
>> 1) Aceite da comunidade MEU_ASN:10013
>>    - Repassar aos upstream providers e aos demais peers com quem a
>> ALOG se interconecta todos os anuncios marcados com essa comunidade,
>> dessa forma eu, MEU_ASN, poderei tomar decisões de roteamento quanto
>> aos neighbors ALOG acerca do ASN que me pertence.
>>
>> Achei adequado colar aqui esse trecho pra alimentarmos a discussão ;-)
>>
>>>
>>>
>>>
>>> On 09/02/2011, at 20:11, Eduardo Meyer <dudu.meyer at gmail.com> wrote:
>>>
>>>> 2011/2/9 Rubens Kuhl <rubensk at gmail.com>:
>>>>> 2011/2/9 Rubens Kuhl <rubensk at gmail.com>:
>>>>>> O no-export também é uma community, mas é uma well-known-community e
>>>>>> que costuma estar ligada por default. As communities de controle de
>>>>>> propagação não são padronizadas, mas são bem mais versáteis desde que
>>>>>> implantadas, aceitadas e divulgadas pela operadora.
>>>>>
>>>>> Hummm... parece que os erros de Português crescem com o passar das
>>>>> horas... melhor parar por aqui.
>>>>
>>>> Senhores,
>>>>
>>>> Agradeço as opiniões, os demais assuntos em que a conversa ramificou
>>>> são elucidativos e bom pro histórico.
>>>>
>>>> Infelizmente então meu problema não é só meu, e além de trabalhar com
>>>> anúncios de CIDR mais específicos e menos específicos eu não tenho
>>>> muito o que fazer pra alguém quem eu não seja vizinho.
>>>>
>>>> Infelizmente a teoria por trás de communities é bonita mas a realidade
>>>> com as operadoras que eu trato é triste. E não são das menores...
>>>>
>>>> Já tentei pedir pra GLX, TIWS, OI, CTBC, e parece que falo grego ou
>>>> algo tão complexo que nem chega na engenharia. O problema deve ser
>>>> comer$$$ial.
>>>>
>>>> Outra coisa, ativei ALOG aparentemente participantes do PTT que
>>>> estejam também na alog preferem chegar a mim via alog. Não importa
>>>> como eu anuncio, com quantos prepend eu coloque, quão específico seja
>>>> meu anúncio comparado com o PTT, os cidadãos que oferecem looking
>>>> glass consigo ver localpref escolhendo ALOG ao invés do PTT. Outros
>>>> que n oferecem LG não consigo ver nada.
>>>>
>>>> O fato do PTT ser mais barato pra mim não parece importar pro mundo.
>>>> Por mais que eu tente hehe.
>>>>
>>>> E com a ALOG até agora nem consegui lista de communities, nem as
>>>> basicas, tipo "é neighbor ou não é" sabe? Community booleana, hehehe.
>>>> Ou estou sem moral e desinformado ou sei la o que acontece.
>>>>
>>>> Meu comercial deve ta negociando um modelo de transito que funciona
>>>> assim: "olha vai ser mais barato mas você só vai falar com estagiários
>>>> ou com a URA".
>>>>
>>>> Pra saída pelo menos eu me viro, faço policy via firewall. Mas pra
>>>> entrada ta dificil alguem respeitar meus mais profundos (e os
>>>> superficiais tbm) desejos de roteamento hhehehe.
>>>>
>>>>
>>>>
>>>> --
>>>> ===========
>>>> Eduardo Meyer
>>>> pessoal: dudu.meyer at gmail.com
>>>> profissional: ddm.farmaciap at saude.gov.br
>>>> --
>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>
>>
>>
>>
>> --
>> ===========
>> Eduardo Meyer
>> pessoal: dudu.meyer at gmail.com
>> profissional: ddm.farmaciap at saude.gov.br
>



-- 
===========
Eduardo Meyer
pessoal: dudu.meyer at gmail.com
profissional: ddm.farmaciap at saude.gov.br