[GTER] Anunciar bloco </24

[Álvaro França - GMAIL]

Anuncia um /23 em uma cidade, /24 na segunda cidade e um /24 na terceira
cidade.

Tudo vai funcionar.

*___*

*Álvaro Araujo França*
*alvaroaraujofranca at gmail.com <alvaroaraujofranca at gmail.com>*
(27) 99776-8825

Em 22 de janeiro de 2018 14:59, Jonni Pianezzer <jhonnyp at deltaativa.com.br>
escreveu:

> simples, o bgp ira descartar por padrao se ver seu proprio asn no as-path,
> entretando tem como voce desativar isso e ele receber as rotas do mesmo
> jeito, um pouco mais arriscado mas podes fazer tbem.
>
> cria uma rota estatica para usas outras duas redes e vice e versa, vc
> tendo seu /24 anuncioado, apos chegar no backbone da sua operadora, vai
> funcionar de boa com rota estaticas tbem,
>
> o maximo que pode te dar é uns falso positivo em caso de queda de algum
> link seu, caso tenha varios. mas é dificil,.
>
> att
>
> JhonnyP
>
>
>
> Em 22/01/2018 13:12, Luis Bueno escreveu:
>
>> Esta terceira região não irá ter conectividade com as outras duas. Como
>> possuem o mesmo ASN, o BGP irá entender como loop e descartar as rotas.
>> Caso não exista interesse de tráfego entre as regiões, pode não ser um
>> problema. Os equipamentos da terceira região serão gerenciados a partir
>> das
>> outras regiões através da Internet?
>>
>> Algumas operadoras de trânsito aceitam anúncios de prefixos menores que
>> /24
>> (como /29), porém apenas para questões de balanceamento de tráfego entre
>> links conectados a ela mesma. Estes certamente serão filtrados e não serão
>> anunciados para terceiros. Então, efetivamente, é necessário alocar um /24
>> inteiro e anunciá-lo nesta nova região.
>>
>> Luis Bueno
>>
>> 2018-01-22 11:28 GMT-02:00 Douglas Fischer <fischerdouglas at gmail.com>:
>>
>> Alternativamente(para dar uma amenizada),
>>> você pode anunciar /22(ou /23) normalmente para cada um desses
>>> upstreams, e
>>> anunciar também /24 com no-export dos blocos preferidos.
>>>
>>> Logicamente, para que consiga fazer isso, tem que estar comprando esse
>>> link
>>> de alguém que proveja um nível mínimo de qualidade e recursos.
>>>
>>>
>>> Em 22 de janeiro de 2018 11:23, Douglas Fischer <
>>> fischerdouglas at gmail.com>
>>> escreveu:
>>>
>>> PERFEITO Danton!
>>>>
>>>> Em 22 de janeiro de 2018 11:06, Danton Nunes <danton.nunes at inexo.com.br
>>>> >
>>>> escreveu:
>>>>
>>>> On Mon, 22 Jan 2018, T Dutra wrote:
>>>>>
>>>>> Dilema: Estamos com um projeto para atender uma terceira região que não
>>>>>
>>>>>> se comunica com as outras duas. Vamos estabelecer um trânsito com
>>>>>>>>>>
>>>>>>>>> uma
>>>
>>>> operadora X.
>>>>>>>>>>
>>>>>>>>>> o problema todo está em "não se comunica com as outras duas". De
>>>>> acordo
>>>>> com a RFC-1930, "An AS is a *CONNECTED* group of one or more IP
>>>>> prefixes
>>>>> run by one or more network operators which has a SINGLE and CLEARLY
>>>>>
>>>> DEFINED
>>>
>>>> routing policy." (*GRIFO* meu). O que você descreve não se encaixa nessa
>>>>> definição.
>>>>>
>>>>> O que vocês acham de anunciar apenas UM /24? Vou sofrer com destinos
>>>>>
>>>>>> inacessíveis? E na falta de um /24, vocês me sugerem algo? Quais as
>>>>>> incosistência em anunciar bloco menor que /24?
>>>>>>
>>>>>> até pode anunciar o /24, ele terá preferência sobre os /23, /22, mas
>>>>> na
>>>>> eventualidade do 'upstream' desse /24 pifar, os pacotes irão para o
>>>>>
>>>> bloco
>>>
>>>> maior que o contém, ou seja, para lugar nenhum. Se o seu sistema
>>>>>
>>>> autônomo
>>>
>>>> fosse conectado no sentido da RFC-1930, qualquer roteador da borda do AS
>>>>> saberia encaminhar o pacote ao seu destino, ainda que dando a volta até
>>>>>
>>>> a
>>>
>>>> China.
>>>>>
>>>>> menor que /24 você corre o risco de ser filtrado e não entrar nas
>>>>>
>>>> tabelas
>>>
>>>> de rotas dos vizinhos e de não ter a rota propagada adiante.
>>>>>
>>>>> se essa terceira região tem só um 'upstream' não é mais negócio usar
>>>>> endereços desse 'upstream' e manter somente uma rota default para ele?
>>>>>
>>>>> -- Danton
>>>>>
>>>>> --
>>>>> 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
>>>
>>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>
>
> ---
> Este email foi escaneado pelo Avast antivírus.
> https://www.avast.com/antivirus
>
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>