Re: oss netflow collector/trending/analysis

[David Edelman]

Argus (qosient.com) is worth looking at. 


Dave Edelman


> On May 2, 2014, at 12:21, Leslie  wrote:
> 
> pmacct (http://www.pmacct.net/) is another pretty awesome open source tool.
> 
> Leslie
> 
>> On Fri, May 2, 2014 at 8:00 AM, Avi Freedman  wrote:
>> 
>> There's also SiLK from CMU.  It's powerful but has a learning curve.
>> 
>> I also see pmacct being used both by some end networks and by
>> some vendors as part of systems.
>> 
>> Avi
>> 
>>> Hey There,
>>> 
>>> I was just wondering, for people who are doing netflow analysis with
>>> open source tools and who are doing at least 10k or more flows per
>>> second, what are you using?
>>> 
>>> I know of three tool sets:
>>> 
>>> - The classic osu flow-tools and the modern continuation/fork.
>>> - ntop
>>> - nfdump/nfsen
>>> 
>>> Is there anything else I've missed? A few folks here really seem to like
>>> nfsen/nfdump.
>>> 
>>> Thanks,
>>> 
>>> Matt
>> 

Re: oss netflow collector/trending/analysis

[Warren Bailey]

Ntop is somehow open source if I recall. Seemed to work well and was fairly 
cheap to license.


Sent from my T-Mobile 4G LTE Device



 Original message 
From: David Edelman 
Date: 05/04/2014 11:05 AM (GMT-07:00)
To: Leslie 
Cc: nanog@nanog.org
Subject: Re: oss netflow collector/trending/analysis


Argus (qosient.com) is worth looking at.


Dave Edelman


> On May 2, 2014, at 12:21, Leslie  wrote:
>
> pmacct (http://www.pmacct.net/) is another pretty awesome open source tool.
>
> Leslie
>
>> On Fri, May 2, 2014 at 8:00 AM, Avi Freedman  wrote:
>>
>> There's also SiLK from CMU.  It's powerful but has a learning curve.
>>
>> I also see pmacct being used both by some end networks and by
>> some vendors as part of systems.
>>
>> Avi
>>
>>> Hey There,
>>>
>>> I was just wondering, for people who are doing netflow analysis with
>>> open source tools and who are doing at least 10k or more flows per
>>> second, what are you using?
>>>
>>> I know of three tool sets:
>>>
>>> - The classic osu flow-tools and the modern continuation/fork.
>>> - ntop
>>> - nfdump/nfsen
>>>
>>> Is there anything else I've missed? A few folks here really seem to like
>>> nfsen/nfdump.
>>>
>>> Thanks,
>>>
>>> Matt
>>

Re: What Net Neutrality should and should not cover

[Charles N Wyble]

On 4/27/2014 3:30 PM, John Levine wrote:

That is, with CATV companies like HBO have to pay companies like
Comcast for access to their cable subscribers.


In a non-stupid world, the cable companies would do video on demand
through some combination of content caches at the head end or, for
popular stuff, encrypted midnight downloads to your DVR, and the
cablecos would split the revenue with content backends like Netflix.


So why hasn't someone like he or cogent done this? Especially for 
delivery into campus/corporate environments (which is a decent amount of 
the customer base for the "smaller" providers I think). Seems like a 
good market opportunity.


I happen to be quite interested in optimizing video delivery (triple 
play, and streaming content) to an access network in Kansas City.


For streaming, I know that Netflix has:
https://www.netflix.com/openconnect that I can stick in the colo that 
the access network already backhauls to.


Does Amazon have something like this? Hmmm maybe we can just peer 
with them at the nearest AWS POP. What are folks doing for optimizing 
Amazon streaming?


As for the traditional content  (hbo etc), my understanding is these can 
be accessed via wholesale agreements? Satellite downlink (lots of cheap 
real estate where I could have a downlink station), then I just need to 
be able to send it to my IPTV distribution fabric (fiber/ long range 
microwave whatever). Though I understand there is much DRM involved, and 
I don't know anything about any accounting / viewer reporting that might 
be required.


So it really seems to me, that even with an established competitive 
access network (located in Kansas City MO) , if I want to offer 
streaming/TV content (and have all the pain that the big boys have) I 
might not be able to do it? I can of course peer with netflix and deploy 
one of their fancy appliances.


See, all of this is so locked up and non clear. It's very un tractable 
to me. I am curious about even generalities of how this all works, where 
the pain points are etc.  I suppose the incumbents are annoyed with 
folks cutting the cord and bypassing that nice set of carefully 
engineered video delivery plant, for that pesky ip based stuff (but 
maybe keeping the ISP portion of the service)? Why don't the access 
network providers just raise the internet portion of the cost to match 
the lost revenue? Or work out a Pay Per View type deal with netflix? 
(Like you can buy apps via your cell phone provider, why don't 
netflix/time warner work out a Pay Per View that you could get on your 
monthly bill)?


It all seems very complicated to me.  Why not just work out deals with 
netflix behind the scenes to help cover port upgrade costs or 
something?  Instead of all this circus nonsense.  That way, you would 
get your costs covered (by the people who are forcing you to incur that 
cost), and you would still get your monthly transit revenue.


If I work on a particular project for a specific customer, I bill that 
customer for my incurred expenses. No one outside of me and the customer 
knows that, or needs to know that. I still bill them a recurring 
(hourly/monthly whatever) rate, and I bill them for one time expenses.



But this world is mostly stupid, the cable companies never got VOD, so
you have companies like Netflix filling the gap with pessimized
technology.  (I do see that starting tomorrow, there will be a Netflix
channel on three small cablecos including RCN, delivered via TiVo,
although it's not clear if the delivery channel will change.)


Yeah that was interesting. I'm curious how that actually works. Will it 
be an app on the set top box?




The other issue is that due to regulatory failure, cable companies are
an oligopoly, and in most areas a local monopoly, so Comcast has the
muscle to shake down Internet video providers.  That's not a technical
problem, it's a political one.  In Europe, where DSL is a lot faster
than here, carriage and content are separate and there are a zillion
DSL providers.  We could do that here if the FCC weren't so spineless.


Yes. Agreed.

I'm (with the Free Network Foundation https://www.thefnf.org) helping 
folks in KC and Austin build alternative access networks (using wifi, 
backhauled to neutral NAP locations).  That seems to be the only viable 
option in the US.

Re: What Net Neutrality should and should not cover

[William Herrin]

On Sun, May 4, 2014 at 2:57 PM, Charles N Wyble  wrote:
> On 4/27/2014 3:30 PM, John Levine wrote:
>> In a non-stupid world, the cable companies would do video on demand
>> through some combination of content caches at the head end or, for
>> popular stuff, encrypted midnight downloads to your DVR, and the
>> cablecos would split the revenue with content backends like Netflix.
>
>
> So why hasn't someone like he or cogent done this?

Because 30 years later the big content owners still hate VCRs.
Streaming doesn't bother them so much but they avail themselves of
every opportunity to say no to the end-user recorded content.

This is hardly a surprise... A century later they still hate the first
sale doctrine too and avail themselves of every opportunity to
undermine it.

Regards,
Bill Herrin


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

Re: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]

[Mark Tinka]

On Saturday, May 03, 2014 11:26:27 AM Måns Nilsson wrote:

> Ideally, we would have a solution where an entire MPLS
> infrastructure could be built without v4 space, demoting
> v4 to a legacy application inside a VRF, but the MPLS
> standards wg seems content with status quo.

There is work ongoing in the MPLS IETF WG on identifying the 
gaps that various MPLS applications have so they can be 
prepared for IPv6 MPLS control and data planes.

Long overdue, if you ask me, but at least it's starting to 
get some attention.

Mark.


signature.asc
Description: This is a digitally signed message part.

Re: Best practices IPv4/IPv6 BGP (dual stack)

[Mark Tinka]

On Saturday, May 03, 2014 08:23:43 PM Mikael Abrahamsson 
wrote:

> I know lots of people who run vpnv4 separately from ipv4
> and ipv6 (so they have 3 sessions). The ones I talked to
> intends to run vpnv6 separately as well.

Except that VPNv6, today, relies on MPLSv4. So it's not 
"pure" yet.

Mark.


signature.asc
Description: This is a digitally signed message part.

Re: Best practices IPv4/IPv6 BGP (dual stack)

[Mark Tinka]

On Saturday, May 03, 2014 07:24:24 PM Vitkovský Adam wrote:

> Sure it's a different transport protocol altogether,
> anyways It's interesting to see how everybody tends to
> separate the IPv4 and IPv6 AFs onto a different TCP
> sessions and still run the plethora of other AFs on the
> common v4 TCP session, maybe apart from couple of the
> big folks, who can afford running separate control-plane
> and edge infrastructure for some of the AFs, IPv6 AF
> being the first ran separately.

We run separate AF's for each family-type, i.e., IPv4 
separate from IPv6, separate from VPNv4 separate from BGP-
based VPLS, e.t.c.

Mark.


signature.asc
Description: This is a digitally signed message part.