Implement FWaaS for ASR1k #106
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
swagner-de
force-pushed
the
fwaas-support
branch
from
25f23fb
to
1ce67c7
Compare
sebageek
reviewed
Feb 1, 2024
asr1k_neutron_l3/plugins/l3/service_plugins/l3_extension_adapter.py
Outdated
Show resolved
Hide resolved
asr1k_neutron_l3/plugins/l3/service_plugins/l3_extension_adapter.py
Outdated
Show resolved
Hide resolved
asr1k_neutron_l3/neutron/services/service_drivers/asr1k/fwaas_driver.py
Outdated
Show resolved
Hide resolved
swagner-de
force-pushed
the
fwaas-support
branch
2 times, most recently
from
2fc57a0
to
88a8339
Compare
sebageek
reviewed
Mar 7, 2024
swagner-de
force-pushed
the
fwaas-support
branch
from
88a8339
to
9f31e74
Compare
sebageek
reviewed
Mar 19, 2024
swagner-de
force-pushed
the
fwaas-support
branch
4 times, most recently
from
7a9ad12
to
13c2fa9
Compare
sebageek
reviewed
May 16, 2024
asr1k_neutron_l3/neutron/services/service_drivers/asr1k/fwaas_driver.py
Outdated
Show resolved
Hide resolved
swagner-de
force-pushed
the
fwaas-support
branch
2 times, most recently
from
73db3e7
to
c088626
Compare
sebageek
reviewed
Jul 3, 2024
asr1k_neutron_l3/plugins/l3/service_plugins/l3_extension_adapter.py
Outdated
Show resolved
Hide resolved
asr1k_neutron_l3/plugins/l3/service_plugins/l3_extension_adapter.py
Outdated
Show resolved
Hide resolved
If specified as a service_provider for FIREWALL_V2 the ASR1KFWaaSDriver will receive all pre/postcommit hooks necessary to implement the OpenStack FWaasV2 service.
fwg policies are shared objects, they can be used by multiple routers. We map them 1:1 to ACL objects on IOS XE and thus need a method to keep them updated. We could do that by calling a router sync on any single router that has a reference to that policy or we just call it on an arbitrary router on every agent. This is what we implement in this commit.
In our FWaaS implementation we will most likely bind policies on external interfaces. In order to tell the customer the external interface we expand the API to convey this information.
In order for the ZBF feature to replicate the state table, interfaces need to be assigned to a redundandancy group and receive a Redundant Interface Identifier (RII) in order to find the same interface on the remote side. In case we find an external policy on the `Router`, we mark all interfaces on the router's interface list with `has_stateful_firewall`. If that is the case, we instantiate the yang model with RII, redundancy group membership and in case of the interface being the gateway interface with an zone membership. As this marking is done post `Interface` instantiation, we make the `_rest_definition` attribute a dynamic property, so later changes in the `Interface` object are represented in its `_rest_definition`.
swagner-de
force-pushed
the
fwaas-support
branch
from
c088626
to
8c4d1a8
Compare
As we cannot support hardware stateful firewalling, we mimic stateful behaviour by inserting a set of rules of the beginning of each ACL that help us letting through packets that are usually an answer to a sent out packet.
swagner-de
force-pushed
the
fwaas-support
branch
2 times, most recently
from
7a6528a
to
44fdc9f
Compare
All netconf_yang classes inherit their `is_orphan` from BulkOperations. Each of these subclasses need different lists to determine if the classes object is orphan or not. Let's simplify adding arguments to this method by using keyword arguments. All subclasses shall send unnecessary arguments to `*args, **kwargs` while only `BulkOperations.is_orphan` should know about the whole argument list.
Zones and ZonePairs are created per VRF that has an external policy attached. We can remove them straigh away once the external policy was removed on an VRF/external router interface.
FWaaS rules are mapped via policies and firewall groups to ports. Yet when we need to troubelshoot, we must compare it to a virtual router's configuration, so we'd need easy access to how the rules would look from a router interface perspective. This commit adds an API endpoint that delivers that view, removing some cluttering attributes from the result.
I noticed that the first iterations of all loopingcalls would always fail. Turns out, `_run_yang_cmd` checks the `alive` condition of the context, which is not set until `device_check_loop` has run the first time. To make matters worse, `device_check_loop` is also the last loopingcall to be triggered, so it's certain that the first iteration off all previous calls will fail. I moved the loopingcall to be the first one triggered and also halt until we see the agents marked alive. I believe that makes sense as no yang action can be run before this happens either way. As I don't want to inhibit agent startup alltogether, I still back out after `nc_timeout`.
swagner-de
force-pushed
the
fwaas-support
branch
from
44fdc9f
to
75252d7
Compare
Firewall policies can be bound to multiple ports. They are realized by ACLs, a ClassMap and a ServicePolicy (if the policy is bound to an external interface). That means, just because a router or a port is removed from a policy the corresponding objects may still be used from other routers. Hence it is not removed immediatly but by a cleanup loop, that checks if anybody on an agent is using that policy and then it will be removed.
swagner-de
force-pushed
the
fwaas-support
branch
from
75252d7
to
9980f5f
Compare
This prevents cyclic imports as the prefix is needed in the orphan check, but also needed when creating the object through one of the higher level l3 classes.
To remove clutter from the AccessList class we move all the code that generates the attributes for the corresponding yang class into `Rule`.
swagner-de
force-pushed
the
fwaas-support
branch
from
9980f5f
to
39fc6fb
Compare
In the previous implementation `firewall.AccessList` would inherit from `l3.AccessList` which inherited from `base.Base`. `firewall.AccessList` also inherited from `firewall.FirewallPolicyObject`. That lead to a Diamond Shaped inheritance. The fact that `FirewallPolicyObject` and `l3.AccessList` had constructors with different arguments made it difficult to let `super()` call the constructors with different arguments. To resolve that, the diamond Shaped inheritance was resolved making it clearer which `__init__`'s `super()` calls which superclasses constructor. The different signatures of the constructor still pose a problem, hence we send all supplemental arguments of a constructor to `**kwargs`.
swagner-de
force-pushed
the
fwaas-support
branch
from
39fc6fb
to
07dc92f
Compare
sebageek
approved these changes
Sep 13, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
is_orphanshould_be_noneall the way through