Network administrators can use micro-segmentation to logically group network resources based on specific criteria such as application attributes. You can use micro-segmentation with Security Groups (SGs) and Security Group ACLs (SGACLs) to create and enforce tailored application centric security policies between security groups regardless of network topology.

In traditional data center environments, the application or workload security is often implemented at the perimeter or the north-south boundary where users from outside the data center fabric enter. This is often implemented using perimeter firewalls and other security inspection devices. However, this approach is not effective against the advanced nature of the latest attacks. The attack surface spans the entire data center including the east-west and north-south flows.

Using micro-segmentation with security groups and security group ACLs, this feature can provide an effective security solution to the users of NX-OS platforms. Micro-segmentation provides more flexibility and lower complexity than traditional general purpose Access Control Lists (ACLs). With micro-segmentation, organizations can provide specific policies that dictate how the application workloads communicate regardless of where these applications reside within the network.

Group Policy Option (GPO) is a backward-compatible extension to VXLAN that adds a Security Group Tag (SGT) to the VXLAN header for security policy enforcement purposes.

In a GPO enabled VXLAN network, you can create Security Groups in the VXLAN EVPN fabrics to define segmentation. By defining smaller, isolated application segments, you can deploy micro-segmentation policies that allow for better control over the flow of network traffic among the application tiers and across applications. Micro-segmentation ensures that security policies are applied only where they are needed, improving application and workload security, thereby improving the security posture.

You can classify network resources to a Security Group tag based on multiple attributes. Traffic between Security Groups can be controlled by Security Group Access Control Lists (SGACLs) also known as Security Contracts, which match source and destination Security Groups using Security Group tags.

GPO has the following guidelines and limitations:

• All supported N9000 platforms require a minimum system memory of 24GB to support this feature.

• Beginning with Cisco NX-OS Release 10.4(3)F, GPO is supported on the following platforms:

  • 9300-FX3

  • 9300-GX

  • 9300-GX2

• Beginning with Cisco NX-OS Release 10.5(1)F, GPO is supported on Cisco Nexus 9408 switch.

• Beginning with Cisco NX-OS Release 10.5(1)F, GPO supports VLAN range match.

• Beginning with Cisco NX-OS Release 10.5(1)F, analytics support for GPO packets is added.

• Beginning with Cisco NX-OS Release 10.5(1)F, service-redirection with GPO is supported.

• Beginning with Cisco NX-OS Release 10.5(2)F, GPO is supported on the following platforms:

  • 9300-FX

  • 9300-FX2

  • 9300-HX

• SGACLs are supported only in the context of a VXLAN EVPN deployment. SGACL cannot be deployed on non-VXLAN enabled VRFs.

• SGACLs are not applicable to BUM and multicast traffic. System generated default permit policies exist for BUM and multicast traffic.

• You cannot configure VLAN-based Security Group selectors with a VLAN part of system reserved-vlan-range values.

• If VLAN-based Security Group selectors are already configured, system-reserved-vlan-range cannot be modified to include VLAN values used in the SG selectors.

• GPO is not supported on a site that has policy-aware and policy-unaware nodes. GPO is supported on policy-aware sites or a mix of policy-aware and policy-unaware sites.

• Unicast Reverse Path Forwarding (URPF) is not supported with routing profile template-security-groups (system routing template-security-groups ).

• For the adjacencies learned on Layer 3 connected interfaces, if the matching ESG selector (connected endpoints) is configured on the switch, the host routes are installed with admin distance of 205.

