Migrate Access Control List into ACI?

[SIMMN]

Hey, Hope someone better than me could offer some suggestions or ideas regards.

I have a traditional Access Control List like below attached to a VLAN SVI, say VLAN 100. There are about 20 workloads on VLAN 100.

ip access-list ACL-for-vlan100
  10 permit ip 10.18.15.150/32 172.16.2.20/32 
  11 permit ip 10.18.15.150/32 172.17.1.5/32 
  20 deny ip 10.18.15.150/32 any 
  50 permit ip any any

As the VLAN100 SVI to be migrated into ACI, I am struggling to find a proper way to maintain the filtering provided by the ACL inside ACI...

Contract itself wont do as it does not define the source/destination...I could potentially try to put workload of IP 10.18.15.150/32 into its own EPG via VMM (VMM is not implemented yet) but the same would have to be done for the destination...This method may work but certainly not scalable.

Thought about ESG as well, but again, going to be complicated to manage and wont be scalable...

Ideas and suggestions please!

[weylin.piegorsch]

I'm having the same concerns.  Contracts are intended consume at point {a} and provide at point {b}, and inherit the IPs at points {a} and {b}.  For things that are sub-components of subnets at {a} or {b}, so far I've only found ESGs (for EPGs under an AP), and differentiated ExternalEPGs (this is the one time, I think, that a contract can be used on an ESG on one end and an EPG on the other).

I agree, there's something fundamentally insane about the policy aproach.  (1) You're taking a diverse policy applied at the point it's needed, and centralizing it into a single global policy. (2) You need to use the GUI to build the individual policies but only the CLI can to figure what the whole thing looks like - ie, management through different modalities. (API can do both, and in theory you could configure through the CLI, but I suspect that's not how most people use the tool.)  (3) You then need to take into account that the constructed policy differs across the fabric, depending on which switch you're looking at.  All of these are among the classic examples of really bad design.  But near as I can tell it's the only way.

[Remi-Astruc]

Hi @SIMMN ,

Yes. The source, the destinations, and the remaining Vl100 workloads need to be each in their own EPG to implement what you describe. That also assumes you set the Vlan IDs different or handle specific design to allow Vlan ID re-use.

It is true that this brown field use case can seem overkilling, but then you can also leverage more control within your subnet, and optionally use Service Graph PBR towards a Firewall to ease the security rules management.

Regards