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

2 Answers 2


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.
  • It came out of the "Brocade MLX Series and NetIron Family Configuration Guide R5_3_0a". ACL chapter under subsection "Applying ACLs to interfaces" Commented May 30, 2013 at 19:37
  • See the amendment above - appears as though this is expected (and documented) behavior. When an ACL is modified while applied to an interface, the old ACL remains in CAM until it's rebound. Commented May 30, 2013 at 21:55
  • Note that IronWare 5.4.0b (MLX/MLXe/XMR/CER/CES) changed ACL configuration behaviour somewhat: you can no longer remove an ACL that is bound to an interface unless you configure force-delete-outbound-acl under acl-policy. This is documented in the Update Guide.
    – Niels
    Commented Jul 11, 2013 at 16:24

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.