• Beginning with Cisco NX-OS Release 10.5(3)F, users can enforce SGACL on an EVPN-VXLAN fabric for traffic flows to and from external endpoints reachable through an SR-MPLS based Layer-3 VPN.

  • ACL Permit logging action for the SGACL Policy shall not work for MPLS terminated flows.

  • On the BGW or BL, the SGACL based service redirection is not supported for flows destined towards MPLS Core

  • This feature is only supported on Virtual MCT BL and is not supported on Physical MCT BGW/BL.

  • SR-MPLS L3VPN interworking is supported on BLs and Anycast BGWs.

  • When this feature is enabled on Cisco Nexus 9300 FX2 platform switches, MPLS-SR LSR functionality is not supported.

  • Non-disruptive ISSU for MPLS features is only supported with BGP labelled unicast in the MPLS core. This limitation will be applicable for this feature also.

  • Beginning with Cisco NX-OS Release 10.5(3)F, users can select a combination of external-subnet IP prefix and next-hop IP address to create groups and enforce SGACL policy. Users can also use next-hop IP address with encapsulation type option to specify the next-hop address used in the VPN address family. In this release, this feature is supported only on BGP and static routes.

    • The next-hop qualifier in the selector can be a recursive next-hop or a connected next-hop for the protocol or client.

    • If the user specifies IP along with next-hop selector match for only a subset of expected next-hops of a route but not all, then

      • The ESG lookup with IP and next-hop for the other next-hops may yield a less specific tag (say based on IP). That tag is installed for such next-hops.

      • Details on the SGT returned to the protocol learned prefixes are as follows:

        • Longest prefix match (LPM) first, then the next-hop match. If LPM matches, but the next-hop doesn’t match, then the protocol will look for the next better LPM (lower mask length).

        • If an IP selector does not have any next-hop specified, then it would be treated as a match against any next-hop. Following is an example.

          • For the below config:

            SGT:100 -> 10.1.1.0/24+NH:1.1.1.1 
            
            SGT:300 -> 10.1.1.0/24+NH:1.1.1.2 
            
            SGT:500 -> 10.1.0.0/16 

          • When the protocol learns 10.1.1.0/25 with NH:1.1.1.1, then the traffic against this prefix will get SGT 100.

          • When the protocol learns 10.1.1.0/20 with NH:1.1.1.1, then the traffic against this prefix will get SGT 500.

    • It would be a misconfiguration to have mismatch of SGTs among next-hop of a route when the paths may become ECMP.

      • In such a case, traffic could get dropped if the tag selected by RIB/FIB for installation if from a NH with tag 0, or not forwarded/processed correctly.

    • The next-hop is expected to be of the same address family as the route prefix.

      • For the VPN case, the next-hop could be of IPv4 address family, even if the route’s prefix is of IPv6 address family.

    • The VRF of next-hop in the IP with next-hop selector should be in the VRF configured for the IP.

    • For IPv6, next-hops can be link-local (since they will be unique across different neighbor devices).

    • Unlike IP selector, route-Injection for IP with next-hop selector is not supported from Cisco NX-OS Release 10.5(3)F.

      Note	Route-Injection for IP selector was introduced from 10.5(2)F

  • Beginning with Cisco NX-OS Release 10.5(3)F, users can select VLAN along with MAC address to create a security group. VLAN and VLAN along with MAC address selector both can coexist in the same security group.

  • Beginning with Cisco NX-OS Release 10.5(3)F, support for ISSU is added for all the SGACL features along with service redirection for multi-node and multisite fabrics.

Step 1: Enabling GPO.

Switch1# configure terminal
Switch1(config)# system routing template-security-groups
Switch1(config)#feature security-group
 
Switch2# configure terminal
Switch2(config)# system routing template-security-groups
Switch2(config)#feature security-group

Step 2: Creating a security class-map to identify specific traffic flows.

Switch1(config)#class-map type security match-any web-class
match ipv4 tcp dport 443
match ipv4 tcp dport 80	
 
Switch2(config)#class-map type security match-any web-class
match ipv4 tcp dport 443
match ipv4 tcp dport 80 

Step 3: Creating a security policy map

 
Switch1(config)#policy-map type security policyMap1
class web-class
permit           
Switch2(config)#policy-map type security policyMap1
class web-class
permit            

Step 4: Creating security group.

switch1(config)security-group 1000 name webserver1
switch1(config-security-group)# match connected-endpoints vrf vrf_blue ipv4 61.1.1.141/32
switch1(config-security-group)# match external-subnets vrf vrf_blue ipv4 10.0.0.0/8
switch1(config-security-group)# match connected-endpoints vrf vrf_blue ipv6 61:1:1:2:1::141/128
switch1(config-security-group)# match external-subnets vrf vrf_blue ipv6 10:11:12:13::/64
switch1(config-security-group)# match connected-endpoints vrf vrf_red ipv4 100.5.150.125/32 
switch1(config-security-group)# match connected-endpoints vrf vrf_red ipv6 100:1:1:495::125/128 
switch1(config-security-group)# match external-subnets vrf vrf_red ipv4 11.0.0.0/8
switch1(config-security-group)# match vlan 10
 
