Re: [pfSense-discussion] full instalation on 4 GB SSD
Eugen Leitl wrote: I was thinking a real 2.5 SSD would have a MTBF comparable to a real hard drive (SanDisk claims 2 Mh MTBF, can't find any such for Hama SSD, which is a bargain at about 100 EUR for 4 GByte, which probably already answers my question). I think that proper ssd units designed to replace a regular magnetic hard drive have to have very sophisticated wear-levelling algorithms, and probably have an intermediate store for written data, e.g. some battery-backed SRAM or non-wearable memory. By ensuring you mount the drive noatime and async you can reduce the number or writes; mounting everything except /var/log as read-only would enforce no writing. Perhaps put /var/log into a ram disk, rotate logs frequently and rsync them to flash would help too. However, this is speculation on my part as I've never created my own unix/linux flash based system (although I do have a zaurus, but rely on the distro creaters to solve the problem!). BTW I've seen very few reports of people having problems with the microdrive in their zauruses which take the 4 or 6GB drives, but people who've replaced their microdrives with CF cards report early failures! Paul
Re: [pfSense-discussion] full instalation on 4 GB SSD
Paul M wrote: Eugen Leitl wrote: I was thinking a real 2.5 SSD would have a MTBF comparable to a real hard drive (SanDisk claims 2 Mh MTBF, can't find any such for Hama SSD, which is a bargain at about 100 EUR for 4 GByte, which probably already answers my question). I think that proper ssd units designed to replace a regular magnetic hard drive have to have very sophisticated wear-levelling algorithms, and probably have an intermediate store for written data, e.g. some battery-backed SRAM or non-wearable memory. Yeah, like this one: http://www.superssd.com Of course, unless you're prepared to spend a six-figure-sum, you don't need to think about buying one of those kits. For a busy mail scratch-dir, this should do wonders. For a firewall: probably overkill... Rainer
[pfSense-discussion] transient network drops
I'm running a transparent firewall on 1.2-RC1 with several hosts behind them, both real and virtual. The network setup looks like this: ---gateway---switch0 | | wan-pfsense-lan | | switch1--diverse hosts what's interesting is that I have transient outages to *some* IPs (it could be just one IP, actually). I can still ping that IP locally (within above assembly), but not from the outside. I can reliably fix that by disabling the port on switch0 which connects to wan interface of pfsense, and reenabling it a few seconds later. After few 10 seconds the IP becomes again pingable. For a (long) while, until the next outage. I don't think the problem is in my setup, but there might be something in my setup which triggers the problem at my ISP. Could it be a MAC table running full? Something else? How can I debug this? (Apart from opening a trouble ticket, I mean; I'd rather narrow down the spots of trouble first). -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
Re: [pfSense-discussion] transient network drops
Eugen Leitl wrote: wan-pfsense-lan | switch1--diverse hosts what's interesting is that I have transient outages to *some* IPs (it could be just one IP, actually). I can still ping that IP locally is your switch manageable? can you turn logging on it? can you look up the mac of the missing host (also check arp table on pfsense)?
Re: [pfSense-discussion] transient network drops
On Wed, Aug 29, 2007 at 02:33:45PM +0100, Paul M wrote: Eugen Leitl wrote: wan-pfsense-lan | switch1--diverse hosts what's interesting is that I have transient outages to *some* IPs (it could be just one IP, actually). I can still ping that IP locally is your switch manageable? can you turn logging on it? can you look up The gateway switch is a Netgear GS724T, the second switch is HP ProCurve. Logging, as in redirecting traffic to a sniffer port, and capture all traffic there? the mac of the missing host (also check arp table on pfsense)? The missing host is a vserver guest, sharing its MAC with the host (00:E0:81:58:58:B3). The pfsense ARP table only shows Diagnostics: ARP Table IP address MAC address HostnameInterface 10.0.0.600:40:63:d9:a7:18 carbon.ativel.com LAN 85.10.225.1 00:02:85:1a:e2:e0 hydrogen.ativel.com WAN (it's a transparent bridge, with no rules defined but the default pass-through-everything rule). The hoster advised doing an mtr, which I will do once the host drops offline again. -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
Re: [pfSense-discussion] transient network drops
Eugen Leitl wrote: On Wed, Aug 29, 2007 at 02:33:45PM +0100, Paul M wrote: Eugen Leitl wrote: wan-pfsense-lan | switch1--diverse hosts what's interesting is that I have transient outages to *some* IPs (it could be just one IP, actually). I can still ping that IP locally is your switch manageable? can you turn logging on it? can you look up The gateway switch is a Netgear GS724T, the second switch is HP ProCurve. Logging, as in redirecting traffic to a sniffer port, and capture all traffic there? logging, as in getting the managed switch to send syslog messages to a server and seeing if it reports any errors. I don't know procurves, but in cisco it's fairly straight forward... add this to config for example: logging facility local5 logging 10.0.0.2 The hoster advised doing an mtr, which I will do once the host drops offline again. yeah, also check arp table on the disappearing host
Re: [pfSense-discussion] transient network drops
On Wed, Aug 29, 2007 at 03:50:05PM +0200, Eugen Leitl wrote: (it's a transparent bridge, with no rules defined but the default pass-through-everything rule). The hoster advised doing an mtr, which I will do once the host drops offline again. I've verified it's the firewall. I could ping the host from within the firewall even while it was not accessible outside. I was able to temporarily restore connectivity by disabling the port leading to the WAN NIC, and reenabling it again. Connectivity was regained, but lost shortly thereafter. After a while, the connectivity was regained spontaneously. Here's the setup from the firewall: # ifconfig -a vr0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::240:63ff:fed9:a718%vr0 prefixlen 64 scopeid 0x1 inet 10.0.0.6 netmask 0xff00 broadcast 10.0.0.255 ether 00:40:63:d9:a7:18 media: Ethernet autoselect (100baseTX full-duplex) status: active vr1: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::240:63ff:fed9:a736%vr1 prefixlen 64 scopeid 0x2 inet 85.10.225.6 netmask 0xff00 broadcast 85.10.225.255 ether 00:40:63:d9:a7:36 media: Ethernet autoselect (100baseTX full-duplex) status: active pfsync0: flags=41UP,RUNNING mtu 2020 pfsync: syncdev: lo0 syncpeer: 224.0.0.240 maxupd: 128 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 pflog0: flags=100PROMISC mtu 33208 enc0: flags=41UP,RUNNING mtu 1536 bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 ether 06:b1:b4:39:d2:42 priority 32768 hellotime 2 fwddelay 15 maxage 20 member: vr1 flags=7LEARNING,DISCOVER,STP port 2 priority 128 path cost 55 forwarding member: vr0 flags=7LEARNING,DISCOVER,STP port 1 priority 128 path cost 55 forwarding Ah, at least something in dmesg: arp: 85.10.225.1 is on vr1 but got reply from 00:02:85:1a:e2:e0 on vr0 arp: 85.10.225.1 is on vr1 but got reply from 00:02:85:1a:e2:e0 on vr0 arp: 85.10.225.1 is on vr1 but got reply from 00:02:85:1a:e2:e0 on vr0 arp: 85.10.225.1 is on vr1 but got reply from 00:02:85:1a:e2:e0 on vr0 arp: 85.10.225.1 is on vr1 but got reply from 00:02:85:1a:e2:e0 on vr0 arp: 85.10.225.1 is on vr1 but got reply from 00:02:85:1a:e2:e0 on vr0 bridge0: Ethernet address: 06:b1:b4:39:d2:42 vr0: promiscuous mode enabled vr1: promiscuous mode enabled arp: 00:40:63:d9:a7:36 attempts to modify permanent entry for 10.0.0.6 on vr0 pflog0: promiscuous mode disabled pflog0: promiscuous mode enabled tcp_output: inc sockbuf, old 66240, new 74432, sb_cc 60444, snd_wnd 54656, sendwnd 53340 vr1: link state changed to DOWN vr1: link state changed to UP arp: 85.10.225.5 moved from 00:40:63:d9:a7:c1 to 00:40:63:d9:a7:e9 on vr1 arp: 85.10.225.5 moved from 00:40:63:d9:a7:e9 to 00:40:63:d9:a7:c1 on vr1 pflog0: promiscuous mode disabled pflog0: promiscuous mode enabled pflog0: promiscuous mode disabled pflog0: promiscuous mode enabled vr1: link state changed to DOWN vr1: link state changed to UP vr1: link state changed to DOWN vr1: link state changed to UP vr1: link state changed to DOWN vr1: link state changed to UP vr1: link state changed to DOWN vr1: link state changed to UP vr1: link state changed to DOWN vr1: link state changed to UP -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
Re: [pfSense-discussion] transient network drops
On Wed, Aug 29, 2007 at 04:37:58PM +0200, Eugen Leitl wrote: I've verified it's the firewall. I could ping the host from within I've got to take that back. pfsense is innocent; there's some ARP mayhem with the machine hosting the vserver guests. I'm just the one who wound up with an unlucky vserver guest. the firewall even while it was not accessible outside. I was able to temporarily restore connectivity by disabling the port leading to the WAN NIC, and reenabling it again. Connectivity was regained, but lost shortly thereafter. After a while, the connectivity was regained spontaneously. -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
[pfSense-discussion] What is /etc/ping_hosts.sh for exactly?
Hi
In writing a program to run a 5 minute ping / ifconfig rescue (which I think I
may have achieved - appended) I note the cron job
running every 5 minutes
*/5 * * * * root /etc/ping_hosts.sh
/etc/ping_hosts.sh contains:
#!/bin/sh
# pfSense ping helper
# written by Scott Ullrich
# (C)2006 Scott Ullrich
# All rights reserved.
# Format of file should be deliminted by |
# Field 1: Source ip
# Field 2: Destination ip
# Field 3: Ping count
# Field 4: Script to run when service is down
# Field 5: Script to run once service is restored
# Field 6: Ping time threshold
# Field 7: Wan ping time threshold
# Read in ipsec ping hosts
if [ -f /var/db/ipsecpinghosts ]; then
IPSECHOSTS=/var/db/ipsecpinghosts
fi
# General file meant for user consumption
if [ -f /var/db/hosts ]; then
HOSTS=/var/db/hosts
fi
# Package specific ping requests
if [ -f /var/db/pkgpinghosts ]; then
PKGHOSTS=/var/db/pkgpinghosts
fi
cat $PKGHOSTS $HOSTS $IPSECHOSTS /tmp/tmpHOSTS
if [ ! -d /var/db/pingstatus ]; then
/bin/mkdir -p /var/db/pingstatus
fi
if [ ! -d /var/db/pingmsstatus ]; then
/bin/mkdir -p /var/db/pingmsstatus
fi
PINGHOSTS=`cat /tmp/tmpHOSTS`
for TOPING in $PINGHOSTS ; do
echo PROCESSING $TOPING
SRCIP=`echo $TOPING | cut -d| -f1`
DSTIP=`echo $TOPING | cut -d| -f2`
COUNT=`echo $TOPING | cut -d| -f3`
FAILURESCRIPT=`echo $TOPING | cut -d| -f4`
SERVICERESTOREDSCRIPT=`echo $TOPING | cut -d| -f5`
THRESHOLD=`echo $TOPING | cut -d| -f6`
WANTHRESHOLD=`echo $TOPING | cut -d| -f7`
echo Processing $DSTIP
# Look for a service being down
ping -c $COUNT -S $SRCIP $DSTIP
if [ $? -eq 0 ]; then
# Host is up
# Read in previous status
PREVIOUSSTATUS=`cat /var/db/pingstatus/$DSTIP`
if [ $PREVIOUSSTATUS = DOWN ]; then
# Service restored
if [ $SERVICERESTOREDSCRIPT != ]; then
echo UP /var/db/pingstatus/$DSTIP
echo $DSTIP is UP, previous state was DOWN .. Running
$SERVICERESTOREDSCRIPT
echo $DSTIP is UP, previous state was DOWN .. Running
$SERVICERESTOREDSCRIPT | logger -p daemon.info -i -t PingMonitor
sh -c $SERVICERESTOREDSCRIPT
fi
fi
echo UP /var/db/pingstatus/$DSTIP
else
# Host is down
PREVIOUSSTATUS=`cat /var/db/pingstatus/$DSTIP`
if [ $PREVIOUSSTATUS = UP ]; then
# Service is down
if [ $FAILURESCRIPT != ]; then
echo DOWN /var/db/pingstatus/$DSTIP
echo $DSTIP is DOWN, previous state was UP .. Running $FAILURESCRIPT
echo $DSTIP is DOWN, previous state was UP .. Running $FAILURESCRIPT |
logger -p daemon.info -i -t PingMonitor
sh -c $FAILURESCRIPT
fi
fi
echo DOWN /var/db/pingstatus/$DSTIP
fi
echo Checking ping time $DSTIP
# Look at ping values themselves
PINGTIME=`ping -c 1 -S $SRCIP $DSTIP | awk '{ print $7 }' | grep time | cut -d
= -f2`
echo Ping returned $?
echo $PINGTIME /var/db/pingmsstatus/$DSTIP
if [ $THRESHOLD != ]; then
if [ $PINGTIME -gt $THRESHOLD ]; then
echo $DSTIP has exceeded ping threshold $PINGTIME / $THRESHOLD .. Running
$FAILURESCRIPT
echo $DSTIP has exceeded ping threshold $PINGTIME / $THRESHOLD .. Running
$FAILURESCRIPT | logger -p daemon.info -i -t
PingMonitor
sh -c $FAILURESCRIPT
fi
fi
# Wan ping time threshold
WANTIME=`rrdtool fetch /var/db/rrd/wan-quality.rrd AVERAGE -r 120 -s -1min -e
-1min | grep : | cut -f3 -d | cut -de -f1`
echo Checking wan ping time $WANTIME
echo $WANTIME /var/db/wanaverage
if [ $WANTHRESHOLD != ]; then
if [ $WANTIME -gt $WANTHRESHOLD ]; then
echo $DSTIP has exceeded wan ping threshold $WANTIME / $WANTHRESHOLD ..
Running $FAILURESCRIPT
echo $DSTIP has exceeded wan ping threshold $WANTIME / $WANTHRESHOLD ..
Running $FAILURESCRIPT | logger -p daemon.info -i -t
PingMonitor
sh -c $FAILURESCRIPT
fi
fi
done
exit 0
What is this supposed to do? (And is it supposed to do what I was wanting to
do, but not quite?)
With thanks
David Hingston
/etc/pinger.sh is called from crontab and is now:
#!/bin/sh
if ! ping -c1 Static_ip_Gateway /dev/null 2/dev/null
then
echo First_Hop_OK
else
ifconfig em0 down ifconfig em0 up
echo Restored
fi
