[GTER] Quagga , BGP - Lookup

[Rinaldo Vaz]

Agradeço a participação de todos...

Vou deixar mais claro:


1- não tenho como utilizar iGP pois os meus peers estão atrás de outro
sistema autônomo:

2- com mikrotik resolvo fazendo assim: */routing filter add
action=passtrought chain=ebgp-in set-target-scopte=40*


o cenário como nesse exemplo:

minha sessão eBGP

neighbor 10.0.0.1 remote-as 123


minha sessão iBGP:

neighbor 20.0.0.1 remote-as "meu-as"


O que acontece é que a rede 20.0.0.0/30 não está diretamente conectada,
recebo essa rede de 10.0.0.1

*
*
*
*
*router> sh ip bgp 20.0.0.0/30*
*BGP routing table entry for **20.0.0.0/30*
*Paths: (1 available, best #1, table Default-IP-Routing-Table)*
*  Advertised to non peer-group peers:*
*  x.x.x.x*
*  123*
*    10.0.0.1 from 10.0.0.1 (1.1.1.1)*
*      Origin IGP, localpref 100, valid, external, best*
*      **Last update: Wed Oct  5 14:16:42 2011*



Consigo assim fechar uma sessão BGP sem problemas com 20.0.0.1, porém, as
rotas que eu recebo de 20.0.0.1 não sobem na minha tabela, e quando verifico
no ZEBRA, a rota está com o nexthop (20.0.0.1) "unrecheable", então quando
adiciono no zebra uma rota estática : ip route 20.0.0.1 255.255.255.255
10.0.0.1 funciona normal.

Como havia dito, no mikrotik eu resolvo esse problema sem a nececidade de
inserir rotas estáticas, apenas aumento o "target scope" das rotas, há
alguma configuração equivalente  no quagga/cisco?


Abs


Em 6 de outubro de 2011 06:41, Renato Frederick
<renato at frederick.eti.br>escreveu:

> Rinaldo,
>
> Já experimentou com o openbgpd?
>
> Acredito que esta configuração poderia ajudar:
>
>
>   nexthop qualify via (bgp|default)
>             If set to bgp, bgpd(8) may use BGP routes to verify nexthops.
> If
>             set to default, bgpd may use the default route to verify nex-
>             thops.  By default bgpd will only use static routes or routes
>             added by other routing daemons like ospfd(8).
>
> Tem alguém discutindo algo aqui[1] sobre isto, apesar de ser sobre
> default-route, é parecido com seu caso
>
> [1] http://kerneltrap.org/mailarchive/openbsd-misc/2007/10/29/366974
>
> Infelizmente não sei te ajudar com o quagga, mas talvez exista algo assim
> nele.
>
> > -----Original Message-----
> > From: gter-bounces at eng.registro.br [mailto:gter-bounces at eng.registro.br]
> > On Behalf Of Rinaldo Vaz
> > Sent: quarta-feira, 5 de outubro de 2011 18:15
> > To: Grupo de Trabalho de Engenharia e Operacao de Redes
> > Subject: Re: [GTER] Quagga , BGP - Lookup
> >
> > "mas, por supuesto, o next-hop não deve ser um dos seus vizinhos
> > alcançáveis?"
> >
> > Nem sempre,
> >
> > No meu caso, estabeleço sessões BGP com peers que estão a vários saltos
> de
> > distância, e que o endereço IP desses peers são aprendidos através de
> outro
> > peer BGP (esse sim está diretamente conectado).
> >
> > O quagga não levanta essa rota na minha tabela pois o zebra considera ela
> > como inalcançável. Meu palpite é de que seja alguma config no zebra, mas
> se
> > eu fosse bom de palpites nao estaria pedindo ajuda =D
> >
> > Abs,
> >
> > Em 5 de outubro de 2011 18:15, Rinaldo Vaz
> > <rinaldo.anid at gmail.com>escreveu:
> >
> > > "mas, por supuesto, o next-hop não deve ser um dos seus vizinhos
> > > alcançáveis?"
> > >
> > > Nem sempre,
> > >
> > > No meu caso, estabeleço sessões BGP com peers que estão a vários
> > > saltos de distância, e que o endereço IP desses peers são aprendidos
> > > através de outro peer BGP (esse sim está diretamente conectado).
> > >
> > > O quagga não levanta essa rota na minha tabela pois o zebra considera
> > > ela como inalcançável. Meu palpite é de que seja alguma config no
> > > zebra, mas se eu fosse bom de palpites nao estaria pedindo ajuda =D
> > >
> > > Abs,
> > >
> > >
> > >
> > > Em 5 de outubro de 2011 17:38, Danton Nunes
> > <danton.nunes at inexo.com.br>escreveu:
> > >
> > > On Wed, 5 Oct 2011, Rinaldo Vaz wrote:
> > >>
> > >>  quando recebo por BGP uma rota cujo next-hop também é recebido por
> > >> BGP
> > >>> essa
> > >>> rede fica inacessível, e só funciona quando adiciono uma rota
> > >>> estática para a rede desse next-hop.
> > >>>
> > >>
> > >> mas, por supuesto, o next-hop não deve ser um dos seus vizinhos
> > >> alcançáveis?
> > >> --
> > >> gter list
> >
> https://eng.registro.br/**mailman/listinfo/gter<
> https://eng.registro.br/mail
> > man/listinfo/gter>
> > >>
> > >
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>