RE: Possible explanations for a large hop in latency

[Mikael Abrahamsson]

On Thu, 26 Jun 2008, Frank Bulk - iNAME wrote:


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.


The ICMP packet (TTL exceeded in transit) contains a copy of the packet 
which TTL expired, including the labels, so label information is available 
to traceroute.


--
Mikael Abrahamssonemail: [EMAIL PROTECTED]

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

[Randy Bush]

hi drc,

does anyone find it droll that the jr high school like clique of root
server operators is gonna bear the burden of this, while billy et alia
sank the iana usefully signing the root?

randy

Re: OS, Hardware, Network - Logging, Monitoring, and Alerting

[Paul Armstrong]

At 2008-06-26T02:22-0700, Rev. Jeffrey Paul wrote:
> Other stuff we really need to keep an eye on is hardware - redundant
> PSU status in our 7204s and Dells, temperatures and voltages 

Do yourself a favor, monitor temp in C. Most stuff only does C, people
burn routers if there's a mix of C and F (I set the alarm to 90, why
didn't it shut down? Well, you should have set it to 30, the router only
understands C).

> 1) Is SNMP the best way to do this?  Obviously some of the data (service
> checks) will need to be collected other ways.
 
Pretty much.
Particularly with NetSNMP, you can hook in external commands etc.

Check out
http://www.net-snmp.org/docs/man/snmpd.conf.html
Arbitrary Extension Commands

If you don't use SNMP for everything, you're going to be stuck with
hooking SNMP into whatever you do use so that all your networking kit
and environmental monitors can be monitored.

> 2) Is there any good solution that does both logging/trending of this
> data and also notification/monitoring/alerting?  I've used both Nagios
> and Cacti in the past, and, due to the number of individual things being
> monitored (3-5 items per OS instance, 5-10 items per physical server,
> 10-50 things per network device), setting them both up independently
> seems like a huge pain.  Also, I've never really liked Nagios that much.

Take a look at OpenNMS

> There's got to be a better way.  What do you guys use?
 
We wrote our own, but that's a company culture thing.

Paul
 
-- 
End dual-measurement, let's finish going metric!
http://gometric.us/
http://www.metric.org/

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

[David Conrad]

On Jun 26, 2008, at 9:01 PM, Jean-François Mezei wrote:
Does anyone know how if the new gTLD system will still give some  
"veto"
power to some people over some domain names that are morally  
objectable

to some people ?


See pages 17 - 20 of 
https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf


Is it fair to hand .ABC to either one of the two ? (highest bidder) or
will ICANN "lock" .ABC out so that neither can get to it ? I am sure
there are many such gTLDs around the world that would conflict across
countries.


See pages 22 - 25 of 
https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf

Finally, will there be any performance impact on DNS servers around  
the

world (thinking of caching issues) ?



Extremely unlikely (IMHO).

Regards,
-drc

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

[David Conrad]

On Jun 26, 2008, at 8:12 PM, Jim Popovitch wrote:

Is there any "full disclosure" clause in ICANN member contracts such
that gifts from, or stock in, a Registrar would be declared?


Not sure who an "ICANN member" would be.  ICANN as a California  
501c(3) has to publish all it's financial details.  The ICANN Board of  
Trustees (who makes the final decision within ICANN on TLD-related  
matters) must abide by a Conflict of Interest Policy (http://www.icann.org/committees/coi/coi-policy-04mar99.htm 
).


Regards,
-drc

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

[Jean-François Mezei]

A while ago, there was come debate about the introduction of a .XXX gTLD
with some of the folks objecting to its formation.

Does anyone know how if the new gTLD system will still give some "veto"
power to some people over some domain names that are morally objectable
to some people ?

I am not thinking of only .SEX but perhaps also .GOD .GAY .ALLAH .BI
.CHRISTIAN .LESBIAN .MORMON .JEW .JEWISH .ISLAM etc.

Religions will be interesting especially in cases where there is no
central representative for a religion who can make the official
registration.

And in the case where there would be global conflicts, what happens ?

For instance, in the USA "ABC" is the american broadcasting companies,
but in australia, it is the Australian Broadcasting Corporation.

Is it fair to hand .ABC to either one of the two ? (highest bidder) or
will ICANN "lock" .ABC out so that neither can get to it ? I am sure
there are many such gTLDs around the world that would conflict across
countries.

Finally, will there be any performance impact on DNS servers around the
world (thinking of caching issues) ?

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

[Frank Bulk - iNAME]

...which is why it might be a strategy to blacklist all new TLDs (if this
proposal gets through) and whitelist just .com, .net, etc.
 
Frank

