Cisco Catalyst 3850 has become a next generation switching platform in our company. We have deployed these switches in a number of our offices recently. Apart from being a converged wired/wireless access platform, it fully supports Flexible NetFlow. Therefore, it was a logical step to begin using this neat feature at least on our branche core switches to improve monitoring capabilities and lessen troubleshooting efforts. I have faced a number of issues while I’ve been trying to configure FNF on the first switch to perform some testing. So…
First of all, Catalyst 3850 is a hardware platform, it has to perform NetFlow collection and reporting without affecting the performance of its main task – packets/frames forwarding. Hence, hardware platform limitations cannot be avoided. This switch’s Flexible NetFlow does not have access to as many amount of fields/keys as on any ISR platform. The most essential limitation relates to the availability of information about ingress and egress interfaces. Catalyst 3850 is unable to provide egress interface information for flows captured in ingress/input direction. Likewise, it does not provide ingress interface information for flows captured in egress/output direction, such as shown on the following screenshot.
For this reason, it is not possible to use single flow monitor for both directions! There must be at least two FNF monitors configured, each referring to its own FNF record. Output record will use output interface as its key/match criteria and Input record will use input interface as its key/match criteria. Even though it is possible to configure FNF record to collect non-key information about ingress/egress interfaces, it will always be set to Null0 (as shown on picture above).
This limitation can be critical for NetFlow collecting systems that try to visualize flows information, such as LiveAction.
Keep in mind that flow collection on Catalyst 3850 can be enabled on VLANs, Layer 2 and physical Layer 3 interfaces, but not SVIs. This may or may not be critical in your environment. We use LiveAction as our NetFlow collector and because of this limitation we are unable to use historical data, can only see live flows information. I do believe this is going to be fixed by support team, but… it will take some time.
The last annoying thing (or is it a bug? I haven’t asked Cisco yet) is that flows collected in output/egress direction have original DSCP value (the one that packet have had before ingress classification took place). It is very annoying and frustrating. It is clearly seen on the picture above, where there’s a TCP flow from 10.X.106.117:62605 to 10.Y.151.107:443 with DSCP 33. In our company we apply DSCP 33 to Lync signaling traffic using Windows GPO. However, this DSCP is then mutated to DSCP CS3 on ingress of the switch (it is being done by per-VLAN QoS classification and marking policy). It is indeed mutated. The following screenshot shows the same flow captured on the adjacent Cisco router from the directly connected interface (where no service policies exist).
There are no egress marking policies on the switch and no ingress marking policies on the router. Hence, why does it show original DSCP value on the switch in egress direction? This is unclear at the moment, but I will raise it with Cisco. An update will follow soon…