Egress on Cisco 6500 and 7600

[BenjaminM]

Hello Everyone,

While working with a customer recently I have discovered an interesting fact about the Cisco 6500 and 7600 devices. Both devices do not support egress due to a hardware limitation. If you are running into an issue with egress on the 6500 and 7600, than this may be why.

I hope this helps.

For any further questions regarding Flow configurations on devices, please reference our activation page
http://www.plixer.com/products/netflow- ... -sflow.php

Thanks,
Ben

[Koen]

This is exactly what I've encountered at almost all of our 6500 switches. Usually the ip flow egress command is not recognised on the interfaces (while ip flow ingress or ip route-cache flow is). However, like I said, I could swear I have seen it working on one or two of our 6500's.
-> Could it be possible this depends on the IOS version and/or use of a SE720?

Network:
[MPLS]-----[CPE Router]---[6500 Coreswitch]-----[LAN]

Since ip flow egress was not available there were 2 options to monitor our WAN line on the switch (usually one port to the CPE router) both inbound as outbound:

1) Configure all the interfaces on the 6500 with the ip flow ingress or ip route-cache flow command.
Result: inbound traffic would be reported directly for the WAN port, outbound traffic would be compiled by Scrutinizer by combining all the inbound data from all other interfaces where source was the WAN port.
Con: Scrutinizer would receive Netflow data from all traffic passing the coreswitch, which would result in enormous amounts of data. Besides the data history would be a problem, we suspected this might have a major impact on switch CPU utilisation and the Scrutinizer server CPU utilisation.

2) Copy the WAN port inbound and outbound to two SPAN ports on the switch, using a probe to receive this data and generate Netflow records both inbound as outbound.
Result: Probe would send both inbound/outbound data to the Scrutinizer server.
Con: Expensive: every site would require a probe.

So at first we didn't want to bother our ISP configuring all the managed CPE routers (and ofcourse we like to have control of our settings), but since this was our only good option we decided to go for that anyway.

-> Is there something I've missed in this analysis?
-> Can we expect Cisco to add ip flow export support in the future on 6500's?
-> For what solution did you customor go in the end?

[BenjaminM]

Hi Koen,

It may be possible that this issue depends on the IOS version of your 6500 and/or use of the SE720. Can you give me a better comparison of your devices that do/don't support ip flow egress command? Are all of them using the SE720? What IOS are they?

A1) This result is true. Our customer was not experiencing a tremendous amount of data for this to worry him. Unfortunately, if your 6500 does not support ip flow egress, than this may be the only solution without missing any data.

A2) Probes are fantastic. nProbes are our go-to probes at the moment. We have been working with them to support many special reports like URL and Latency statistics. Unfortunately, the price may be expensive.

http://www.plixer.com/blog/netflow/scru ... -analysis/

Cisco is aware of this issue and has a bug ticket open on this.

The customer was able to just configure ip route-cache flow on all of his interfaces and he was able to see the information in Scrutinizer.

Does this help?

Thanks,
Ben

[Koen]

It may be possible that this issue depends on the IOS version of your 6500 and/or use of the SE720. Can you give me a better comparison of your devices that do/don't support ip flow egress command? Are all of them using the SE720? What IOS are they?

Hi Ben, I'm sorry but I don't have any records of that anymore. I was hoping (ideal case) you had a matrix of switches vs IOS version, listing which supported what kind of NetFlow features (which would be awesome). It's a year ago that I was working on that issue, and in between then and now I've left the office for 5 months, so I really can't remember any more details.

A1) This result is true. Our customer was not experiencing a tremendous amount of data for this to worry him. Unfortunately, if your 6500 does not support ip flow egress, than this may be the only solution without missing any data.

So this was the solution your customer went for.

Our sites with 6500 cores usually have multiple 4500's as the access layer and can have up to a 1000 connected users, and including local server farms. Yes I've found some benchmarking documents (also from Cisco) about switch CPU utilisation with different kind of NF configurations running, but since I don't have a good simulationnetwork I didn't want to take any chances.

A2) Probes are fantastic. nProbes are our go-to probes at the moment. We have been working with them to support many special reports like URL and Latency statistics. Unfortunately, the price may be expensive.

I'd love having nProbes in our network, however we're probably talking about 15 sites which would require such a device. Management is highly likely not willing to invest in a project of $xx.xxx, unless I come up with a damn good reason. You're talking about latency reporting: I've seen this demonstrated at the Plixer blog by some of your co-workers, using routers/L3 switches supporting NF v9+FNF.

This is offtopic, but I'm going to ask it anyway. We're going to move the entire organisation to VoIP somewhere in 2012/2013, and being able to measure latency, jitter, what more would be a great help for troubleshooting. Since I know Scrutinizer can handle this data and present it the common way, it seems like a good tool for this. Would a nProbe list all the neccesary fields in the NF records it sends to the collector, or do you really need to have advanced FNF support (as in: very recent version of IOS) in your switch/router?

[BenjaminM]

Hi Koen,

Unfortunately, we do not have a matrix document of switches and IOS versions. This is something interesting to ask Cisco about.

FnF alone does not give you latency. You do need FnF to turn on medianet. SonicWALL will also give you latency.

nProbe does give some excellent latency reports. For VoIP, I would suggest Cisco medianet. We have worked with Cisco to create reports that will give you: Jitter, packetloss, QoS, and RTT of EACH phone call - and how much data that phone call used.
http://www.plixer.com/blog/voice-over-i ... t-netflow/

I hope this helps.

Thanks,
Ben

[Koen]

If you ever find such a document from Cisco I'd be happy to hear about it!

Anyhow, the whole FnF+Medianet is topic I might get back at some day in the near future. Thanks for your help so far.

[BenjaminM]

Hi Koen,

No problem. If you have any more questions, please do not hesitate to contact us again on the forums.

Have a wonderful holiday!

Thanks,
Ben