I’m doing some more work lately with Wireshark and Scrutinizer v7. I thought that the topic of egress vs. ingress might be interesting to some readers.  NOTE: Egress is only available in Cisco NetFlow v9 and not NetFlow v5.

IPFIX or NetFlow v9?
In theory, ingress and egress should work the same in IPFIX, which is based on NetFlow v9, but they are certainly different. Although they are very similar, don’t let any company tell you they are exactly the same. Many collectors that work with NetFlow v9 will puke when they receive IPFIX. Scrutinizer handles both with ease. Nortel supports IPFIX, as does/did Avici, which is now Soapstone Networks, Inc. Other vendors, such as Adtran and Enterasys, support NetFlow v9.

One annoying area where IPFIX and NetFlow v9 differ is in the labeling of fields: NetFlow v9 has ‘IN_BYTES’ and IPFIX labels the same field ‘octetDeltaCount’.  IPFIX probably renamed it because when talking about egress flows, IN_BYTES is sort of misleading.

Ingress vs. egress differences
NetFlow v9 Ingress is collected on traffic going into (i.e. inBound) an interface.  This is how NetFlow v5 collects data. To figure out outBound traffic volume, ingress must be collected on all interfaces and the reporting software then displays outbound traffic. What goes in must go out, right?  Ya, usually.

NetFlow v9 Egress is collected on traffic going out (i.e. outBound) of an interface.  Generally, it is used in combination with Ingress, but it doesn’t have to be. I’ll dive into this a bit more.

Why collect with egress?
Why collect with egress, if ingress worked so well with NetFlow v5? Because hardware such as WAN optimizers compress data.  Traffic compression with Cisco NetFlow means that what comes in 100 bytes might go out as 50 bytes. If only using ingress flows, the NetFlow reporting software will show 100 bytes outbound, even if it was compressed to 50 bytes. GASP!!! This is because it was calculated using ingress flows.

Tell me the truth!
If the router is exporting both ingress and egress and the NetFlow monitor can report on both without overstating utilization, you can see how much of each flow is being compressed. It’s pretty slick, but it requires that the NetFlow collector understand what is known as the flow “Direction”. If the field in the NetFlow v9 packet is a 0, then it is an ingress collected flow.  If the field is a 1, then it is an egress collected flow.

Ingress Flow with IPv6 (the same with IPv4)

Egress Flow with IPv6 (the same with IPv4)

The network traffic reports produced by the NetFlow analyzer need to be intelligent when dealing with ingress and egress flows. I feel that dynamically figuring out flow direction in mixed NetFlow v9 ingress egress environments is crucial, especially if the customer has hundreds of routers. If you are just setting up ingress, I would keep this blog in mind: “ip route-cache flow or ip flow ingress… Which do I use?”

Something else to think about
NetFlow traffic analysis is going to be taken to another level as Flexible NetFlow matures. Perhaps we’ll see it take advantage of what NetFlow v9 calls ‘OUT_BYTES’. (IPFIX, needing to be different, calls this same field ‘postOctetDeltaCount’.)

Now you might ask: how is it related to ingress or egress?  Stay tuned…

Michael Patterson
Scrutinizer Product Manager
Follow Me on Twitter

For some reason, this week I’ve been bombarded with questions regarding configuring the 6509 Catalyst for NetFlow.

Being a switch/router hybrid model, the configurations are a little different from standard CISCO routers models, like the 2811, but not too much.

I would also recommend checking out this great resource directly from CISCO to configure the 6509 Catalyst for NetFlow.

With most CISCO routers, there are two sets of commands used to enable NetFlow. However, with the 6509, there are technically three sets of commands.

To enable NetFlow on the router, you need the following:

ip flow-export source (insert interface name here)
ip flow-export version 5
ip flow-export destination (netflow collector ip address) (port to export flows to)
ip flow ingress layer2-switched vlan (insert vlans X,Y,X) <---- this will enable flows for all bridged traffic
ip flow-cache timeout active 1

Once those are in place, we now need to configure NetFlow for the switched traffic:

