| 1 |
On dim. 26 mars 12:49:44 2017, Andrew Savchenko wrote: |
| 2 |
> Run tcpdump -w on both sides. Compare dumps when connection stalls |
| 3 |
> and when it works fine. Many reasons are possible, it's hard to |
| 4 |
> guess from data you provided. |
| 5 |
|
| 6 |
I did this, I saw many neighbor solicitation on pokedex’s side (the |
| 7 |
lossy side) when the loss happens. I’ve also included some monitoring |
| 8 |
packets, but they didn’t match the loss window time. However, they are |
| 9 |
flapping accordingly to the loss in the monitoring web interface. |
| 10 |
|
| 11 |
https://bulbizarre.swordarmor.fr/garbage/documents/argall.pcap |
| 12 |
https://bulbizarre.swordarmor.fr/garbage/documents/pokedex.pcap |
| 13 |
|
| 14 |
> But it makes me wonder why you have default via VPN and given |
| 15 |
> address via eth0. This may lead to undesirable consequences like |
| 16 |
> VPN carrier (or some aux request) trying to go through its own VPN |
| 17 |
> tunnel. |
| 18 |
|
| 19 |
The only goal is to reach the server from its two public addresses. As |
| 20 |
each provider is doing BCP38, I have to set up multiple routing tables |
| 21 |
to make the traffic flows to the correct interface based on the source |
| 22 |
address. |
| 23 |
|
| 24 |
> Best regards, |
| 25 |
> Andrew Savchenko |
| 26 |
|
| 27 |
Regards, |
| 28 |
|
| 29 |
-- |
| 30 |
alarig |
Archives