NFSen plugin - ddd

[Andrew Jones]

Hi All,
Does anyone have a copy of the DDoS detection plugin for NFSen called ddd
that they could send to me?
According to a blog article [1] I read, it used to be available at [2].
It's not there, and I haven't had any luck trying to track it down the
usual ways. If anyone is able to provide a copy, I'd appreciate it.
Thanks,
Jonesy


[1] http://www.ccieflyer.com/2010-01-JasonRowley.php
[2] http://www.synacknetworks.com/ddd/ddd.zip

Re: Update from the NANOG Communications Committee regarding recent off-topic posts

[Rhys Rhaven]

On 07/30/2012 09:23 PM, Allen McKinley Kitchen (gmail) wrote:
> On Jul 30, 2012, at 15:04, joel jaeggli  wrote:
>
>> On 7/30/12 10:57 AM, Steven Noble wrote:
>>> The fix for this issue is trivial. Every new signup ...
>> Most of the subscribers to the mailing list never post.
>>
> +1 (from an inveterate but VERY appreciative lurker)
>
> ..Allen
>
I run a tiny network, no AS number. I try to build interesting features
into my local hackerspace's network from what I find here. I don't post
because I don't have useful experience to the size/scale of what is
posted here. I don't know what your organization is really nor where you
meet or who any of you are.

But even in my small network, I have picked up 10x more operational
knowledge here than what I learned from courses and classes, which
always seem to push you to use X just because it exists or because its
from a specific company.

I guess I mean to say thanks, for the knowledge and the moderation. If
most are like me, this will make it nicer to read. (except those people
whos email client breaks Thunderbird's threading system. no kudos for
them.)

Re: Update from the NANOG Communications Committee regarding recent off-topic posts

[George Herbert]

Friends don't let friends binary shift.

On Thu, Aug 2, 2012 at 2:47 PM, Jamie Bowden  wrote:
> What's an order of magnitude between friends?
>
> Very occasionally yours,
>
> --
> Jamie Bowden(ja...@photon.com)
> Sr. Sys. Admin. (703) 243-6613 x3848
> Photon Research Associates, Inc.
> 1616 Fort Myer Drive, Suite 1000
> Arlington, VA 22209
>
>> -Original Message-
>> From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu]
>> Sent: Thursday, August 02, 2012 4:56 PM
>> To: Robert Drake
>> Cc: nanog@nanog.org
>> Subject: Re: Update from the NANOG Communications Committee regarding
>> recent off-topic posts
>>
>> On Thu, 02 Aug 2012 16:25:56 -0400, Robert Drake said:
>>
>> > Percentages:  5804/54166=1% of posts from low contributors.
>>
>> I suspect you fat-fingered something -  I get 10.7%, not 1%, for that
>> calculation...
>
>



-- 
-george william herbert
george.herb...@gmail.com

RE: Update from the NANOG Communications Committee regarding recent off-topic posts

[Jamie Bowden]

What's an order of magnitude between friends?

Very occasionally yours,

-- 
Jamie Bowden(ja...@photon.com)
Sr. Sys. Admin. (703) 243-6613 x3848
Photon Research Associates, Inc.
1616 Fort Myer Drive, Suite 1000
Arlington, VA 22209

> -Original Message-
> From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu]
> Sent: Thursday, August 02, 2012 4:56 PM
> To: Robert Drake
> Cc: nanog@nanog.org
> Subject: Re: Update from the NANOG Communications Committee regarding
> recent off-topic posts
> 
> On Thu, 02 Aug 2012 16:25:56 -0400, Robert Drake said:
> 
> > Percentages:  5804/54166=1% of posts from low contributors.
> 
> I suspect you fat-fingered something -  I get 10.7%, not 1%, for that
> calculation...

Re: Update from the NANOG Communications Committee regarding recent off-topic posts

[valdis . kletnieks]

On Thu, 02 Aug 2012 16:25:56 -0400, Robert Drake said:

> Percentages:  5804/54166=1% of posts from low contributors.

I suspect you fat-fingered something -  I get 10.7%, not 1%, for that
calculation...



