Hi Job, All,
It is definitely great to see progress on the deployment side! I realize
that there may be some gaps in the network operator toolchain, and this
may be something i'd like to contribute to.
For network operators to better understand the impact of BGP hijacks in
terms of revenue or v
On Sat, Nov 13, 2010 at 09:17:55PM -0600, Richard A Steenbergen wrote:
> Oh and the sFlow on EX is actually pretty cripled when used for routing.
> It's missing support for a bunch of important extended message tpes, and
> doesn't fully populate all of the fields of the message types it does
>
On Sun, Nov 14, 2010 at 09:04:36AM -0500, Jared Mauch wrote:
>
> On Nov 14, 2010, at 3:59 AM, Paolo Lucente wrote:
>
> > OTOH it would be nice to see one day those NetFlow v9 MAC address fields
> > populated on higher-grade boxes, say, to facilitate analysis of public
&g
On Sun, Nov 14, 2010 at 11:32:10AM -0600, Richard A Steenbergen wrote:
> On Sun, Nov 14, 2010 at 08:59:33AM +0000, Paolo Lucente wrote:
> > On Sat, Nov 13, 2010 at 09:17:55PM -0600, Richard A Steenbergen wrote:
> >
>
> Remember that every RIB in your network can and wi
On Mon, Nov 15, 2010 at 06:45:06PM -0600, Richard A Steenbergen wrote:
> today. The only flow collector implementation which I've spent any
> amount of time looking at besides the stuff I've written myself is
> pmacct, which IMHO shows great promise, but I don't believe it supports
> IPFIX yet.
Another role for IPFIX/NetFlow in the context of DPI (on top of
PSAMP that was already mentioned by Roland) is to serve as a
transport mechanism to travel flow data along with their DPI
classification from probes to remote collectors, for persistent
storage, analysis, etc.
This model is supported
Please note NBAR/NetFlow integration wanted to be an example of
using NetFlow/ IPFIX as a transport for DPI classification info
(where classification could be performed with any other in-line
technology than NBAR).
Whether NBAR works or does not as a classification technology is
out of scope for m
On Thu, Dec 15, 2011 at 11:28:48AM -0500, Drew Weaver wrote:
> I could be wrong here but I believe origin-AS uses a lookup from the routing
> table to figure out what the originAS for the source IP should be (and not
> what it explicitly IS) which means the information is unreliable.
Using a bi
On Sat, Jul 14, 2012 at 10:30:25AM +0200, ?ukasz Bromirski wrote:
> NetFlow supports [ .. ] As well as L2 traffic (v9) [ .. ]
Let's be real and speak implementations: where is L2 information in
NetFlow for routed traffic on bigger platforms typically thrown for
peering at internet exchanges - ASR
The reference to a IOS supporting 32-bit ASNs being too fresh
was specific to the 7600 platform and the SRE software train.
As of SRE1, for example, NetFlow v9 template still advertizes
source and destination ASNs fields as 2 bytes long.
Cheers,
Paolo
On Sun, Apr 11, 2010 at 11:15:57PM +1200, F
Besides the Juniper specifics on which i do agree.
The fact that NetFlow v5 doesn't carry L2 information doesn't
per-se imply it can't be theorically applied to L2 interfaces
and report on upper layers - making it fair, on a multi-layer
thing. Which is the underlying issue here.
Cheers,
Paolo
O
Too much widsom in just a single email
Paolo
On Thu, Aug 19, 2010 at 09:04:13AM -0700, George Bonser wrote:
>
>
> > -Original Message-
> > From: jacob miller
> > Sent: Thursday, August 19, 2010 4:36 AM
> > To: nanog@nanog.org
> > Subject: Re: Monitoring Tools
> >
> > Phil,
> >
> > A
On Sat, Oct 10, 2009 at 06:34:03PM +0200, ?ukasz Bromirski wrote:
> The 12.2SRE for RSP720 on 7600 is going to be available shortly and
> it will support 4B ASNs. It was communicated a number of times on
> cisco-nsp@ for those who subscribe it and did care.
>
> But I see that conspiracy theory loo
On Tue, Nov 17, 2009 at 01:28:06AM +0100, Daniel Roesen wrote:
> Caveat: no MAC accounting on LAGs (IEEE speak) / Aggregated Ethernet (Juniper
> speak) / Etherchannels (Cisco speak).
>
> Might or might not be important when using bundled links to public
> peering fabrics.
Or for the very same go
On Fri, Dec 18, 2009 at 10:09:32PM -0600, James Hess wrote:
> On Fri, Dec 18, 2009 at 1:24 PM, Jonny Martin wrote:
> ..
> > modified if need be - to achieve this. ?Mixing billing with the reachability
> > information signalled through BGP just doesn't seem like a good idea.
>
> Indeed not.. but
On Sat, Dec 19, 2009 at 08:42:33PM +0900, Randy Bush wrote:
> i am truely in awe how deeply the implications and alternatives have
> been analysed. this is particularly impressive given the complete
> absense of any facts about the alleged proposal.
Part of the thread just went more of general di
On Thu, Mar 11, 2010 at 10:20:41PM +0100, Arnold Nipper wrote:
> On 11.03.2010 16:29 Dylan Ebner wrote
>
> > Do the Arista switches support netflow? From a management perspective
> > netflow can be vital. This is something we have been unhappy with on
> > our 3560 and 3750 cisco's.
> >
>
> They
17 matches
Mail list logo
