Hello,
I've been dealing with a buggy link for a few days and I'm now looking at my
ppp command line options.
ICMP across the tunnel works fine. Any large burst of traffic kills it. On the
wire I'm see TCP retransmissions. I am 99% sure this s a problem one the site's
edge. I'm looking at my options to see if I can fix this without looking at
their equipment.
1. compression disabled
2. Vtun 3.0.1
3. Protocol is TCP
4. All endpoints are on private nets behind firewalls. Port 5000 is NAT'ed to
the vtun server. Endpoint firewalls allow TCP outbound.
5. On successful auth ppp is executed with the following options on client.
/sbin/pppd noipdefault nomagic lcp-echo-interval 30 lcp-echo-failure 2 lock
unit 100
Why lcp? 12 years ago we discovered what I all dumb NAT firewalls. The amount
of traffic on these links can be so low that 60s could pass with not one IP
packet traversing the tunnel. Firewalls would assume the connection is "dead",
remove from their list, and then we had to wait for the 2 hour timeout to hit.
We can also add keepalive to the config.
These tunnels need to be up 24/7 so the kernel is tuned to hit KA every 5
minutes. Those LCP options will kill pppd in 60s. Lowering the
lcp-echo-interval to 20 would increase traffic.
Using tun on my tunnel is not really possible with this setup. It is a complex
config, 100s are connected, and everything is database driven. No mods to vtun.
Only config creation, pppd start, etc.
If I SSH to the device inside the tunnel and execute 'dmesg' the output burst
terminates tunnel. I use trickle -u 20 -d 20 -t 0.1 ssh to assist. On the
remote I have to throttle its traffic so I have a program I run output through
to slow it down. 0.02s/char, Yes, it sucks, and this is just temp so I can fix
this.
One option is to add speed to the config of each tunnel and throttle this one
down. See if that works. Speed is ignored on the client. will it attampt to
burst and the server throttle? If so I may need to start vtun on the remote
with trickle.
To explain complexity,
1. vtund on server accept()s connection and does auth.
2. Instead of pppd it executes program.
3. Program creates command line for real pppd. Executes it on pseduo
4. ip-up/ip-down are called once ip is up on pppd.
5. Those programs look in database for routes.
6. If routes are found the apply them.
7. ip-up/ip-down can actually down another ppp interface with same address.
That interface could be a demand mode ppp interface attached to modem.
Yep, do a ping and kill the network. Ping will pause and then start back, but
latency has grown. This is not used often.
This is where using ppp in vtun works very well.
Thanks,
Chris
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Vtun-Users mailing list
Vtun-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/vtun-users
