[FUG-BR] Falha roteamento x vlan
Matheus Cucoloto
matheuscucoloto em gmail.com
Quarta Fevereiro 1 17:20:23 BRST 2017
Pois é Paulo, eu participei dessa thread que você comentou, na verdade abri
novamente essa discussão imaginando que alguém conseguiu evoluir (ou se
realmente é um problema, pode ser cagada minha tb.).
Não tenho affinity no cenário, analisando os contadores não vejo
necessidade de fazer isso, mas como estou no escuro vou fazer e esperar por
resultados melhores.
2017-02-01 15:55 GMT-02:00 Paulo Henrique <paulo.rddck em bsd.com.br>:
> Em 1 de fevereiro de 2017 14:35, Matheus Cucoloto <
> matheuscucoloto em gmail.com
> > escreveu:
>
> > Srs. mais um ambiente e o mesmo dilema, só reiniciando para voltar ao
> > normal.
> > Imagino que seja algum cache, buffer algo do gênero porque é muito
> > aleatório.
> >
> > O 172.16.10.242 esta diretamente conectado através da vlan. Porém os
> > pacotes ao invés de obedecerem a tabela de roteamento usando a rota mais
> > especifica 172.16.10.240/30 esta usando o gw padrão.
> >
> > Estou sem ROUTETABLES e sem MROUTING no kernel.
> >
> > E o pior, até pacotes para ele mesmo esta escapando para o gw padrão
> > (observem abaixo no tcpdump a seqüência icmp 6 e 15 escapando para o
> > default).
> >
> > Dessa vez consegui ser mais detalhista vejam as infos abaixo. Alguem aqui
> > já passou por isso?
> >
> > root em bgp:/etc # traceroute -n 172.16.10.242
> >
> > traceroute to 172.16.10.242 (172.16.10.242), 64 hops max, 40 byte packets
> >
> > 1 200.183.24.33 10.010 ms 9.918 ms 9.921 ms
> >
> > 2 204.246.244.62 10.050 ms 10.068 ms 10.038 ms
> >
> > 3 64.208.27.170 9.937 ms
> >
> > 64.208.27.158 22.572 ms 12.972 ms
> >
> > 4 149.3.181.103 39.617 ms 10.897 ms 11.053 ms
> >
> > 5 209.197.25.165 14.013 ms * 13.587 ms
> >
> > 6 200.150.1.69 13.378 ms 13.590 ms 13.800 ms
> >
> > 7 127.0.0.1 13.452 ms 13.666 ms 13.640 ms
> >
> > 8 172.16.10.242 14.131 ms 12.778 ms 14.210 ms
> >
> > root em bgp:/etc # route -n get 172.16.10.242
> >
> > route to: 172.16.10.242
> >
> > destination: 172.16.10.240
> >
> > mask: 255.255.255.252
> >
> > fib: 0
> >
> > interface: vlan2010
> >
> > flags: <UP,DONE,PINNED>
> >
> > recvpipe sendpipe ssthresh rtt,msec mtu weight expire
> >
> > 0 0 0 0 1500 1 0
> >
> > root em bgp:/etc #
> >
> > root em bgp:/etc # ifconfig vlan2010
> >
> > vlan2010: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0
> mtu
> > 1500
> >
> > options=3<RXCSUM,TXCSUM>
> >
> > ether 0c:c4:7a:11:0c:13
> >
> > inet6 fe80::ec4:7aff:fe11:c13%vlan2010 prefixlen 64 scopeid 0x7
> >
> > inet 172.16.10.241 netmask 0xfffffffc broadcast 172.16.10.243
> >
> > nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
> >
> > media: Ethernet autoselect (1000baseT <full-duplex>)
> >
> > status: active
> >
> > vlan: 2010 parent interface: em0
> >
> > root em bgp:/etc #
> >
> > root em bgp:/etc # uname -a
> >
> > FreeBSD bgp 10.3-STABLE FreeBSD 10.3-STABLE #3 r312885: Fri Jan 27
> 14:09:44
> > BRST 2017 matheus em bgp:/usr/obj/usr/src/sys/BGP amd64
> >
> > root em bgp:/etc #
> >
> >
> >
> >
> > root em bgp:/usr/local/etc # tcpdump -npi ix0 host 172.16.10.241
> >
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> >
> > listening on ix0, link-type EN10MB (Ethernet), capture size 65535 bytes
> >
> > 14:27:51.216338 IP 192.168.10.1 > 172.16.10.241: ICMP echo request, id
> > 47897, seq 6, length 64
> >
> > 14:28:00.224323 IP 192.168.10.1 > 172.16.10.241: ICMP echo request, id
> > 47897, seq 15, length 64
> >
> >
> >
> >
> > $ ping -S 192.168.10.1 172.16.10.241
> >
> > PING 172.16.10.241 (172.16.10.241) from 172.16.10.241: 56 data bytes
> >
> > 64 bytes from 172.16.10.241: icmp_seq=0 ttl=63 time=1.009 ms
> >
> > 64 bytes from 172.16.10.241: icmp_seq=1 ttl=63 time=0.134 ms
> >
> > 64 bytes from 172.16.10.241: icmp_seq=2 ttl=63 time=0.129 ms
> >
> > 64 bytes from 172.16.10.241: icmp_seq=3 ttl=63 time=0.182 ms
> >
> > 64 bytes from 172.16.10.241: icmp_seq=4 ttl=63 time=0.158 ms
> >
> > 64 bytes from 172.16.10.241: icmp_seq=5 ttl=63 time=0.132 ms
> >
> > 64 bytes from 172.16.10.241: icmp_seq=6 ttl=63 time=13.533 ms
> >
> > 64 bytes from 172.16.10.241: icmp_seq=7 ttl=63 time=0.258 ms
> >
> > 64 bytes from 172.16.10.241: icmp_seq=8 ttl=63 time=0.152 ms
> >
> > 64 bytes from 172.16.10.241: icmp_seq=9 ttl=63 time=0.153 ms
> >
> > 64 bytes from 172.16.10.241: icmp_seq=10 ttl=63 time=0.186 ms
> >
> > 64 bytes from 172.16.10.241: icmp_seq=11 ttl=63 time=0.109 ms
> >
> > 64 bytes from 172.16.10.241: icmp_seq=12 ttl=63 time=0.329 ms
> >
> > 64 bytes from 172.16.10.241: icmp_seq=13 ttl=63 time=0.139 ms
> >
> > 64 bytes from 172.16.10.241: icmp_seq=14 ttl=63 time=0.843 ms
> >
> > 64 bytes from 172.16.10.241: icmp_seq=15 ttl=63 time=13.576 ms
> >
> >
> >
> >
> > --
> > -----------------------------------------------
> > Matheus Cucoloto
> > -------------------------
> > Histórico: http://www.fug.com.br/historico/html/freebsd/
> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> >
>
> O Marcelo Gondin teve um problema parecido e apos 2 anos apanhando
> descobriu que o problema estava em configurações legadas de IRQ Affinity.
> De uma busca no historico de 2016 durante o mes de Maio/Junho que foi
> quando ele descobriu o problema.
> Na thread há inumeras discussões quanto ao problema de roteamento sobre
> vlan que ele estava sofrendo.
>
> Att. Paulo henrique.
>
> --
> :UNI><BSD:
> Paulo Henrique.
> Fone: (21) 37089388.
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
--
-----------------------------------------------
Matheus Cucoloto
Mais detalhes sobre a lista de discussão freebsd