For this next example, let’s assume that you need to deploy a three-tier web application. The application is built on VMs that run different operating systems and different versions of the same operating system. For example, the VMs might run Linux, Windows 2012 R2, and Windows 2016. The application is distributed, so the company has divided the VMs into three different EPGs: EPG_Web, EPG_App, and EPG_DB.
Because of a recent vulnerability in the Windows 2012 R2 operating system, your company’s security team decided to quarantine VMs running Windows 2012 R2 in case those VMs are compromised. The security team also decided to upgrade all Windows 2012 R2 VMs to Windows 2016. It also wants to microsegment all production VMs across all EPGs and restrict external connectivity to those VMs.
To meet this requirement, you can configure a uSeg EPG in the Cisco APIC. The attribute would be Operating System, and the value of the attribute would be Windows 2012 R2.
You can now quarantine the VMs running Windows 2012 R2 and upgrade them to Windows 2016. When the upgrade is complete, the VMs will no longer be part of the uSeg EPG you created for VMs running Windows 2012 R2. This change is reflected dynamically to the Cisco APIC, and those virtual machines revert to their original EPGs.
As shown in Figure 18-16, the new uSeg EPG EPG_Windows_2012 has the attribute type Operating System and the value Windows 2012 R2. The VMs App_VM_2, DB_VM_1, DB_VM_2, and Web_VM_2 run Windows 2012 R2 as their operating system—and so have been moved to the new uSeg EPG EPG_Windows_2012. However, the VMs App_VM_1, DB_VM_3, and Web_VM_1 run Linux or Windows 2016, so they remain in their application EPGs.