On Thu, Mar 3, 2016 at 9:16 AM, Nick Hilliard wrote:
> The beauty of sflow is that you can do anything in the collector, but
> most people aren't going to do this because it means maintaining two
> sets of data about your flow configuration: one set on the switch and
> one set in your collector co
Peter Phaal wrote:
> sampled packet. A simple filter along the lines:
>
> if ( sourceId.split(':')[1] != inputPort) return;
It's not a one-liner in practice. It involves maintaining an array of
source ip + egressPorts with sflow enabled and (depending on how you
implement it) e.g. ensuring that
While it would be nice if the Nexus switches supported ingress
sampling, you can get exactly the same result at the receiving end by
dropping the egress samples. The following sflowtool output shows some
of the metadata contained in the packet sample:
startSample --
sampleType_
Peter Phaal wrote:
> I think "pathologically broken" somewhat overstates the case.
> Bidirectional sampling is allowed by the sFlow spec and other vendors
> have made that choice. Another vendor used to implement egress only
> sampling (also allowed) but unusual. I agree that ingress is the most
>
On 2/Mar/16 19:25, Peter Phaal wrote:
> The Nexus 3200 should work well with 100G flows - I believe it's based on the
> latest Broadcom Tomahawk ASIC. The older Trident II ASICs in the Nexus 9k are
> 40g parts.
Yes, the new Tomahawk chips support native 100Gbps lanes.
Mark.
On Wed, Mar 2, 2016 at 2:45 PM, Nick Hilliard wrote:
> Peter Phaal wrote:
>> Monitoring ingress and egress in the switch is wasteful of resources.
>
> It's more than a waste of resources: it's pathologically broken and
> Cisco decline to fix it, despite the fact that enabling ingress-only or
> eg
Peter Phaal wrote:
> Monitoring ingress and egress in the switch is wasteful of resources.
It's more than a waste of resources: it's pathologically broken and
Cisco decline to fix it, despite the fact that enabling ingress-only or
egress-only is fully supported via API in the Broadcom SDKs, and
c
On Wed, Mar 2, 2016 at 9:30 AM, Nick Hilliard wrote:
> Peter Phaal wrote:
>> The Nexus 3200 should work well with 100G flows - I believe it's
>> based on the latest Broadcom Tomahawk ASIC. The older Trident II
>> ASICs in the Nexus 9k are 40g parts
>
> does nx-os still force ingress-and-egress sfl
Peter Phaal wrote:
> The Nexus 3200 should work well with 100G flows - I believe it's
> based on the latest Broadcom Tomahawk ASIC. The older Trident II
> ASICs in the Nexus 9k are 40g parts
does nx-os still force ingress-and-egress sflow? sflow is pretty
useless you can define an accounting peri
>
> On Mar 1, 2016, at 10:12 PM, Mark Tinka wrote:
>
>
>
>> On 2/Mar/16 08:04, Mark Tinka wrote:
>>
>> We were initially looking at at the Nexus 9000, but then moved to the
>> 7700 because the Broadcom chip on the 7700 cannot do single flows larger
>> than 40Gbps on the 100Gbps ports.
>
> Th
On 2/Mar/16 08:04, Mark Tinka wrote:
> We were initially looking at at the Nexus 9000, but then moved to the
> 7700 because the Broadcom chip on the 7700 cannot do single flows larger
> than 40Gbps on the 100Gbps ports.
The Broadcom chip on the 9000, I meant...
Mark.
On 1/Mar/16 17:18, Peter Phaal wrote:
> It also appears that Cisco's merchant silicon based switches have a
> greater variety of orchestration capabilities, Python, NX-API,
> Ansible, etc.
We were initially looking at at the Nexus 9000, but then moved to the
7700 because the Broadcom chip on th
On Tue, Mar 1, 2016 at 6:13 AM, Mark Tinka wrote:
>
>
> On 29/Feb/16 12:15, Nikolay Shopik wrote:
>
>> Cisco Nexus switches support sflow, since they are broadcom based.
>
> Not all of them, just the Nexus 9000, IIRC.
>
The situation in the Cisco Nexus line is confusing. In addition, to
the Nexus
On 01/03/16 10:44, Pavel Odintsov wrote:
> But unfortunately they (Cisco Nexus) are pretty expensive and fairly
> new for DC and ISP market. It's pretty rare to find big company with
> switching backbone on Nexus switches.
You could go with withbox switches, which is based on same broadcom
ASIC, b
On 01/03/16 17:13, Mark Tinka wrote:
>
>
> On 29/Feb/16 12:15, Nikolay Shopik wrote:
>
>> Cisco Nexus switches support sflow, since they are broadcom based.
>
> Not all of them, just the Nexus 9000, IIRC.
>
Nexus 3000 also broadcom, but maybe not all models.
Brocade as well.
On Mar 1, 2016 8:39 AM, "David Bass" wrote:
> I don't agree with that statement (about rare to find big companies using
> Nexus). If you want 10 gig/40 gig (or 100 gig soon) your options are Cisco
> Nexus/Arista/Juniper QFX...some periphery devices as well, but the majority
> us
Yep, actually do not mean. I've never used Nexus and haven't any
experience with it :) I mentioned this in original message. I'm pretty
sure it's awesome switch. But as I haven't any experience I do not
known cons and pros about it.
On Tue, Mar 1, 2016 at 5:38 PM, Mark Tinka wrote:
>
>
> On 1/Mar
On 1/Mar/16 16:33, Pavel Odintsov wrote:
> As opposed to older Cisco switches.
Well, every vendor has older switches.
> Btw, 100GE is pretty new and
> actually I have experience only with Extreme Black Diamond 8.
Does not mean the Nexus is a bad choice for high capacity core
switching. Just
I don't agree with that statement (about rare to find big companies using
Nexus). If you want 10 gig/40 gig (or 100 gig soon) your options are Cisco
Nexus/Arista/Juniper QFX...some periphery devices as well, but the majority use
one of those 3.
The merchant silicon based switches are pretty r
As opposed to older Cisco switches. Btw, 100GE is pretty new and
actually I have experience only with Extreme Black Diamond 8.
On Tue, Mar 1, 2016 at 5:24 PM, Mark Tinka wrote:
>
>
> On 1/Mar/16 09:44, Pavel Odintsov wrote:
>> But unfortunately they (Cisco Nexus) are pretty expensive and fairly
>
On 1/Mar/16 09:44, Pavel Odintsov wrote:
> But unfortunately they (Cisco Nexus) are pretty expensive and fairly
> new for DC and ISP market. It's pretty rare to find big company with
> switching backbone on Nexus switches.
As opposed to?
We are looking at the Nexus 7700 for 100Gbps core switchi
On 29/Feb/16 12:15, Nikolay Shopik wrote:
> Cisco Nexus switches support sflow, since they are broadcom based.
Not all of them, just the Nexus 9000, IIRC.
Mark.
Yep, Broadcom doing thing right way! :)
But unfortunately they (Cisco Nexus) are pretty expensive and fairly
new for DC and ISP market. It's pretty rare to find big company with
switching backbone on Nexus switches.
But I like this direction of switch silicom unification :) Focus moved
from "netw
Cisco Nexus switches support sflow, since they are broadcom based.
On 29/02/16 10:26, Pavel Odintsov wrote:
> Cisco do not support this protocol at all (that's pretty weird,
> really).
On 29 February 2016 at 17:40, Phil Bedard wrote:
> It would be interesting to get some data from vendors on what the actual
> limitation is. I know with some new platforms like the NCS 55XX from Cisco
> (BRCM Jericho) it has limited space for counters, but I don’t know if that
> contributes to
-Original Message-
From: NANOG on behalf of Saku Ytti
Date: Monday, February 29, 2016 at 08:31
To: Nick Hilliard
Cc: nanog list
Subject: Re: sFlow vs netFlow/IPFIX
>On 29 February 2016 at 15:05, Nick Hilliard wrote:
>
>> depends on what you define by "cheap&qu
On 29 February 2016 at 15:05, Nick Hilliard wrote:
> depends on what you define by "cheap". Netflow requires separate packet
> forwarding lookup and ACL handling silicon.
That's not inherently so, it depends how specialised your hardware is.
If it's very specialised like implementing just LPM,
Pavel Odintsov wrote:
> From hardware point of view almost all brand new switches support
> sflow free of charge (no additional licenses or modules). But be
> aware, Cisco do not support this protocol at all (that's pretty weird,
> really).
sflow is supported on the Nexus 3k range, but it's availa
Roland Dobbins wrote:
> Inconsistent stats, lack of ifindex information.
I've not yet come across an sflow implementation which didn't fill out
the ifindex field. No doubt they exist.
Not sure what you mean by "inconsistent stats".
Nick
Saku Ytti wrote:
> I cannot see why not, it's cheap. You're doing 1-2 LPM on the packet,
> QoS lookup, ACL lookup, incrementing various counters, etc., adding
> one hash lookup and two counters is not going to be relevant cost to
> the lookup time.
depends on what you define by "cheap". Netflow r
Thanks! Very interesting. Will dig into details :)
On Mon, Feb 29, 2016 at 3:55 PM, Edward Dore
wrote:
>
>> On 29 Feb 2016, at 12:37, Pavel Odintsov wrote:
>>
>> Hello!
>>
>> Nice information. Very interesting architecture. They are using L3 on
>> IX? How big Juniper Lan in comparison with Extre
> On 29 Feb 2016, at 12:37, Pavel Odintsov wrote:
>
> Hello!
>
> Nice information. Very interesting architecture. They are using L3 on
> IX? How big Juniper Lan in comparison with Extreme lan?
Hi Pavel,
The Juniper LAN is VPLS and the Extreme LAN is standard layer 2 with EAPS
instead of *STP
On 29 February 2016 at 14:17, wrote:
> A relevant question might be if the Trio hardware can do 1:1 while
> handling multiple ports of line rate DDoS traffic consisting of small
> packets with different port numbers (i.e. high pps traffic resulting
> in basically 1 flow per packet). No, I don't
Hello!
Nice information. Very interesting architecture. They are using L3 on
IX? How big Juniper Lan in comparison with Extreme lan?
On Mon, Feb 29, 2016 at 3:16 PM, Edward Dore
wrote:
>
>> On 29 Feb 2016, at 09:59, Pavel Odintsov wrote:
>>
>> For example, at huge Internet Exchanges you actua
> > That's interesting, given that most larger routers don't support 1:1.
>
> I find that strange, because if you're doing in in HW, doing hash
> lookup for flow and adding packets and bytes to the counter is cheap.
> It's expensive having lot of those flows, but incrementing their
> packet and by
> On 29 Feb 2016, at 09:59, Pavel Odintsov wrote:
>
> For example, at huge Internet Exchanges you actually haven't any
> netflow enabled devices (just check design architecures from AMX-IX,
> DEC-IX, LINX or even MSK-IX).
LINX use IPFIX (which is derived from NetFlow) for the Juniper LAN.
The
On 28 February 2016 at 22:06, Todd Crane wrote:
> This maybe outside the scope of this list but I was wondering if anybody had
> advice or lessons learned on the whole sFlow vs netFlow debate. We are
> looking at using it for billing and influencing our sdn flows. It seems like
> everything I h
On 29 February 2016 at 04:24, Roland Dobbins wrote:
>> Around here they are currently voting on a law that will require unsampled
>> 1:1 netflow on all data in an ISP network with more than 100 users.
>
> That's interesting, given that most larger routers don't support 1:1.
I find that strange, b
On 29 Feb 2016, at 16:59, Pavel Odintsov wrote:
I have only one question. Why you against sFLOW protocol telemetry
with so huge passion ? :)
Because I've had very poor experiences with it. And it doesn't seem to
scale very well.
Actually, sflow is not so popular as netflow. But to be hone
Thanks for detailed question!
I have only one question. Why you against sFLOW protocol telemetry
with so huge passion ? :)
It's not proprietary technology and not an product from yet another
big company. I'm not trying to sell anything because... nothing to
sell. Really, isn't it?
It's just yet
On 29 Feb 2016, at 15:53, Pavel Odintsov wrote:
It's not about default. It's about minimal possible.
To my knowledge, there has never been a Cisco router which only allowed
an active flow timer value of 180s, which wasn't user-configurable. I
would appreciate the details of any such router.
Thanks for explained answer!
But actually it's mistake to think I haven't real field experience
just because I'm developer. In world of big companies nobody could do
ops and development. But I'm trying to keep close to both worlds. And
could conclude it's definitely possible.
It's definitely poss
On 29 Feb 2016, at 15:12, Pavel Odintsov wrote:
Looks like you haven't so much field experience with sflow. I could
help and offer some real field experience below.
I've already recounted my real-world operational experience with
NetFlow.
I have my own netflow collector implementation for n
What you mean as lack of ifindex in sflow?
I could offer example sflow v5 sample structure description (it's from
my C++ based sflow parser but actually it's pretty simple to
understand):
uint32_t sample_sequence_number; // sample sequence number
uint32_t source_id_type; /
On 29 Feb 2016, at 14:41, Pavel Odintsov wrote:
Could you describe they in details?
Inconsistent stats, lack of ifindex information.
But netflow __could__ delay telemetry up to 30 seconds (in case of
huge syn/syn-ack flood for example) and you network will experience
downtime.
This is inc
Sorry but I could not understand what issues you've found in sflow.
Could you describe they in details?
Recently I had speech at RIPE 71 and show pattern of real attack which
achieved 6 gbps in first 30 seconds (just check slide 6 here
http://www.slideshare.net/pavel_odintsov/ripe71-fastnetmon-ope
> This maybe outside the scope of this list but I was wondering if anybody had
> advice or lessons learned on the whole sFlow vs netFlow debate. We are
> looking at using it for billing and influencing our sdn flows. It seems like
> everything I have found is biased (articles by companies who h
On 29 Feb 2016, at 14:26, Pavel Odintsov wrote:
From my own experience sflow should be selected if you are interested
in internal packet payload (for dpi / ddos detection) or you need fast
reaction time on some actions (ddos is best example).
This does not match my experience. In particular,
Re: limits -
For Cisco/Juniper it's in the low hundreds of thousands of flows/sec
per chipset/linecard for 1:1 NetFlow/IPFIX, I think.
Then of course, as has been mentioned, you'll need to be able to send
it and receive it to something - and store+query.
Avi Freedman
CEO, Kentik
> On 28 Februa
Hello, folks!
I've huge experience for battle sflow vs netflow because in my free
DDoS detection toolkit fastnetmon we support both capture methods.
You could look at this comparison table:
https://github.com/pavel-odintsov/fastnetmon/blob/master/docs/CAPTURE_BACKENDS.md
>From my own experience
On Mon, 29 Feb 2016 09:24:42 +0700, "Roland Dobbins" said:
> On 29 Feb 2016, at 6:26, Baldur Norddahl wrote:
>
> > Around here they are currently voting on a law that will require unsampled
> > 1:1 netflow on all data in an ISP network with more than 100 users.
>
> That's interesting, given that mo
On 29 Feb 2016, at 6:26, Baldur Norddahl wrote:
> Around here they are currently voting on a law that will require unsampled
> 1:1 netflow on all data in an ISP network with more than 100 users.
That's interesting, given that most larger routers don't support 1:1.
---
On 28 February 2016 at 23:40, Nick Hilliard wrote:
> Netflow was designed to measure flows, and it turned out that the design
> was robust enough for it to be more-or-less good enough for billing
> purposes. It's "more or less" because on larger routers, you can't do
> 1:1 data export and you end
What HW are your looking at our are you rolling your own probes? Router/switch
HW almost never does both. Netflow/IPFIX puts the flow intelligence in the
router, but with that comes more limitations.
Sflow typically uses more BW because you are sending headers for each packet.
The sflow co
Todd Crane wrote:
> This maybe outside the scope of this list but I was wondering if
> anybody had advice or lessons learned on the whole sFlow vs netFlow
> debate. We are looking at using it for billing and influencing our
> sdn flows. It seems like everything I have found is biased (articles
> by
55 matches
Mail list logo
