[GTER] OpenBGPD escondendo prefixos

[Diogo Montagner]

Não sou especialista em openbgpd mas aqui vai a minha dica (ou loucura
- como queiram).

Uma vez que o código do openbgpd é free, você pode alterar o
comportamento do programa para atender o que você quer. Olhando o
código dele, parece ser bem simples de fazer isto se você domina C e
entende o protocolo BGP. O código é limpo e simples.

Na função path_add o software faz a comparação entre o prefixo atual e
o novo recebido para escolher o "best" para fazer o update na RIB. Se
você alterar este código de modo que ele também inclua o "não-best" na
RIB, eu acredito que você atingirá o que você quer.

Entretanto, você perderá toda e qualquer decisão de roteamento feita
no route-server, e esta função deverá ser feita nos peers. Lembre-se
que os peers deverão suportar o aumento de memória requerido com
relação ao prefixo/next-hop adicional.

Abs
./diogo -montagner



2011/6/16 Christian Lyra <lyra at pop-pr.rnp.br>:
> Caros,
>
> Aproveitando o assunto, solicito a ajuda de quem já mexeu com o
> openbsd com o seguinte cenário:
>
> Estou configurando um route-server (65000) e mais 3 ASs clientes ( 1,
> 2, 3). Os As 2 e 3 fornecem transito para um quarto AS (4). O AS4 por
> sua vez anuncia os seus prefixos com um prepend para o AS3 e sem
> prepend para o AS2. Se o ascii permitir a topologia é essa:
>
>                 RS
> -----------------------------------
> |                 |                |
> AS1          AS2           AS3
>                  |                |
>                  -----------------
>                          |
>                       AS4
>
> Como cada AS anuncia dois prefixos, a tabela de rotas conhecida pelo
> RS é a seguinte:
>
> flags destination          gateway          lpref   med aspath origin
> *>    10.1.0.0/17         x.x.x..91     100     0 1 i
> *>    10.1.128.0/17        x.x.x.x.91     100     0 1 i
> *>    10.2.0.0/17          x.x.x.x.92     100     0 2 i
> *>    10.2.128.0/17        x.x.x.x.92     100     0 2 i
> *>    10.3.0.0/17          x.x.x.x.93     100     0 3 i
> *>    10.3.128.0/17        x.x.x.x.93     100     0 3 i
> *>    10.4.0.0/17          x.x.x.x.92     100     0 2 4 i
> *     10.4.0.0/17          x.x.x.x.93     100     0 3 4 4 i
> *>    10.4.128.0/17        x.x.x.x.92     100     0 2 4 i
> *     10.4.128.0/17        x.x.x.93     100     0 3 4 4 i
>
> Como o BGP por padrão exporta apenas as rotas "best", o AS1 aprende o
> caminho para o AS4 através do AS2, como era de se esperar. A
> configuração do RS nesse cenário é a seguinte:
>
> peer1="x.x.x.91"
> peer2="x.x.x.92"
> peer3="x.x.x.93"
> ASN="65000"
>
> AS $ASN
> router-id x.x.x.99
> fib-update no
> transparent-as yes
> nexthop qualify via bgp
>
> group "RS" {
>        neighbor $peer1 {
>                descr   "AS1"
>                remote-as 1
>                announce all
>        }
>        neighbor $peer2 {
>                descr "AS2"
>                remote-as 2
>                announce all
>        }
>        neighbor $peer3 {
>                descr "AS3"
>                remote-as 3
>                announce all
>        }
> }
>
> match from any set community $ASN:neighbor-as
>
> Ok... até aí tudo bem. Agora vamos complicar um pouco mais o cenário e
> estabelecer que o AS1 não troque mais tráfego com o AS2. Se
> simplesmente aplicarmos um filtro no que é exportado para o AS1 e AS2,
> então o AS1 não vai aprender o caminho para o AS4, porque a rota para
> este AS via AS3 não é best. Essa situação é bem explicada pelo pessoal
> do quagga aqui[1]. Para solucionar esse problema no quagga, foi criado
> a opção de "route server client", que na prática implementa uma tabela
> de roteamento para cada participante. O filtro é aplicado antes dos
> prefixos serem inseridos na tabela do participante, e depois é feita a
> escolha de caminhos.
>
> No BIRD a solução é parecida, mas com um pequeno "plus" que é a
> utilização de um tabelão principal onde *não* é aplicado a seleção de
> rotas. Um exemplo dessa configuração pode ser encontrado em [2].
>
> Estou com dificuldades de implementar uma solução parecida com o
> OpenBGPd. Minha primeira tentativa foi a de simplesmente adicionar a
> opção "route-collector yes" que segundo o manual, faz com que o
> processo de seleção de rotas seja desligada. Imaginei que com isso o
> RS enviasse todas as rotas que ele aprendeu para os peers, mas não foi
> o aconteceu. E ao aplicar os filtros o AS1 não aprendeu o caminho para
> o AS4. A configuração adicionada foi a seguinte:
>
> route-collector yes
> deny to $peer1 community $ASN:2
> deny to $peer2 community $ASN:1
>
> Bom... a segunda tentativa foi a de criar uma tabela de rotas nova, e
> no comando que a cria é possível desligar a seleção de rotas:
>
> rde rib tudo no evaluate
>
> e dentro de cada peer acrescentei "rib tudo". Ao fazer isso descobri
> que se não tem seleção de rotas, então nenhuma rota é exportada (o
> openbpd leva a sério o negócio de só exportar as best!).
>
> Por fim, a última tentativa foi a de criar uma rib para cada
> participante e tentar aplicar o filtro a apenas uma rib. O manual dá a
> entender que:
>
> deny to $peer1 community $ASN:2 rib toAS1
>
> é valido. Mas não é :-(
>
> A documentação do openbgpd segue o padrão "openbsd", ou seja, costuma
> ser boa, mas carece de exemplos. O google não ajudou muito, e
> encontrei apenas alguns poucos exemplos de configuração. Desconfio que
> é possível resolver isso com o recurso de rdomains, mas o manual
> parece indicar esse recurso para outros cenários (vpns).
>
> Enfim... alguem tem alguma idéia? :-)
>
>
> [1] http://www.quagga.net/docs/docs-multi/Description-of-the-Route-Server-model.html
> [2] https://git.nic.cz/redmine/projects/bird/wiki/Route_server_example
>
> p.s. eu teria enviado essa msg para a lista "ptt.br" mas ela não existe :-(
>
> --
> Christian Lyra
> PoP-PR/RNP
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>