switch2(config)security-group 2000 name webserver2
switch2(config-security-group)# match connected-endpoints vrf vrf_blue ipv4 61.1.1.142/32
switch2(config-security-group)# match external-subnets vrf vrf_blue ipv4 20.0.0.0/8
switch2(config-security-group)# match connected-endpoints vrf vrf_blue ipv6 61:1:1:2:1::142/128
switch2(config-security-group)# match external-subnets vrf vrf_blue ipv6 20:11:12:14::/64
switch2(config-security-group)# match connected-endpoints vrf vrf_red ipv4 100.5.150.126/32 
switch2(config-security-group)# match connected-endpoints vrf vrf_red ipv6 100:1:1:495::126/128 
switch2(config-security-group)# match external-subnets vrf vrf_red ipv4 21.0.0.0/8
switch2(config-security-group)# match vlan 10

Step 5: Moving VRF to enforce mode

switch1(config)# vrf context vrf_blue
switch1(config-vrf)# security enforce tag 100 default deny
switch2(config)# vrf context vrf_red
switch2(config-vrf)# security enforce tag 101 default deny

Step 6: Apply contract

switch1(config-vrf-blue)# security contract source 1000 destination 2000 policy policyMap1   
switch1(config-vrf-red)# security contract source 1000 destination 2000 policy policyMap1  
          
switch2(config-vrf-blue)# security contract source 1000 destination 2000 policy policyMap1   
switch2(config-vrf-red)# security contract source 1000 destination 2000 policy policyMap1 

Beginning with Cisco NX-OS Release 10.4(3)F, SG and SGACLs are supported on VXLAN EVPN fabrics part of the same Multi-Site domain. Policy aware and policy-unaware fabrics can be deployed as part of the same Multi-Site domain.

Anycast Border Gateways (BGWs) and vPC BGWs are supported with SGACL feature. Border-Gateway nodes in a policy-aware site can establish Multi-Site EVPN connectivity with policy-aware sites as well as policy-unaware sites. SGACLs can be applied between SGs locally defined on separate fabrics. Additionally, it is possible to stretch a SG across multiple fabrics.

All the EVPN routes from policy-unaware sites are distributed into policy-aware sites and installed with a reserved security group tag value 15. To allow workload communication between policy unaware to policy aware sites, the user must create explicit contracts with tag 15 and the intended destination tag.

When a remote prefix is learned with multiple next-hops belonging to a mix of policy-unaware and policy-aware fabrics, the next-hop(s) of policy-aware fabrics are preferred. If multiple next-hops all belong to policy-unaware fabrics, then the received prefix route is installed and re-originated inside the policy-aware fabric with policy-unaware tag.

In the figure, BGW 1 and BGW 2 are part of policy aware sites and BGW 3 belongs to a policy unaware site. External network 10.1.1.0/24 is advertised from Site 3 and Site 2 to Site 1. Since Site-2 is policy-aware, Route 10.1.1.0/24 is advertised with “TagY”, which is configured on Site2. Site-3 is policy-unaware, so the route advertised from BGW3 would not carry any policy information and would be locally assigned to have the default Policy-unaware tag which is ‘15’ when received by BGW1.

On BGW1, the Route would have overlay ECMP of BGW2 and BGW3 with tags of TagY and, ‘15’ respectively. However, since TagY is a valid tag from the policy-aware site, 10.1.1.0/24 is programmed with Tag ‘TagY’. Similarly, when BGW1 re-originates the route to a leaf in Site-1, it adds the tag ‘TagY’ to the route.

In a typical Anycast BGW setup, there are no SVI configurations for L2VNIs. However, to support GPO for L2 Bridged IP traffic, you need to configure an SVI for the L2VNIs on the Anycast BGWs. The SVI configuration does not need an IP Address or the “ip forward” command. The only requirement is to be configured under the Tenant VRF. This is needed to derive the Tenant VRF information for Host-IP lookup of the endpoints connected to the L2VNI segment and provide the SGT & DGT tags necessary to enforce the security policy.

Policy Aware Fabrics in a Multi-Site Domain

This section describes how the route advertisement and packet movement happens between 2 hosts in a policy aware Multi-Site domain.

In the above topology, site 1 and site 2 are policy aware.

Route-advertisement of Host H1 from Leaf L1 to Leaf L5

When a host route H1 is advertised from L1, site 1 to L5 site 2, the route advertisement flow is as follows:

1. Next-hop Router L1 advertises the route with L1 next-hop and source group tag (TagX) as configured by the policy on router L1.

2. Router A1, which is the BGW in the Site-1, re-originates the route with the Multi-Site VIP of the BGW as next-hop, however, retains the SGT tag (TagX) received from L1.