pgpGDidhtOsTj.pgp
Description: PGP signature

Re: Update from the NANOG Communications Committee regarding recent off-topic posts

[Robert Drake]

On 7/30/2012 1:42 PM, Patrick W. Gilmore wrote:

I'm sorry Panashe is upset by this rule.  Interestingly, "Your search - Panashe 
Flack nanog - did not match any documents."  So my guess is that a post from that 
account has not happened before, meaning the post was moderated yet still made it through.

Has anyone done a data mining experiment to see how many posts a month are from 
"new" members?  My guess is it is a trivial percentage.



Ignoring many harder to determine things like "who has changed their 
email address" and reducing it to simple shell commands, I got this:


for i in `cat ../nanog_archive_index.html | grep txt | cut -f2 -d\"` ; 
do wget http://mailman.nanog.org/pipermail/nanog/$i; done
du -sh=41M (uncompressed=100M).  That seems small for all the mail since 
random 2007 but I'd rather use an official archive so people can 
duplicate results and refine things.

 grep -h "^From: " * |  sort | uniq -c | sort -nr

First of all I will say Owen is winning by a fair margin:

   1562 From: owen at delong.com (Owen DeLong)
929 From: randy at psg.com (Randy Bush)
775 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
688 From: morrowc.lists at gmail.com (Christopher Morrow)
621 From: jbates at brightok.net (Jack Bates)
558 From: jra at baylink.com (Jay Ashworth)
480 From: gbonser at seven.com (George Bonser)
450 From: patrick at ianai.net (Patrick W. Gilmore)
446 From: cidr-report at potaroo.net (cidr-report at potaroo.net)

Total count:
grep -h "^From: " * | wc -l
54166

# Totals for < 10 contributors
for i in 1 2 3 4 5 6 7 8 9; do grep -h "^From: " * | sort | uniq -c | 
sort -nr | grep "  $i" | wc -l; done

3129

552
319
208
157
131
103
94

Total for less than 10 posts contributors:  5804

Percentages:  5804/54166=1% of posts from low contributors.

# shows the number of people who've contributed that number of times.
grep -h "^From: " * | sort | uniq -c | sort -nr | awk '{print $1}' | 
uniq -c | sort -nr


# another interesting thing to look at is posts by month per user 
(dropping the -h from grep):

grep "^From: " * | sort | uniq -c | sort -nr

# not the most efficient, but tells you who posted the most in a month:
for i in *; do grep "^From: " * | sort | uniq -c | sort -nr | grep $i | 
head -n 1; done


# Per month, how many single post contributions happen/total.  The 
numbers can be higher here since people who posted in a different month 
may still be counted as a new contributor
 for i in *; do echo -n "$i "; grep "^From: " $i | sort | uniq -c | 
sort -nr | grep "  1 " | wc -l | tr '\n' '/'; grep "^From: " $i | wc 
-l ; done

Re: Fwd: Re: DOCSIS 3.0 & PPPoE/L2TP compatibility

[Scott Helms]

Brian,

That's only true if you want to truly implement transparent LAN 
services over DOCSIS.  Separating the CPE data flow works with any 
DOCSIS 1.0 or better modem since all of the tricky parts are in the 
CMTS.  We took a municipal cable network through 3 different CMTSs (3Com 
and then a Terayon Be2k and finally an Arris C4).  The first two did 
PPPoE hand off to a Redback to act as the LNS and when they wanted to 
move up to a bigger CMTS the city choose Arris and PPPoE stopped being 
an option.  In short, replacing the modems isn't a requirement unless 
the modem has to pass up the TLS data, which isn't the case in an open 
access ISP scenario.


On 8/1/2012 3:40 PM, Brian Mengel wrote:

One thing to be mindful of is that BSoD support may not be prevelant
in the installed modem base of your MSO.  Replacing those modems would
be costly for someone.

On Wed, Aug 1, 2012 at 10:17 AM, iptech  wrote:

Hi Scott,

Thanks for the feedback,

