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.rd...@bsd.com.br>: > Em 1 de fevereiro de 2017 14:35, Matheus Cucoloto < > matheuscucol...@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@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@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@bgp:/etc # > > > > root@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@bgp:/etc # > > > > root@bgp:/etc # uname -a > > > > FreeBSD bgp 10.3-STABLE FreeBSD 10.3-STABLE #3 r312885: Fri Jan 27 > 14:09:44 > > BRST 2017 matheus@bgp:/usr/obj/usr/src/sys/BGP amd64 > > > > root@bgp:/etc # > > > > > > > > > > root@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 ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
