TCAM ACL table lookups

aueddonline

I'm missing a piece of the puzzle here, looking at the pg 72 BCMSN cert guide fig 3 -5, it shows an illustration of the TCAM table,

How can an access list be read properly from top to bottom (as that's the way they're written) if there is nothing in the table referencing a specific ACL or sequence number?

accely

I went back and looked at this figure.

It's to my understanding that the ACL's just get, as it's stated, merged into the TCAM. So you won't really see references to specific ACL numbers or names. The TCAM is just a different way of holding the rules for packets to be checked against.

aueddonline

accely wrote: »

I went back and looked at this figure.

It's to my understanding that the ACL's just get, as it's stated, merged into the TCAM. So you won't really see references to specific ACL numbers or names. The TCAM is just a different way of holding the rules for packets to be checked against.

thanks for taking the time to look,

how can it check a packet againt an ACL stored in the TCAM if it doesn't know what order to read the ACL in.

for instance you could have an ACL

10 permit ip host 192.168.20.10 192.168.30.0 0.0.0.255
20 deny ip 192.168.20.0 0.0.0.255 192.168.30.0 0.0.0.255

depending which line you read first host 192.168.20.10 gets either permit or deny

Forsaken_GA

Reread the entire section. The part your getting hung up on is the masking, and how a lookup is actually processed. You're still thinking sequential lookups, when in this case, the lookups are done in parallel and the longest (best) match is the result that is returned. Sequence numbers are meaningless.

In your example, the first line is always returned when sourced from the example IP, because there's a host entry... all 32 bits are masked. The second line will also match, but only on 24 bits, since it's masked out to where 8 bits are don't care. 32 bits is a longer match than 24 bits, so the 32 bit entry wins.