Beginning with Cisco NX-OS Release 10.5(1)F, users can redirect traffic flows between endpoints part of different Security-Groups. The redirection can happen through a single service function (as a firewall or a load-balancer) or through a chain of service functions. A given service function is built with one or more endpoints, representing the service devices performing such function. Traffic flows can be load-balanced across these service endpoints, while ensuring that both directions of traffic flow symmetrically use the same service endpoint. The onboarding of these service-devices, health monitoring mechanisms, and the user intent of chaining and load-balancing the traffic based on the properties of these service devices is captured and enforced through ePBR. To know more about micro-segmentation configuration, See Micro-segmentation for VXLAN Fabrics Using Group Policy Option (GPO).

Beginning with Cisco NX-OS 10.5(1)F, ePBR with micro-segmentation supports load-balancing traffic between service endpoints that are part of the same service function. Load-balance method may be configured for a service-chain if the same load-balance mechanism is desired for every service function in the chain. If one or more service functions or sequences inside the chain require a different load-balancing mechanism, this may be configured for the specific sequence inside the chain. Traffic may be load-balanced using source IP parameters, destination-IP parameters or source IP, destination IP along with the protocol indications available in the IP headers. ePBR with micro-segmentation ensures traffic is symmetrically load-balanced to the same service device in both directions.

Beginning with Cisco NX-OS 10.5(1)F, ePBR with micro-segmentation supports redirection of traffic to service devices that modify the destination and/or source IP addresses of the traffic. These devices may be external load-balancers, NATTing firewalls and CGNAT devices.  

Service devices may perform only destination NAT (load-balancers with SNAT disabled), only source NAT (CGNAT devices for return traffic) or both (load-balancers with SNAT enabled).  

Traffic to devices such as external load-balancers performing destination NAT in the forward direction do not need policy-based redirection but need to be permitted.  

Similarly, traffic in the reverse direction returning to devices such as external load-balancers or CGNAT devices, that have performed Source NAT in the forward direction, do not need policy-based redirection, but need to be permitted.  

Traffic to devices such as external load-balancers that do not have source NAT enabled, require policy-based redirection for traffic in the reverse direction. 

As described above, traffic to these services needs to be handled in different ways based on their NAT capabilities. Additionally, due to the modification of the IP addresses of the traffic by these appliances, the destination and/or source security-group tags may be different before and after redirection to these services.  Handling these variances may ordinarily require complex asymmetric, uni-directional contracts. 

ePBR simplifies the contract creation for the user by allowing the user to indicate that the service in the ePBR service-chain at a particular sequence, has destination and/or source NAT capabilities. This is done by configuring an action for the service inside the chain, for the forward and reverse directions of traffic.

• Services that perform destination NAT on the traffic only are configured with action of route for the forward direction.

• Services that perform both destination and source NAT on the traffic, are configured with action of route for both directions of traffic.

• Services that perform only source NAT on the traffic are configured with action of route only for the reverse direction of traffic.

The user may then configure an end-to-end bi-directional contract for the traffic, regardless of any changes in security-tags in the traffic path and the varying behavior based on the direction.

When no action is configured for any direction, the service sequences inside the chain are treated as requiring redirection in both directions. Fail-action and threshold features will not be supported for sequences in the service-chain that have action of route configured for either the forward or reverse directions.

ePBR with micro-segmentation has the following guidelines and limitations: 

• In NXOS 10.5(1)F SGACL based service redirection is only supported to a single service function in the chain. The service function may contain one or more layer-3 one-arm or dual-arm service endpoints only.

• For external load balancer, SGACL based service redirection only supports only one service endpoint in a service function and doesn't support load balance.

• Service functions with a mix of one-arm and dual-arm service endpoints are not supported.

• The sum total of weights across all active endpoints in the ePBR service cannot exceed 128.

• For the external load-balancer to monitor the health of the server cluster, contracts with permit action must be explicitly created between the layer4-7 security-tags of the load-balancer service and the servers.

• Service with one-arm devices must not be configured with a reverse security-group identifier.

• Services with dual-arm devices must be configured with a reverse security-group identifier that is different from the forward security-group. 

