Routing Constraints
Routing Zone Constraints enable you to define policies at the management layer, on what virtual routing function (VRF) services or combination of services are authorized to exist on any port. The constraint policy can be defined in various ways, such as a list of allowed VRFs, a list of VRFs to exclude, a maximum number of VRFs permitted, and so on.
For example, you may have security or data protection demands that state services from Customer_A are never allowed to exist on the same port with services of Customer_B. In other words, a VLAN belonging to Customer_A VRF and VLAN in Customer_B VRF should never be allowed to exist on any port simultaneously. Alternatively, you could have a business requirement that states a port can belong to a maximum of 1 VRF, or a port can carry all VRFs except Payment.
In each of these use cases, the requirement is to enforce a business or security requirement that prevents a network operator from performing completely valid networking actions. Nothing is preventing you from provisioning an interface as a trunk port and adding two VLANs to it. What the Routing Zone Constraints policy allows you to do is capture these requirements in code and enforce them at run time for everyone rather than hoping all the operators follow the policy.
Only Trusted Use Case
In this example, the business must conform to a General Data Protection Regulation (GDPR) directive that obliges endpoints with data from trusted networks and domains to never contain data from untrusted networks. In networking terminology, this translates to clustering Routing Zones (network VRFs) and all of the Virtual Networks and endpoints in those Routing Zones together. Then, continuously audit and validate that the Day-2 changes your administrators perform adhere to this lawful regulation. The Routing Constraints feature does precisely this. It automatically cross-references each VN you assign to an interface to its assigned RZ, verifies if the RZ is part of the Trusted or Untrusted Group, and then ensures that you don’t mistakenly provision an interface to host any Trusted and Untrustworthy networks at the same time.
Routing Zone Group
The first step is to create the Routing Zone Group with `red` and `blue` members. You can create multiple groups, for instance, a `Contractors` group for any VN’s part of the Orange Routing Zone. Trusted networks are any VN’s part of the `red` or `blue` Routing Zones.
Routing Zone Constraints
Next, you need to define your routing zone policy constraints. You can write constraints in several ways. Some examples of how you could constrain VRFs include:
- One VRF maximum
- Any VRF except Management
- Only VRFs Blue and Red
- Only VRF Group Orange
The `ONLY TRUSTED` Routing Zone Constraint below creates a policy that allows only networks that are part of the Trusted Group to be provisioned on any interface.
Routing Zone Constraint Connectivity Policy
Once the constraint is defined, you enforce the constraint on server-facing interfaces by utilizing connectivity templates. These connectivity templates present the means by which to assign the policy specifically to an individual interface or with the flexibility to allocate the policy to many interfaces in bulk or reliant on explicit tags. The connectivity templates act as a mold, allowing you to shape the policy precisely to the interface or group of interfaces requiring targeted enforcement. This ensures that you proactively enforce the policy accurately and effectively for each and every operation in real time.
Here is a new connectivity template using the Routing Zone Constraint primitive. The `ONLY TRUSTED` Routing Zone Constraint from above is called.
Apply Constraints to Endpoints
Once the connectivity template is created, you assign the policy specifically to the interfaces on which you want this policy enforcement.
Operation and Validation
Once the policy is applied, every time a network admin performs a task that alters the VN configuration of an interface, Apstra will figure out which routing zones those virtual networks belong to and consult with the routing zone constraint policy to determine if the newly intended state complies with or violates the given constraint policy.
Here you can see the validation warning alerting you of a violation. The `Badge Net` VN belongs to RZ Orange, which is not a Trusted RZ Constraint Group member. This operation violates the TRUST ONLY policy because Leaf1, interface xe-0/0/2, already has a VN that belongs to the `red` or `blue` Routing Zones that are members of the Trusted network.
Summary
This document provides you with an overview of Juniper Apstra’s Policy Assurance feature. Policy Assurance is vendor-agnostic and, in conjunction with Apstra’s Intent-Based Networking approach, can significantly enhance your organization’s security posture. The post walks you through concepts and use case examples. To see an interactive demo, check out the link below in the Related Information section.