Ricardo, A saida do “sh next” deixa claro que seu nextshop pra v6 é invalido e incompleto.
A saida do “sh rib det” tambem indica incompleto, veja o “via ???” ao invés do via gw ou porta. Quanto ao IP do from CUA_v6 não se preocupe é apenas o Router-ID, não significa nada alem disso (não é v4 entregando v6 por essa saída). Ou seja precisa agora repassar sua conf e revisar o setup do ambiente mas esta claramente invalido/incompleto pelo diagnostico das 2 saídas. Creio que falta uma rota estática em algum lugar, ou prefixlen esta errado/diferente do esperado. Não sei também se o circuito v6 deveria ser LAN-LAN ou loop, mas o diagnostico é esse, agora é revisar e ajustar. > On 31/03/2016, at 09:31, Ricardo B. Volpato <ricardobvolp...@yahoo.com.br> > wrote: > > Patrick, entrei em contato com a operadora, fizemos alteração do IP da WAN de > /127 para /64 e a sessão subiu e as rotas foram instaladas na FIB normalmente. > O FreeBSD por padrão não permite a utilização de /127 para o bgp ou seria > algo errado ou bug na versão do OpenGBP? > > > -----Mensagem original----- > De: Ricardo B. Volpato [mailto:ricardobvolp...@yahoo.com.br] > Enviada em: quinta-feira, 31 de março de 2016 08:51 > Para: 'Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)' > <freebsd@fug.com.br> > Assunto: RES: [FUG-BR] RES: FreeBSD + OpenBGP + IPv6 > > Bom dia, Patrick. Vi a sua resposta somente hoje. > > O Next hop está diretamente conectado à interface. > Seguem os resultados dos comandos: > [root@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@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-boun...@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@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 <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 > > ------------------------- > 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
