CEF and access-list

[sarahr202]

Hi everybody

h1(10.10.10.100--f1/1(layer3sw)--f1/2---11.11.11.2(h2)

Both ports f1/1,f1/2 are operating as layer 3 ports:

Now If i configure an access list on layer3 sw as :

access-list 101 deny ip any host 11.11.11.2

CEF and access-list 101 under physical int f1/1

int f1/1

ip access-group 101 in

Let assume  an entry for 11.11.11.2 exists in FIB with a valid adjacency.

Suppose h1 sends a ping packet at 11.11.11.2

Following will occur:

h1 encapsulates the ping packet in ethernet frame with src mac---mac1 of h1, dst mac---mac address of default gateway.

layer 3 switch receives the frame. Next switch removes ethernet frame and recovers the ip packet. Sw next check if the there is access-list configured under f1/1; sw finds the access-list 101 and drops the packet .

In this example, FIb table and adjacency table were not even looked up.

Is my understanding correct?

=========================================================

h1--10.10.10.10-vlan1-f1/1-( layer 3sw)-f1/2-Vlan2--11.11.11.2-(h2)

Here f1/1 and f1/2 are operating as access ports

layer 3 sw:

int vlan1

10.10.10.1/24 ( it is the defaultgateway for vlan1, mac1)

int vlan 2

11.11.11.1/24( default gateway for vlan2,mac1)

CEF is configured.

Let assume an valid entry exist for 11.11.11.2 in FIB table with a valid adjacency .

Next we configure the access-list under " int vlan 1" as:

access-list 101 deny ip any host 11.11.11.2

int vlan1

ip access-group 101 in

Let suppose h1 sends a ping packet to h2

Following will occur ( I might be wrong)

sw receives a frame on its f1/1 port with dst mac-mac1 ( which is mac associated with int vlan1)

sw next consults FIB table and adjacency table ;sw finds a match;sw rewrites ethernet header with src mac--mac1, dstmac-mac2 . Next sw consults the mac-table for dest mac-mac2 and finds the egress port as f1/2.

In above set up, any packet is  from h1 to 11.11.11.2 is supposed to be dropped. 

The question is  once we have valid entry in FIB table with valid adjacency for a prefix and later we configure an access -list to drop any packet destined for that prefix. How does it influence the FIB table?  Will the fib entry be modified because of access-list? If not, then sw ends up forwarding traffic from h1 to h2 erroneously.

I appreciate your help.

thanks and have a great weekend.

[Ryan Wolfe · Accepted solution]

The FIB considers ACL conditions before forwarding traffic. It stores ACL information as well.

In the scenario you have setup above, you can setup some Debugging and use show commands for CEF and ACLs to verify hat packets are being forwarded using CEF but the ACLs are still getting matches even though the routing isn't taking place in hardware.

I've done a lab to experiment with the same questions you're having when I was preparing for my CCNP. I did a quick search to find a good CEF/FIB explanation or document but I couldn't find anything. I'm sure there are some out there if you dig. But, for the sake of your question, CEF considers ACL information before forwarding.

Sent from Cisco Technical Support iPad App

[Peter Paluch · Accepted solution]

Hi Sarah and Ryan,

I agree with Ryan in that ACL lookup is performed before FIB lookup. A packet must first be deemed eligible for processing, only then it can be subject to routing.

However, the FIB does not hold any ACLs to my best knowledge. The FIB should be seen as an optimized form of the routing table with particular focus on fast lookup operations, with no recursive routing entries (if the routing table contains recursions, they are resolved during the compilation of the routing table into FIB), and with next hop information readily available.

The CEF is a mechanism that consists of two structures: the FIB and the adjacency table. The FIB contains an optimized copy of the router's routing table but it does not contain any next hop information directly. Instead, each entry in the FIB points to the precompiled next hop rewrite and egress interface information in the adjacency table. If you are somewhat familiar with database systems and indexes over tables or columns, the FIB can be seen as an index over entries in the adjacency table. What you really look up in the CEF is the adjacency information, and you perform that lookup using the index - the FIB table.

On multilayer switches, the FIB is stored in the TCAM memory, or better said, the TCAM is used as the FIB (as an indexing function). Also, the TCAM can hold ACL entries. That may suggest - incorrectly - that the FIB also contains ACLs. That would be a wrong assumption, however - FIB and ACLs are two distinct and unrelated structures. They may both be stored in a TCAM but even then, they are independent.

Best regards,

Peter

[Ryan Wolfe]

Peter,

Thanks for clearing me up. I was a little unsure in saying the FIB held ACLs, but, as you said, beig stored in the TCAM with the FIB is what got me mixed up.

Sent from Cisco Technical Support iPhone App

[Peter Paluch]

Ryan,

You are welcome!

Best regards,

Peter

[John Peterson]

Hi Peter,

Are  ACLs also stored in TCAM for a Cisco router?

We have a router with few ACLs on the outside interfaces and we sometimes experience high CPU as the packets are denied by the ACL?

Kr.

John.

[Peter Paluch]

John,

If the router is equipped with a TCAM then ACLs would normally be stored in the TCAM as well. This is certainly done on all Catalyst switches, for example.

However, ISR and ISR G2 routers do not use a TCAM - they are purely software-based routers. If you happen to run one of these then all your traffic is handled in software and thus on CPU. That could very well explain your high CPU loads although we would need to do more debugging to pinpoint the exact cause.

Best regards,
Peter