Information About ePBR L3
Enhanced Policy-based Redirect (ePBR) in Elastic Services Re-direction (ESR) provides traffic redirection and service chaining across the NX-OS and fabric topologies by leveraging policy-based redirect solution and achieves service chaining without adding extra headers, and avoids latency in using extra headers.
ePBR enables application-based routing and provides a flexible, device-agnostic policy-based redirect solution without impacting application performance. The ePBR service flow includes the following tasks:
Licensing Requirements
For a complete explanation of Cisco NX-OS licensing recommendations and how to obtain and apply licenses, see the Cisco NX-OS Licensing Guide and the Cisco NX-OS Licensing Options Guide.
Configuring ePBR Service and Policy
You must first create an ePBR service which defines the attributes of service end points. Service end points are the service appliances such as firewall, IPS, etc., that can be associated with switches. You can also define probes to monitor the health of the service end points and can define the forward and reverse interfaces where the traffic policies are applied. ePBR also supports load balancing along with service chaining. ePBR allows you to configure multiple service end points as a part of the service configuration.
Beginning with Cisco NX-OS Release 10.2(1)F, the VRF of every service in a chain may either be unique or may be exactly identical. The service endpoints and interfaces defined for a service, should pertain to the VRF defined for the service.
Service end-point interfaces having an existing IPv4 PBR policy cannot be used inside an IPv4 ePBR service. Similarly service end-point interfaces having an existing ipv6 PBR policy cannot be used inside an IPv6 ePBR service.
After creating the ePBR service, you must create an ePBR policy. The ePBR policy allows you to define traffic selection, redirection of traffic to the service end point and various fail-action mechanisms on the end point health failure. You may use IP access-list end points with permit access control entries (ACE) to define the traffic of interest to match and take the appropriate action.
The ePBR policy supports multiple ACL match definitions. A match can have multiple services in a chain which can be sequenced by a sequence number. This allows flexibility to add, insert, and modify elements in a chain in a single service policy. In every service sequence, you can define the fail action method such as drop, forward, and bypass. The ePBR policy allows you to specify source or destination-based load balancing and bucket counts in order to have granular load balancing of traffic.
Applying ePBR to an Interface
After creating the ePBR policy you need to apply the policy on an interface. This allows you to define the interface at which the traffic ingresses into the NX-OS or Nexus fabric. You can also apply the policy in both the forward and reverse directions. There may only be two IPv4/IPv6 policies applied to the interface, one in the forward and one in the reverse direction.
Beginning with Cisco NX-OS Release 10.2(1)F, ePBR supports policy application on layer-3 port-channel sub-interfaces
Beginning with Cisco NX-OS Release 10.2(1)F, the interface on which the ePBR policy is applied may be on a different VRF than the VRF of the services in the chain.
ePBR IPv4 policies cannot be applied to an interface on which an IPv4 PBR policy is already applied. ePBR IPv6 policies cannot be applied to an interface on which an IPv6 PBR policy is already applied.
Creating Bucket and Load Balancing
ePBR computes the number of traffic buckets based on the service that has maximum number of service-end-points in the chain. If you configure the load balance buckets, your configuration will have the precedence. ePBR supports load balancing methods of source IP and destination IP but does not support L4-based source or destination load balancing methods.
ePBR Service Endpoint Out-of-Service
The ePBR service endpoint Out-of-Service feature provides the option to temporarily remove the endpoint from service. The following two methods can be used to move an endpoint Out-of-Service:
-
Administrative Out-of-Service: This method is used during maintenance or upgrades to temporarily move the service-endpoints to operationally down state and avoid sending traffic to the node, while still retaining the service-endpoints as a valid endpoint device in service.
The user would also require the ability to bring the service endpoint back in service on the Cisco NX-OS switch after the maintenance procedure has been completed. This is a standard feature provided used by load-balancers in the industry today.
-
Auto Out-of-Service: This method is used during recovery of endpoints after failures, ePBR detects the reachability of the endpoints getting re-established and attempts to redirect subsets of flows back to the node.
Also, when certain networks may be tolerant to a rare endpoint failure and recovery but may require detecting endpoints that are losing and re-establishing connectivity constantly, each event disrupting end-to-end connections twice. It may be desirable to put such nodes Out-of-Service.
ePBR Object Tracking, Health Monitoring, and Fail-Action
ePBR creates SLA and Track objects based on the probe types configured in the service and supports various probes and timers such as ICMP, TCP, UDP, DNS, and HTTP. ePBR also supports user defined tracks, which allows you to create tracks with various parameters including milli second probes in associating with ePBR.
ePBR monitors the health of the end points by provisioning IP SLA probes and object tracks to track the IP SLA reachability when you apply the ePBR probe configuration.
You can configure the ePBR probe options for a service or for each of the forward or reverse end points. You can also configure frequency, timeout, retry up and down counts, and source loopback interface so that they can be used for source IP of an IP SLA session. The retry-up and down counts are used as multipliers for the frequency to determine delay-up and delay-down intervals. Once the service endpoint is initially detected as failed or recovered, the system will act on these events after the expiry of these intervals. You can define any type of tracks and associate them with the forward or the reverse end points. The same track objects is re-used for all policies using the same ePBR service.
You can define tracks separately and assign the track ID to each service-end point in ePBR. If you do not assign any user-defined track to an endpoint, ePBR will create a track using probe method for the end point. If no probe method is defined at the end point level, the probe method configured for the service level will be used.
ePBR supports the following fail-action mechanisms for its service chain sequences:
-
Bypass
-
Drop on Fail
-
Forward
Bypass of a service sequence indicates that the traffic must be redirected to the next service sequence when there is a failure of the current sequence.
Drop on fail of a service sequence indicates that the traffic must be dropped when all the service-end-points of the service become unreachable.
Forward is the default option and indicates that upon failure of the current service, traffic should use the regular routing tables. This is the default fail-action mechanism.
Note |
Symmetry is maintained when fail-action bypass is configured for all the services in the service chain. In other fail-action scenarios, when there are one or more failed services, symmetry is not maintained in the forward and the reverse flow. |
ePBR Session-based Configuration
ePBR sessions allow addition, deletion or modification of the following aspects of in-service services or policies. The in-service refers to a service that is associated with a policy that has been applied to an active interface or a policy that is being modified and currently configured on an active interface.
-
Service endpoints with their interfaces and probes
-
Reverse endpoints and probes
-
Matches under policies
-
Load-balance methods for matches
-
Match sequences and fail-action
Note |
In ePBR Sessions, you cannot move interfaces from one service to another service in the same session. To move interfaces from one service to another service, perform the following steps:
|
ePBR Multi-Site
Beginning with Cisco NX-OS Release 10.2(1)F, service-chaining in a VXLAN multisite fabric can be achieved by using the following configuration and topology guidelines.
-
Endpoints in a service or services in the chain may be distributed across different leaf switches, in the same or different site.
-
Every service should be in its unique VRF, which is different from the tenant VRF context in which the ePBR policy is applied.
-
To segregate traffic for different tenant VRFs, the VLANs used for the services would be required to be segregated and new services and policies would need to be defined.
-
Tenant VRF routes should be leaked to each of the service VRFs on every leaf switch hosting the services, to allow traffic to be routed back at the end of the service chain to its destination, in the tenant VRF.
-
VNIs should be symmetrically allocated across different leaf switches and sites.
-
The ePBR policy should be enabled on all layer-3 VNIs of the service VRFs being used, on all leaf switches hosting services and on the border leaf or border gateway switches, if it is acting as transit for multi-site.
-
The service chain may be isolated to one site entirely, with traffic arriving from different sites. Although this scenario doesn't involve multi-site distribution of service devices, the layer-3 VNIs of the service VRFs on the border gateways or border leafs should only be treated as multi-site transit and the ePBR policy should be applied on them. The ePBR policy should be also applied on the host or tenant facing interfaces in the remote sites where the traffic is arriving from.
ACL Refresh
ePBR session ACL refresh allows you to update the policy generated ACLs, when the user-provided ACL gets modified or added or deleted with ACEs. On the refresh trigger, ePBR will identify the policies that are impacted by this change and create or delete or modify the buckets’ generated ACLs for those policies.
For ePBR scale values, see Cisco Nexus 9000 Series NX-OS Verified Scalability Guide.