[GTER] BGP - Embratel - Filtros ???

Rubens Kuhl Jr. rubensk at gmail.com
Mon Dec 29 10:49:32 -02 2008


Considerando que a maioria dos clientes BGP são AS terminais e com um
único bloco CIDR, não é difícil *mesmo em escala* colocar um AS-Path
padrão (número-do-AS ancorado à esquerda e à direita) e um prefix-list
padrão com o bloco CIDR do cliente admitindo prefixos mais longos até
/24. E assim como há um procedimento operacional para inclusão de
novos AS-Path, esse mesmo procedimento pode cobrir a possibilidade de
algo ligeiramente fora do padrão (um segundo bloco CIDR etc.).

Isso também não tem efeitos sob convergência, pois o processamento das
mensagens de UPDATE de BGP fica até menos carregado ao se descartar
mensagens que no final não iam mesmo gerar mudança de topologia.



Rubens



2008/12/29 jimmi <jimmi at netpoint.com.br>:
> Sergio.
>
> Para carriers é inviável controlar o aprendizado de rotas de seus AS
> Customers por prefix lists (CIDR). Esta política é de difícil manutenção
> quando se pensa em escala, e sugere degradação em cenários como
> convergências. Geralmente esta finalidade é atendida com o uso de as-path
> acls.
>
> A tarefa de evitar leakings e spoofings é tranqüila para clientes sem
> roteamento dinâmico.
>
> De clientes AS é diferente e é intuitivo e demandado pela circunstância que
> estes respondam com competência pelas políticas de roteamento de seus AS,
> o que freqüentemente não se encontra; ainda mais quando estes se tornam
> multi-homed.
>
> At.
>
> Jimmi.
>
>
> ---------- Original Message -----------
> From: "Sergio Ferreira ( WGO )" <sergio at wgo.com.br>
> To: "'Grupo de Trabalho de Engenharia e Operacao de Redes'"
> <gter at eng.registro.br>
> Sent: Sun, 28 Dec 2008 20:58:32 -0200
> Subject: [GTER] BGP - Embratel - Filtros ???
>
>> Estava ajudando um colega com um BGP e notei que a Embratel estava
> aceitando
>> qualquer coisa que ele anunciava para ela.
>>
>> Ele tinha uma rota estática das redes da Microsoft MSN e Hotmail
>> forçando a saída via Embratel. E em um determinado momento ele
>> ativou o redistribute-static, as rotas estáticas foram anunciadas
>> para a Embratel, ela aceitou e passou pra frente.
>>
>> No meu provedor :
>>
>> wgocisco#sh ip bgp 207.68.160.0/19
>> BGP routing table entry for 207.68.160.0/19, version 3775
>> Paths: (2 available, best #2, table Default-IP-Routing-Table)
>>   Advertised to non peer-group peers:
>>   200.241.239.149
>>   4230 28xxx
>>     200.241.239.149 from 200.241.239.149 (200.230.224.194)
>>       Origin incomplete, localpref 100, valid, external
>>
>> =========================================
>>
>> Na RNP
>>
>> RNP - Looking Glass - show bgp 207.68.160.0/19
>> ________________________________________
>> Router: Rio de Janeiro, RJ
>> Command: show route protocol bgp 207.68.160.0/19 terse exact
>> inet.0: 272678 destinations, 293079 routes (43793 active, 20
>> holddown, 240296 hidden) @ = Routing Use Only, # = Forwarding Use
>> Only + = Active Route, - = Last Active, * = Both A Destination
>>  P Prf   Metric 1   Metric 2  Next hop        AS path *
>> 207.68.160.0/19    B 170        100          0 >200.143.253.174 4230
>> 28xxx ?                     B 170        100          0
>> >200.143.252.21  4230 28xxx ?                     B 170        100
>>        0 >200.143.252.25  4230 28xxx ?
>>                    200.143.252.21
>>
>> Não deveria ter filtros na Embratel para evitar isso ?
>>
>> []s
>>
>> Sérgio Ferreira
>> WGO Telecom
>>
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
> ------- End of Original Message -------
>
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



More information about the gter mailing list