yes this is how I understand it also, however I find it strange that the
Cisco platform designated as the future LNS will not accommodate the DOCSIS
3.0requirements - not much collaboration. There is no roadmap for
introcducing PPTP on the ASR1K that I can see, so i will not be holding out
for one.

I am veering towards using a L2 pw solution, but would be interested to hear
what you have used in-house yourself to accommodate this change, care to
share?

Thanks


On 7/31/2012 5:46 PM, Scott Helms wrote:












I've actually run into this specific problem and the issue your running
into is that at no time was PPPoE part of the DOCSIS specification.  It
was supported on several CMTSs  because the Cisco UBR shares much of its
OS with more mainline Cisco routers which support L2TP and a host of
other non-DOCSIS related protocols.  It was also widely supported on
some of the earliest CMTSs which were bridges instead of routers (then
you needed a separate box to be the LNS).  The real problem isn't a
change in DOCSIS version but that they choose a platform that doesn't
share a code base with a general purpose router. This could have been
happenstance or by design, but I can tell you your chances of getting
PPPoE to work at all on that platform (even for the cable operator) are
not high because the box will not operate as a bridge and there is no
(AFAIK) way to relay the PPP discover packets.

The D3 Arris is either a C4 or a C4C:
http://www.arrisi.com/products/product.asp?id=3

On 7/30/2012 8:33 AM, iptech wrote:

Hi,

We are a small ISP and have a setup in place with the local cable
company for terminating their users via L2TP for Internet access.
However they have just announced to us that they are moving to a
DOCSIS 3.0 compliant setup, and this standard no longer supports PPPoE
via L2TP, and can now only offer PPTP for terminating with us.

We have already begun replacing our Cisco 7206VXR LNS devices with
Cisco ASR 1Ks and as you will be aware the older 7206 can do both L2TP
and PPTP, whereas the ASR1k can do only L2TP. I do not have any
experience in the cable arena, but from what I have read in the DOCSIS
standards, each version has maintained backwards compatibility,
therefore I am very surprised our CableCo has claimed they cannot do
PPPoE/L2TP anymore.

The CMTS they are currently using is a Cisco, and now they are moving
to a new ARRIS CMTS. I have not been able to find any information on
this device and what it can do or not. With the ASR1K marked as the
natural upgrade path for LNS functions, therefore I cannot believe
that it is not fully compatible with DOCSIS 3.0.

 From what I can tell the only way to accommodate the new CMTS PPTP
connections will be to terminate them on the legacy 7206VXR, which at
the end of the day is a backwards step. I would greatly appreciate if
anyone can give me any pointers and/or suggestions on this matter, so
I can understand it and move it forward.

FYI: The driver for the CMTS upgrades is to offer higher bandwidth
access speeds 15mb-20mb.

Thank you.












--
Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms

Re: Is Hotmail in the habit of ignoring MX records?

[William Herrin]

On Mon, Jul 30, 2012 at 4:26 PM,   wrote:
> On Mon, 30 Jul 2012 10:07:37 -1000, William Herrin said:
>> If you can reference where in the SMTP RFC it offers an authoritative
>> explanation what to do when merging results from various naming
>> systems where one but not all of the naming systems has generated an
>> error then let's read it.
>
> RFC5321, section 5.1 is pretty clear on it:
>
> 5.1.  Locating the Target Host
>
>Once an SMTP client lexically identifies a domain to which mail will
>be delivered for processing (as described in Sections 2.3.5 and 3.6),
>a DNS lookup MUST be performed to resolve the domain name (RFC 1035
>[2]).  The names are expected to be fully-qualified domain names
>(FQDNs): mechanisms for inferring FQDNs from partial names or local
>aliases are outside of this specification.

Well there you have it. Mechanisms for determining whether a name is
intended to be acquired from the DNS are _outside the scope of the
RFC_. So, the specifics of merging results from multiple naming
systems is left to the implementer without IETF guidance. Clear as
mud. And when the RFC goes on to say:

> If an empty list of MXs is returned,
> the address is treated as if it was associated with an implicit MX
> RR, with a preference of 0, pointing to that host.

