NMS Topic : NetFlow

NetFlow began its life as a routing technique similar to Fast Switching or CEF. It has since evolved to become a useful accounting technology.

Cisco NetFlow consists of three components:

  1. Network traffic analysis and collection (performed on a network element)
  2. Flow record export (network device sends the records to a ‘collector’)
  3. Flow analysis (automated or performed by humans at a NMS console)

Flow records contain any number of KEY fields, including

  1. Source/destination IP address
  2. Protocol and Port
  3. ToS values

NetFlow has gone through several revisions, but the most popular ones are:

  1. version 5 – probably the most widely deployed version
  2. version 8 – specific to the Catalyst 6500
  3. version 9 – this is the version you should be deploying

For those of you looking for an IETF standard, the IPFIX working group used the version 9 architecture as a starting point.

What NetFlow is:

You can use NetFlow to help you with Traffic Engineering, security analysis, and billing. Since it is low cost (free on Cisco devices), you can more easily deploy NetFlow than external RMON probes.

What NetFlow is not:
NetFlow is not a replacement for a protocol analyzer. Think of NetFlow as a “phone bill” for your network. You are less concerned with the details of a particular conversation, but you are concerned with who talked with whom, and how long the conversation lasted (the cost). NetFlow Data Export (NDE) rides UDP, so it susceptible to the same problems as other UDP applications.

Under what circumstances would you deploy NetFlow, and what design considerations do you need to keep in mind?

Engine (Record Generator) Placement
Try to minimize the amount of duplicate records. Configure NetFlow accounting on ingress and egress interfaces. It is usually not necessary or desireable to configure NetFlow on transit devices.

Record Collector Placement
Place the collectors as close to the sources as possible.
You could use Anycast as a collection mechanism, with an out-of-band backhaul to a central management station.
Keep in mind the UDP nature of export.

NetFlow resources:

Flexible NetFlow Whitepaper



Sorry I’ve not posted anything recently: I’ve been studying intently for 352-001. It must have worked out because I passed the qualification today. First attempt.

Here’s what I need to work on:

QoS is definitely my weakest area. I think it’s probably good to revisit my original plan of taking and passing 642-642

I am also weak in Management. Unfortunately there’s not a good test to study for this, so I’m going to at least begin by reading Network Management Fundamentals.

I will also need to more intensely study the variety of MPLS offerings available. It opens up a whole new area of service provisioning.


CCDE Written Outline Topic 4 : CMIP and TMN

A few notes from the Written Outline Topic of Management:

“Identify when use of CMIP is appropriate”

CMIP stands for Common Management Information Protocol and was designed for OSI-based network management. It was designed as a competitor to SNMP and supports the following:

  • The ability to perform tasks – as opposed to SNMP which can only perform SET and GET
  • Logging and AAA
  • Better reporting of network conditions


“Identify when use of TMN is appropriate”

TMN stands for Telecommunications Management Network

I found this on Wikipedia : “TMN can be used in the management of ISDN, B-ISDN, ATM, and GSM networks. It is not as commonly used for purely packet-switched data networks.”

TMN uses CMIP.

From what I’ve been able to gather, TMN and CMIP are appropriate for GSM and circuit-switched networks. I don’t know of any implementations for packet-switched networks. Anyone care to disagree?

TMN Tutorial


CCDE presentation from Cisco Live 2008

I did not attend Cisco Live, but someone has posted the presentation Russ White gave on the CCDE here.

A few comments on the information in this presentation.

Under the “why are we doing this” section they note that a lot of L3 design issues are coming up, despite being “easy”. Expect a lot of L3 issues on the CCDE.

Business problems are the primary driver of the CCDE test questions.

The skill set tested should be timeless.

Is generally vendor neutral.

The practical will be computer-based – no lab environment.

You’ll be presented with a bunch of information, from which you generate requirements. After answering some questions through a variety of means, you’ll gain access to additional information.


CCO Documentation?

CCO contains a wealth of information for those preparing for the CCIE exam. Unfortunately, that same information is not necessarily good preparation for the CCDE exam. The CCDE won’t be testing your CLI skills, or even your Cisco feature implementation skills. No, the CCDE claims to test timeless network design skills, which requires something different. Design is considered a dark art, since most of the answers begin with ‘it depends’. The trouble is, you’re expected to know what the conditions for deployment will be, and as network designers we work with imperfect information. Customer requirements are fuzzy since customers sometimes don’t know what they want. Feature parity between platforms can be frustrating. The CCDE will most likely be testing your ability to see big-picture issues instead of digging into the weeds. Nobody but the CCDE creators know, of course, but we can infer this information by the reading list and written outline.

Let’s look at the first topic: IP routing

  1. Explain route aggregation concepts and techniques.
    1. Purpose of route aggregation
    2. Scalability and fault isolation
    3. How to Aggregate

Nothing in here will be specific to Cisco products. Nothing in here will be feature/platform dependent. What is in here, however, is IP routing protocol dependent.

What is the purpose of route aggregation?

We aggregate to scale our networks. By aggregating, we reduce the impact of a link flap in one area of the network. We hide topology through aggregation. Link-state and Distance-vector routing protocols aggregate in different ways. If we want to hide topology in link-state, we need to use areas for aggregation. Distance-vector by definition hides topology.

Do you notice what’s left unsaid in the above question? I think a key question you need to ask yourself is:

What are the problems with route aggregation?

Route aggregation hides topology. Route aggregation can result in suboptimal routing. How do you fix these issues if you need to? Why should you care? Topological information hiding can be useful, but can be detrimental in the case of Traffic Engineering and Mobility. With Mobility, as your users move around the network you will be unable to aggregate as effectively. Suboptimal routing is something you may not care about immediately, but it could cause problems for your customers depending on link speed, etc, and you should know how to address these issues in your design.


back home..

Hi everyone, I’m finally back home after a week without Internet access. I’ve received a lot of comments & emails that deserve replies and/or posts. I’ll be working to address these issues shortly. Bear with me please as I recover from jetlag.


Best Common Practices

For those of you who don’t know, the IETF publishes these documents called BCPs (Best Common Practice). These documents are useful to see what the Internet community believes is a best practice for a particular deployment type. I think these could be useful for CCDE study – not only because one of them is referred to on the written outline (BCP38) – but because they contain some very useful design information. BCP121, for example, contains MSDP deployment scenarios.

Here’s the full listing of BCP documents.

BCP128 – Avoiding ECMP in MPLS networks looks interesting.