[ale] PPP/SSH VPN dies randomly
Christopher Bergeron
christopher at bergeron.com
Mon Mar 4 23:28:07 EST 2002
Too funny...! I was actually "assured" (translation: they're liable) that
our DSL and T1 lines were on different circuits and that the only point of
failure is the Telco Central Office. Soooo, your example below could be
entirely accurate.
After going through all this trouble, I _do_ need to provide at least uptime
during business hours without "periodic" breakage. If 20 people get
disconnected for 10 seconds it's equivalent to about 2 minutes of downtime.
My reasoning is that the VPN has to get re-established, they have to log
back in, get back to the screen they were at, and finally, call me for at
least 1 minute and complain about the "unreliability" of the network since
I've put the VPN in. We moved to the VPN from a $6,000/month dedicated T1
so I have to try to provide something "reasonably" similar in performance
(at least from 9-5).
So starting the VPN in the morning is the solution?
Should I kill it late at night after the backups have run? or should I let
it stay up and if the daily morning start detects that it survived; kill it
and start it back up?
-? CB
> -----Original Message-----
> From: James P. Kinney III [mailto:jkinney at localnetsolutions.com]
> Sent: Monday, March 04, 2002 10:56 PM
> To: Christopher Bergeron
> Cc: Ale
> Subject: RE: [ale] PPP/SSH VPN dies randomly
>
>
> Ahh! That's different. I was having horrible visions of another sys
> admin in a tattered monks robe being tortured by management to perform
> unholy and impossible tasks.
>
> Of course, management may still be like that.
>
> If I were in your situation, I would do exactly as you suggested. While
> the T1 is up (before the A.M. reset) , I would reset the DSL. When it
> has been verified, then reset the T1.
>
> Of course, this does nothing for the hardware between your endpoints.
> The weakest link is the phone pole outside the office that all this data
> hangs from. Waiting for that delivery truck to smack it head on at 40
> mph.
>
> "But Mr. Boss!", the admin pleads as the ropes around his wrists tighten
> again, pulling his shoulders past his ears, his knees creaking as the
> tendons near the separation point, "It wasn't my fault the UPS truck hit
> the pole and took out all communications for 18 seconds. It was
> delivering your new laptop!"
>
> "REPENT WORTHLESS ADMIN!". bellows the crimson robed Boss, who was
> completely unexpected, "Had you been worthy, you would have had the DSL
> backup line on a separate pole at the BACK to avoid just such a
> calamity." The fires from the boiling oil shone ominously in his eyes as
> he ...
>
> On Mon, 2002-03-04 at 22:25, Christopher Bergeron wrote:
> > Okay, lemme rephrase: I'd _like_ to have 99.99999%
> availability. I feel
> > that I can offer at least that between 8am-7pm EST though. I
> have a T1 VPN
> > with a redundant DSL fallover VPN. So basically, I have 2
> pipes between my
> > locations. Should I cron the VPN so that it starts every
> morning at like
> > 7:30 AM? Should I kill it just before then, or at COB? I'd
> like to have
> > the VPN as much as possible during "human" hours in case
> someone works late
> > or gets in early.
> >
> > Our KEY business hours are between 8AM EST and 6PM Central time (roughly
> > 8am-8pm EST).
> >
> > Any suggestions?
> > -CB
> >
> >
> > > -----Original Message-----
> > > From: James P. Kinney III [mailto:jkinney at localnetsolutions.com]
> > > Sent: Monday, March 04, 2002 9:56 PM
> > > To: Christopher Bergeron
> > > Cc: Ale
> > > Subject: RE: [ale] PPP/SSH VPN dies randomly
> > >
> > >
> > > If you're expected to provide 7 nines of VPN reliability, I'm glad I
> > > don't work for your company!
> > >
> > > The only way to get even 99.99% VPM uptime would involve multiple,
> > > redundant, synchronous data lines. I don't want to even think
> about the
> > > engineering costs.
> > >
> > > As most places that have VPN's have them automated for
> connection setup,
> > > use that to your advantage. Keep a connection test running at
> intervals
> > > appropriate to your normal loading. When the connection test fails,
> > > reroute the VPN traffic before the tunneling to a buffered fifo and
> > > remake the connection. Dump the buffer through the connection
> when it's
> > > ready.
> > >
> > > I have never kept a VPN up for days on end. There has always been some
> > > network glitch outside my control that has required a
> reconnect. I saw a
> > > statistic (I need to keep a better log of this stuff) that
> claimed there
> > > is a fiber line cut every day in the US.
> > >
> > > On Mon, 2002-03-04 at 21:43, Christopher Bergeron wrote:
> > > > And this is acceptable? Forgive me for being naive, but that
> > > would be like
> > > > using an Operating System that crashed almost daily and wrote
> > > it off as, "I
> > > > guess that's just how it has to be". By definition there
> has to be a
> > > > "reason" for it and therefore, a solution.
> > > >
> > > > Have you confronted your VPN vendor about it (please say it
> > > wasn't Cisco)?
> > > > If so, what was their response?
> > > >
> > > > I'm currently adding a VPN watchdog to my crontab, but even
> 1 minute of
> > > > downtime per month is a major malfunction. Someone has to have
> > > some clues
> > > > about this. I'm not using IPsec, I'm using SSH over PPP. I
> > > understand that
> > > > encryption can be finicky, but I have a hard time blaming SSH.
> > > I'm expected
> > > > to produce 99.99999% availability and I can't accept anything
> > > less. Call me
> > > > a spoiled Linux user for assuming availability, if you must...
> > > >
> > > > :)
> > > >
> > > > Anyone have any leads or even starting points for debugging this?
> > > >
> > > > Thanks,
> > > > CB
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Geoffrey [mailto:esoteric at 3times25.net]
> > > > > Sent: Monday, March 04, 2002 7:53 PM
> > > > > To: Christopher Bergeron
> > > > > Cc: Ale
> > > > > Subject: Re: [ale] PPP/SSH VPN dies randomly
> > > > >
> > > > >
> > > > > No real help, except to say that this happens to my
> (commercial) vpn
> > > > > connectivity on occasion. It presents an error message
> > > something to the
> > > > > effect of: "heartbeat missed, assuming tunnel is down."
> This is an
> > > > > ipsec vpn.
> > > > >
> > > > > Christopher Bergeron wrote:
> > > > > > Does anyone have any idea why my VPN connection dies
> > > > > periodically? It seems
> > > > > > to be okay for a few days and then one of the procees goes
> > > > > defunct and the
> > > > > > connection goes down. I'm tunneling ssh over ppp over a T1
> > > > > connection to
> > > > > > the 'net on both sides.
> > > > > >
> > > > > > Any clues are greatly appreciated...
> > > > > > -CB
> > > > > >
> > > > > >
> > > > > > ---
> > > > > > This message has been sent through the ALE general
> discussion list.
> > > > > > See http://www.ale.org/mailing-lists.shtml for more info.
> > > > > Problems should be
> > > > > > sent to listmaster at ale dot org.
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Until later: Geoffrey esoteric at 3times25.net
> > > > >
> > > > > I didn't have to buy my radio from a specific company to listen
> > > > > to FM, why doesn't that apply to the Internet (anymore...)?
> > > > >
> > > > >
> > > > > ---
> > > > > This message has been sent through the ALE general
> discussion list.
> > > > > See http://www.ale.org/mailing-lists.shtml for more info.
> > > > > Problems should be
> > > > > sent to listmaster at ale dot org.
> > > > >
> > > >
> > > >
> > > > ---
> > > > This message has been sent through the ALE general discussion list.
> > > > See http://www.ale.org/mailing-lists.shtml for more info.
> > > Problems should be
> > > > sent to listmaster at ale dot org.
> > > >
> > > --
> > > James P. Kinney III \Changing the mobile computing world/
> > > President and COO \ one Linux user /
> > > Local Net Solutions,LLC \ at a time. /
> > > 770-493-8244 \.___________________________./
> > >
> > > GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
> > > <jkinney at localnetsolutions.com>
> > > Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7
> > >
> > >
> > >
> >
> >
> > ---
> > This message has been sent through the ALE general discussion list.
> > See http://www.ale.org/mailing-lists.shtml for more info.
> Problems should be
> > sent to listmaster at ale dot org.
> >
> --
> James P. Kinney III \Changing the mobile computing world/
> President and COO \ one Linux user /
> Local Net Solutions,LLC \ at a time. /
> 770-493-8244 \.___________________________./
>
> GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
> <jkinney at localnetsolutions.com>
> Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7
>
>
>
---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be
sent to listmaster at ale dot org.
More information about the Ale
mailing list