[ale] PPP/SSH VPN dies randomly
Jeff Hubbs
hbbs at attbi.com
Mon Mar 4 22:45:09 EST 2002
What are you going to do to keep the CMOS battery alive for that long? ;-)
- Jeff
Jeff Hubbs wrote:
> Chris -
>
> If you're using a normally-configured PC for your VPN node, to get
> seven nines you're looking at one reboot on the order of no more than
> ten years. Linux in BIOS and/or solid-state hard drives are going to
> be mandatory.
> - Jeff
>
> 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.
>>
>>
>
>
>
>
> ---
> 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.
More information about the Ale
mailing list