-Original Message-
From: Rich Kulawiec [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 26, 2008 9:50 PM
To: nanog@nanog.org
Subject: Re: ICANN opens up Pandora's Box of new TLDs

On Thu, Jun 26, 2008 at 01:34:22PM -0700, Ken Simpson wrote:
> How will ICANN be allocating these? An auction format? It will be a
> blood bath otherwise.. And for abuse and spam, this is a nightmare.

There's no doubt this last will happen since it has *already* happened,
as I pointed out in a note to Dave Farber's IP list earlier today.

For example: the .info TLD is completely overrun with spammers, to
the point where many people, including me, have simply blacklisted the
whole thing.  It simply became too onerous to maintain a blacklist with
hundreds of thousands of individual domains and hundreds of additions
per day.  We never needed a .info TLD and soon its existence will be
moot -- well, except for all the money wasted dealing with squatters
and typosquatters and spammers and phishers and other abusers.

This follows on the heels of .biz, which is so broadly blacklisted that
not even spammers tend to use it much any more.

And so on.

So the outcome of this is inevitable: expense, litigation, hassle,
spam, abuse, and oh-by-the-way massive profits for registrars, which
had nothing at all to do with ICANN's decision.  Of course not.

---Rsk

Re: Possible explanations for a large hop in latency

[Randy Bush]

Frank Bulk - iNAME wrote:
> Just google "tbr1.sl9mo.ip.att.net" and it's clear that high latency through
> that point has occurred before.  And guess what kind of customer complained
> to me about the latency?  A gamer.

you can pay a lot of money for the net propagation anomaly detection
services that gamers give you for free.

randy

RE: Possible explanations for a large hop in latency

[Frank Bulk - iNAME]

Just google "tbr1.sl9mo.ip.att.net" and it's clear that high latency through
that point has occurred before.  And guess what kind of customer complained
to me about the latency?  A gamer.

Frank

-Original Message-
From: Frank Bulk - iNAME [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 26, 2008 9:27 PM
To: 'Robert Richardson'; John T. Yocum
Cc: nanog list
Subject: RE: Possible explanations for a large hop in latency



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 AT&T 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 AT&T 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 AT&T 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 AT&T (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 AT&T 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: ICANN opens up Pandora's Box of new TLDs

[John Levine]

>Is there any "full disclosure" clause in ICANN member contracts such
>that gifts from, or stock in, a Registrar would be declared?

Since ICANN doesn't have members, no.

R's,
John

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

[Jim Popovitch]

On Thu, Jun 26, 2008 at 10:49 PM, Rich Kulawiec <[EMAIL PROTECTED]> wrote:
> So the outcome of this is inevitable: expense, litigation, hassle,
> spam, abuse, and oh-by-the-way massive profits for registrars, which
> had nothing at all to do with ICANN's decision.  Of course not.

Perhaps this is straying into OT land... (but I must push the envelope!) ;-)

Is there any "full disclosure" clause in ICANN member contracts such
that gifts from, or stock in, a Registrar would be declared?

-Jim P.

Re: Possible explanations for a large hop in latency

[bensons]

Depending on whether TTL is propagated into MPLS, this could be true.

Though it should also be pointed out that ICMP responses aren't exactly a 
precise scientific tool... The responding router could just be busy, and the 
response time could be reflective of load more than link latency etc. 
Similarly, failure to get any response at all from a router isn't necessarily 
indicative of packet loss...

Cheers,
-Benson


Sent via BlackBerry from T-Mobile

-Original Message-
From: "Frank Bulk - iNAME" <[EMAIL PROTECTED]>

Date: Thu, 26 Jun 2008 19:54:42 
To:"'John T. Yocum'" <[EMAIL PROTECTED]>
Cc:nanog list <[EMAIL PROTECTED]>
Subject: RE: Possible explanations for a large hop in latency


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 AT&T (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 AT&T 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: ICANN opens up Pandora's Box of new TLDs

[Rich Kulawiec]

On Thu, Jun 26, 2008 at 01:34:22PM -0700, Ken Simpson wrote:
> How will ICANN be allocating these? An auction format? It will be a  
> blood bath otherwise.. And for abuse and spam, this is a nightmare.

There's no doubt this last will happen since it has *already* happened,
as I pointed out in a note to Dave Farber's IP list earlier today.

For example: the .info TLD is completely overrun with spammers, to
the point where many people, including me, have simply blacklisted the
whole thing.  It simply became too onerous to maintain a blacklist with
hundreds of thousands of individual domains and hundreds of additions
per day.  We never needed a .info TLD and soon its existence will be
moot -- well, except for all the money wasted dealing with squatters
and typosquatters and spammers and phishers and other abusers.

This follows on the heels of .biz, which is so broadly blacklisted that
not even spammers tend to use it much any more.

And so on.

So the outcome of this is inevitable: expense, litigation, hassle,
spam, abuse, and oh-by-the-way massive profits for registrars, which
had nothing at all to do with ICANN's decision.  Of course not.

---Rsk

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 AT&T 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 AT&T 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 AT&T 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 AT&T (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 AT&T 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: ICANN opens up Pandora's Box of new TLDs

[Jason Williams]

>> > 
>> > You are welcome to ascribe it to whatever you want.  I will note that
>> > very few Non-profit organizations engage in such behavior. Very
>> > few governments do so, either. In fact, absent a corporate profit
>> > motive, this behavior seems very rare.
> 
> Given the level of customer service most governmental agencies and non-profits
> provide, they¹ve got a lot of other usability holes to fill first before they
> start worrying about their ³clients² going to the wrong website. Secondarily,
> their clients going to the wrong location isn¹t going to put them out of
> existence.  So on the level that profit=existence I¹d agree it¹s definitely
> profit motivated. But greed is pejorative term.
> 
> -J
> 


Jason J. W. Williams
COO/CTO, DigiTar
http://www.digitar.com
Voice: 208.343.8520
Mobile: 208.863.0727
FAX: 208.322-8522
E-mail: [EMAIL PROTECTED]
XMPP/Jabber: [EMAIL PROTECTED]

Re: Possible explanations for a large hop in latency

[Tim Peiffer]

We had a similar situation going from Minneapolis to Kansas City via 
Chicago. Normal latency from Minneapolis to Chicago via Level3 MPLS 
network is about 14msec RTT.  When the the circuit from Minneapolis to 
Chicago went out for one reason or another, our MPLS link went from 
Minneapolis to Tulsa, to Dallas, and then to Chicago..  That added a 
little latency in the path from Minneapolis to Chicago.. We didn't need 
to exceed the SLA in order to cry foul.  They didn't intentionally 
create an inefficient path.. The problem was recognized and fixed the 
same day.


Latency on an MPLS circuit is the cumulative latency on the Label Switch 
Path, and a number of the hops are invisible.  The latency per hop is 
still the same... you just can't see that your traffic is travelling to 
say Denver or Dallas.


Tim Peiffer
Network Support Engineer
Networking and Telecommunications Services
University of Minnesota/NorthernLights GigaPOP


Frank Bulk - iNAME wrote:

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 AT&T 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 AT&T (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 AT&T 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 AT&T 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 AT&T (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 AT&T 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: ICANN opens up Pandora's Box of new TLDs

[Tuc at T-B-O-H.NET]

> 
> Once upon a time, Ken Simpson <[EMAIL PROTECTED]> said:
> > Oooh -- dibs on that one. And .some, so you can register awe.some,  
> > trouble.some, and fear.some. And .ous, which would allow humm.ous,  
> > seri.ous, fabul.ous, etc..
> 
> Somebody on /. mentioned .dot, so you could tell someone to go to:
> 
> eych tee tee pee colon slash slash slash dot dot dot
> 
Yea, I thought that was funny when I owned

www . wwwdotnet . net

tooLost a bit later on trying to explain to people. Then
again TTSG (PPFG? TPSG? TPFG?) and "T dash B dash O dash H" aren't
so fun either.

Tuc

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

[Tuc at T-B-O-H.NET]

> 
> Two years ago I posed the question here about the need for TLDs
> (http://www.mcabee.org/lists/nanog/May-06/msg00110.html).
>
This all should have been solved by allowing those who
wanted/applied for TLDs to be granted them back in 1995 when
originally requested :

http://www.gtld-mou.org/gtld-discuss/mail-archive/00990.html

There was a procedure, people followed it, and IANA
decided to go other ways with it. Now years later there is
all this red tape restricting things.

And if the "powers that be" decide to go back to
it, you can replace stormking.com with t-b-o-h.net and I
look forward to it! ;)

Tuc / Scott Ellentuch

Re: Possible explanations for a large hop in latency

[Robert Richardson]

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 AT&T (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 AT&T 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

[Mikael Abrahamsson]

On Thu, 26 Jun 2008, John T. Yocum 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.


This is standard for MPLS, the ICMP TTL expire message is sent along the 
LSP and returned via the router at the end of the LSP.


--
Mikael Abrahamssonemail: [EMAIL PROTECTED]

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

[Chris Adams]

Once upon a time, Ken Simpson <[EMAIL PROTECTED]> said:
> Oooh -- dibs on that one. And .some, so you can register awe.some,  
> trouble.some, and fear.some. And .ous, which would allow humm.ous,  
> seri.ous, fabul.ous, etc..

Somebody on /. mentioned .dot, so you could tell someone to go to:

eych tee tee pee colon slash slash slash dot dot dot

-- 
Chris Adams <[EMAIL PROTECTED]>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: Possible explanations for a large hop in latency

[John T. Yocum]

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 AT&T (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 AT&T 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]

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 AT&T (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 AT&T 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: ICANN opens up Pandora's Box of new TLDs

[TJ]

Ah, but some are ... for trademark or brand protection usually.
I know _one_ company that paid $140k just for domain names related to a
rebranding effort.


/TJ

-Original Message-
From: Brandon Butterworth [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 26, 2008 6:59 PM
To: nanog@nanog.org
Subject: Re: ICANN opens up Pandora's Box of new TLDs

> And no, companies *aren't* "forced to pay for another domain name" 
> just because a new TLD appears -- they aren't doing it *now*

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

[Owen DeLong]

On Jun 26, 2008, at 4:30 PM, Jason Williams wrote:




3. It is somewhat anti-social to do so, but, that has rarely been a
constraint on corporate greed, especially amongst the Intelectual
Property crowd.


It doesn't seem to me to be "anti-social" behavior to ensure when your
customers mistype your domain as a .net or .de (depending on the  
customer's
locale) that they still end up at your site. Definitely, wouldn't  
ascribe it

as corporate greed.


You are welcome to ascribe it to whatever you want.  I will note that
very few Non-profit organizations engage in such behavior. Very
few governments do so, either. In fact, absent a corporate profit
motive, this behavior seems very rare.

It is my considered opinion that turning control of the Domain Name
system over to WIPO and allowing them to decide that domains
and trademarks had common namespace to ill-defined levels of
degree with different categorical mappings that also had undefined
translations was one of the biggest mistakes in internet history.

Owen

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

[Tomas L. Byrnes]

Followed by .bites 

And .rules and .rules

And so the DNS descends into anarchy, and search engines become more
empowered.

Cacophony merely empowers those who control the amp.


> -Original Message-
> From: Marshall Eubanks [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, June 26, 2008 5:20 PM
> To: Jeff Shultz
> Cc: NANOG list
> Subject: Re: ICANN opens up Pandora's Box of new TLDs
> 
> I see an auction  on that one.
> 
> Marshall
> 
> On Jun 26, 2008, at 7:56 PM, Jeff Shultz wrote:
> 
> > Owen DeLong wrote:
> >
> >> Whether some choose to do that or not, I believe that the point is
> >> that:
> >> 1.Nobody is FORCING them to do so.
> >> 2.Most are _NOT_ doing so.
> >> 3.It is somewhat anti-social to do so, but, that has rarely  
> >> been a
> >>constraint on corporate greed, especially amongst the 
> Intelectual
> >>Property crowd.
> >> Owen
> >
> > On that note, it will be very interesting to see who manages to 
> > register the *.sucks TLD, and what they do with it.
> >
> > --
> > Jeff Shultz
> >
> 
> 
> 

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

[Marshall Eubanks]

I see an auction  on that one.

Marshall

On Jun 26, 2008, at 7:56 PM, Jeff Shultz wrote:


Owen DeLong wrote:

Whether some choose to do that or not, I believe that the point is  
that:

1.Nobody is FORCING them to do so.
2.Most are _NOT_ doing so.
3.It is somewhat anti-social to do so, but, that has rarely  
been a

   constraint on corporate greed, especially amongst the Intelectual
   Property crowd.
Owen


On that note, it will be very interesting to see who manages to  
register the *.sucks TLD, and what they do with it.


--
Jeff Shultz

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

[Ken Simpson]

On that note, it will be very interesting to see who manages to  
register the *.sucks TLD, and what they do with it.


Oooh -- dibs on that one. And .some, so you can register awe.some,  
trouble.some, and fear.some. And .ous, which would allow humm.ous,  
seri.ous, fabul.ous, etc..


Oh - vomit - this is gonna hurt.

Regards,
Ken

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

[Jeff Shultz]

Owen DeLong wrote:


Whether some choose to do that or not, I believe that the point is that:

1.Nobody is FORCING them to do so.

2.Most are _NOT_ doing so.

3.It is somewhat anti-social to do so, but, that has rarely been a
constraint on corporate greed, especially amongst the Intelectual
Property crowd.

Owen




On that note, it will be very interesting to see who manages to register 
the *.sucks TLD, and what they do with it.


--
Jeff Shultz

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

[Marshall Eubanks]

On Jun 26, 2008, at 7:58 PM, Ken Simpson wrote:


This gives an (unofficial) estimate :

<http://arstechnica.com/news.ars/post/20080626-confusion-icann-opens-up-pandoras-box-of-new-tlds.html 
>


.confusion: ICANN opens up Pandora's Box of new TLDs
By Jacqui Cheng | Published: June 26, 2008 - 12:11PM CT


Not every zany TLD will be immediately available to anyone who want  
to register a domain, however. Businesses must apply to register  
the TLD first, then go through a review process to ensure that it  
isn't offensive and doesn't infringe on anyone's intellectual  
property. If approved, registering the TLD will cost anywhere from  
$100,000 to $500,000, ICANN says, and the business or organization  
must prove that they are either capable of managing the TLD or can  
reach a deal with a company that will. This is no small beans— 
unless you're planning to fork over up to half a million dollars  
and put in the labor to manage everything that appears under the  
TLD, this task is probably best left to large organizations and  
governmental entities. The organization registering the TLD will  
also be responsible for determining whether it will be restricted  
to certain types of sites or open to the public.




Thanks for the info. Okay, well that kind of pricing will prevent  
most of the fraudsters from obtaining TLDs. But of course it doesn't  
prevent shady operators from setting up a TLD with lenient abuse  
controls - such as .info or .to. Imagine 40 .infos spamming away...


What I wonder is what that amount is going to ? Is that a fee, or is it
an estimate of what it would take to set up a registrar ?

If it is the latter, GoDaddy or Network Solutions may start offering  
TLDs for a lot less. I don't see much
of an intrinsic reason why it should be more than 1 hour of person  
time to evaluate, thus a cost in the $ 100's

of USDs, plus ongoing registry costs. This

https://par.icann.org/files/paris/GNSO-gTLD-Update-Paris22jun08.pdf

makes it look like much of the process could be automated.

Regards
Marshall

Re: Possible explanations for a large hop in latency

[John T. Yocum]

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 AT&T (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 AT&T 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

[James R. Cutler]

Deep Packet Inspection engine delay. 


On Jun 26, 2008, at 6:51 PM, Frank Bulk wrote:


Our upstream provider has a connection to AT&T (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 AT&T 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




James R. Cutler
[EMAIL PROTECTED]

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

[Ken Simpson]

This gives an (unofficial) estimate :

<http://arstechnica.com/news.ars/post/20080626-confusion-icann-opens-up-pandoras-box-of-new-tlds.html 
>


.confusion: ICANN opens up Pandora's Box of new TLDs
By Jacqui Cheng | Published: June 26, 2008 - 12:11PM CT


Not every zany TLD will be immediately available to anyone who want  
to register a domain, however. Businesses must apply to register the  
TLD first, then go through a review process to ensure that it isn't  
offensive and doesn't infringe on anyone's intellectual property. If  
approved, registering the TLD will cost anywhere from $100,000 to  
$500,000, ICANN says, and the business or organization must prove  
that they are either capable of managing the TLD or can reach a deal  
with a company that will. This is no small beans—unless you're  
planning to fork over up to half a million dollars and put in the  
labor to manage everything that appears under the TLD, this task is  
probably best left to large organizations and governmental entities.  
The organization registering the TLD will also be responsible for  
determining whether it will be restricted to certain types of sites  
or open to the public.




Thanks for the info. Okay, well that kind of pricing will prevent most  
of the fraudsters from obtaining TLDs. But of course it doesn't  
prevent shady operators from setting up a TLD with lenient abuse  
controls - such as .info or .to. Imagine 40 .infos spamming away...

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

[Martin Hannigan]

 

>> 1.Nobody is FORCING them to do so.

>scammers, squaters and click collectors

> 3.It is somewhat anti-social to do so

>So are the abusers. If someone is going to it may as
>well be us (marginally less evil)

There are probably some variations based on the zone, languages, IDN'ability, 
etc., but it certainly is a good idea to be bankofamerica.* for reasons that I 
think are obvious to most of us.

-M<

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

[Marshall Eubanks]

Hello;

On Jun 26, 2008, at 7:28 PM, Ken Simpson wrote:

Has anyone been able to figure out what it will cost to secure a  
completely un-contested tld? I haven't been able to find proposed  
fees anywhere. I think it will be a practical necessity for all  
organizations to secure their own TLD at the outset, lest someone  
else secure it for them and leave it up to the court of arbitration.


.. And where, pray-tell, will the mega cash from the TLD auctions be  
going? Surely ICANN doesn't need a multi-billion $ annual budget,  
but if these TLD auctions go the way of the cellular auctions,  
there's a good potential for that kind of an outcome.




This gives an (unofficial) estimate :

<http://arstechnica.com/news.ars/post/20080626-confusion-icann-opens-up-pandoras-box-of-new-tlds.html 
>


.confusion: ICANN opens up Pandora's Box of new TLDs
By Jacqui Cheng | Published: June 26, 2008 - 12:11PM CT


Not every zany TLD will be immediately available to anyone who want to  
register a domain, however. Businesses must apply to register the TLD  
first, then go through a review process to ensure that it isn't  
offensive and doesn't infringe on anyone's intellectual property. If  
approved, registering the TLD will cost anywhere from $100,000 to  
$500,000, ICANN says, and the business or organization must prove that  
they are either capable of managing the TLD or can reach a deal with a  
company that will. This is no small beans—unless you're planning to  
fork over up to half a million dollars and put in the labor to manage  
everything that appears under the TLD, this task is probably best left  
to large organizations and governmental entities. The organization  
registering the TLD will also be responsible for determining whether  
it will be restricted to certain types of sites or open to the public.



Regards
Marshall

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

[Brandon Butterworth]

> 1.Nobody is FORCING them to do so.

scammers, squaters and click collectors

> 3.It is somewhat anti-social to do so

So are the abusers. If someone is going to it may as
well be us (marginally less evil)

brandon

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

[Jason Williams]

> 3. It is somewhat anti-social to do so, but, that has rarely been a
> constraint on corporate greed, especially amongst the Intelectual
> Property crowd.

It doesn't seem to me to be "anti-social" behavior to ensure when your
customers mistype your domain as a .net or .de (depending on the customer's
locale) that they still end up at your site. Definitely, wouldn't ascribe it
as corporate greed.

-J


Jason J. W. Williams
COO/CTO, DigiTar
http://www.digitar.com
Voice: 208.343.8520
Mobile: 208.863.0727
FAX: 208.322-8522
E-mail: [EMAIL PROTECTED]
XMPP/Jabber: [EMAIL PROTECTED]

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

[Ken Simpson]

Has anyone been able to figure out what it will cost to secure a  
completely un-contested tld? I haven't been able to find proposed fees  
anywhere. I think it will be a practical necessity for all  
organizations to secure their own TLD at the outset, lest someone else  
secure it for them and leave it up to the court of arbitration.


.. And where, pray-tell, will the mega cash from the TLD auctions be  
going? Surely ICANN doesn't need a multi-billion $ annual budget, but  
if these TLD auctions go the way of the cellular auctions, there's a  
good potential for that kind of an outcome.

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

[Owen DeLong]

On Jun 26, 2008, at 4:07 PM, Martin Hannigan wrote:




And no, companies *aren't* "forced to pay for another domain name"  
just
because a new TLD appears -- they aren't doing it *now*, by and  
large,

and thank ghod:


The last time I looked there were a few thousand companies  
protecting their intellectual property by using companies like Mark  
Monitor to insure that they had defensive registrations in all  
ccTLD's possible.


-M<



Whether some choose to do that or not, I believe that the point is that:

1.  Nobody is FORCING them to do so.

2.  Most are _NOT_ doing so.

3.  It is somewhat anti-social to do so, but, that has rarely been a
constraint on corporate greed, especially amongst the Intelectual
Property crowd.

Owen

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

[Martin Hannigan]

 

>And no, companies *aren't* "forced to pay for another domain name" just
>because a new TLD appears -- they aren't doing it *now*, by and large,
>and thank ghod: 
 
The last time I looked there were a few thousand companies protecting their 
intellectual property by using companies like Mark Monitor to insure that they 
had defensive registrations in all ccTLD's possible.
 
-M<
 
 

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

[Brandon Butterworth]

> And no, companies *aren't* "forced to pay for another domain name" just
> because a new TLD appears -- they aren't doing it *now*

Oh yes we are

brandon

Possible explanations for a large hop in latency

[Frank Bulk]

Our upstream provider has a connection to AT&T (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 AT&T 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: ICANN opens up Pandora's Box of new TLDs

[R. Irving]

Thank you people doing all the ICANN politics for destroying the 
Internet.


You know, last time someone ( Robert Metcalfe 
) prophesied the death of 
the Internet, when it didn't

come true... we made him eat his words. You up for a repeat ?

:-P


Greets,
 Jeroen

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

[Jeroen Massar]

David Conrad wrote:

On Jun 26, 2008, at 1:34 PM, Ken Simpson wrote:

How will ICANN be allocating these?



https://par.icann.org/files/paris/GNSO-gTLD-Update-Paris22jun08.pdf


and
http://www.circleid.com/posts/86262_launch_of_paris_domain_icann/
and
http://www.circleid.com/posts/86269_icann_approves_overhaul_top_level_domains/#4133

and well the rest of CircleID.

Some people are going to get very rich over this. I hope that they drown 
in the money just as the Internet will drown in all the crap TLD's, not 
even thinking of all the nice security issues which come along (home, 
mycomputer and .exe etc anyone ? :) And of course the people who like to 
grab typos will also have a field day with this.


Thank you people doing all the ICANN politics for destroying the Internet.

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature

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

[David Conrad]

On Jun 26, 2008, at 1:34 PM, Ken Simpson wrote:

How will ICANN be allocating these?



https://par.icann.org/files/paris/GNSO-gTLD-Update-Paris22jun08.pdf

Regards,
-drc

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

[Zaid Ali]

I hear from my friend's attending ICANN in Paris that there are tons  
of business folks who want to scoop up a gTLD. I haven't heard of  
anything that will be structured so looks like it will be a blood bath.


Zaid

On Jun 26, 2008, at 1:34 PM, Ken Simpson wrote:


Two years ago I posed the question here about the need for TLDs
(http://www.mcabee.org/lists/nanog/May-06/msg00110.html).
I summerizsed that companies IP (Intellectual Property) guidelines
would never allow domain.org to exist if they owned domain.com
(ibm.org vrs ibm.com).I felt that TLDs really represented a
monetary harvesting scheme as every new TLD forced companies to "pay
for yet another domain name" (slowly milking businesses).   At that
time several knowledgeable folks commented that TLDs  were necessary
in the beginning due to the need to distribute queries.   Now it
seems, ICANN has decided to add a new paradigm :-)   How will a TLD
like .ibm be handled now, and how is this different than what I
proposed in 2006?


How will ICANN be allocating these? An auction format? It will be a  
blood bath otherwise.. And for abuse and spam, this is a nightmare.

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

[Ken Simpson]

Two years ago I posed the question here about the need for TLDs
(http://www.mcabee.org/lists/nanog/May-06/msg00110.html).
I summerizsed that companies IP (Intellectual Property) guidelines
would never allow domain.org to exist if they owned domain.com
(ibm.org vrs ibm.com).I felt that TLDs really represented a
monetary harvesting scheme as every new TLD forced companies to "pay
for yet another domain name" (slowly milking businesses).   At that
time several knowledgeable folks commented that TLDs  were necessary
in the beginning due to the need to distribute queries.   Now it
seems, ICANN has decided to add a new paradigm :-)   How will a TLD
like .ibm be handled now, and how is this different than what I
proposed in 2006?


How will ICANN be allocating these? An auction format? It will be a  
blood bath otherwise.. And for abuse and spam, this is a nightmare.

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

[Jay R. Ashworth]

On Thu, Jun 26, 2008 at 04:09:30PM -0400, Jim Popovitch wrote:
> Two years ago I posed the question here about the need for TLDs
> (http://www.mcabee.org/lists/nanog/May-06/msg00110.html). I
> summerizsed that companies IP (Intellectual Property) guidelines
> would never allow domain.org to exist if they owned domain.com
> (ibm.org vrs ibm.com). I felt that TLDs really represented a monetary
> harvesting scheme as every new TLD forced companies to "pay for
> yet another domain name" (slowly milking businesses). At that time
> several knowledgeable folks commented that TLDs were necessary in the
> beginning due to the need to distribute queries. Now it seems, ICANN
> has decided to add a new paradigm :-) How will a TLD like .ibm be
> handled now, and how is this different than what I proposed in 2006?

Could someone point me to a reference (other than a very poorly written
BBC article) that suggests that .ibm is even a valid possiblity in
light of whatever ICANN actually *is* proposing?

And no, companies *aren't* "forced to pay for another domain name" just
because a new TLD appears -- they aren't doing it *now*, by and large,
and thank ghod: a) it doesn't constitute a violation of Ford Motor's
trademark that the Ford Foundation has ford.org or a Mustang club has
ford.net and b) it's horrible DNS hygiene to do that in the first
place; it re-flattens the TLD namespace.  I certainly advise my clients
not to do things that foolish.  I'm sure Randy encourages me in this.

Cheers,
-- jra
-- 
Jay R. Ashworth   Baylink  [EMAIL PROTECTED]
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

 Those who cast the vote decide nothing.
 Those who count the vote decide everything.
   -- (Joseph Stalin)

ICANN opens up Pandora's Box of new TLDs

[Jim Popovitch]

Two years ago I posed the question here about the need for TLDs
(http://www.mcabee.org/lists/nanog/May-06/msg00110.html).
I summerizsed that companies IP (Intellectual Property) guidelines
would never allow domain.org to exist if they owned domain.com
(ibm.org vrs ibm.com).I felt that TLDs really represented a
monetary harvesting scheme as every new TLD forced companies to "pay
for yet another domain name" (slowly milking businesses).   At that
time several knowledgeable folks commented that TLDs  were necessary
in the beginning due to the need to distribute queries.   Now it
seems, ICANN has decided to add a new paradigm :-)   How will a TLD
like .ibm be handled now, and how is this different than what I
proposed in 2006?

-Jim P.

Re: OS, Hardware, Network - Logging, Monitoring, and Alerting

[Alex Thurlow]

Andrew Girling wrote:


On Jun 26, 2008, at 5:22 AM, Rev. Jeffrey Paul wrote:


Hi.  I've a (theoretically) simple problem and I'm wondering how others
solve it.

I've recently deployed ~40 Linux instances on ~20 different Dell blades
and PowerEdges (we're big on virtualization), a few 7204s and 3560s, and
assorted switchable PDUs and whatnot.

We need to monitor standard things like cpu, memory, disk usage on all
OSes.  This is straightforward with net-snmp.  It would also be cool if
I could monitor more esoteric things, like ntp synchronization status,
i/o statistics, etc.

Other stuff we really need to keep an eye on is hardware - redundant
PSU status in our 7204s and Dells, temperatures and voltages (one of
our colos in New York peaked at over 40C a few weeks ago, for
instance), and disk array status (I'd like to know of a failed disk
in a hardware RAID5 before I get calls about performance issues).  Our
blade chassis have DRACs in them and I think they export this data via
SNMP (I'm trying to avoid the use of SNMP traps), but not all of our
other PowerEdges have the DRACs in them so some of this information may
need to be pulled via IPMI from within the host OS.  Presumably the
Cisco gear makes the temperature available via SNMP.

Finally, service checks - standard stuff (dns, http, https, ssh, smtp).

Now, to the questions.

1) Is SNMP the best way to do this?  Obviously some of the data (service
checks) will need to be collected other ways.

2) Is there any good solution that does both logging/trending of this
data and also notification/monitoring/alerting?  I've used both Nagios
and Cacti in the past, and, due to the number of individual things being
monitored (3-5 items per OS instance, 5-10 items per physical server,
10-50 things per network device), setting them both up independently
seems like a huge pain.  Also, I've never really liked Nagios that much.

I recently entertained the idea of writing a CGI that output all of this
information in a standard format (csv?), distributing and installing 
it, then

collecting it periodically at a central location and doing all the
rrd/notification myself, but then realized that this problem must've
been solved a million times already.

There's got to be a better way.  What do you guys use?

(I'm not opposed to non-free solutions, provided they work better.)



You may want to have a look at Zenoss, http://www.zenoss.com/

Cheers,
Andrew




I have to second the Zenoss recommendation.  Fairly automatic setup for 
most things, great categorization and it will incorporate nagios plugins 
or any script that outputs in that format.


It's free, but you can also buy support or install service from them.



--
Alex Thurlow
Technical Director
Blastro Networks

Re: OS, Hardware, Network - Logging, Monitoring, and Alerting

[Laurence F. Sheldon, Jr.]

Rev. Jeffrey Paul wrote:

Hi.  I've a (theoretically) simple problem and I'm wondering how others
solve it.


Taken one at a time, mos of them are simple.  Most of life is like that.



1) Is SNMP the best way to do this?  Obviously some of the data (service
checks) will need to be collected other ways.


I've actually been out of the admin biz for some time but back in the 
day I was very found of SNMP tools for all sorts of reporting.


For output I liked MRTG for most things, WhatsUpGold had some nice 
features if you would rather pay money.


For alarms, I used some unix hack or another (home-made).

I also used home-made hacks to gather data about things that did not 
have a suitable SNMP interface.



2) Is there any good solution that does both logging/trending of this
data and also notification/monitoring/alerting?  I've used both Nagios
and Cacti in the past, and, due to the number of individual things being
monitored (3-5 items per OS instance, 5-10 items per physical server,
10-50 things per network device), setting them both up independently
seems like a huge pain.  Also, I've never really liked Nagios that much.


See MRTG, RRD, et al.


I recently entertained the idea of writing a CGI that output all of this
information in a standard format (csv?), distributing and installing it, then
collecting it periodically at a central location and doing all the
rrd/notification myself, but then realized that this problem must've
been solved a million times already.

There's got to be a better way.  What do you guys use?


I had the luxury of management that thought managing was a good idea, so 
I had a machine pretty much dedicated to systems management and all the 
machines (including routers, bridges, hubs, and such) reported to it. 
We had a web interface to the MRTG and MRTG-like presentations.



(I'm not opposed to non-free solutions, provided they work better.)


Just before the fired me for being too old, they bought all the HP and 
cisco stuff in the world.  I do not recommend any of it.

--
Requiescas in pace o email  Two identifying characteristics
 of System Administrators:
Ex turpi causa non oritur actioInfallibility, and the ability to
 learn from their mistakes.
Eppure si rinfresca

ICBM Targeting Information: http://tinyurl.com/4sqczs

AW: OS, Hardware, Network - Logging, Monitoring, and Alerting

[Tom Quilling]

hi jeffrey

I personally prefer hobbit over cacti and nagios

http://sourceforge.net/projects/hobbitmon/
http://hobbitmon.sourceforge.net/


Thomas Quilling
NCIR GmbH
Network, Consulting & Internet Services
Munich / Germany
[EMAIL PROTECTED]





-Ursprungliche Nachricht-
Von: Rev. Jeffrey Paul [mailto:[EMAIL PROTECTED] 
Gesendet: Donnerstag, 26. Juni 2008 11:22
An: nanog@nanog.org
Betreff: OS, Hardware, Network - Logging, Monitoring, and Alerting

Hi.  I've a (theoretically) simple problem and I'm wondering how others
solve it.

I've recently deployed ~40 Linux instances on ~20 different Dell blades
and PowerEdges (we're big on virtualization), a few 7204s and 3560s, and
assorted switchable PDUs and whatnot.  

We need to monitor standard things like cpu, memory, disk usage on all
OSes.  This is straightforward with net-snmp.  It would also be cool if
I could monitor more esoteric things, like ntp synchronization status,
i/o statistics, etc.

Other stuff we really need to keep an eye on is hardware - redundant 
PSU status in our 7204s and Dells, temperatures and voltages (one of
our colos in New York peaked at over 40C a few weeks ago, for 
instance), and disk array status (I'd like to know of a failed disk 
in a hardware RAID5 before I get calls about performance issues).  Our
blade chassis have DRACs in them and I think they export this data via
SNMP (I'm trying to avoid the use of SNMP traps), but not all of our
other PowerEdges have the DRACs in them so some of this information may
need to be pulled via IPMI from within the host OS.  Presumably the
Cisco gear makes the temperature available via SNMP.

Finally, service checks - standard stuff (dns, http, https, ssh, smtp).

Now, to the questions.

1) Is SNMP the best way to do this?  Obviously some of the data (service
checks) will need to be collected other ways.

2) Is there any good solution that does both logging/trending of this
data and also notification/monitoring/alerting?  I've used both Nagios
and Cacti in the past, and, due to the number of individual things being
monitored (3-5 items per OS instance, 5-10 items per physical server,
10-50 things per network device), setting them both up independently
seems like a huge pain.  Also, I've never really liked Nagios that much.

I recently entertained the idea of writing a CGI that output all of this
information in a standard format (csv?), distributing and installing it,
then
collecting it periodically at a central location and doing all the
rrd/notification myself, but then realized that this problem must've
been solved a million times already.

There's got to be a better way.  What do you guys use?

(I'm not opposed to non-free solutions, provided they work better.)

Cheers,
-jp

-- 

 Rev. Jeffrey Paul-datavibe- [EMAIL PROTECTED]
  aim:x736e65616b   pgp:0xD9B3C17D  phone:1-800-403-1126
   9440 0C7F C598 01CA 2F17  D098 0A3A 4B8F D9B3 C17D
"Virtue is its own punishment."

Re: OS, Hardware, Network - Logging, Monitoring, and Alerting

[Andrew Girling]

On Jun 26, 2008, at 5:22 AM, Rev. Jeffrey Paul wrote:

Hi.  I've a (theoretically) simple problem and I'm wondering how  
others

solve it.

I've recently deployed ~40 Linux instances on ~20 different Dell  
blades
and PowerEdges (we're big on virtualization), a few 7204s and 3560s,  
and

assorted switchable PDUs and whatnot.

We need to monitor standard things like cpu, memory, disk usage on all
OSes.  This is straightforward with net-snmp.  It would also be cool  
if

I could monitor more esoteric things, like ntp synchronization status,
i/o statistics, etc.

Other stuff we really need to keep an eye on is hardware - redundant
PSU status in our 7204s and Dells, temperatures and voltages (one of
our colos in New York peaked at over 40C a few weeks ago, for
instance), and disk array status (I'd like to know of a failed disk
in a hardware RAID5 before I get calls about performance issues).  Our
blade chassis have DRACs in them and I think they export this data via
SNMP (I'm trying to avoid the use of SNMP traps), but not all of our
other PowerEdges have the DRACs in them so some of this information  
may

need to be pulled via IPMI from within the host OS.  Presumably the
Cisco gear makes the temperature available via SNMP.

Finally, service checks - standard stuff (dns, http, https, ssh,  
smtp).


Now, to the questions.

1) Is SNMP the best way to do this?  Obviously some of the data  
(service

checks) will need to be collected other ways.

2) Is there any good solution that does both logging/trending of this
data and also notification/monitoring/alerting?  I've used both Nagios
and Cacti in the past, and, due to the number of individual things  
being

monitored (3-5 items per OS instance, 5-10 items per physical server,
10-50 things per network device), setting them both up independently
seems like a huge pain.  Also, I've never really liked Nagios that  
much.


I recently entertained the idea of writing a CGI that output all of  
this
information in a standard format (csv?), distributing and installing  
it, then

collecting it periodically at a central location and doing all the
rrd/notification myself, but then realized that this problem must've
been solved a million times already.

There's got to be a better way.  What do you guys use?

(I'm not opposed to non-free solutions, provided they work better.)



You may want to have a look at Zenoss, http://www.zenoss.com/

Cheers,
Andrew

Re: OS, Hardware, Network - Logging, Monitoring, and Alerting

[Phil Regnauld]

Rev. Jeffrey Paul (sneak) writes:
> 
> 1) Is SNMP the best way to do this?  Obviously some of the data (service
> checks) will need to be collected other ways.

SNMP, the vendor MIBs + SNMP extensions for monitoring hardware 
specifics
(PSU, etc...), and something like Nagios to do the TCP/network checks.

> 2) Is there any good solution that does both logging/trending of this
> data and also notification/monitoring/alerting?  I've used both Nagios
> and Cacti in the past, and, due to the number of individual things being
> monitored (3-5 items per OS instance, 5-10 items per physical server,
> 10-50 things per network device), setting them both up independently
> seems like a huge pain.  Also, I've never really liked Nagios that much.

Well, you could look at Zabbix, Hyperic, ZenOSS, OpenNMS and see if
they cut it better for you, but the trick with Nagios is to use
a DB and generate the include files automatically, then have some
other more user friendly tools to populate the DB.  Or use templates
extensively.

Then make sure your plugins output performance data for perf.data
monitoring, and use something like NagiosGraph
http://nagiosgraph.wiki.sourceforge.net/ or PNP4Nagios:

http://www.pnp4nagios.org/pnp/about#system_requirements
http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN203
http://www.pnp4nagios.org/pnp/screenshots


> I recently entertained the idea of writing a CGI that output all of this
> information in a standard format (csv?), distributing and installing it, then
> collecting it periodically at a central location and doing all the
> rrd/notification myself, but then realized that this problem must've
> been solved a million times already.

Yes :)  But check out the above links, and with a bit of planning
and a small amount of coding/adapting existing components, it will
work out.

> There's got to be a better way.  What do you guys use?

We rewrote our own NMS from scratch :)

> (I'm not opposed to non-free solutions, provided they work better.)

We sell our solution, so I'm biased, but do check out the Nagios
route, it works well enough for small to medium, and larger 
installations
with careful planning (problem with Nagios is how to make it perform
with thousands of hosts).

Hth,
Phil

OS, Hardware, Network - Logging, Monitoring, and Alerting

[Rev. Jeffrey Paul]

Hi.  I've a (theoretically) simple problem and I'm wondering how others
solve it.

I've recently deployed ~40 Linux instances on ~20 different Dell blades
and PowerEdges (we're big on virtualization), a few 7204s and 3560s, and
assorted switchable PDUs and whatnot.  

We need to monitor standard things like cpu, memory, disk usage on all
OSes.  This is straightforward with net-snmp.  It would also be cool if
I could monitor more esoteric things, like ntp synchronization status,
i/o statistics, etc.

Other stuff we really need to keep an eye on is hardware - redundant 
PSU status in our 7204s and Dells, temperatures and voltages (one of
our colos in New York peaked at over 40C a few weeks ago, for 
instance), and disk array status (I'd like to know of a failed disk 
in a hardware RAID5 before I get calls about performance issues).  Our
blade chassis have DRACs in them and I think they export this data via
SNMP (I'm trying to avoid the use of SNMP traps), but not all of our
other PowerEdges have the DRACs in them so some of this information may
need to be pulled via IPMI from within the host OS.  Presumably the
Cisco gear makes the temperature available via SNMP.

Finally, service checks - standard stuff (dns, http, https, ssh, smtp).

Now, to the questions.

1) Is SNMP the best way to do this?  Obviously some of the data (service
checks) will need to be collected other ways.

2) Is there any good solution that does both logging/trending of this
data and also notification/monitoring/alerting?  I've used both Nagios
and Cacti in the past, and, due to the number of individual things being
monitored (3-5 items per OS instance, 5-10 items per physical server,
10-50 things per network device), setting them both up independently
seems like a huge pain.  Also, I've never really liked Nagios that much.

I recently entertained the idea of writing a CGI that output all of this
information in a standard format (csv?), distributing and installing it, then
collecting it periodically at a central location and doing all the
rrd/notification myself, but then realized that this problem must've
been solved a million times already.

There's got to be a better way.  What do you guys use?

(I'm not opposed to non-free solutions, provided they work better.)

Cheers,
-jp

-- 

 Rev. Jeffrey Paul-datavibe- [EMAIL PROTECTED]
  aim:x736e65616b   pgp:0xD9B3C17D  phone:1-800-403-1126
   9440 0C7F C598 01CA 2F17  D098 0A3A 4B8F D9B3 C17D
"Virtue is its own punishment."