Fw: new message

[Frank Bulk - iName . com]

Hey!

 

New message, please read 

 

Frank Bulk - iName.com

Fw: new message

[Frank Bulk - iName . com]

Hey!

 

New message, please read 

 

Frank Bulk - iName.com

Fw: new message

[Frank Bulk - iNAME]

Hey!

 

New message, please read <http://hurricanedisasterphotos.com/return.php?sel30>

 

Frank Bulk - iNAME

RE: Level3 tries cell-phone style billing scam on customers

[Frank Bulk - iNAME]

At least they didn't label it a fuel surcharge. =)

Frank

-Original Message-
From: Patrick Giagnocavo [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 31, 2008 10:47 AM
To: nanog@nanog.org
Subject: Level3 tries cell-phone style billing scam on customers

Today I looked at my most recent bill from Level3.

They are now assessing a 2.5% surcharge, which is listed as Taxes on
the bandwidth bill I have.  In the state of PA, telecoms services are
explicitly not taxable.

When you call Level3 billing, they admit in their recorded message it is
not a tax at all, but a surcharge, and if you want to dispute it you are
supposed to quote back their own contract terms to them via email (i.e.
you cannot reach a human).

I would expect this kind of scamminess from Verizon's cell-phone
billing, but a contract is a contract and I can see no provision for
arbitrarily tacking on fees, illegally labeling them as taxes and then
putting the onus on you to prove that they can't charge you.

Anyone else seeing this same behavior from Level3?

(It seems that the larger a telecom company gets, the more they want to
act like a scum-sucking ILEC.)

--Patrick

RE: tacid.org

[Frank Bulk - iNAME]

Nick:

Leaving a domain and IP fallow for such a long time will end up looking like
my garden did this year when I did the same thing -- overrun with weeds.

Sending a blanket e-mail to NANOG is not going to get the attention of those
who manage the e-mail flow (unless you domain belonged to a Fortune 100).

Just like I should have with my garden, rather than replant among the weed
seeds and spend 99% of my time pulling weeds, I would recommend sowing a new
field by moving your outbound e-mail server(s) to some fresh address space
(different /24 to be sure, ideally another section of SWIPed space) and
start monitoring your outgoing servers logs.  You'll need to work with each
MTA that blocks your e-mail and ask them to delist you from whatever block
(domain or domain reputation) that they have.  At the same time,
systematically go to every RBL that tracks by domain name and check the
status of your domain and request delisting as necessary.

Regards,

Frank

-Original Message-
From: Nick Shank [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 03, 2008 5:51 AM
To: nanog@nanog.org
Subject: tacid.org

Greetings,
 My name is Nick, and I have inherited admin duties for tacid.org. For an
un-known amount of time (A month or more?) mail.tacid.org has been an
open-relay, and sending out large amounts of spam. This should now be fixed.
If anyone is having issues with this domain still, please contact me off
list.
Thank you,
Nick

RE: Mail Server best practices - was: Pandora's Box of new TLDs

[Frank Bulk - iNAME]

You mean, you don't employ *any* spam mitigation techniques besides sorting?
Because if you do anything, even as basic as RBLs, you're not being
consistent with your stance.

Frank

-Original Message-
From: Stephane Bortzmeyer [mailto:[EMAIL PROTECTED] 
Sent: Sunday, June 29, 2008 3:08 PM
To: Chris Owen
Cc: nanog
Subject: Re: Mail Server best practices - was: Pandora's Box of new TLDs

[Wow, operational content!]

On Sat, Jun 28, 2008 at 05:25:16PM -0500,
 Chris Owen [EMAIL PROTECTED] wrote
 a message of 53 lines which said:

 At some point what is the difference between putting the mail into a
 spam folder and sending them to /dev/null?

To me, there is a huge difference. I send no mail to Dave Null,
everything goes into a spam folder. Do I read it? Do I review it from
time to time? Never. It is too huge. So, what's the point besides
bringing money to hard disk manufacturers?

It is because, if someone reports (by telephone, IRC or IRL) that he
sent an email and I did not receive it, I regard as VERY IMPORTANT to
be able to check the spam folder (with a search tool, not by hand) and
go back to him saying No, we really did not receive it.

In a professional environment, I would not accept the idea of email
disappearing without being able to recover it.

RE: ICANN opens up Pandora's Box of new TLDs

[Frank Bulk - iNAME]

You do have a choice if you're not concerned about the deliverability of
your e-mail.  Remember, the Internet remains a group of service
providers/organizations/subscribers that voluntarily work together and can
choose what goes in or out.  And so if they decide not to receive traffic
from you, for any reason at all, there's no legal requirement.  If they
require that all e-mail servers that want to send e-mail to them have rDNS
entries then persons who want to deliver e-mail to that entity need to
comply.

Frank

-Original Message-
From: Stephane Bortzmeyer [mailto:[EMAIL PROTECTED] 
Sent: Sunday, June 29, 2008 11:32 AM
To: nanog@nanog.org
Subject: Re: ICANN opens up Pandora's Box of new TLDs

snip

We already see this in the email world, where a self-appointed cartel
like the MAAWG can decide technical rules and policies, bypassing both
IETF and ICANN. Even if only one half of the big operators enforce
these rules, they will become de facto regulations, since noone can
afford to have his email refused by this half. (To take a recent
example, I configure rDNS on every email server I managed, even if I
find the rule stupid and unfair, because I have no choice.)

snip

RE: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)

[Frank Bulk - iNAME]

One way to provide protection is too allow those who have the domain portion
of any domain.(com|net|org|...) to have first dibs for the domain of any new
gTLD.  i.e. if nanog.org, nanog.com, nanog.net, etc. would have first dibs
on nanog.thisisgreatstuff.

Or is that too simplistic and fraught with division?

Frank

-Original Message-
From: David Conrad [mailto:[EMAIL PROTECTED] 
Sent: Saturday, June 28, 2008 7:50 AM
To: WWWhatsup
Cc: nanog@nanog.org
Subject: Re: what problem are we solving? (was Re: ICANN opens up Pandora's
Box of new TLDs)

On Jun 27, 2008, at 8:59 PM, WWWhatsup wrote:
 David Conrad wrote:
 With that said, personally, I agree that more attention should be
 spent on the welfare of the registrants.  Unfortunately, given I work
 for ICANN, my providing comments in the RAA public consultation along
 those lines would be a bit ... awkward.

 Would you agree with Danny Younger (I believe this is his position)
 then that there should be a
 properly constituted  recognized registrants constituency?


Obviously speaking personally, conceptually I agree, but the challenge
here has always been how do you properly constitute and recognize
registrants in a way that doesn't allow for capture.  For example,
you could say 'only folks who have domain names can be part of that
constituency', but in reality, the majority of domain names are held
by registrars.  You could add the restriction that 'registrants' must
be natural persons, but how would one verify this across the entire
planet?  It obviously isn't impossible, but people already complain
about how big ICANN is -- I can't see how having some mechanism to
validate a registrant constituency won't make ICANN _much_ larger...

However, lacking this, I personally believe there should be strong
explicit registrant protections built into the RAA.  But that's just me.

Regards,
-drc

RE: Mail Server best practices - was: Pandora's Box of new TLDs

[Frank Bulk - iNAME]

Comments in-line.

-Original Message-
From: Phil Regnauld [mailto:[EMAIL PROTECTED] 
Sent: Saturday, June 28, 2008 1:02 PM
To: [EMAIL PROTECTED]
Cc: nanog@nanog.org
Subject: Re: Mail Server best practices - was: Pandora's Box of new TLDs

[EMAIL PROTECTED] (michael.dillon) writes:


 http://www.maawg.org/about/MAAWG_Sender_BCP/MAAWG_Senders_BCP_Combine.pdf

Thanks for the pointer.  I don't necessarily agree with all of it,
but it's definitely a good reference.

I just get irritated by actions that penalize end users who feel
they
don't have other options other than just using some horrible webmail
service, because their operator/ISP is clueless.  I do make a
distinction.

FB You do have an option -- ask the sender to clean up their act.  Then the
operator/ISP will happily receive the sender's e-mail.  When one of our
business customers complains to us (ISP) that they can't send e-mail to an
external third-party and I find out it's due to poor configuration on their
part (almost 100% of the time -- the sole exception that I can recall is a
business customer's IP address being blocked by a GoDaddy RBL even though
another properly SWIPed customer was sending the spam.  Apparently GoDaddy's
minimum block size is /24 and they can't bother to look up the ranges), I
don't complain about the external third-party, I educate our business
customer on best practices.

 On page 5 they do recommend matching reverse DNS and in
 Appendix A they go on to state that RFC 1912 states that
 all hosts on the Internet should have a valid rDNS entry.

Indeed it does, but rejecting a mail based on a missing PTR
is still arbitrarily useless (and I'm speaking in terms of
volume of spam emanating from hosts with a missing PTR, vs
spam origination from hosts that do have a PTR).

FB The point is that those are able to create a valid rDNS entry likely
have more control of their infrastructure than those who don't.  You must
admit, if you can't get a proper rDNS entry created for your domain, what
does that say about your ability to control your infrastructure?  Of course,
the inverse it not true.

snip

RE: Possible explanations for a large hop in latency

[Frank Bulk - iNAME]

Did that satisfy you?  I guess with MPLS they could tag the traffic and send
it around the country twice and I wouldn't see it at L3.

Frank

-Original Message-
From: John T. Yocum [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 26, 2008 7:04 PM
To: [EMAIL PROTECTED]
Cc: nanog list
Subject: Re: Possible explanations for a large hop in latency

When I asked ATT about the sudden latency jump I see in traceroutes,
they told me it was due to how their MPLS network is setup.

--John

Frank Bulk wrote:
 Our upstream provider has a connection to ATT (12.88.71.13) where I
 relatively consistently measure with a RTT of 15 msec, but the next hop
 (12.122.112.22) comes in with a RTT of 85 msec.  Unless ATT is sending
that
 traffic over a cable modem or to Europe and back, I can't see a reason why
 there is a consistent ~70 msec jump in RTT.  Hops farther along the route
 are just a few msec more each hop, so it doesn't appear that 12.122.112.22
 has some kind of ICMP rate-limiting.

 Is this a real performance issue, or is there some logical explanation?

 Frank

RE: Possible explanations for a large hop in latency

[Frank Bulk - iNAME]

Thanks for the added information.

Even if their MPLS path went from the midwest (where I'm located) to San
Francisco and then back to St. Louis (where 12.122.112.22 appears to be), I
don't think that accounts for a 70 msec jump in traffic.  And I don't think
they would (intentionally) create such an inefficient MPLS path.

Someone off-list told me they tried to trace to 12.88.71.13, but once they
hit an ATT router their ICMP traffic appeared to be blocked.

Frank

-Original Message-
From: John T. Yocum [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 26, 2008 8:09 PM
To: [EMAIL PROTECTED]
Cc: nanog list
Subject: Re: Possible explanations for a large hop in latency

The explanation I got, was that the latency seen at the first hop was
actually a reply from the last hop in the path across their MPLS
network. Hence, all the following hops had very similar latency.

Personally, I thought it was rather strange for them to do that. And,
I've never seen that occur on any other network.

Perhaps someone from ATT would like to chime in.

--John

Frank Bulk - iNAME wrote:
 Did that satisfy you?  I guess with MPLS they could tag the traffic and
send
 it around the country twice and I wouldn't see it at L3.

 Frank

 -Original Message-
 From: John T. Yocum [mailto:[EMAIL PROTECTED]
 Sent: Thursday, June 26, 2008 7:04 PM
 To: [EMAIL PROTECTED]
 Cc: nanog list
 Subject: Re: Possible explanations for a large hop in latency

 When I asked ATT about the sudden latency jump I see in traceroutes,
 they told me it was due to how their MPLS network is setup.

 --John

 Frank Bulk wrote:
 Our upstream provider has a connection to ATT (12.88.71.13) where I
 relatively consistently measure with a RTT of 15 msec, but the next hop
 (12.122.112.22) comes in with a RTT of 85 msec.  Unless ATT is sending
 that
 traffic over a cable modem or to Europe and back, I can't see a reason
why
 there is a consistent ~70 msec jump in RTT.  Hops farther along the route
 are just a few msec more each hop, so it doesn't appear that
12.122.112.22
 has some kind of ICMP rate-limiting.

 Is this a real performance issue, or is there some logical explanation?

 Frank

RE: Possible explanations for a large hop in latency

[Frank Bulk - iNAME]

Interestingly enough, when I trace from my Cisco router it seems to show
some MPLS labels after the hop of interest (12.88.71.13 to 12.122.112.78,
only 24 msec here!).  I'm not sure how our Cisco box derives these from a
foreign network.

 

Router#traceroute 69.28.226.193

 

Type escape sequence to abort.

Tracing the route to 69.28.226.193

 

  1 sxct.sxcy.mtcnet.net (167.142.156.197) 0 msec 0 msec 0 msec

  2 siouxcenter.sxcy.137.netins.net (167.142.180.137) 4 msec 4 msec 4 msec

  3 ins-b12-et-4-0-112.desm.netins.net (167.142.57.106) 8 msec 8 msec 8 msec

  4 ins-h2-et-1-10-127.desm.netins.net (167.142.57.129) 8 msec 8 msec 8 msec

  5 ins-c2-et-pc2-0.desm.netins.net (167.142.57.142) 8 msec 8 msec 8 msec

  6 12.88.71.13 28 msec 24 msec 28 msec

  7 tbr2.sl9mo.ip.att.net (12.122.112.78) [MPLS: Label 30663 Exp 0] 52 msec
48 msec 52 msec

  8 cr2.sl9mo.ip.att.net (12.122.18.69) [MPLS: Label 17306 Exp 0] 52 msec 52
msec 52 msec

  9 cr2.cgcil.ip.att.net (12.122.2.21) [MPLS: Label 16558 Exp 0] 52 msec 52
msec 52 msec

 10 cr1.cgcil.ip.att.net (12.122.2.53) [MPLS: Label 17002 Exp 0] 48 msec 52
msec 52 msec

 11 cr1.n54ny.ip.att.net (12.122.1.189) [MPLS: Label 17033 Exp 0] 52 msec 52
msec 48 msec

 12 tbr1.n54ny.ip.att.net (12.122.16.138) [MPLS: Label 32364 Exp 0] 52 msec
52 msec 52 msec

 13 12.122.86.165 48 msec 48 msec 52 msec

 14 12.118.100.58 60 msec 60 msec 64 msec

 15 oc48-po2-0.tor-151f7-cor-2.peer1.net (216.187.115.125) 52 msec 52 msec
68 msec

 16 oc48-po7-0.tor-151f-dis-1.peer1.net (216.187.114.149) 52 msec 52 msec 48
msec

 17 tor-fe3-5a.ne.peer1.net (216.187.68.6) 52 msec 52 msec *

Router#

 

Wondering why the RTT dropped to 24 msec for that hop, I entered both
69.28.226.192 and the IP address that my customer has been complaining about
(12.129.255.4) into PingPlotter and I see that those behave very
differently.  I'm now guessing that ATT is routing back traffic sent to
12.129.255.4 in a different way (perhaps asymmetrically) than traffic sent
to 69.28.226.192, but it doesn't show up until it hits 12.122.112.22.
Perhaps it's all those 1's and 2'. ;)

 

I notice that in the low RTT trace router 12.88.71.13 goes to
tbr2.sl9mo.ip.att.net (12.122.112.78), but in the high RTT trace, roouter
12.88.71.13 goes to tbr1.sl9mo.ip.att.net (12.122.112.22).   Must be
something about the way ATT gets to tbr1.sl9mo.ip.att.net (12.122.112.22).
I can't traceroute to either of those networks directly.  In fact, I don't
appear to be able to traceroute to any of the 12.122.x.x or 12.129.x.x I see
in my traceroutes, perhaps because ATT uses some of that space internally
and doesn't advertise it.

 

Frank

 

From: Robert Richardson [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 26, 2008 8:20 PM
To: John T. Yocum
Cc: [EMAIL PROTECTED]; nanog list
Subject: Re: Possible explanations for a large hop in latency

 

They probably don't propagate TTL w/in their MPLS core.  Depending on how
they have MPLS implemented, you may only see 2 hops on the network; the
ingress and egress routers.  If the ingress router was in NYC and the egress
in Seattle, you could understandably expect a large jump in RTT.

 

Not an ATT customer but do know other providers run their MPLS core's this
way...

 

-Robert

On Thu, Jun 26, 2008 at 6:09 PM, John T. Yocum [EMAIL PROTECTED]
wrote:

The explanation I got, was that the latency seen at the first hop was
actually a reply from the last hop in the path across their MPLS network.
Hence, all the following hops had very similar latency.

Personally, I thought it was rather strange for them to do that. And, I've
never seen that occur on any other network.

Perhaps someone from ATT would like to chime in.

--John 



Frank Bulk - iNAME wrote:

Did that satisfy you?  I guess with MPLS they could tag the traffic and send
it around the country twice and I wouldn't see it at L3.

Frank

-Original Message-
From: John T. Yocum [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26,
2008 7:04 PM
To: [EMAIL PROTECTED]
Cc: nanog list
Subject: Re: Possible explanations for a large hop in latency

When I asked ATT about the sudden latency jump I see in traceroutes,
they told me it was due to how their MPLS network is setup.

--John

Frank Bulk wrote:

Our upstream provider has a connection to ATT (12.88.71.13
http://12.88.71.13/ ) where I
relatively consistently measure with a RTT of 15 msec, but the next hop
(12.122.112.22 http://12.122.112.22/ ) comes in with a RTT of 85 msec.
Unless ATT is sending

that

traffic over a cable modem or to Europe and back, I can't see a reason why
there is a consistent ~70 msec jump in RTT.  Hops farther along the route
are just a few msec more each hop, so it doesn't appear that 12.122.112.22
http://12.122.112.22/ 
has some kind of ICMP rate-limiting.

Is this a real performance issue, or is there some logical explanation?

Frank



 

 

 

RE: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)]

[Frank Bulk - iNAME]

For the reason you stated, much to the chagrin of receivers.  Easier to
sell a service to customers downstream if it's being done in the network,
without MX changing.

Frank

-Original Message-
From: Ken Simpson [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 24, 2008 8:38 AM
To: [EMAIL PROTECTED]
Cc: 'Christopher Morrow'; nanog@nanog.org
Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip address
reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)]

 Source IP blocking makes up a large portion of today's spam arrest
 approach,
 so we shouldn't discount the CPU benefits of that approach too
 quickly.

 I'm not sure where today's technology is in regards for caching the
 first 1
 to 10kB of a sessiononce enough information is garnered to
 block, issue
 TCP RSETs.  If it's good, free the contents of the cache.


What's your interest in mopping up spam in the middle of the network?
Usually spam is viewed as a leaf-node problem (much to the chagrin of
receivers, actually).

Regards,
Ken

--
Ken Simpson
CEO

MailChannels - Reliable Email Delivery
http://mailchannels.com
604 685 7488 tel

RE: easy way to scan for issues with path mtu discovery?

[Frank Bulk - iNAME]

Look at mturoute: http://www.elifulkerson.com/projects/mturoute.php

Frank

-Original Message-
From: Darden, Patrick S. [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 24, 2008 9:28 AM
To: nanog@nanog.org
Subject: easy way to scan for issues with path mtu discovery?

Hi all,

Does anyone know of an easy way to scan for issues with path mtu discovery
along a hop path?  E.g. if you think someone is ICMP black-holing along a
route, or even on the endpoint host, could you use some obscure nmap flag to
find out for sure, and also to identify the offending hop/router/host?  What
tool would you use to test for this, and how would you do such a test?  Is
there any probing tool that does checks like this automatically?

Seems to me this happens often enough that someone has probably already
figured it out, so I am trying not to reinvent the wheel.  All I can think
of would be to handcraft packets of steadily increasing sizes and look for
replies from each hop on the route (which would be laborious at best).
Google has not been kind to my researches so far.

I appreciate any help!
--Patrick Darden

Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)]

[Frank Bulk - iNAME]

When I hear cloud services I think in the network even though it appears
all these cloud services perform their work at a data center as an
outsourced service.

Is there a vendor that makes a product that perform spam/malware filtering
literally in the network, i.e. as a service provider, can I provide spam
filtering for the enterprises in my customer base by adding a piece of
network gear?  I'm not aware of one today except those who provide
enterprise-oriented gateways like SonicWall.

Frank

-Original Message-
From: Roland Dobbins [mailto:[EMAIL PROTECTED] 
Sent: Sunday, June 22, 2008 9:20 PM
To: [EMAIL PROTECTED]
Subject: Re: EC2 and GAE means end of ip address reputation industry? (Re:
Intrustion attempts from Amazon EC2 IPs)

snip 

This is far different from free email Google or Hotmail - these cloud
services (EC2, Mosso, Slicehost, Terremark's Enterprise Cloud,
Telstra's new service, AppEngine, et.al.) are where many popular new
Internet applications will live, and, even more significantly, where
an increasing amount large-scale enterprise computing (like banking,
pharma, government, and so forth) will take place.

I foresee interesting times ahead.

---
Roland Dobbins [EMAIL PROTECTED] // +66.83.266.6344 mobile

  History is a great teacher, but it also lies with impunity.

-- John Robb

RE: SMTP no-such-user issues

[Frank Bulk - iNAME]

Once you've performed a full capture on port 25, Wireshark does a nice job
of providing an option to extract the relevant conversation by
right-clicking on just one packet in that conversation and choosing
something called Follow the TCP stream, I believe. 

Frank

-Original Message-
From: Steve Bertrand [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 17, 2008 7:44 AM
To: [EMAIL PROTECTED]
Cc: nanog@nanog.org
Subject: Re: SMTP no-such-user issues

Frank Bulk - iNAME wrote:
 Please share a packet capture of a working and not working SMTP exchange.

In order to provide the highest amount of clarity, could you recommend a
specific set of tcpdump command line args that I should use?

Steve

RE: [NANOG] Introducing latency for testing?

[Frank Bulk - iNAME]

It's not free, but at a recent trade show I did see what appeared to be an
affordable unit from Apposite Technologies (apposite-tech.com).  And there's
always PacketStorm.

Frank

-Original Message-
From: Mike Lyon [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 02, 2008 3:13 PM
To: NANOG
Subject: [NANOG] Introducing latency for testing?

So I want to mimic some latency in a test network for DB replication.
I am wondering what other's have used for this? Obviously, the best
way to would be to actually have one box across the US or across the
globe to actually test against but what if you don't have that? Are
there any GPL software router solutions that would allow you to tweak
the latency in between the two test boxes?

Thanks in advance.

-Mike

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

RE: Power/temperature monitoring

[Frank Bulk - iNAME]

Thanks.  The TemPager doesn't appear to support identifying AC power
failure, but that's in the Room Alert 7.  The price point and features do
seem reasonable.

 

Frank

 

From: Josh Fiske [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 04, 2008 9:19 PM
To: [EMAIL PROTECTED]; nanog@nanog.org
Subject: RE: Power/temperature monitoring

 

Frank,

We have had good luck with a device called TemPager (http://tempager.com/).
Our specific device is used for SNMP temperature monitoring, but they also
make a device that includes the ability to humidity, power, flood, room
entry, etc. etc.

Hope that is helpful,

Josh

- - - -
Joshua Fiske '03, '04
Network and Security Engineer
Clarkson University, Office of Information Technology
(315) 268-6722 -- Fax:  (315) 268-6570
GPG Key:  http://clarkson.edu/~jfiske/jfiske_pub.asc
[EMAIL PROTECTED]

CONFIDENTIALITY:  This e-mail (including any attachments) may contain
confidential, proprietary and privileged information, and unauthorized
disclosure or use is prohibited.  If you received this e-mail in error,
please notify the sender and delete this e-mail from your system.



-Original Message-
From: Frank Bulk [mailto:[EMAIL PROTECTED]
Sent: Fri 5/30/2008 10:58 AM
To: nanog@nanog.org
Subject: Power/temperature monitoring

Hopefully monitoring the status of a network is on-topic.

I'm looking for temperature and power monitoring unit to install in some
remote BWA cabinets.  We had two incidents where we lost power in a town and
we weren't aware of it until the backup batter drained to empty, and another
situation where the cabinet became too cold.  Because these cabinets are
less than 19 wide and just 3-5 deep, I need something quite small.  I did
find one product but it requires four components (unit with built-in
temperature sensor, adapter, and AC power sensor, plus power supply)

Perhaps there's someone on this list who has gone down this road and can
point me to a good product.

Required:
- temperature sensor
- 110 VAC power monitoring (on/off, not necessarily current)
- Ethernet interface (at least SNMP, Web GUI and

Optional:
- fed via 12 VDC power
- 12 VDC power monitoring (current)
- humidity sensor


Frank

RE: Power/temperature monitoring

[Frank Bulk - iNAME]

This is basically the AKCP product, repackaged. =)

Frank

-Original Message-
From: Kyle Duren [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 05, 2008 9:31 AM
To: nanog@nanog.org
Subject: RE: Power/temperature monitoring

We have had great luck, with Ravica Bitsight:
http://ravica.com/products/index.php

We use the smallest model, the Bitsight2, we have it at a solar site,
monitoring the voltage of a 12v battery bank (which also powers the unit),
along with 2 microwave radios and a 12v switch. It works great for this, and
they many other sensor types, but it is a bit pricey. It has a nice web gui
and users snmp and other forms of notification, and has built in graphing.
We used email messages with alerts when certain voltage levels were reached.

-Kyle


-Original Message-
From: Frank Bulk [mailto:[EMAIL PROTECTED]
Sent: Fri 5/30/2008 10:58 AM
To: nanog@nanog.org
Subject: Power/temperature monitoring

Hopefully monitoring the status of a network is on-topic.

I'm looking for temperature and power monitoring unit to install in some
remote BWA cabinets.  We had two incidents where we lost power in a town and
we weren't aware of it until the backup batter drained to empty, and another
situation where the cabinet became too cold.  Because these cabinets are
less than 19 wide and just 3-5 deep, I need something quite small.  I did
find one product but it requires four components (unit with built-in
temperature sensor, adapter, and AC power sensor, plus power supply)

Perhaps there's someone on this list who has gone down this road and can
point me to a good product.

Required:
- temperature sensor
- 110 VAC power monitoring (on/off, not necessarily current)
- Ethernet interface (at least SNMP, Web GUI and

Optional:
- fed via 12 VDC power
- 12 VDC power monitoring (current)
- humidity sensor


Frank

Re: [NANOG] would ip6 help us safeing energy ?

[Frank Bulk - iNAME]

Dale:

ESPN360 used to be something that internet subscribers paid for themselves,
but now it's something that ISPs (most interesting to those who are also
video providers) can offer.

If you google around you can find a pretty good Wikipedia page on ESPN360.

I looked into this for our operations because we do both (internet and
video).  The price was reasonable and you only pay on the number of internet
subs that meet their minimum performance standards.  Since 50% of our user
base is at 128/128 kbps, that's a lot of subscribers we didn't need to pay
for.  In the end, I didn't get buy-in from the rest of the management team
into adding this.  I think they perceived (and probably correctly so) that
too few of our users would actually *use* it.  If I could get even 2% of our
customer base seriously interested I think we would move on this.

BTW, there's no multicast (at lease from Disney/ABC directly) involved.
It's just another unicast video stream like YouTube.

Frank

-Original Message-
From: Dale Carstensen [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 28, 2008 8:02 AM
To: nanog@nanog.org
Subject: Re: [NANOG] would ip6 help us safeing energy ?

I became aware of something called espn360 last fall.  I just did a
google search so I could provide a URL, but one of the top search
responses was a Aug 9, 2007 posting saying ESPN360 Dies an
Unneccessary Death: A Lesson in Network Neutrality ...  I don't
think it's dead, though, and maybe if you don't know about it, you
can do your own google search.

I think Disney/ABC thinks they can get individual ISPs to pay them
to carry sports audio/video streams.  I suppose that would be yet
another multicast stream method, assuming an ISP location had multiple
customers viewing the same stream.

Are other content providers trying to do something similar?  How are
operators dealing with this?  What opinions are there in the operator
community?

  Mr. Dale



___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog


___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog