ALTDB.NET DNS?

2009-03-09 Thread Jeff S Wheeler
I notice the ALTDB.NET DNS has been updated, and WWW.ALTDB.NET goes to a
GoDaddy "parked domain" landing page, and also, email bounces.  Jacked?

--
Jeff




Re: ALTDB.NET DNS?

2009-03-09 Thread Jeremy Gaddis
On Mon, Mar 9, 2009 at 2:26 AM, Jeff S Wheeler  wrote:
> I notice the ALTDB.NET DNS has been updated, and WWW.ALTDB.NET goes to a
> GoDaddy "parked domain" landing page, and also, email bounces.  Jacked?

$ whois altdb.net | grep Expiration
   Expiration Date: 08-mar-2009

-- 
Jeremy L. Gaddis
http://evilrouters.net/



Re: ALTDB.NET DNS?

2009-03-09 Thread Steve Rubin

Jeremy Gaddis wrote:

On Mon, Mar 9, 2009 at 2:26 AM, Jeff S Wheeler  wrote:

I notice the ALTDB.NET DNS has been updated, and WWW.ALTDB.NET goes to a
GoDaddy "parked domain" landing page, and also, email bounces.  Jacked?


$ whois altdb.net | grep Expiration
   Expiration Date: 08-mar-2009



Whoops.  Sorry about that.  It's been renewed.

--
Steve Rubin  / AE6CH   /   http://www.altdb.net/
Email: s...@tch.org  /  N6441C  /   http://www.tch.org/~ser/




Re: Usage-Based Billing for DIA

2009-03-09 Thread Sam Stickland

Jon Lewis wrote:

On Thu, 5 Mar 2009, Rodriguez, Mauricio wrote:

Looking at possibilities for an implementation of usage-based 
billing, it seems that the same techniques and tools always come up.  
I'm looking for some feedback from the list on experiences with these 
tools and techniques as well as alternatives that may not be listed 
here.


+Techniques
   --Flow data (Netflow, SFlow, etc) analysis to 
determine 95th percentile traffic levels
   --SNMP polling of interface counters to determine 95th 
percentile traffic levels



I need to look into this in the near future as well.  The problems I'm 
aware of are:


1) we have customers on policed ports, and the interface snmp counters 
count packets before service-policy.  It doesn't seem right to bill 
for packets we dropped :)...so this isn't useful data for billing 
purposes.


Torrus (www.torrus.org) can use the Cisco MIBs to graph pre and 
post-policy packets.


http://www.torrus.org/plugins/tp-cisco-cbqos.pod.html

Sam



RE: Network SLA

2009-03-09 Thread Holmes,David A
We use BRIX for SLA's by measuring round trip times, jitter, and packet
loss across all of our backbone links. In conjunction with a traffic
generator to add background traffic, and potentially invoke queueing on
interfaces, we have found that BRIX enables us to accurately predict the
behavior of new applications, particularly multicast and HD video,
without the need to implement elaborate QoS configurations. BRIX is now
owned by EXFO, a fiber optic test equipment manufacturer. Low values for
rtt, jitter, and packet loss imply a relatively queue-free network,
which makes confident predictions about network behavior easier.
When we last looked at the technology, the Cisco IP SLA probes did not
capture a random distribution of network events, as the probes are
triggered every N minutes. BRIX randomizes the probes within a
configurable window, so that, over time, all time intervals are covered
by the accumulated probes. 

 

-Original Message-
From: Saqib Ilyas [mailto:msa...@gmail.com] 
Sent: Saturday, March 07, 2009 3:12 AM
To: nanog@nanog.org
Subject: Re: Network SLA

I must thank everyone who has answered my queries. Just a couple more
short questions.
For instance, if one is using MRTG, and wants to check if we can meet
a 1 Mbps end-to-end throughput between a couple of customer sites, I
believe you would need to use some traffic generator tools, because
MRTG merely imports counters from routers and plots them. Is that
correct?
We've heard of the BRIX active measurement tool in replies to my
earlier email. Also, I've found Cisco IP SLA that also sends traffic
into the service provider network and measures performance. How many
people really use IP SLA feature?
Thanks and best regards

On Mon, Feb 23, 2009 at 1:19 PM, Zartash Uzmi  wrote:
> As I gather, there is a mix of answers, ranging from "building the
resources
> according to requirements and HOPE for the best" to "use of arguably
> sophisticated tools and perhaps sharing the results with the legal
> department".
>
> I would be particularly interested in hearing the service providers'
> viewpoint on the following situation.
>
> Consider a service provider with MPLS deployed within its own network.
>
> (A) When the SP enters into a relation with the customer, does the SP
> establish new MPLS paths based on customer demands (this is perhaps
similar
> to "building" based on requirements as pointed out by David)? If yes,
> between what sites/POPs? I assume the answer may be different
depending upon
> a single-site customer or a customer with multiple sites.
>
> (B) For entering into the relationship for providing X units of
bandwidth
> (to another site of same customer or to the Tier-1 backbone), does the
SP
> use any wisdom (in addition to MRTG and the likes)? If so, what
scientific
> parameters are kept in mind?
>
> (C) How does the customer figure out that a promise for X units of
bandwidth
> is maintained by the SP? I believe customers may install some
measuring
> tools but is that really the case in practice?
>
> Thanks,
> Zartash
>
> On Fri, Feb 20, 2009 at 1:16 AM, Stefan  wrote:
>
>> Saqib Ilyas wrote:
>>
>>> Greetings
>>> I am curious to know about any tools/techniques that a service
provider
>>> uses
>>> to assess an SLA before signing it. That is to say, how does an
>>> administrator know if he/she can meet what he is promising. Is it
based on
>>> experience? Are there commonly used tools for this?
>>> Thanks and best regards
>>>
>>>
>> Not necessarily as a direct answer (I am pretty sure there'll be
others on
>> this list giving details in the area of specific tools and
standards), but I
>> think this may be a question (especially considering your end result
>> concern: *signing the SLA!) equally applicable to your legal
department. In
>> the environment we live, nowadays, the SLA could (should?!? ...
>> unfortunately) be "refined" and (at the other end - i.e. receiving)
>> "interpreted" by the lawyers, with possibly equal effects (mostly
financial
>> and as overall impact on the business) as the tools we (the technical
>> people) would be using to measure latency, uptime, bandwidth, jitter,
etc...
>>
>> Stefan
>>
>>
>



-- 
Muhammad Saqib Ilyas
PhD Student, Computer Science and Engineering
Lahore University of Management Sciences




Re: Network SLA

2009-03-09 Thread Charles Wyble
What products/services do you use for traffic generation?  Also what 
sort of testing methodology do you use? As for random probes that 
certainly seems like a nice feature.


Holmes,David A wrote:

We use BRIX for SLA's by measuring round trip times, jitter, and packet
loss across all of our backbone links. In conjunction with a traffic
generator to add background traffic, and potentially invoke queueing on
interfaces, we have found that BRIX enables us to accurately predict the
behavior of new applications, particularly multicast and HD video,
without the need to implement elaborate QoS configurations. BRIX is now
owned by EXFO, a fiber optic test equipment manufacturer. Low values for
rtt, jitter, and packet loss imply a relatively queue-free network,
which makes confident predictions about network behavior easier.
When we last looked at the technology, the Cisco IP SLA probes did not
capture a random distribution of network events, as the probes are
triggered every N minutes. BRIX randomizes the probes within a
configurable window, so that, over time, all time intervals are covered
by the accumulated probes.




--
Charles N Wyble char...@thewybles.com
(818)280-7059 http://charlesnw.blogspot.com
CTO SocalWiFI.net