ACLs

[DanPartelly]

I need ACLs. I'm willing to implement them, at least the most useful parts. ( permit/deny, source/dest match, network masks, protocol matching, logging. TCP/UDP ports can come later)

1. Where should it go?

• Having it in core, implementation would benefit from code from the general routing module and could reuse prefixes, making it easy for route maps and other constructs to refer to an ACL in the future if the need arises. The increasing complexity of templates could be mitigated by factoring some parts into separate files and using includes + macros.

• At the same time, ACLs are quirky enough to mandate being a plugin.

2. What features do you guys need from an ACLs module/plugin ?
3. Throw input, please.

[ipspace]

I need ACLs.

I was waiting for this to happen ;)

I'm willing to implement them, at least the most useful parts

Thank you!

1. Where should it go?

The routing module. It has all the infrastructure we need (for example, item sequencing, merging global to node objects, all sorts of callbacks that can do object expansion...). Maybe we should start with the data model, and then I can add the scaffolding to the routing module (that one is "somewhat" complex).

2. What features do you guys need from an ACLs module/plugin ?

I'd go for the usual: source, destination (both as prefixes, or would you like to have weird masks?), protocol(s) (list), port(s) (list). Then you can apply the ACL to an interface (input/output).

Next step(s):

• Allow more ways to specify source/destination parameters
• Use ACLs in route maps (which brings us pretty close to PBR)

[ssasso]

Next step(s):

• Allow more ways to specify source/destination parameters
• Use ACLs in route maps (which brings us pretty close to PBR)

additional next step: allow to refer ACLs in the firewall.zonebased plugin, to create stateful firewall rules ;)

[DanPartelly]

Ok, that's a plan then.

I was waiting for this to happen ;)

Well, it's a small gap for using netlab not as "lab" but as "serious firepower out there". We have most of what it needs. In the last few months, I barely wrote configs for anything. Netlab generated them, and I verified and deployed. I wrote manual stuff mostly for ACL's, NAT, ISPEC, and custom addressing. NAT and IPsec had custom templates for Cisco, which rendered most of the useful stuff. Minimal manual intervention required. But ACLs ... a pain in the ass. All were written manually.

I use ACLs mainly for inter-VLAN routing detail policy and CP firewalling. (Coarse policy might be in VRFs, but that's not the point here) .

Next step(s):

* Allow more ways to specify source/destination parameters

All for it. And one killer feature would be automatically supernetting. Once we figure out the most useful ways to specify prefixes, add an option to supernet them. This is the way I use ACLs most often. Reject/ Allow whole networks in a single ACL line. This is a feature I would like to have.

* Use ACLs in route maps (which brings us pretty close to PBR)

It does.

[Muddyblack]

I use ACLs mainly for inter-VLAN

This. Never used acl in clab/netlab tests but this would open new opportunities especially with vlan acl setups.

[DanPartelly]

Not long now :P

[sdktr]

Not sure whether it's to heavy for what you're looking for in netlab ACL feature, but maybe this can help. If not for the code, then at least the vendor agnostic data model and platform adapters could help.
https://github.com/aerleon/aerleon

[DanPartelly]

Thanks a lot for pointing out this tool, sdktr ! Look cool, Ill check it out.