one reasonable interpretation is that MX-type lookups only apply to
lookups from the DNS system, another is that both the MX lookup and
host lookup have to come from the same naming system, and a third
reasonable interpretation is that they do not. And that's true even
though the RFC also says:

> If a temporary error is returned, the message MUST be queued
> and retried later

because the MTA *did* successfully acquire the _implicit MX_ from one
of the name systems it uses.

Chalk this up as a point that "needs work" in the next XX21 RFC.


> The Internet uses DNS.  You use some other scheme at your own peril,
> and probably shouldn't expect said other scheme to work outside the
> range of your administrative control.

"The Internet" uses a far broader set of technologies than you give it
credit for. And it routinely uses the DNS badly. Structure your
systems with that understanding or pay for your negligence with
malfunction.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Is Hotmail in the habit of ignoring MX records?

[Tony Finch]

The relevant spec is RFC 5321 section 5.

Tony.
--
f.anthony.n.finchhttp://dotat.at/

On 31 Jul 2012, at 03:27, Jimmy Hess  wrote:
> 
> Aside from that RFC974 [Page 3] gives mailers significant leeway in
> deciding how to handle errors:

RE: cost of misconfigurations

[Brandt, Ralph]

The misconfiguration cost is usually not calculable in itself.  But I
think the more important issue is, "How do we prevent it?"  I would
spend more time on prevention than assessing the cost.

I can think of several minor provisioning issues that cost us more in
customer relations than everything else put together and a couple
significant ones that seemed like nothing happened.  And I am not sure I
could have predicted the outcome the day before the event if someone had
handed me the scenario to assess it.  Reason, when it happens the
CURRENT situation is as much a driver of the impact as is the actual
event.  It even goes back to the emotional state of the customer and
maybe if his toast was burned this morning, if he/she had a fight with
the spouse, who flipped him the bird during his drive in and a lot of
other things that dictate mental state.  

I would be very lax to use a vendor who is taking an approach that all
they are concerned about is what an error costs them. I want them to be
more concerned about what that costs their customer (me) and what they
can do to prevent it.

Proper Prior Preparation Prevents Piss Poor Performance. 

Training, sound processes, good management practices, good maintenance,
good personnel selection go a long way.  

To quote Chief Gassaway (fire chief with good stuff on the web for any
business) "Luck validates bad practices."  The REB translation, "We did
it this way for years and nothing bad happened."  

In Chief Gassaway's business, bad practices cause Line of Duty Deaths.
In ours it causes outages, lost revenue and possibly bankruptcy.
Remember, if your company goes belly up, you are out of a job...

http://www.samatters.com/2012/07/31/positive-reinforcement-of-undesirabl
e-behavior/
 

Ralph Brandt

-Original Message-
From: George Herbert [mailto:george.herb...@gmail.com] 
Sent: Wednesday, August 01, 2012 9:17 PM
To: Diogo Montagner
Cc: nanog@nanog.org
Subject: Re: cost of misconfigurations

On Wed, Aug 1, 2012 at 5:32 PM, Diogo Montagner
 wrote:
> Hi Darius,
>
> You are right. The lost of a customer due to those things. However, I
> would classify this as an unknown situation (in terms of risk
> analisys) because the others I mentioned are possible to calculate and
> estimate (they are known). But it is very hard to estimate if a
> customer will cancel the contract because 1 or n network outages. In
> theory, if the customer SLA is not being met consecutively, there is a
> potential probability he will cancel the contract.
>
> Regards

On the end customer side, I've done a bunch of reliability / risk cost
assessments for various customers over the years.  It's never easy.

For an ISP... customers are fairly locked in, but for big networks and
customers, especially multihoming customers, business goes where they
want it.

SLA costs are easy.  Predicting the final financial impact is hard.


-- 
-george william herbert
george.herb...@gmail.com

Re: Level3 (3356/3549) changes routing policy

[Adrian M]

Better to use communities instead.
On Aug 2, 2012 11:34 AM, "Fredy Kuenzler"  wrote:

