Bom dia,
So vi essa mensagem agora, o que da pra notar de imediato é:
flags destination gateway lpref med aspath origin
xxxx:xxx::/32 xxxx:xxx:1::2 100 0 99999 i
Falta o *, ou seja o BGP considera sua rota invalida, e por isso ele nem tentou
de fato colocar na FIB, so existe a entrada na RIB do daemon. Voce precisa
investigar pq essa rota é invalida, comece dando “sh rib det” nela. Verifique
com “bgpctl sh int” se a interface da qual essa entrada depende esta ok, veja
com “sh next” se o nexthop do qual a rota depende é valido, veja se voce esta
diretamente conectado ao next hop ou se existe uma rota estatica. Se pra chegar
no proximo hop existe dependência de outra rota BGP ou de outro daemon (OSPF)
isso é considerado rota frágil e por default no OpenBGP é invalida, ou vc
corrige e torna a rota não frágil (ie, estática) ou no bgpd.conf aceitar rotas
frageis vindas do BGP, ie, "nexthop qualify via bgp”.
Esses sao os motivos mais óbvios que tornam uma rota não valida. Se bater e não
nenhum desses casos cola as saídas dos comandos pra gente acompanhar.
> On 29/03/2016, at 00:25, Fabricio Lima <em...@fabriciolima.com.br> wrote:
>
> Ricardo,
>
> joga isso na lista GTER [1]...
> pode ser ate algum bug de versao. eles podem ajudar.
> aqui vai ter um publico menor (bgp6).
>
> eu ja levantei bgp6 e mesmo assim sou um complete inutil pra te ajudar...
>
> os caras la comem com farinha bgp, e ipv6 eh o ketchup no pirao pra eles.
>
> 1-Grupo de Trabalho de Engenharia e Operacao de Redes <g...@eng.registro.br>
>
> abs
>
> [ ]'s
> Fabricio Lima
> +64 021 088-12688
> *This email uses 100% recycled electrons*
>
> 2016-03-23 1:21 GMT+13:00 Ricardo B. Volpato <ricardobvolp...@yahoo.com.br>:
>
>> Pessoal, detalhe... acatei a dica do Tales, se eu adicionar a rota
>> xxxx:xxx::/32 com gateway xxxx:xxx:1::2, consigo pingar o IP
>> xxxx:xxx:1:1::
>>
>> -----Mensagem original-----
>> De: freebsd [mailto:freebsd-boun...@fug.com.br] Em nome de Ricardo B.
>> Volpato
>> Enviada em: segunda-feira, 21 de março de 2016 18:14
>> Para: freebsd@fug.com.br
>> Assunto: [FUG-BR] FreeBSD + OpenBGP + IPv6
>>
>> Saudações pessoal da lista.
>>
>>
>>
>> Trabalho em um provedor e estamos tentando subir uma sessão BGP ipv6 com
>> uma
>> das operadoras de transito IP que utilizamos atualmente, para iniciarmos os
>> testes com esse novo protocolo.
>>
>> Temos as sessões IPv4, com duas operadoras e mais um iBGP, funcionando
>> normalmente nesse roteador.
>>
>> Vamos ao cenário.
>>
>> Roteador de Borda FreeBSD 9.3-Stable, o IP configurado na placa de rede WAN
>> é um /127 (por opção da operadora).
>>
>> Os IP´s estão configurados corretamente, pois um roteador pinga o outro
>> normalmente.
>>
>>
>>
>> Segue o arquivo bgpd.conf
>>
>> Peer_asn= "99999"
>>
>> v6_peer = "xxxx:xxx:1::2"
>>
>> v6_local = "xxxx:xxx:1::3"
>>
>> holdtime 90
>>
>> holdtime min 3
>>
>> fib-update yes
>>
>> log updates
>>
>>
>>
>>
>>
>> network yyyy:yyyy::/32
>>
>>
>>
>> group "v6" {
>>
>> remote-as $Peer_asn
>>
>> announce all
>>
>> neighbor $v6_peer {
>>
>> local-address $v6_local
>>
>> # announce IPv6 unicast
>>
>> # announce IPv4 none
>>
>> descr "CUA_v6"
>>
>> set nexthop self
>>
>> }
>>
>> }
>>
>>
>>
>> deny to $v6_peer
>>
>> allow to $v6_peer prefix yyyy:yyyy::/32 prefixlen = 32
>>
>>
>>
>> Com a configuração acima, a sessão BGP é estabelecida, eu recebo o anuncio
>> da operadora e a operadora recebe o meu anuncio.
>>
>> Seguem os resultados de alguns comandos:
>>
>>
>>
>> [root@router01 /usr/local/etc]# bgpctl show nei CUA_v6
>>
>> BGP neighbor is xxxx:xxx:1::2, remote AS 99999
>>
>> Description: CUA_v6
>>
>> BGP version 4, remote router-id 123
>>
>> BGP state = Established, up for 01:02:04
>>
>> Last read 00:00:23, holdtime 90s, keepalive interval 30s
>>
>> Neighbor capabilities:
>>
>> Multiprotocol extensions: IPv6 unicast
>>
>> Route Refresh
>>
>> Graceful Restart
>>
>> 4-byte AS numbers
>>
>>
>>
>> Message statistics:
>>
>> Sent Received
>>
>> Opens 2 2
>>
>> Notifications 1 0
>>
>> Updates 5 4
>>
>> Keepalives 272 292
>>
>> Route Refresh 0 0
>>
>> Total 280 298
>>
>>
>>
>> Update statistics:
>>
>> Sent Received
>>
>> Updates 8 1
>>
>> Withdraws 0 0
>>
>> End-of-Rib 1 1
>>
>>
>>
>> Local host: xxxx:xxx:1::3, Local port: 59434
>>
>> Remote host: xxxx:xxx:1::2, Remote port: 179
>>
>>
>>
>> [root@router01 /usr/local/etc]# bgpctl show rib nei CUA_v6 out
>>
>> flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale
>>
>> origin: i = IGP, e = EGP, ? = Incomplete
>>
>>
>>
>> flags destination gateway lpref med aspath origin
>>
>> AI*> yyyy:yyyy::/32 :: 100 0 i
>>
>>
>>
>> [root@router01 /usr/local/etc]# bgpctl show rib nei CUA_v6 in
>>
>> flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale
>>
>> origin: i = IGP, e = EGP, ? = Incomplete
>>
>>
>>
>> flags destination gateway lpref med aspath origin
>>
>> xxxx:xxx::/32 xxxx:xxx:1::2 100 0 99999 i
>>
>>
>>
>>
>>
>> Lembrando que como a sessão é somente de teste por enquanto, eles estão me
>> enviando somente um bloco /32, para teste.
>>
>> O ponto que me chamou a atenção é no resultado do comando “bgpctl show rib
>> nei CUA_v6 in”, onde a rota recebida não possui nenhuma flag.
>>
>>
>>
>> O ping para o endereço IP de Loopback do roteador da operadora, mostra o
>> seguinte:
>>
>> [root@router01 /usr/local/etc]# ping6 xxxx:xxx:1:1::
>>
>> ping6: UDP connect: No route to host
>>
>>
>>
>> A interface que está conectada fisicamente ao roteador da operadora é a
>> igb0.
>>
>> Vejam que a fib possui as seguintes rotas instaladas:
>>
>> [root@router01 /usr/local/etc]# bgpctl show fib inet6
>>
>> flags: * = valid, B = BGP, C = Connected, S = Static
>>
>> N = BGP Nexthop reachable via this route
>>
>> r = reject route, b = blackhole route
>>
>>
>>
>> flags prio destination gateway
>>
>> *S r 48 ::/96 ::1
>>
>> *C 0 ::1/128 link#0
>>
>> *C 48 ::1/128 link#10
>>
>> *S r 48 ::ffff:0.0.0.0/96 ::1
>>
>> *C 48 2804:ef4:1::3/127 link#1
>>
>> *C 48 fe80:1::/64 link#1
>>
>> C 48 fe80:4::/64 link#4
>>
>> *C 48 fe80:5::/64 link#5
>>
>> *S r 48 fe80:a::/10 ::1
>>
>> *C 48 fe80:a::/64 link#10
>>
>> *C 48 fe80:a::1/128 link#10
>>
>> *C 48 fe80:a::7686:7aff:fefa:4460/128 link#10
>>
>> *C 48 fe80:a::7686:7aff:fefa:4461/128 link#10
>>
>> *C 48 fe80:a::92e2:baff:fe4b:824/128 link#10
>>
>> *C 48 fe80:a::92e2:baff:fe4b:825/128 link#10
>>
>> *C 48 fe80:a::92e2:baff:fe4b:825/128 link#10
>>
>> *C 48 fe80:b::/64 link#11
>>
>> *C 48 fe80:c::/64 link#12
>>
>> * 48 ff01:1::/32 fe80:1::92e2:baff:fe4b:824
>>
>> * 48 ff01:4::/32 fe80:4::7686:7aff:fefa:4460
>>
>> * 48 ff01:5::/32 fe80:5::7686:7aff:fefa:4461
>>
>> * 48 ff01:a::/32 ::1
>>
>> * 48 ff01:b::/32 fe80:b::92e2:baff:fe4b:825
>>
>> * 48 ff01:c::/32 fe80:c::92e2:baff:fe4b:825
>>
>> *S r 48 ff02::/16 ::1
>>
>> * 48 ff02:1::/32 fe80:1::92e2:baff:fe4b:824
>>
>> * 48 ff02:4::/32 fe80:4::7686:7aff:fefa:4460
>>
>> * 48 ff02:5::/32 fe80:5::7686:7aff:fefa:4461
>>
>> * 48 ff02:a::/32 ::1
>>
>> * 48 ff02:b::/32 fe80:b::92e2:baff:fe4b:825
>>
>> * 48 ff02:c::/32 fe80:c::92e2:baff:fe4b:825
>>
>>
>>
>> Alguém poderia analisar o caso e sugerir alguma mudança na configuração do
>> roteador ou do OpenBGP?
>>
>> Já desabilitei os filtros, alterei o tipo de anuncio e mesmo assim o
>> trafego
>> não flui.
>>
>>
>>
>> Qual será o motivo pelo qual o OpenBGP não está conseguindo instalar a rota
>> na FIB?
>>
>>
>>
>> Att.
>>
>> Ricardo
>>
>> Skype: ricardobvolpato
>>
>> -------------------------
>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>
>> -------------------------
>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
--
Patrick Tracanelli
FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316...@sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
