Brocade MLX reapplying modified ACL

Question

Why do Brocade MLX ACL changes require the extra configuration step as described below? Compared to Cisco ACLs this seems inconvenient.

If you make an ACL configuration change, you must reapply the ACLs to their interfaces to place the change into effect.

An ACL configuration change includes any of the following:

• Adding,changing, or removing an ACL or an entry in an ACL

• Changing ToS-based QoS mappings

To reapply ACLs following an ACL configuration change, enter the following command at the global CONFIG level of the CLI.

Brocade(config)# ip rebind-acl all

Answer 1

It likely has to do with how the TCAM is programmed (see edit below - Brocade refers to it as CAM). I'd definitely be interested to hear why adding a completely separate ACL (vs just an entry in an ACL) would require you to "reapply the ACLs". Do you have a source for that quote? If you don't have an SE assigned to your account, I do have contacts that I can ask and get clarification on this.

While not Brocade, I have had experience with vendor hardware where modifying an ACL "in place" would cause certain rules "further up" in the ACL to be completely ignored/stop functioning. Until the bug was actually fixed, the only workaround was to delete the ACL itself, and then recreate it with all of the rules before applying it to any interface.

Edit: Turns out my original thought was correct - from NetIron documentation:

How the Brocade device processes ACLs

The Brocade device processes traffic that ACLs filter in hardware. The Brocade device creates an entry for each ACL in the Content Addressable Memory (CAM) at startup or when the ACL is created. The Brocade device uses these CAM entries to permit or deny packets in the hardware, without sending the packets to the CPU for processing.

And then further down on the next page:

• If you change the content of an ACL (add, change, or delete entries), you must remove and then reapply the ACL to all the ports that use it. Otherwise, the older version of the ACL remains in the CAM and continues to be used. You can easily re-apply ACLs using the

  ip rebind-acl num | name | all

  command. Refer to “Applying ACLs to interfaces” on page 1018.

Answer 2

I don't have a lot of experience with Brocade, but I do know on the FC side that it's not uncommon (i.e. Cisco Nexus, MDS) for Fibre Channel switches to require a re-activation of the active zoneset when zoning changes are made. A show run will show a new zone, for instance, but show zoneset active will not until the zoneset being referenced is actually activated. It's one of the only cases I'm aware of (at least on Cisco gear) where the show run output isn't actually live and running on the system yet.

Though I wouldn't know of any technical reason for one or the other (pertaining to TCAM or switch logic) I do know that this provides for a little better handle on the changes that are being made. It is an extra step but it allows you to make the changes, show the changes, but not apply them until you've reviewed and verified that they're good.

Zoning from the SAN world being a rough analogy to ACLs in the IP world.