Re: Environmental monitoring options

2011-09-27 Thread bgold 
 I'd like to ask the list what products people are using to monitor their
 environments. By this I'm referring to datacenters, and other equipment.
 Temperature, humidity, airflow, cameras, dry contacts, door sensors, leak
 detection, all that sort of thing.

 I've used Netbotz in the past. Looking to see what else is out there that
 people like.

 Thanks

 E


We've been using RoomAlert units (http://environmentmonitor.com/)
monitored by nagios via snmp. Multiple temp/humidity probes, power, flood,
etc. All graphed nicely by pnp4nagios.

Re: routing issue for verizon dsl customers in western massachusetts

2011-09-16 Thread bgold 
 On Thu, Sep 15, 2011 at 20:52 UTC, Christopher Morrow
 morrowc.li...@gmail.com wrote:
 On Thu, Sep 15, 2011 at 4:13 PM, Steve Bohrer skboh...@simons-rock.edu
 wrote:
 Traceroutes from Brian's house
 show that for our blocked hosts, the users don't get beyond Verizon's
 NAT.

 I wasn't aware verizon implemented CGN already... way to be a 'first
 mover' in this field verizon!

 I am betting they have not.

 FAILS:
 Tracing route to wilbur.simons-rock.edu [208.81.88.15]
 over a maximum of 30 hops:

  1    1 ms    1 ms    1 ms  192.168.10.1
  2     1 ms     1 ms     1 ms  192.168.1.1
  3    53 ms   104 ms   116 ms  10.14.1.1
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.

 Here's a trace to the same destination from a Verizon residential DSL
 on Maryland's Eastern Shore:

 Tracing route to wilbur.simons-rock.edu [208.81.88.15]
 over a maximum of 30 hops:

   11 ms1 ms1 ms  192.168.201.1
   225 ms25 ms24 ms  10.31.8.1
   338 ms99 ms78 ms
 at-4-3-0-1712.sal-core-rtr1.verizon-gni.net [130.81.136.122]
   426 ms26 ms26 ms
 so-0-0-0-0.sal-core-rtr2.verizon-gni.net [130.81.18.247]
   594 ms31 ms31 ms  130.81.20.238
   632 ms32 ms32 ms  0.ae2.BR2.IAD8.ALTER.NET [152.63.34.73]
   732 ms33 ms31 ms  te2-3.ar6.DCA3.gblx.net [64.215.195.113]
   833 ms33 ms32 ms  xe6-2-0-10G.scr2.WDC2.gblx.net
 [67.16.136.197]
   937 ms38 ms38 ms  so2-2-0-10G.scr2.NYC1.gblx.net
 [67.17.95.102]
  1043 ms44 ms44 ms  pos9-0-2488M.cr2.BOS1.gblx.net
 [67.17.94.157]
  11   244 ms   200 ms   204 ms  pos1-0-0-155M.ar1.BOS1.gblx.net
 [67.17.70.165]
  1250 ms51 ms50 ms  64.213.79.250
  1349 ms50 ms48 ms  wilbur.simons-rock.edu [208.81.88.15]

 192.168.201.1 is the router behind the bridged ADSL CPE which
 terminates the customer PPPoE.  10.31.8.1 is RFC 1918, but is not a
 NAT.  I know from various test my crappy broadband sites that the
 only drain bramage on the provider side of the link is routine
 consumer-class port blocking (SMB networking, SQL, and of course port
 80 so the mothe#@#$rs can charge extra for business with static IP
 and unblocked http).  At least https works.

 Looking at Brian's trace above, I can't help wondering if the client
 is 444'd, but not due to CGN/LSN.  Could both 192.168.10.1 and
 192.168.1.1 be on-premises, with 192.168.1.1 terminating PPPoE?  The
 latencies seem to confirm.  It is possible it's only a single level of
 NAT on .1.1, with more-respectable routing by .10.1...

In my setup, 192.168.10.1 is my DD-WRT router and 192.168.1.1 is the DSL
modem. When I ran a traceroute directly from the DSL modem's web
interface, I got the following results:

157 ms98 ms   129 ms  10.14.1.1
3 *** Request timed out.
5 *** Request timed out.
5 *** Request timed out.
6 *** Request timed out.


 Cheers,
 Dave Hart