• Services with dual-arm devices should use different service VLANs for the forward and reverse arms of the endpoints.

• The forward arms of one or more endpoints in the service may share the service VLAN. The reverse arms of one or more endpoints in the service may share the service VLAN.

• Users must ensure that service VLANs are used exclusively for the service devices and are not used for any other host traffic. This is required to avoid incorrect classification of such traffic.

• Security-groups configured inside ePBR services must also be defined as layer4-7 security-group selectors on the leaf switches which have the endpoint connected interfaces configured.

• In NXOS 10.5(1)F endpoint connected interfaces used in services must be interface VLANs only. 

• While security-groups and service VLANs may be shared between ePBR services, users must ensure that the contracts that use these services in chains do not have conflicting match filters or actions.

• In NXOS 10.5(1)F, the service that the traffic is redirected to, must be configured in the same VRF context as the contract. 

• Match class-maps for IPv4 traffic must be configured with service-chains containing IPv4 services and match class-maps for IPv6 traffic must be configured with service-chains containing IPv6 traffic.

• Unique layer-4 source and destination port parameters should be specified for the match class-map filters, if traffic is required to match any-any source and destination security-groups in the contract and the service in the chain is a dual-arm service. 

• Users must ensure that multiple contracts using the same source and destination security-groups are not configured with policies and match class-maps having different service redirection results for the same traffic flows.

• When fail-action is configured for a sequence inside a service-chain , it is recommended that probing is consistently enabled for the service via service-level or endpoint-level probes.

• It is recommended that probe traffic is classified in a separate CoPP class. Otherwise, probe traffic may use the default CoPP class and might be dropped causing continuous IP SLA state changes during spikes in supervisor traffic. For information on CoPP configuration for IP SLA, see Configuring CoPP for IP SLA Packets.

• ePBR administrative and operational out-of-service features are not supported for services used in service redirection with micro-segmentation. For more information, see Configuring ePBR L3.

• Endpoint states of the forward and reverse arms of dual-arm devices are not synchronized automatically. If this is needed, identical probe track configuration on the forward and reverse arms should be used.

• Probe tracks configured for endpoints may be shared between the forward and reverse arms of the same endpoints, but not across endpoints in the same or different services.

• Probe tracks must be used for any automatic synchronization of endpoint states across the forward and reverse arms of dual-arm devices.

See figure 5 for the configuration example showing SGACL service-chaining configuration.

1. Create layer4-7 selectors for the service.

   security-group 2010 name fw_out 			 
     type layer4-7							   
     match interface vlan 24 
     match interface vlan 16  
   security-group 2011 name fw_in  
     type layer4-7 
     match interface vlan 25 
     match interface vlan 17 

2. Creating ePBR service and endpoints.

   epbr service fw 
     vrf tenant 
     security-group 2010 reverse 2011 
     probe tcp 80 frequency 5 timeout 3 source-interface 
      loopback10 reverse loopback11 
     service-end-point ip 24.1.1.2 
       reverse ip 25.1.1.2 
     service-end-point ip 16.1.1.2 
       reverse ip 17.1.1.2 

3. Create security-group selectors for host traffic.

   security-group 5051 name sec_5051 
     match connected-endpoints vrf tenant ipv4 151.1.1.0/24  
   
   security-group 5050 name sec_5050 
     match connected-endpoints vrf tenant ipv4 150.1.1.0/24   

4. Create security class-maps to define the layer3, layer-4 match criteria.

   class-map type security match-any class_ipv4_tcp 
     match ipv4 tcp dport 80 
     match ipv4 tcp dport 443 

5. Configure the ePBR service-chain. Configuration of class-maps, policy-maps and contracts under vrf need to be consistent on all leafs.

   epbr service-chain web 
     load-balance method src-dst-ipprotocol 
     10 set service fw fail-action drop

6. Configure the security policy-map and attach the service-chain to the required match class-map.

   policy-map type security web_policy 
     class type security class_ipv4_tcp 
       service-chain web 

7. Configure the contract.

   vrf context tenant 
     security contract source 5050 destination 5051 policy web_policy 

   For more details on moving the VRF context to enforced mode, see Configuring Security contracts between Security Groups.