[FUG-BR] RES: RES: FreeBSD + OpenBGP + IPv6

Patrick Tracanelli eksffa em freebsdbrasil.com.br
Sexta Abril 1 11:16:17 BRT 2016


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 <ricardobvolpato em 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:ricardobvolpato em 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 em 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 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
> 
> -------------------------
> 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!"



Mais detalhes sobre a lista de discussão freebsd