3. Similarly, router B2 (BGW in Site-2) re-originates the route H1 inside the local fabric with the Multi-Site VIP of B2 BGW as next-hop and the same SGT tag (TagX).

4. L5 receives the route from router B2 and installs it in the forwarding table with the associated security tag “TagX”. This way, the tag from the originator leaf is retained across the entire multi-site domain.

Refer to the following figure to know about the learned endpoint information on the various nodes.

Packet-Flow from Host H5 to Host H1

The packet flow between the hosts H5 and H1 would be as follows.

1. Router L5 receives the traffic from the host H5. Since both SRC and DST tags are available, L5 would locally apply the security policy. If the policy-action is permitted, it would set the policy-applied (PA) bit in the VXLAN-GPO header and send the traffic to BGW router B2, representing the next-hop to reach the destination host H1.

2. Along with this, the PA bit setting is retained in the VXLAN GPO header B2, on seeing the PA bit set in the VXLAN header, would not reapply the policy, and just decapsulate and re-encapsulate the traffic sending it to the BGW A1, site 1, representing the next-hop to reach the destination host H1. Along with this, the PA bit setting is retained in the VXLAN GPO header.

3. BGW A1 would take a similar action as BGW B2 and forward the traffic to router L1.

4. Router L1 would not apply Policy as well because of the PA bit set and would forward the traffic to the destination host H1.

Policy Aware and Policy Unaware Fabrics in a Multi-Site Domain

In the above picture, Site-1 is a policy aware site and Site-2 is a policy unaware site.

Route advertisement of Host H1 from Router L1 to Router L5

The route advertisement of Host H1 from router L1 to router L5 would be as follows.

1. Router L1 advertises the route H1 with next-hop as L1 and SGT Tag (TagY) based on the configuration on L1.

2. Router A1 locally installs the route with next-hop L1 (and associated tag TagY) and re-originates the route to the remote BGW B2 with next-hop as A1 Multi-Site VIP and the same SGT Tag (TagY).

3. The BGW B2, upon receiving the route with SGT Tag (TagY), locally installs the route with A1 as next-hop and ignores the SGT Tag as it is policy unaware. It then re-originates the route to router L5 with next-hop as B2 Multi-Site VIP.

4. Router L5 installs the route H1.

Route advertisement of Host H5 from Router L5 to Router L1

The route advertisement of Host H5 from router L5 to router L1 would be as follows.

1. Router L5 advertises the route for host H5 with next-hop as L5.

2. BGW B2 locally installs the route with L5 as next-hop and re-originates the prefix with next-hop as B2 Multi-Site VIP.

3. Since A1 is in a policy aware site, and received the route from a policy unaware fabric, A1 installs the route with the Default Tag for Policy unaware sites, Tag ‘15’.

4. BGW router A1 re-originates the route to L1 with next-hop as A1 Multi-Site VIP and Tag 15.

5. Router L1 installs the route with SGT TAG 15 and next-hop as A1 Multi-Site VIP.

Refer to the following figure to know about the learned endpoint information on the various nodes.

Packet flow from Host H5 to Host H1

The packet flow between the hosts H5 and H1 would be as follows.

1. Router L5 receives the traffic from the host H5 and routes the traffic to B2 with standard VXLAN header.

2. B2 decapsulates and re-capsulates in a standard VXLAN header.

3. A1 decapsulates the traffic, applies the policy based on source Tag “15” and destination “Tag Y”. Based on the policy, traffic is forward to L1 with VXLAN GPO tunnel and policy-applied bit set.

4. L1 decapsulates the traffic and since PA bit is set, policy is not applied again and forwarded to H1.

Packet flow from Host H1 to Host H5

Packet flow from host H1 to host H5 would be as follows.

1. Router L1 receives the traffic from H1, applies the policy based on the source Tag ‘TagY’, destination Tag ‘15’. Based on the policy result, L1 routes the traffic to A1 with VXLAN GPO Tunnel with policy-applied (PA) bit set.

2. A1 decapsulates and since PA bit is set, it does not reapply the policy and forwards the traffic to B2 in a standard VXLAN Tunnel.

3. Traffic flow from B2 to H5 is similar to any Multi-Site deployment.

With the help of micro-segmentation and GPO, NX-OS users can create smaller and isolated segments within a network and enforce security policies. This allows users to have better control over the traffic flow and apply security policies only where they are needed.