The Need for CEF(peed) – Part 2

Today, we’ll wrap up the CEF discussion with the last two exam objectives regarding CEF:

1.1.b (ii)   Load balancing Hash
1.1.b (iii)   Polarization concept and avoidance

CEF Load Balancing

By now, you’re probably familiar with the concept of how IOS chooses a “winning” route when it has multiple unequal paths to a destination.  But what about when a router has multiple paths to a destination that are equal – same prefix length, metric, administrative distance, etc.  Which path should IOS use then?  The best answer, of course, is “All of them!”  CEF can do just that!

To determine the method being used for load balancing, there are a few important considerations.  First and foremost, some routers, such as the ASR series routers, have the ability to run CEF in dedicated hardware.  If that is the case for your router, you will have the ability to activate the global configuration level ip cef distributed command.  This further offloads processing requirements from the routers main CPU.

Next, you can run the CEF algorithm on a per-destination or a per-packet basis.  Per-destination is the default, and is preferable in most cases.  The reason for this is that you usually want packets destined for the same host to take the same path.  This helps avoid issues that can be caused when packets arrive out or order, which can cause issues for applications like VoIP and Video streaming.  Further stateful firewalls can have trouble managing traffic when they only see a part of a conversation.  If you do need to change this default, it can be done per-interface with the no ip load-sharing per-destination command.  Then, turn on per-packet mode with the ip load-sharing per-packet command.  This might need to be done in cases where the majority of traffic is going to and from a single pair of hosts.  The traffic between two hosts would normally always follow the same path.  That can be changed with per-packet sharing.

That essentially defines when you want to run the algorithm (either when a source/destination pair exists, or when each and every packet arrives).  So now we need to define how the algorithm actually operates.  This can be changed from global configuration with the ip cef load-sharing algorithm {universal|tunnel|original} command.  The default is “Universal” and is sufficient in the vast majority of cases.  The “tunnel” option can be used in cases when there are virtual tunnels terminating on an interface, such as GRE.  “Original” exists for backwards compatibility, and unless absolutely necessary, should always yield to the “universal” option.  The difference between these two algorithms leads us beautifully into our next section.

CEF Polarization and Avoidance

The original CEF load-balancing algorithm was susceptible to a concept called “polarization”.  To understand what polarization is, imagine a router named R1 that is connected to two downstream routers, R2 and R3, and that each of those two downstream routers are each connected to two more downstream routers, R4, R5, R6 and R7.  Let’s say for the sake of simplicity that R1 runs an algorithm that assigns a packet an even or an odd number, then hands off even numbered packets to R2 and odd-numbered packets to R3:

In

Algorithm1

 

 

 

 

 

 

 

Out

Algorithm2

 

 

 

 

 

 

 

So far so good, right?  The problem is that the original implementation of CEF would then run the EXACT same algorithm at the next step.  R2 will assign an “even” value to every packet it receives and will hand off all traffic to R4, while leaving the link to R5 completely unused.  R3 would likewise assign an “odd” value to every packet and will hand off all traffic to R7, leaving its link to R6 completely unused:

Algorithm3

 

 

 

 

 

 

 

 

So how do we avoid polarization?  The simple answer is “don’t use an old IOS version.”  Newer IOS versions no longer use the original implementation of the load-balancing algorithm, defaulting to the “universal” algorithm.  The universal algorithm accomplishes this by essentially adding a randomized number into the CEF algorithm, helping ensure that no two routers will make the same path selection decision for the same packets.  Since newer routers use this algorithm, polarization avoidance is relatively easy to accomplish.  You can see the exact path that a packet will take with the show ip cef exact-route source-host destination-host command.

CEF is an important concept, and certainly worth taking a few minutes to learn about.  Thanks for tuning in!

Leave a Comment

Your email address will not be published. Required fields are marked *