Re: [gentoo-user] Strange IPv6 behaviour

2017-03-28 Thread Alarig Le Lay
On dim. 26 mars 12:49:44 2017, Andrew Savchenko wrote:
> Run tcpdump -w on both sides. Compare dumps when connection stalls
> and when it works fine. Many reasons are possible, it's hard to
> guess from data you provided.

I did this, I saw many neighbor solicitation on pokedex’s side (the
lossy side) when the loss happens. I’ve also included some monitoring
packets, but they didn’t match the loss window time. However, they are
flapping accordingly to the loss in the monitoring web interface.

https://bulbizarre.swordarmor.fr/garbage/documents/argall.pcap
https://bulbizarre.swordarmor.fr/garbage/documents/pokedex.pcap

> But it makes me wonder why you have default via VPN and given
> address via eth0. This may lead to undesirable consequences like
> VPN carrier (or some aux request) trying to go through its own VPN
> tunnel.

The only goal is to reach the server from its two public addresses. As
each provider is doing BCP38, I have to set up multiple routing tables
to make the traffic flows to the correct interface based on the source
address.

> Best regards,
> Andrew Savchenko

Regards,

-- 
alarig


signature.asc
Description: PGP signature


Re: [gentoo-user] Strange IPv6 behaviour

2017-03-26 Thread Andrew Savchenko
On Sat, 25 Mar 2017 12:36:04 +0100 Alarig Le Lay wrote:
> Hi,
> 
> On one of my machines, I have two public IPv6 from two different
> providers (one natively, another by VPN). I use ip -6 rule to make both
> pingable.
> 
> I see some strange things on the native one. It stops responding from
> time to time. Here are some examples of mtr:
> https://paste.swordarmor.fr/raw/mXVT
> 
> At this time, the other IPv6 (bulbizarre.swordarmor.fr) works normally.
> 
> And if I do the same test on another machine in the same LAN, no loss:
> https://paste.swordarmor.fr/raw/XGbK 
> 
> I have this routing table:
> alarig@bulbizarre ~ $ ip -6 rule list 
> 0:from all lookup local 
> 31010:from 2a01:cb08:898c:fc00:9913:b7a:b9bf:d30c lookup 3215 
> 31100:from all lookup 51083 
> 32766:from all lookup main 
> alarig@bulbizarre ~ $ ip -6 route show 
> 2a00:5881:4008:400::/64 dev tun0  proto kernel  metric 256  pref medium
> 2a01:cb08:898c:fc00::/64 dev eth0  proto kernel  metric 4  pref medium
> fe80::/64 dev eth0  proto kernel  metric 256  pref medium
> fe80::/64 dev tun0  proto kernel  metric 256  pref medium
> fe80::/64 dev tun-mysql  proto kernel  metric 256  pref medium
> default via fe80::20d:b9ff:fe3a:1fa1 dev eth0  metric 4  pref medium
> alarig@bulbizarre ~ $ ip -6 route show table 3215
> 2a01:cb08:898c:fc00::/64 dev eth0  metric 1024  pref medium
> default via fe80::20d:b9ff:fe3a:1fa1 dev eth0  metric 1024  pref medium
> alarig@bulbizarre ~ $ ip -6 route show table 51083
> default dev tun0  metric 1024  pref medium
> 
> I’m using the kernel 4.9.16-gentoo.
> 
> I’m running out of ideas, so I ask for your help :)

Run tcpdump -w on both sides. Compare dumps when connection stalls
and when it works fine. Many reasons are possible, it's hard to
guess from data you provided.

But it makes me wonder why you have default via VPN and given
address via eth0. This may lead to undesirable consequences like
VPN carrier (or some aux request) trying to go through its own VPN
tunnel.

Best regards,
Andrew Savchenko


pgp3fIREW1JZ4.pgp
Description: PGP signature


Re: [gentoo-user] Strange IPv6 behaviour

2017-03-25 Thread Alan McKinnon

On 25/03/2017 13:36, Alarig Le Lay wrote:

Hi,

On one of my machines, I have two public IPv6 from two different
providers (one natively, another by VPN). I use ip -6 rule to make both
pingable.

I see some strange things on the native one. It stops responding from
time to time. Here are some examples of mtr:
https://paste.swordarmor.fr/raw/mXVT



Please don't use pastebins here. They go away after a short while, and 
then yur post is useless in the archives to everyone else who finds it 
in the future.


Your pastes are quite small, just attach them to them mail. That way 
they last forever


--
Alan McKinnon
alan.mckin...@gmail.com