End to End Visibility: Path Through the Network
Quality of Service (QoS) is a paramount concern for most network administrators. To try an guarantee it, the prioritization of voice, video and other business applications are generally configured on every core switch and router and sometimes even on the periphery switches. But, all it takes is one intermediary device between A & B to degrade the overall quality of the connection and if the communication is traveling through several network devices (i.e. switches and routers) how do you know which device(s) introduced the issue?
In the world of computer networking, the concept of end to end visibility on the specific path a datagram takes through a meshed topology is often not possible. Sure some mapping utilities provide OSPF or RIP topology maps but, if multiple paths between A and B exist, these protocols can’t be reliably depended on to definitively answer the question “which way did it go”. Trace route isn’t reliable because different applications between points A and B could take different paths. And here’s another twist: due to the resiliency we’ve built into our infrastructure, the topology can dynamically change during the day due to outages or even high traffic loads. This means the path between A and B three days ago could be different from what it was this morning and even different again from what it is right now.
If you are trying to trouble shoot an end user problem that occurred earlier in the day, going back through the data (e.g. NetFlow history) can be a very cumbersome process. Ideally, you may want one click answers to questions like:
- What exact path (i.e. hop by hop) did this flow take through the network at the time of the transaction?
- Did the DSCP or ToS value change in the flow in either direction and if so, where?
- Was the connection path in both directions exactly the same?
Determining the above is possible with NetFlow exports. Take a look at the connection below.
When looking at internal traffic, Flow Hopper is a utility that leverages NetFlow data which includes next hop information to map out the connection path for a specific flow. If the path were to change 10 minutes later, the flow created and sent off to the collector for archival would contain a different next hop. NetFlow is inherently ideal for retrieving historical path details. Take a look at the next Flow Hopper example:
Notice above that the path from A to B is completely different than the path from B back to A. This flow stitching technique is used to map out both flow directions. Best network traffic monitoring practices benefit from details like those demonstrated above but, the switches and the routers on the network must support NetFlow or IPFIX. This can’t be done with sFlow. If you want to learn more about Advanced NetFlow, join NetFlow Developments on Linkedin