[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