Hi Oh Wise List :)
If one was going to start up collecting netflow data for connectivity / peering
/ traffic engineering reasons, what tools work well these days.
What shops using to look at top source or dest ASN's
Track traffic anomalies (ddos, scans, other fun things)
We are needing to track
Cascade product by riverbed is really nice tool. Check it out.
On Tuesday, January 17, 2012, John Brown wrote:
> Hi Oh Wise List :)
>
> If one was going to start up collecting netflow data for connectivity /
peering / traffic engineering reasons, what tools work well these days.
>
> What shops us
On Wed, 18 Jan 2012, John Brown wrote:
Hi Oh Wise List :)
If one was going to start up collecting netflow data for connectivity / peering
/ traffic engineering reasons, what tools work well these days.
What shops using to look at top source or dest ASN's
Track traffic anomalies (ddos, scans,
> > We are needing to track GigE and 10GigE interfaces. Packet rates are not
> high yet, but want to have something that reasonably scales.
>
> Are you sure whatever platforms you're using can handle and export that
> volume of netflow?
Today we use GSR 12408, 6506-E Sup720-3BXL. Looking to mov
On Jan 17, 2012, at 11:23 PM, John Brown wrote:
> 6506-E Sup720-3BXL.
The NetFlow you get from this box won't be operationally useful - many caveats.
Strongly suggest a move to Sup2T and DFC4 (where applicable), if you want good
NetFlow from 6500s.
nfdump/nfsen is a good open-source set of t
On 18/01/12 10:14, Dobbins, Roland wrote:
nfdump/nfsen is a good open-source set of tools to use in getting started with
flow telemetry, IMHO.
Seconded with Roland words. We find nfdump pretty much solid and with
nfsen is good tool for detecting anomalies.
___
Can nfdump/nfsen show useage per AS number as I cannot see anything on their
site?
Nick
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Dobbins, Roland
Sent: 18 January 2012 06:14
To: Cisco NSP
Subject: Re: [c-nsp] Flow
On 18/01/12 10:38, Nick Ryce wrote:
Can nfdump/nfsen show useage per AS number as I cannot see anything on their
site?
I don't know if it's in earlier versions, but the latest version of
nfdump has aggregation / summary by asnum, e.g.
nfdump <...> -a -A srcas,dstas
...or:
nfdump <...> -s
On 18/01/2012 11:21, Phil Mayers wrote:
> On 18/01/12 10:38, Nick Ryce wrote:
>> Can nfdump/nfsen show useage per AS number as I cannot see anything on
>> their site?
>
> I don't know if it's in earlier versions, but the latest version of nfdump
> has aggregation / summary by asnum, e.g.
>
> nfdu
On 18/01/12 11:23, Nick Hilliard wrote:
On 18/01/2012 11:21, Phil Mayers wrote:
On 18/01/12 10:38, Nick Ryce wrote:
Can nfdump/nfsen show useage per AS number as I cannot see anything on
their site?
I don't know if it's in earlier versions, but the latest version of nfdump
has aggregation / s
On 18/01/2012 11:25, Phil Mayers wrote:
> Sure. In particular, I note that on the 6500/sup720 platform, src/dst AS in
> the netflow requires lookup (and export) by the supervisor CPU; distributed
> NDE i.e. done by the linecard CPU will not be available.
... and also if you decide to change from o
Hi,
On Wed, Jan 18, 2012 at 11:27:57AM +, Nick Hilliard wrote:
> ... and also if you decide to change from origin-as to peer-as or
> vice-versa on a sup720, you should expect the sup720's CPU to be trashed
> for a couple of minutes.
Ouch. What is it doing there? Sounds like it has some so
On 18/01/2012 12:14, Gert Doering wrote:
> Ouch. What is it doing there? Sounds like it has some sort of lookup
> cache to get the AS number, and needs to rebuild that...
I suspect so.
> Some nice addition to netflow would be to have "origin *and* peer AS",
> just btw... depending on which lin
bbins, Roland
> Sent: 18 January 2012 06:14
> To: Cisco NSP
> Subject: Re: [c-nsp] Flow tools
>
>
> On Jan 17, 2012, at 11:23 PM, John Brown wrote:
>
> > 6506-E Sup720-3BXL.
>
> The NetFlow you get from this box won't be operationally useful - many
> cave
On Wed, 18 Jan 2012, Dobbins, Roland wrote:
On Jan 17, 2012, at 11:23 PM, John Brown wrote:
6506-E Sup720-3BXL.
The NetFlow you get from this box won't be operationally useful - many caveats.
Strongly suggest a move to Sup2T and DFC4 (where applicable), if you want good
NetFlow from 6500
On Jan 18, 2012, at 7:56 AM, Jon Lewis wrote:
> Sampled netflow is certainly more operationally useful than no netflow.
Concur, and this is what the majority of network operators use.
Unfortunately, pre-Sup2T 6500s can't really do sampled NetFlow. Instead, in
any kind of environment with flo
On Wed, 2012-01-18 at 07:56 -0500, Jon Lewis wrote:
> On Wed, 18 Jan 2012, Dobbins, Roland wrote:
> > On Jan 17, 2012, at 11:23 PM, John Brown wrote:
> > > 6506-E Sup720-3BXL.
> >
> > The NetFlow you get from this box won't be operationally useful -
> > many caveats. Strongly suggest a move to Sup
Just for the record, I'v checked this (cause I do have distributed NDE and use origin-as info), and
I can see origin AS in my flow data from 10G card with DFC. For example, 2 netflow packets with
SrcAS/DstAS (wireshark capture, unimportant omitted, IP/AS replaced):
- Packet 1 (from 10G module w
On Wed, 2012-01-18 at 13:10 +, Dobbins, Roland wrote:
> One can check one's 6500s in order to see if table insertion errors
> are occurring, and I recommend doing so for anyone who's running
> pre-Sup2T 6500s.
And for posterity: Check this with e.g. "show mls netflow
table-contention detailed"
Hi,
On Wed, Jan 18, 2012 at 02:11:58PM +0100, Peter Rathlev wrote:
> The Sup2T is practically the same price as the Sup720-10G, so there are
> few reasons not to buy it for new deployments.
"Availability of used Sup720-10G for much less money" :-)
And, just maybe, "non-compatibility of Sup2T wit
On 18/01/2012 13:28, Gert Doering wrote:
> And, just maybe, "non-compatibility of Sup2T with your existing stock
> of line cards". Like, all bus-based cards, and everything with a DFC
> on it.
Gert, hardware upgrades need to happen; otherwise we would all be stuck
using bus interfaces designed i
On Wed, 2012-01-18 at 14:28 +0100, Gert Doering wrote:
> On Wed, Jan 18, 2012 at 02:11:58PM +0100, Peter Rathlev wrote:
> > The Sup2T is practically the same price as the Sup720-10G, so there are
> > few reasons not to buy it for new deployments.
...
> And, just maybe, "non-compatibility of Sup2T w
On 18/01/12 14:07, Nick Hilliard wrote:
Gert, hardware upgrades need to happen; otherwise we would all be stuck
using bus interfaces designed in the early 1990s. Nobody likes paying for
upgrades, but Cisco's 67xx line cards have been properly supported since
2003 - 9 years ago. If you bought t
Hi,
On Wed, Jan 18, 2012 at 02:07:51PM +, Nick Hilliard wrote:
> On 18/01/2012 13:28, Gert Doering wrote:
> > And, just maybe, "non-compatibility of Sup2T with your existing stock
> > of line cards". Like, all bus-based cards, and everything with a DFC
> > on it.
>
> Gert, hardware upgrades
Hi,
> Second: I'm curious if people are seeing prices that "make sense" for
> the DFC4 upgrade parts for 67xx linecards. They were about 50% more than
> the equivalent DFC3 parts. When we costed out the upgrade of our main
> core routers to sup2T, the DFC parts made it quite pricey, and pushed
Lewis; Cisco NSP
Subject: Re: [c-nsp] Flow tools
Hi,
On Wed, Jan 18, 2012 at 02:07:51PM +, Nick Hilliard wrote:
> On 18/01/2012 13:28, Gert Doering wrote:
> > And, just maybe, "non-compatibility of Sup2T with your existing
> > stock of line cards". Like, all bus-ba
On 18/01/2012 15:54, Chuck Church wrote:
> So no more PFC falling back to a mode that is common to all the DFCs?
er, yes, if you mix XL and non-XL, you'll fall back to the lowest common
denominator.
> http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/qa_c67-649419.html#wp994
T
Hi,
I'm finding it slightly ironing that the subject of this email is about
netflow...and yet people are dissing the Sup2T - the Sup2T is a netflow beast!
:-)
I'm just suprised that they took the opportunity to ditch the old PFC/DFC mixing
but kept the old inter-module communication link... 10/
27;Cisco NSP'
Subject: Re: [c-nsp] Flow tools
On 18/01/2012 15:54, Chuck Church wrote:
> So no more PFC falling back to a mode that is common to all the DFCs?
er, yes, if you mix XL and non-XL, you'll fall back to the lowest common
denominator.
>
http://www.cisco.com/en/US/prod/col
On 18/01/12 16:12, Chuck Church wrote:
Oh, maybe I was thinking of 3A vs. 3B. Those would play together sort of.
Not sure about 3C.
You can mix 3B and 3C.
You can't mix 3 and 4.
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.neth
On Jan 18, 2012, at 10:54 AM, Chuck Church wrote:
> So no more PFC falling back to a mode that is common to all the DFCs?
I seem to recall you can still use CFC with SUP2T
- Jared
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.neth
t
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers
Sent: Wednesday, January 18, 2012 7:35 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Flow tools
On 18/01/12 14:07, Nick Hilliard wrote:
>
> Gert, hardware upgrades need to happen; otherwise we would all be
> s
On Wed, 18 Jan 2012, Nick Ryce wrote:
Can nfdump/nfsen show useage per AS number as I cannot see anything on
their site?
You can also set up graphs for traffic to/from specific ASNs of interest.
I do this for several ASNs of interest in my environment.
jms
__
On Wed, 18 Jan 2012, Nick Hilliard wrote:
On 18/01/2012 11:25, Phil Mayers wrote:
Sure. In particular, I note that on the 6500/sup720 platform, src/dst AS in
the netflow requires lookup (and export) by the supervisor CPU; distributed
NDE i.e. done by the linecard CPU will not be available.
..
I apologize for hijacking this thread but it appears we have a lot of NetFlow
attention here and I want to keep the momentum for my own use :)
We currently utilize netflow in conjunction with Cisco MARs for security
incident management of our ~2,000 remote sites. We also use CA's NetQoS for
Ne
35 matches
Mail list logo
