This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Netflow configuration - ingress vs egress

So, I've tried to wade through the documentation on cisco.com and solarwinds but could use some help figuring how to setup netflow v9 for my monitoring needs. I'm particularly interested in the pros and cons of ingress vs egress capturing or whether I should do both. I have two main data center locations and 7 branch locations that talk over mpls WAN. The previous admin had it setup "ip flow ingress" on the LAN ports (including subinterfaces) of the cisco routers with nothing on the WAN interfaces. Wouldn't it make more sense to collect both directions (ip flow ingress and ip flow egress) on the WAN interface since as I read it is after WAAS (WAN compression).

Any reason this is a bad idea?

It makes sense to capture both ingress and egress, right?

I appreciate any input or expertise.

  • Well, that depends.   Monitoring both can cause Netflow to report double the data that is really going across the link if you don't do it right.

    I'll give the quick explanation as I've figured it out through working with it.

    If all the data you want to monitor is going to go through a single link, then you can do ingress and egress netflow on that one interface and should be just fine.

    However, let's say you have two WAN links, a main link and a backup.   Or if you have multiple VLAN's controlled on the router.  In either of those cases, there are multiple directions that the traffic can go.  In this case, you would want to do ingress monitoring on all the links, that way you capture the data >once< no matter which direction it goes.   Let's say your ingress link was ser0 and your LAN links were fa0/0.1, fa0/0.100, fa0/0.200, fa0/0.300.   If 100mbps of data came in ser0 and went to a client on the fa0/0.100 vlan and you captured both ingress/egress on both of those links, you would see the traffic coming in ser0 and out fa0/0.100, or twice on the same device at the same time.  This would show up on your graphs as 200mbps of data.   Make sense?

    Lets look a little bit deeper.   Lets say you had two VLANs on the site, VLAN 1 (fa0/0.1) for internal traffic and VLAN 2 (fa0/0.2) for guest traffic.   All your WAN traffic came in from the internet on Ser0.   You have an IPSEC/GRE tunnel to your home office for internal traffic, on Tun0, and you split-tunnel the internet traffic directly out.    If you didn't care about monitoring Guest network traffic, you could just do ingress/egress monitoring on Fa0/0.1.   But, if you want to monitor all traffic, you should do ingress-only monitoring on fa0/0.1 (inbound from LAN), fa0/0.2 (inbound from Guest network), Ser0 (to capture inbound internet traffic) and on Tun0 (inbound from your corporate network).     Why both ser0 and tun0?    They are both on the same link, won't it show double the traffic?   The answer is yes and no.  If you just monitor Tun0, you will see the corporate traffic, including what servers were contacted and such.   If you just monitor Ser0, you will see all the traffic out to the internet as well as all the corporate traffic.  However, the corporate traffic will show up just GRE tunnel traffic, because by monitoring Ser0 you only see the GRE tunnel traffic, not what's inside of it.

    Gets a bit confusing, but does make some sense.   In general, you're better off simply doing ingress monitoring on all links rather than trying to decide what link you might be able to put ingress/egress filtering on.

    Make sense?

  • That's quite confusing for me too. I always have to deep think from which side I should seek for some anomalies on traffic to find them. Can't remember what does it means: Do I look it from interface point of view or network point of view. ...Is ingress traffic actually the traffic coming to INTERFACE (means out from sub network) or to NETWORK (out from interface). And interface in here means physical port or VLAN (same thing). Somehow I always have to think what does it mean. Embarrassing... emoticons_blush.png

    For example someone says "please check if there's is something going on in WAN link, because internet is slow". So internet traffic is (mostly) coming IN-direction to my network, I understand it that far. But is traffic coming into our WAN VLAN-subnet from WAN router (ingress), or traffic coming to netflow collector from WAN VLAN subnet (egress). So is it ingress or egress in that point of view. Maybe I think it too complex... emoticons_grin.png Would be nice to have a thumb-rule to remember how to think it from VLAN point of view. (I'm monitoring VLANs only)


    Anyway, it's possible to filter NTA to show one traffic (ingress or egress) in time, but do I still see some traffic two times? If so, that's news for me!

  • I think that makes sense. For conversation sake, why wouldn't you just do ingress/egress monitoring on the WAN interfaces (even if you have multiple WAN connections at each site) instead of doing ingress monitoring on the LAN and ingress on the WAN?

    Also, I have Cisco WAAS so if I monitor on the LAN interfaces it's reporting on traffic being sent to the WAAS before optimization and before going out the WAN link. Seems to me that's not the best place to get the most accurate reporting.

    Thanks for the input.

  • You are correct, in an environment with WAN compression, doing ingress monitoring on the LAN interfaces will show more traffic than is actually going out the WAN interface.  If you do egress on the WAN interface, you get post-compression statistics.  If you do ingress on the LAN interface you get pre-compression statistics.   So, the question would be which do you want?

    There are also concerns with multicast traffic doing ingress filtering too.

    However, if you just do ingress filtering on your WAN links, there is other traffic that could be missed.   The first and most obvious is traffic from the LAN to the router itself.  Ie: if it doesn't egress the router, how would you see it?   This could including anything from PINGS, to routing traffic, maybe a hacker on the LAN trying to hack your router, etc. etc...

    What is probably more significant is if you are doing VLAN's on your LAN interface, you would miss inter-vlan traffic.   ie: if a device on VLAN 1 were communicating with another device on VLAN 2, monitoring your WAN interfaces would not pick up on this.

    The last thing that ingress/egress filtering might distort is if this router can be used to transit information to another location.    I'll use a practical example from a prior job.   We had two head-end routers in different data centers that were geographically separated by maybe a couple hundred miles near Chicago, lets call them sites A and B.   We had two large remote locations in South Carolina which we'll call sites X and Y.    Between A and B there was an OC-192.   A was connected to site X via a T3.   B was connected to site Y via a T3.   X and Y had a T3 between them, which allowed them to use the others link should there be a failure somewhere.  But, in some cases it did route some traffic through one site from one or the others datacenters.    If we were to do ingress/egress monitoring on sites X and Y, which would have been on 2 WAN interfaces at each site, if any traffic was to transit to site Y through site X, you would have seen some of the traffic volume doubling.    So, if any traffic might use a given router to transit out one of the other WAN links, ingress/egress monitoring can be bad.

    It all depends on what is important to you and what information you want.   It is not bad to do ingress/egress filtering, but it can cause troubles where you see double the traffic at times.  However, if you aren't going to transit any traffic, you don't care about inter-vlan traffic, or traffic to the router itself, it can work for you quite well AND have some benefits if that's what you want.

    But, in general, ingress filtering on all links has the least chance of having problems AND the best chance of monitoring all traffic.   But, if see post-compression data, or needing to see what interface multicast traffic went out is a higher concern for you, go for it!

    HTH!