> From my observation Level3 has recently changed their routing policy. It
> seems that 3356 always prefers customer prefixes of 3549, regardless of the
> AS path length. Example (seen from 3356):
>
> 3549_13030_[Customer1]_[**Customer2]
>
> is preferred over
>
> 2914_[Customer1]_[Customer2]
>
> Considering that both 2914 and 3549 are peers of 3356, and 13030 is a
> customer of 3549, 3356 seems to give higher local-pref on the longer
> AS-path, likely to increase traffic and revenue of their sister network
> 3549.
>
> Certainly it's common practice to overrule the BGP4 default behaviour, and
> widely used by smaller networks.
>
> Still I'm surprised that it happened obviously rather undetected, at
> least, to my knowledge, Level3 did implement it silently and hasn't
> published an official statement or customer announcement, which I think,
> would have been fair, at least.
>
> Considering that Level3 3356 and 3549 are by far the largest networks
> globally this decision must have a large impact on traffic flows and, of
> course money flows.
>
> Maybe the BGP monitoring experts (aka Renesys et al) can shed some light?
>
> --
> Fredy Künzler
> Init7 / AS13030
>
>

RE: Level3 (3356/3549) changes routing policy

[Siegel, David]

Thanks David, you hit the nail on the head on both points. 

Level 3 made the routing policy change last November, roughly 6 weeks after the 
acquisition of Global Crossing.

Dave


-Original Message-
From: David Reader [mailto:david.rea...@zeninternet.co.uk] 
Sent: Thursday, August 02, 2012 6:41 AM
To: nanog@nanog.org
Subject: Re: Level3 (3356/3549) changes routing policy

On Thu, 2 Aug 2012 10:33:38 +0200
Fredy Kuenzler  wrote:

>  From my observation Level3 has recently changed their routing policy. 
> It seems that 3356 always prefers customer prefixes of 3549, 
> regardless of the AS path length. Example (seen from 3356):
> 
> 3549_13030_[Customer1]_[Customer2]
> 
> is preferred over
> 
> 2914_[Customer1]_[Customer2]
> 
> Considering that both 2914 and 3549 are peers of 3356, and 13030 is a 
> customer of 3549, 3356 seems to give higher local-pref on the longer 
> AS-path, likely to increase traffic and revenue of their sister network 3549.

Hi Fredy,

Level 3 owns both 3356 and 3549.
They're simply preferring to have their customers pay them, rather than a 3rd 
party.

I don't think it's suprising at all that they're doing it. If, as you think, 
it's only happened recently then what is suprising is that it didn't happen 
sooner IMO.

d.

RE: Level3 (3356/3549) changes routing policy

[John van Oppen]

It probably should be noted that AS3356's local pref heirarchy is as follows:

Highest: customers of 3356
Next highest: customers of 3549
Lowest: peers

This does not really seem odd at all, and is probably what I would do if I 
owned two separate networks that were going to take a long time to merge...   
We noticed this change at least three months ago so it is not a super recent 
change.

Re: Level3 (3356/3549) changes routing policy

[Justin M. Streiner]

On Thu, 2 Aug 2012, David Reader wrote:


On Thu, 2 Aug 2012 10:33:38 +0200
Level 3 owns both 3356 and 3549.
They're simply preferring to have their customers pay them, rather than
a 3rd party.

I don't think it's suprising at all that they're doing it. If, as you
think, it's only happened recently then what is suprising is that it
didn't happen sooner IMO.


I would also guess that over time, 3549 will go away, as the GX network 
gets borged into Level3.


jms

Procera Networks contact

[Jason Lixfeld]

If anyone has a contact at Procera Networks who can answer some technical 
questions about their product, could you please pass it along?  The suggested 
methods at www. have so far gone unanswered.

Thanks in advance.

Re: Level3 (3356/3549) changes routing policy

[David Reader]

On Thu, 2 Aug 2012 10:33:38 +0200
Fredy Kuenzler  wrote:

