[FUG-BR] RES: RES: FreeBSD + OpenBGP + IPv6
Ricardo B. Volpato
ricardobvolpato em yahoo.com.br
Quinta Março 31 08:50:52 BRT 2016
Bom dia, Patrick. Vi a sua resposta somente hoje.
O Next hop está diretamente conectado à interface.
Seguem os resultados dos comandos:
[root em router01 /usr/local/etc]# bgpctl sh rib det xxxx:xxx::/32
BGP routing table entry for xxxx:xxx::/32
99999
Nexthop xxxx:xxx:1::2 (via ???) from CUA_v6 (201.201.201.252)
Origin IGP, metric 0, localpref 100, weight 0, external
Last update: 01w1d18h ago
[root em router01 /usr/local/etc]# bgpctl sh next
Flags: * = nexthop valid
Nexthop Route Prio Gateway Iface
xxxx:xxx:1::2
* 187.187.187.1 187.187.187.1/32 48 187.187.187.81 vlan15 (UP, 1000 Mbps)
* 201.201.201.137 201.201.201.136/30 48 connected igb0 (UP, 1000 Mbps)
Achei bem estranho o resultado do primeiro comando, pelo que me parece, estou recebendo o prefixo v6 através de IPv4. É isso?
A sessão bgp6 está sendo fechada através da interface igb0, onde já temos uma sessão bgp estabelecida.
Reavaliei o arquivo de configuração, tanto na declaração das variáveis, quanto na configuração da sessão v6, não há nada que utilize a variável do peer v4.
Tá estranho!
Agradeço as dicas, aguardo mais algumas instruções, se possível.
Att.
Ricardo
-----Mensagem original-----
De: freebsd [mailto:freebsd-bounces em fug.com.br] Em nome de Patrick Tracanelli
Enviada em: terça-feira, 29 de março de 2016 09:58
Para: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" <freebsd em fug.com.br>
Assunto: Re: [FUG-BR] RES: FreeBSD + OpenBGP + IPv6
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 <email 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
> <gter em 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 <ricardobvolpato em 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-bounces em fug.com.br] Em nome de Ricardo B.
>> Volpato
>> Enviada em: segunda-feira, 21 de março de 2016 18:14
>> Para: freebsd em 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 em 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 em 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 em 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 em 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 em 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
316601 em 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
Mais detalhes sobre a lista de discussão freebsd