mls nde sender version 5
mls flow ip interface-full
mls nde interface
mls aging long 64
mls aging normal 64

After you have configured these globals, you now can configure each of the interfaces themselves for NetFlow:

ip route-cache flow
ip flow ingress

I have discussed the usage of the ip route-cache flow and ip flow ingress commands before. You might want to take look for more details.

That wasn’t so bad, was it?

-Nate

If you’ve ever configured a router for NetFlow, you may have had to work with either, or both, of these commands.

When configuring NetFlow on your router, you have two sets of configurations to setup. First, being your global commands that define which version of NetFlow is being used, where the flows will be exported, and on what port.

After configuring the global commands, however, you also need to configure the interfaces that will be using NetFlow. To enable flows on an interface, you have two commands that are very similar in nature, but used in different circumstances.

For more information regarding NetFlow configurations, check out this Activating NetFlow Guide.

So, back to the original question: “Do I use ip route-cache flow or ip flow ingress?”

Deciding which interfaces you want to monitor will answer this question.

If you are interested in monitoring flows on a physical interface, you would use ip route-cache flow. By enabling ip route-cache flow on the physical interface, it will in turn enable flows on all subsequent sub-interfaces.

But let’s say that you are not interested in seeing flows on sub-interfaces x,y and z; but you do want to see flows on subs a, b and c, from that same interface. This is where the command comes into use.

So as a quick summary:
ip route-cache flow will enable flows on the physical interface and all sub-interfaces associated with it.

ip flow ingress will enable flows on individual sub-interfaces, as opposed to all of them on the same interface.

Cisco’s article on Netflow and subinterface support offers a wealth of information on this subject.

**NOTE** With NetFlow v5, we only had the option to monitor inbound statistics using the ip flow ingress command. However, with the release of NetFlow v9, we now have the option to monitor traffic leaving each interface via ip flow egress. Check out this blog which tackles the question: Which one is better to use? Ingress or Egress?

-Nate

Hello everyone,

Welcome to the launch of our new website Systrax! Coming from the technical support desk; we all hope that you will find valuable threads and blogs that will make Scrutinizer even easier to manage than it already is…

In an effort to make sure that your copy of Scrutinizer is running at 100%, we will be posting blogs that will tackle some of the most common issues that we see with customers when they request support.

Today, I wanted to address an issue that some customers don’t even notice when calling for support. Netflow misconfigurations.

First, let’s give every Network Engineer out there a gold star for the effort they put in setting up all the 50 billion devices on their network for Netflow. That’s no small feat…

So now that you have Netflow setup, let’s make sure of the small things too…

Listed below is a screenshot taken from a customer that we have worked with. Thanks to Chris for letting me use his setup as an example.

Looking at these interfaces, there’s a couple problems to take note of. The first thing that screams at me is the utilization on those interfaces. How can an interface have more than 100% utilization? Stay tuned for a later blog to address this issue…

But let’s focus on another big issue. If you look closely, you may notice there are interfaces showing 0% utilization for either inbound or outbound traffic…

Now either there is truly no traffic coming in/out or we have a problem. Personally, I look at the 3rd interface from the top and I’m a bit skeptical. 101% utilization inbound with no outbound traffic? Uh huh…

So what causes this problem? If you’ve ever looked at our FAQ, we have provided you the configurations you’ll need to enable Netflow on your devices.

It’s basically 2 steps. Setup the global Netflow configs and then enable each interface.

Below is the command used for each interface.

router(config)# int Eth0/0

router(config)#ip route-cache flow

Along with the global Netflow commands that you have setup, it’s critical that you enable ip route-cache flow on every active interface. If the inteface is enabled and is routing any traffic, be sure to slap that config on that interface! If you do happen to forget to configure an active interface, Scrutinizer will report 0% utilization on either inbound or outbound traffic on every interface for that device.

As a note, if you do end up going back to your router to enable an interface with ip route-cache flow, be sure to give Scrutinizer a few minutes to report the utilization…

Technorati Profile