>  From my observation Level3 has recently changed their routing policy. It 
> seems that 3356 always prefers customer prefixes of 3549, regardless of the 
> AS path length. Example (seen from 3356):
> 
> 3549_13030_[Customer1]_[Customer2]
> 
> is preferred over
> 
> 2914_[Customer1]_[Customer2]
> 
> Considering that both 2914 and 3549 are peers of 3356, and 13030 is a 
> customer of 3549, 3356 seems to give higher local-pref on the longer 
> AS-path, likely to increase traffic and revenue of their sister network 3549.

Hi Fredy,

Level 3 owns both 3356 and 3549.
They're simply preferring to have their customers pay them, rather than
a 3rd party.

I don't think it's suprising at all that they're doing it. If, as you
think, it's only happened recently then what is suprising is that it
didn't happen sooner IMO.

d.

RE: cost of misconfigurations

[Eric Wieling]

I do not think occasional outages cause significant loss of customers.  
Customers get angry easily, but once an issue is fixed, they get happy quickly. 
 Customers have very short memories and the cost and hassle of changing 
services is often significant.  Outages are never good, but it is better to 
concentrate on fixing the issue than panic about customers canceling their 
service.

Many times the cause of an outage is totally out of your control.  For example, 
most of our outages are caused by Verizon's aging and neglected copper cable 
plant.   I often wish some company had the balls to file a class action lawsuit 
over Verizon's neglect of their copper plant, but NOBODY wants to piss off 
their ILEC, including us.

-Original Message-
From: Diogo Montagner [mailto:diogo.montag...@gmail.com] 
Sent: Wednesday, August 01, 2012 8:32 PM
To: Darius Jahandarie; Murat Yuksel; nanog@nanog.org
Subject: Re: cost of misconfigurations

Hi Darius,

You are right. The lost of a customer due to those things. However, I would 
classify this as an unknown situation (in terms of risk
analisys) because the others I mentioned are possible to calculate and estimate 
(they are known). But it is very hard to estimate if a customer will cancel the 
contract because 1 or n network outages. In theory, if the customer SLA is not 
being met consecutively, there is a potential probability he will cancel the 
contract.

Regards

On 8/2/12, Darius Jahandarie  wrote:
> On Wed, Aug 1, 2012 at 8:08 PM, Diogo Montagner 
>  wrote:
>> A misconfiguration will, at least, impact on two points: network 
>> outage and re-work. For the network outage, you have to use the SLAs 
>> to calculate the cost (how much you lost from the customers' revenue) 
>> due to that outage. On the other hand, there is the time efforts 
>> spent to fix the misconfiguration. Under the fix, it could be 
>> removing the misconfig and applying a new one correct. Or just fixing 
>> the misconfig targeting the correct config. This re-work will 
>> translate in time, and time can be translated in money spent.
>
> Isn't the largest cost omitted (or at least glossed over) here?
> Namely, lost customers due to the outage. That's why people have SLAs 
> and rework the network at all -- to avoid that cost.
>
>
> --
> Darius Jahandarie
>

--
Sent from my mobile device

./diogo -montagner
JNCIE-SP 0x41A

Level3 (3356/3549) changes routing policy

[Fredy Kuenzler]

From my observation Level3 has recently changed their routing policy. It 
seems that 3356 always prefers customer prefixes of 3549, regardless of the 
AS path length. Example (seen from 3356):


3549_13030_[Customer1]_[Customer2]

is preferred over

2914_[Customer1]_[Customer2]

Considering that both 2914 and 3549 are peers of 3356, and 13030 is a 
customer of 3549, 3356 seems to give higher local-pref on the longer 
AS-path, likely to increase traffic and revenue of their sister network 3549.


Certainly it's common practice to overrule the BGP4 default behaviour, and 
widely used by smaller networks.


Still I'm surprised that it happened obviously rather undetected, at least, 
to my knowledge, Level3 did implement it silently and hasn't published an 
official statement or customer announcement, which I think, would have been 
fair, at least.


Considering that Level3 3356 and 3549 are by far the largest networks 
globally this decision must have a large impact on traffic flows and, of 
course money flows.


Maybe the BGP monitoring experts (aka Renesys et al) can shed some light?

--
Fredy Künzler
Init7 / AS13030