[c-nsp] more net flow, which interfaces to monitor and in which direction?

Charles Sprickman spork at bway.net
Wed May 21 21:11:02 EDT 2014


On May 21, 2014, at 2:52 PM, Eric Van Tol <eric at atlantech.net> wrote:

>> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
>> Scott Granados
>> Sent: Wednesday, May 21, 2014 2:32 PM
>> 
>> Hi,
>> First, thanks for all the great input on analyzers and their strong and
>> weak points.  It looks like from the comments I'm going to give nfsen a
>> shot.
>> 	My followup question concerns selection of interfaces and the
>> direction to monitor.  While googling I find that almost all examples I
>> find are sampling in the input direction only.  Also most of the examples
>> out there seem to be quite simple and involve one interface or a few.  
> 
> I think this really all depends on what you want to see.  If you want a full profile of where your traffic is headed, I believe it's best to run it as close to the "edge" as possible - both at customer/user-facing ports and at AS boundary ports.  In addition, anything in between that you might want more granular data from, such as service networks hanging off your core.

I recall seeing cautions from long ago about using both ingress and egress on an interface.  On my old NPE-G2, it seemed to work.

I have not re-enabled it on our ASR1K yet as I’ve not had the time to research this, and I also want to complete the move to nfsen from the old flow-tools package.

I understand the old recommendation - ingress on all interfaces should catch all traffic in both directions.  But what I’m dealing with is a single box with two transit interfaces and a ton of subscriber interfaces (subinterface per customer basically).  It seems unwise (and complicated) to add an ingress flow statement on every subinterface.  If I could just add an “ingress” and “egress” statement to each of my two transit connections, that seems more ideal.  Is this something I should *not* do on modern hardware?  If so, what other options are there short of adding an ingress monitor on hundreds of subinterfaces?

Thanks,

Charles


> I could be wrong, but I think the type of metering you can do (ingress/egress) depends on the Netflow version you plan on running.  I believe version 5 can only do ingress metering.  However, if you have ingress metering configured on all edge-facing ports and all core-facing ports, you can expect to get everything you need, because the return traffic from an edge port will be seen as an ingress flow on a core port.  I'm not sure of the benefits you would get by using v9 or IPFIX and doing both ingress/egress metering, as it would seem to me that you're just duplicating flow data at that point.  I think it really all depends on your traffic flow patterns.  That said, if your devices support it, v9 or IPFIX would be the way to go.  
> 
> -evt 
> 
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/




More information about the cisco-nsp mailing list