CCIE or Null!

My journey to CCIE!

Posts Tagged ‘Cisco Express Forwarding

Cisco Express Forwarding – CEF

with one comment

In my last post about unicast Reverse Path Forwarding, I made quite a few references to CEF. CEF (known as Cisco Express Forwarding) is a feature built into every Cisco router and is enabled by default it’s really the feature that makes Cisco well Cisco. I figured I would take a little time and discuss CEF in a little detail.

From a 500 foot view CEF is a method the router uses to forward packets, without utilizing any CPU cycles. CEF builds 2 cached tables in memory, these 2 cached tables are built from every entry in the routing table. So when the next packet arrives the router simply looks up the CEF entry found within memory to forward the packet, compared to sending the packet to the packet to the CPU for a route lookup and then forwarding the packet on.

CEF works by creating two tables:

  1. The Adjacency table maintains the layer 2 forwarding information for each FIB entry eliminating the need for the router to send out ARP requests.
  2. The FIB (Forwarding Information Base, also known as the CEF table) contains information from the routing tables and tracks the next-hop for all routes. So where the adjancency table manages layer 2 information the CEF table manages the layer 3 forwarding information

Now that we know the components of CEF, lets talk a little about how CEF interacts with packets as they enter the router.

  1. Once the packets arrives at the router the layer 2 information is stripped off. (This is normal and happens whenever a frame is accepted to a layer 3 device)
  2. Next the router looks up the destination using the CEF table.
  3. Then the router finds the corresponding adjacency table entry.
  4. The router then adds the corresponding layer 2 information (found in the adjacency table) back to the packet and forwards the packet on. All from memory.

You can view the CEF table by issuing the command sh ip cef:

Now remember the CEF table is layer 3 information so we have destination prefixes and what the next hop address is along with the outgoing interface.

You can view layer 2 adjacencies by issuing the sh adjacency %Interface% detail:

Since the adjancency table pertains to layer 2 information we’ll see some MAC addresses here, one thing I want to point is that long hexidecimal number in the fifth line that line consists of the destination MAC address of 10.1.1.2, the source MAC address of this routers fa0/0 interface and the ethertype of 0800 (Meaning it’s an ethernet interface)

Now this was only the tip of the iceberg for CEF, and this post was only supposed to bring it to light on a real high level so more CEF related posts will mostly surface as time goes on.

Written by Stephen J. Occhiogrosso

October 11, 2012 at 11:05 AM

Unicast Reverse Path Forwarding uRPF

with 5 comments

Another great security feature within every Cisco IOS ISR is uRPF, Unicast Reverse Path Forwarding. This nifty little feature has the router verify the source of any IP packets received is reachable via the routing table. uRPF is used to prevent common spoofing attacks and follows RFC 2827 for ingress filtering. The router will actually rely on the CEF table to perform lookups. uRPF works in 2 modes strict mode and loose mode, lets quickly talk about these two modes of operation.

  1. Strict Mode: In this mode the router verifies the source of the IP packet arrives on the same interface the router would use to reach that source address. Beware of asymmetric routing.
  2. Loose Mode: In this mode the router simply verifies the source IP can be reached via the CEF table using any interface.

Now that we quickly discussed the 2 different modes uRPF operates in, let’s go over a few quick tips:

  1. Since uRPF relies on CEF, CEF must be enabled.
  2. uRPF takes into account multiple paths, so if you are doing any equal cost load sharing uRPF will take that into account. uRPF will also take into account any unequal cost load sharing (such as EIGRP variance).
  3. Asymmetric routing is different from (un)equal cost load sharing, and can/will cause issues with uRPF.
  4. uRPF works best at the network edge, and to further specify the network edge not on your access layer the network edge facing the public internet.

Let’s now configure uRPF, we are going to start off with the configuration of loose mode:

This is a good time to mention uRPF is configured on an interface basis, and it is enabled by a single command. The keyword at the end of the command specifies the mode uRPF operates in, since I am configuring uRPF in loose mode I want to make sure the router can reach the source of any IP packet received on interface fa0/0 using any interface on the router.

Now let’s configure uRPF to operate in strict mode:

You’ll notice this command is very similar to the way enable loose mode, with the exception of the keyword rx at the end of the commend, this tells the router to verify the source of any IP packet received on interface fa0/1 should be reachable via interface fa0/1 and not any other interface on the router. As mentioned previously the router verifies connectivity by looking at the CEF table, if CEF points to an interface that the packet was not received on that packet will get dropped.

Now that we have configured uRPF (simple right?) let’s issue a couple show commands to verify our configuration:

Show ip traffic – This command will tell you how many packets uRPF has dropped.

Under the IP statistics the first Drop section has an entry for unicast RPF this counter keeps track of how many packets uRPF drops which is definitely useful to know. You’ll also notice 12 packets were dropped, which we will discuss later.

Another command is show cef interface %Interfacenum/num% this command will also tell you whether or not uRPF is enabled on the specific interface.

Let’s also not forget the simplest command of them all: show run interface %interfacenum/num%

One feature that makes uRPF even more powerful is the fact we can tag on an ACL specifying traffic we want checked or don’t want to be checked. For example I configured uRPF on one my lab routers that had an old DMVPN & BGP configuration running on it, shortly after I configured uRPF I noticed the BGP adjacencies to the spokes go down. After that I configured an ACL so my DMVPN Tunnel traffic was not caught by the uRPF check.

You guys should know by now how much I love named ACL’s but you’ll notice I used an extended numbered ACL, the reason for that on the is simply due to the fact I couldn’t use a named ACL with uRPF.

No option to use a named ACL only numbered ACLs. There are two other options there allow-default which allows the default router to be used when verifying source addresses, and allow-self-ping which allows the router to ping itself, although allowing self-ping opens the router up to a DoS vulnerability.

You can also read more about uRPF in RFC 3704.

Written by Stephen J. Occhiogrosso

September 10, 2012 at 9:08 AM

%d bloggers like this: