practical applications of - clnv.s3.amazonaws.com · epg, uepg, domain associations, contract...

Practical Applications of Cisco ACI Micro Segmentation

@JuanLage, Principal Engineer – INSBU

BRKACI-2301

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

Cisco Spark

Questions? Use Cisco Spark to communicate with the speaker after the session

1. Find this session in the Cisco Live Mobile App

2. Click “Join the Discussion”

3. Install Spark or go directly to the space

4. Enter messages/questions in the space

How

cs.co/ciscolivebot#BRKACI-2301


Session Objectives

• Explain the ACI features that enable Micro Segmentation

• Provide you ideas of how to use these features

• Show you these features working on simple yet practical examples

5BRKACI-2301

• ACI Fundamentals Review

• Micro Segmentation Fundamentals

• ACI Group Based Policy Model

• Deep dive into Micro EPG options

• Demo #1 – Applying IP-Based uEPGs to segment BM and VM

• Demo #2 – Using uSeg for Automated Application Deployment

Agenda


External

L2/L3

Network Virtualization• Distributed L2/L3 across the fabric,

across different sites

• Seamless networking for physical, storage, VMs and Containers

Virtualization Support• VMware vCenter

• Microsoft SCVMM

• Red Hat Virtualization

• OpenStack

• Kubernetes

Integrated Security• Distributed Programmable Policy

• Micro Segmentation

• L4-7 Service Chaining

Ecosystem • Cisco ACI App Center

• +65 Ecosystem Partners

• Cloud Management Integration

Virtual Switch

7BRKACI-2301

Application Centric InfrastructureSingle Point of Management with full FCAPS

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 8BRKACI-2301

Cisco ACI: Industry Leader

ACI Customers ACI Attach Rate Ecosystem Partners

46+%4,400+ 65+

Ecosystem Partners


ACI AnywhereAny Workload, Any Location, Any Cloud

Remote PoD Multi-Pod / Multi-Site Hybrid Cloud Extension

ACI ANYWHERE

IP

WAN

IP

WAN

Remote Location Public CloudOn Premise

Security Everywhere Policy EverywhereAnalytics Everywhere







Agenda

What do we mean by Micro Segmentation?


What is Micro Segmentation?

Segment 1Segment 3

Segm

ent

2S

egm

ent

4

Segmentation

✔

✖

Segment = Broadcast domain / VLAN / Subnet

BRKACI-2301 12



Segment 1Segment 3

Segm

ent

2S

egm

ent

4

Segmentation Micro Segmentation

Segment 1

Micro Segment 1 Micro Segment 3

✖

Micro Segment 2

✔ ✔✔

✖

Segment = Broadcast domain / VLAN / Subnet Micro Segment = Endpoint or Group of Endpoints

BRKACI-2301 13



Segment 1Segment 3

Segm

ent

2S

egm

ent

4

Segmentation Micro Segmentation

Segment 1

Micro Segment 1 Micro Segment 3

✖

Micro Segment 2

✔ ✔✔

✖

Segment = Broadcast domain / VLAN / Subnet Micro Segment = Endpoint or Group of Endpoints

Micro Segment 4

✖

Segm

ent

2

BRKACI-2301 14


Why Micro Segmentation?

• Perimeter security is not enough: oncebreached, lateral movement can allowattackers to compromise more assets

• Improve the security posture inside the Data Center

• Minimize segment size and provide smallest exposure to lateral movement

15BRKACI-2301


Micro Segmenting in an heterogeneous Data Center

Many different types of workloads running in a Data CenterCampus

and

Branch Users



Campus

and

Branch Users

BRKACI-2301 17



Virtualized w/ VMware

Campus

and

Branch Users

BRKACI-2301 18




Virtualized w/

MicrosoftCampus

and

Branch Users

BRKACI-2301 19




Virtualized w/

MicrosoftCampus

and

Branch Users

Virtualized w/

KVM

BRKACI-2301 20



Virtualized w/ VMware Bare Metal / Big Data

Virtualized w/

MicrosoftCampus

and

Branch Users

Virtualized w/

KVM

BRKACI-2301 21



Virtualized w/ VMware Bare Metal / Big Data Shared/Infra

Virtualized w/

MicrosoftCampus

and

Branch Users

Virtualized w/

KVM

BRKACI-2301 22


Micro Segmenting requires granularly grouping endpoints, and defining and enforcing policy between them

Policy EnforcementBRKACI-2301 23



Sale

sC

ontr

acto

r

Policy EnforcementBRKACI-2301 24



Sale

sC

ontr

acto

r

Policy Enforcement

Look at SDA for this

BRKACI-2301 25


Key Functions to Achieve Better Segmentation

Endpoint Identity Policy Definition Verify, Refine

How to classify endpoints

into groups:

- Network identity

(IP/MAC/VLAN)

- Meta-data: VM attributes,

labels, tags, etc.

- DNS

- User Authentication (i.e.

from ISE)

Determine what policy to

configure between and

within groups:

- Application Dependency

Mapping

- White-List vs. Black-List

- Policy Simulation

- Dynamic vs. pre-defined

Verify policy enforcement,

lifecycle management:

- Policy visibility

- Logging and log analysis

- Alerts, remediation

- Constant updates


Where should we enforce policy?

• Centrally manage host-based firewalls.

• Pros:

• distributed

• network independent

• can use extremely granular policies

• process-level visibility and correlation

• Cons:

• guest-OS dependent

• Centrally manage rules at network edge (vSwitch, pSwitch or both)

• Pros:

• distributed

• guest OS independent

• best scale with group based policy

• network level visibility and correlation

• Cons:

• requires network resources (memory, TCAM, etc.) for policy

Host-based Enforcement Network-based Enforcement


ACI implements distributed network policies

• Contracts allow definition of Layer2 to Layer4 security policies.

• Distributed security policies implemented at different enforcement points:

• Leaf: hardware based, no performance penalty.

• vSwitch (i.e. OVS, AVE, FD.io/VPP)

vSwitch vSwitch w/OpFlex

External

L2/L3


Cisco Tetration provides best network analytics and host-based distributed security

Opera

tions

Security

Cisco Tetration™

Visibility and

forensics

Application

insight

Policy

Neighborhood

graphs

Application

segmentation

Compliance

Policy

simulation

Process

inventory

BRKACI-2301 29


It is possible to combine both host-based and network-based for tiered-security and operational reasons (SecOps vs. NetOps vs. DevOps).

BRKACI-2301 30

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco PublicBRKACI-2301

APIC Enforces Policy across dissimilar data planes

APIC Policy

and Visibility

Point

Application

Traffic

31

VMware

vCenterMicrosoft

SCVMM

Northbound APIs

APP

OS

APP

OS

APP

OS

APP

OS

VDS

APP

OS

APP

OS

APP

OS

APP

OS

Any vSwitch

APP

OS

APP

OS

APP

OS

APP

OS

AVE

KVM w/ OVS

APP

OS

APP

OS

APP

OS

APP

OS

N9K

Leaf

k8s w/ OVS

N9K

Leaf

OpFlex

Focus of this session Check BRKACI-3456 Check BRKACI-2505







Agenda

Identifying and Classifying endpoints into Groups in ACI


An Endpoint Group (EPG) is a set of devices that share the same policy

requirements.

BRKACI-2301 34


Every EPG belongs to a VRF and an Application Profile.

BRKACI-2301 35


Application ProfileA group of EPGs related to each other to represent an application

EPG, uEPG, domain associations,

contract relations and L4-7

Configuration

Health scores, statistics, logs

and audit data automatically

correlated and rolled up at

Application Profile level

BRKACI-2301 36


By default …

endpoints inside and EPG can communicate freely.

BRKACI-2301 37


By default …

endpoints in different EPGs cannot communicate at all.

BRKACI-2301 38


Defaults can be changed ...

BRKACI-2301 39


Policy Enforcement can be enabled or disabled at VRF level

• Policy Enforce: no communication without contracts

• Policy Unenforced: all communication allowed

40BRKACI-2301

VRF – MyVRF

EPG-A EPG-B EPG-C

L3Out

External

EPG

VRF – MyVRF

EPG-A EPG-B EPG-C

L3Out

External

EPG


Another option

is to use Preferred Groups inside a VRF.

BRKACI-2301 41


Preferred Group Operating Principle

VRF – MyVRF

EPG-A EPG-B EPG-C EPG-D

EPG-1

EPG-2

EPG-3

Contract-2

Contract-1

L3OutExternal

EPG

Inside the

Preferred Group there

is unrestricted

communication

Excluded EPGs can

NOT communicate

without contracts

Preferred Group


Preferred Group Operating Principle

VRF – MyVRF

EPG-A EPG-B EPG-C EPG-D

EPG-1

EPG-2

EPG-3

Contract-2

Contract-1

L3OutExternal

EPG

Contract-3

Contracts are required to

reach EPG inside the

Preferred Group

Preferred Group

BRKACI-2301 43


Preferred Group Configuration – Enable at VRF, then select at EPG Level

• First, enable Preferred Group feature for the VRF at the vzAny configuration

• Then configure for each EPG

BRKACI-2301 44


Restrict all traffic inside a Group – Intra EPG Isolation

Intra EPG Isolation

• Intra-EPG Isolation blocks communication

between all endpoints inside the group

• Supports mixing of Physical and Virtual

endpoints in same EPG

• Software Dependency: 1.3(1g) or higher

• Hardware Dependency: supported on all hardware models

Intra-EPG Isolation

EPG Video-Server


Restrict all traffic inside a group:Intra EPG isolation

• Supported on PhysDoms, VMware VMM domain (AVS, AVE, DVS) (*)

• Since ACI 3.0 Microsoft VMM domain also supports intra EPG isolation.

• Can be configured on EPG and uEPG (**)

• For uEPGs it’s supported with EX and FX leaf.

• We utilize PVLAN integration for VMware DVS and MSFT VMM Domains.

• We use Proxy-ARP – required to reach other EPG in the same subnet

(*) On AVS and AVE it requires VXLAN mode

(**) IntraEPG Isolation not supported yet with uEPG on AVS/AVE


EPGs can have relations with ContractsContract Determine Communication using a White List model

Bridge Domain – 10.10.10.1/24

BM-01

10.10.10.11

VM-02

10.10.10.12VM-03

10.10.10.13BM-04

10.10.10.14

EPG BLUE EPG GREEN

BRKACI-2301 47

L2/L3




BM-01

10.10.10.11

VM-02

10.10.10.12VM-03

10.10.10.13BM-04

10.10.10.14

EPG BLUE EPG GREEN

Contract: Blue-to-Green

Scope: VRF

Subject: AppTraffic

Both Directions: True

Reverse Port Filters: Yes

permit tcp/80

permit tcp/443C

ON

SU

ME

S

PR

OV

IDE

S

BRKACI-2301 48

L2/L3




BM-01

10.10.10.11

VM-02

10.10.10.12VM-03

10.10.10.13BM-04

10.10.10.14

EPG BLUE EPG GREEN


Scope: VRF

Subject: AppTraffic



permit tcp/80

permit tcp/443C

ON

SU

ME

S

PR

OV

IDE

S

GREEN Provides the contract,

so ports tcp/80 and tcp/443 are

exposed.

BRKACI-2301 49

L2/L3




BM-01

10.10.10.11

VM-02

10.10.10.12VM-03

10.10.10.13BM-04

10.10.10.14

EPG BLUE EPG GREEN


Scope: VRF

Subject: AppTraffic



permit tcp/80

permit tcp/443C

ON

SU

ME

S

PR

OV

IDE

S



exposed.

BLUE Consumes the contract,


NOT exposed.

BRKACI-2301 50

L2/L3




BM-01

10.10.10.11

VM-02

10.10.10.12VM-03

10.10.10.13BM-04

10.10.10.14

EPG BLUE EPG GREEN


Scope: VRF

Subject: AppTraffic



permit tcp/80

permit tcp/443C

ON

SU

ME

S

PR

OV

IDE

S



exposed.



NOT exposed.

any, tcp/80

BRKACI-2301 51

L2/L3




BM-01

10.10.10.11

VM-02

10.10.10.12VM-03

10.10.10.13BM-04

10.10.10.14

EPG BLUE EPG GREEN


Scope: VRF

Subject: AppTraffic



permit tcp/80

permit tcp/443C

ON

SU

ME

S

PR

OV

IDE

S

any,tcp/8080



exposed.



NOT exposed.

any, tcp/80

BRKACI-2301 52

L2/L3


Contracts also allow inserting L4-7 services, like Next Generation Firewalls, ADC, IPS/IDS, etc.


BM-01

10.10.10.11

VM-02

10.10.10.12VM-03

10.10.10.13BM-04

10.10.10.14

EPG BLUE EPG GREENC

ON

SU

ME

S

PR

OV

IDE

S


Scope: VRF

Subject: AppTraffic



permit tcp/80

permit tcp/443

You can insert an NGFW, or

a LB by attaching a Service

Graph to the contract subject

BRKACI-2301 53

L2/L3


Restricting traffic inside a group with Intra EPG Contracts

EPG AppNetwork

10.80.80.13 10.80.80.12 10.80.80.15

EPG AppNetwork2

10.90.90.15

Contract: ansible

Subject: Allow-ssh

TCP/22

ICMP



EPG AppNetwork

10.80.80.13 10.80.80.12 10.80.80.15

EPG AppNetwork2

10.90.90.15

Contract: ansible

Subject: Allow-ssh

TCP/22

ICMP

Contract: allow-icmp

Subject: ICMP-traffic

ICMP, log

<fvRSIntraEpg tnVzBrCPName=“allow-icmp”/>

New contract relationship

type to specify IntraEPG



EPG AppNetwork

10.80.80.13 10.80.80.12 10.80.80.15

EPG AppNetwork2

10.90.90.15

Contract: ansible

Subject: Allow-ssh

TCP/22

ICMP



ICMP, log





Restricting communication between endpoints inside a Group with IntraEPG Contracts

• Since ACI 3.0 it is possible to assign contracts to restrict traffic between endpoints of the same EPG

• It can be enabled on both EPG and uEPG

• As of 3.1, it is supported for PhysDoms and VMware VDS VMM Domains

• IntraEPG contracts require using proxy-arp.

• It is only supported with EX/FX switches or newer.


IntraEPG Contract Use Case – service vNIC used for mgmt in a clustered App

app1-web

(uEPG)

Web

VM

10.10.40.11

web-prod-aci-01

Web

VM

10.10.40.11

web-prod-aci-02

Web-Tier PorGroup (BaseEPG)

(PVLAN 2300/2301)

Example: a clustered web application. The jump host must be able to access all endpoints and

you cannot use IntraEPG Isolation because the required protocols must be allowed between

the VM inside the dvPortGroup.

EPG JumpHost

10.90.90.15Contract: Zookeeper

Subject: Allow Zookeeper

TCP/2181

TCP/2888

TCP/3888

intraEPG

Only Zookeeper ports

allowed between VMs

Contract: any-ip

Subject: Allow-any-ip

Any IP


Taboo Contract

• Taboo contracts are specific to one EPG

• They deny a set of ports on the EPG when taboo contract is applied

• For instance you can say EPG-A do not allow any port 80 traffic

• Taboo filters will override regular contract filters

60BRKACI-2301


vzAny Details

vzAny Allows to configure contracts for all EPG in a VRF

• vzAny represents the collection of EPGs that belong to the same VRF, including L3 external.

• Instead of associating contracts to each individual EPG you can configure a contract to the vzAny

• With cross-VRF contracts, vzAnycan be a consumer, not provider

VRF1

EPG1

EPG2

EPG3

EPG4

vzAny

Tenant

BD1

BD2

BRKACI-2301 61


Simplifying Contract Configurations:- EPG Contract Inheritance

• Simplify policy configuration of EPG contract relations

- EPG(s) can refer to Master EPG(s) to inherit contract relationship from

- 1 level and 1 direction of contract inheritance (ie. Master EPG -> Child EPG)

- Child EPG can inherit from multiple Parent EPGs

- When new contract relations are added to the higher EPG, those with

inheritance relation will automatically get those same contract associations

• Caveats: - EPGs must be under same Tenant

- Contract Inheritance does NOT reduce number of contracts or TCAM entries

- Inheritance does NOT apply to VzAny

BRKACI-2301 62


Example: EPG_A has three contract relations

BRKACI-2301 63

EPG_A Consumes Provides

Contract_DNS

Contract_Internet

Contract_SSL


EPG_B is configured to inherit from EPG_A

64


Contract_DNS

Contract_Internet

Contract_SSL

EPG_B

(Master: EPG_A)

Consumes Provides

Contract_DNS

Contract_Internet

Contract_SSL

Use the same contracts

as EPG_A

EPG_B Consumes Provides

BRKACI-2301


EPG_B is configured to inherit from EPG_A- can now add specific contracts to “child”


Contract_DNS

Contract_Internet

Contract_SSL

EPG_B

(Master: EPG_A)

Consumes Provides

Contract_DNS

Contract_Internet

Contract_SSL

Contract_TomCat

EPG_B also provides

another contract

BRKACI-2301 65


EPG_C is configured to inherit from EPG_A


Contract_DNS

Contract_Internet

Contract_SSL

EPG_B

(Master: EPG_A)

Consumes Provides

Contract_DNS

Contract_Internet

Contract_SSL

Contract_TomCat

EPG_C

(Master: EPG_A)

Consumes Provides

Contract_DNS

Contract_Internet

Contract_SSL

EPG_C only gets

contracts from EPG_A

BRKACI-2301 66


Changes to contract relations on EPG_A are inherited by EPG_B and EPG_C


Contract_DNS

Contract_Internet

Contract_Ansible

Contract_SSL

EPG_B

(Master: EPG_A)

Consumes Provides

Contract_DNS

Contract_Internet

Contract_Ansible

Contract_SSL

Contract_TomCat

EPG_C

(Master: EPG_A)

Consumes Provides

Contract_DNS

Contract_Internet

Contract_Ansible

Contract_SSL

New contract relation added only

to EPG_A and automatically

inherited by EPG_B and EPG_C

BRKACI-2301 67


Contract Logging – Denied Packets

Logging Deny

• ACI can log implicit deny hits• For Bare Metal, VMware VDS and MSFT Domains logs

generated by Leaf

• For AVS logs may be generated on Leaf or vLeaf

• For OpenStack ML2 mode, logs configured external to

the fabric at the host

• Syslog is exported according to monitoring policies

and configured External Data Collectors

• Logs include Tenant/VRF, EPG VLAN encap,

ingress interfaces and offending packet details

• Software Dependency: supported on all software releases

• Hardware Dependency: supported on all hardware models

VM-02

10.10.50.101VM-03

10.10.10.200

CO

NS

UM

ES

Subject: DB-Traffic

Filter: Action:

icmp allow

tcp/3106 allow

MySQLAccess

PR

OV

IDE

S

SIP:10.10.50.101 DIP:10.10.10.200 sPort:54135 dPort:125Proto: 6

Feb 04 10:26:54 troy-leaf1 %LOG_LOCAL7-6-SYSTEM_MSG [E4204936][transition][info][sys] %ACLLOG-5-ACLLOG_PKTLOG_DENY: CName: Test-Tenant:Test-Tenant-VRF(VXLAN: 2162689), VlanType: FD_VLAN, Vlan-Id: 21, SMac: 0x00505690b43a, DMac:0x0022bdf819ff, SIP: 10.10.50.101, DIP: 10.10.10.200, SPort: 54135, DPort: 125, Src Intf: port-channel2, Proto: 6, PktLen: 74

ACL deny not logged by default:

Fabric -> Fabric Policies -> Monitoring Policies -> Common Policy -> Syslog Message

Policies -> Policy for system syslog messages -> Change ‘default’ to ‘info’


Contract Logging – Permitted Packets

Logging Permit

• Permit logging is configured per Filter• For Bare Metal, VDS and MSFT Domains logs

generated by Leaf

• For AVS logs may be generated on Leaf or

vLeaf

• For OpenStack ML2 mode, logs configured

external to the fabric at the host

• Syslog is exported according to monitoring

policies and configured External Data

Collectors

• Logs include Tenant/VRF, EPG VLAN encap,

ingress interfaces and offending packet details

• Software Dependency: 2.2(1n) or higher

• Hardware Dependency: requires EX models or newer

VM-02

10.10.50.101VM-03

10.10.10.200

CO

NS

UM

ES

Subject: DB-Traffic

Filter: Action:

icmp allow log

tcp/3106 allow log

MySQLAccess

PR

OV

IDE

S

SIP:10.10.50.101 DIP:10.10.10.200 sPort:0 dPort:0Proto: 1

Feb 04 10:14:44 troy-leaf1 %LOG_LOCAL7-6-SYSTEM_MSG [E4204936][transition][info][sys] %ACLLOG-5-ACLLOG_PKTLOG_PERMIT: CName: Test-Tenant:Test-Tenant-VRF(VXLAN: 2162689), VlanType: FD_VLAN, Vlan-Id: 21, SMac: 0x00505690b43a, DMac:0x0022bdf819ff, SIP: 10.10.50.101, DIP: 10.10.10.200, SPort: 0, DPort: 0, Src Intf: port-channel2, Proto: 1, PktLen: 98

Permit log configured at the

subject on a per filter basis.







Agenda


Micro EPGs allow grouping of endpoints based on their attributes,

rather than an encapsulation.

BRKACI-2301 71


Understanding Micro EPGs

• A MicroEPG (uEPG) is equivalent to a regular EPG for all purposes, but classification is based on endpoint attributes (and dynamic in nature)

• Endpoints assigned to the uEPGregardless of the encapsulation/port

• The endpoint must be first known to a regular EPG, called “base EPG”

VM-01

10.10.10.13

EPG GREEN

BM-02

10.10.10.12

f4:5c:89:b2:ab:cd

Base EPG based on port and encapsulation (i.e

VLAN or VXLAN)

BM-01

10.10.10.11

f4:5c:89:b2:bf:cb

BRKACI-2301 72






VM-01

10.10.10.13

EPG GREEN

BM-01

10.10.10.11

f4:5c:89:b2:bf:cb

BM-02

10.10.10.12

f4:5c:89:b2:ab:cd

uEPG MyDB

Define uEPG based on MAC. Example:

Select MAC=f4:5c:89:b2:bf:cb

Base EPG based on port and encapsulation (i.e

VLAN or VXLAN)

BRKACI-2301 73






BM-01

10.10.10.11

f4:5c:89:b2:bf:cb

EPG GREEN

BM-02

10.10.10.12

f4:5c:89:b2:ab:cd

uEPG MyDB uEPG Quarantine

VM-01

10.10.10.13

Define uEPG based on VM attributes. Example:

VM-name=VM-01

BRKACI-2301 74


Micro EPGs are “attribute-based” EPGs

BRKACI-2301 75



New attribute called ‘isAttrBasedEPg’ in fvAEPg. Admin has to explicitly

specify a given EPG is an attributed based EPG or not.

BRKACI-2301 76





BRKACI-2301 77





isAttrBasedEPg = “no”

BRKACI-2301 78






isAttrBasedEPg = “yes”

BRKACI-2301 79






isAttrBasedEPg = “yes”

An object fvCrtrn defines the ‘criteria’ - i.e. attributes – that

select endpoints into this group.

BRKACI-2301 80


Classification possibilities depend on the type of endpoint.

BRKACI-2301 81


For endpoints connected to Physical Domains (bare metal) you can use the IP or MAC

addresses.

BRKACI-2301 82


PhysDom (Bare Metal) with MAC Address

MAC Micro EPGs considerations on PhysDoms

• Base EPG must be configured and deployed to program VLANs on leaf host ports

• Base EPG & MAC uEPG must associate with same BD

• MAC uEPG must be deployed by using node attachment on all the nodes where BD is deployed

• Deployment Immediacy must be “Immediate”

• VRF must be configured for ingress policy enforcement mode otherwise fault will be raised

• Software Dependency: 2.1(1h)

• Hardware Dependency: E-Series or newer


PhysDom (Bare Metal) with IP Addresses

IP Micro EPGs considerations on PhysDoms

• Software Dependency: 1.2(x)

• Hardware Dependency: E-Series or newer

• Caveat: No bridged traffic will be enforced based on the IP-EPG classification

• Base EPG must be configured and deployed to program VLANs on leaf host ports

• Base EPG & IP uEPG must associate with same BD. BD MUST have subnet configured.

• IP uEPG must be deployed by using node attachment on all the nodes where BD is deployed

• Deployment Immediacy must be “Immediate”

• You can specify individual IP addresses and/or subnets (i.e. 10.10.10.1, 10.10.10.0/24)


For endpoints connected to VMware or Microsoft VMM Domains you can use the

IP, MAC or VM-attributes.

Note: uEPG support for Red Hat Virtualization is a roadmap item

BRKACI-2301 85


Micro EPGs with Microsoft Hyper-V1. Start with a Base EPG

EPG GREEN (vlan-100)

MSFT vSwitch

VM Network GREEN (trunk)

ubuntu-01 centos-01 ubuntu-02centos-02

Base EPG GREEN mapped to Microsoft VMM Domain defines vSwitch Network

and base encapsulation

GREEN(vlan-100)

GREEN(vlan-100)

OpFlex

Policy Enforcement

OpFlex

Hyper-V


Micro EPGs with Microsoft Hyper-V2. Configure uEPGs

Hyper-V



1.- We define a new uEPG called Ubuntu-VM and map it to the MSFT

VMM Domain.

Hyper-V




VMM Domain.

2.- We define attributes to match, in this example, matching on the VM Operating

System (Ubuntu Linux)

Hyper-V




VMM Domain.

2.- We define attributes to match, in this example, matching on the VM Operating


The uEPG will use a new encapsulation, communicated to the vSwitch using OpFlex

Hyper-V


Micro EPGs with Microsoft Hyper-V3. VM classified according to attributes


MSFT vSwitch



GREEN(vlan-100)

GREEN(vlan-100)


MSFT vSwitch



GREEN(vlan-100)

GREEN(vlan-100)

OpFlex OpFlex OpFlex OpFlex

Hyper-V

Policy Enforcement


Micro EPGs with Microsoft Hyper-V3. VM classified according to attributes


MSFT vSwitch



uEPG UBUNTU (vlan-102)

GREEN(vlan-100)

GREEN(vlan-100)

Ubuntu(vlan-102)

Ubuntu(vlan-102)


MSFT vSwitch



GREEN(vlan-100)

GREEN(vlan-100)

OpFlex OpFlex

Ubuntu VMs now cannot communicate with CentOS VM and

vice versa

(no contract) OpFlex OpFlex

Hyper-V

Policy Enforcement


Micro EPG Support with vSphere VDS1. Start with Base EPG, enable MicroSeg

vSphere

VMware VDS

dvPortGroup GREEN (PVLAN p-3012, s-3019)

Policy Enforcement



vSphere

VMware VDS



EPG GREEN

Policy Enforcement



vSphere

Must be True!

VMware VDS



EPG GREEN

Policy Enforcement



vSphere

Must be True!

VMware VDS


APIC will then configure

the dvPortGroup as an

isolated PVLAN


EPG GREEN

Policy Enforcement



vSphere

Must be True!

VMware VDS


Must be Immediate!



isolated PVLAN


EPG GREEN

Policy Enforcement



vSphere

Must be True!

VMware VDS

GREEN(v-3012/3019)

GREEN(v-3012/3019)


Must be Immediate!



isolated PVLAN


EPG GREEN

Policy Enforcement


Micro EPG Support with vSphere VDS1.1 Base EPG is working as normal EPG

vSphere

VMware VDS

GREEN(v-3012/3019)

GREEN(v-3012/3019)

EPG GREEN



Policy Enforcement


Micro EPG Support with vSphere VDS1.1 Base EPG is working as normal EPG

vSphere

VMware VDS

GREEN(v-3012/3019)

GREEN(v-3012/3019)

EPG GREEN



Communication between

endpoints inside the EPG

is allowed at the Leaf.

Proxy-ARP enabled. Policy Enforcement


Micro EPG Support with vSphere VDS2. Configure uEPG based on attributes

vSphere

1. Define uEPG and map to the same VMM Domain and BD as Base EPG

Must be Immediate!

2. Map uEPG to the required leafs (where ESXi servers are connected)


Micro EPG Support with vSphere VDS2. Configure uEPG based on attributes

vSphere

3. Configure the required attributes

We define attributes to match, in this example, matching on the VM Operating



Micro EPG Support with vSphere VDS3. VM is classified according to attributes

vSphere

VMware VDS

GREEN(v-3012/3019)

GREEN(v-3012/3019)

EPG GREEN



uEPG UBUNTUuEPG UBUNTU

Ubuntu(mac-list)

Ubuntu(mac-list)

uEPG

Ubuntu

MAC Address

vm-1 00:50:56:AD:15:2E

vm-2 00:50:56:AD:15:1F

VM name: ubuntu-01

IP: 0.0.0.0

MAC: 00:50:56:AD:15:2E

VM name: ubuntu-02

IP: 192.168.1.41

MAC: 00:50:56:AD:15:1F

Policy Enforcement


Micro EPG Support with vSphere VDS – Details

Micro EPG Considerations on vSphere VDS

• Software Dependency: 1.3(1g)

• Hardware Dependency: EX-Series or newer

• Under base EPG you must enable useg EPG for vDS. This is only required if using uSeg

with VDS.

• When EPG is mapped to VMM domain, it will change vDS and port-group configuration:

PVLAN will be enabled.

• Port-group uses secondary VLAN (isolated), which is same with intra-EPG isolation.

• Proxy-ARP is automatically enabled on base EPG (this is only supported in EX-models)

• PVLAN configuration is only to force all traffic to flow through Leaf.

• You can create uEPG with attribute classification and map to the same VMM domain:

• Even though we use VM attribute, since APIC knows VM name and other info (IP, MAC)

from vCenter and data plane, APIC will find the MAC address of the VM.

• Leaf will use MAC address for uSeg EPG classification.


Micro EPG with AVE functions in a way similar to both Microsoft and VDS

BRKACI-2301 106


An EPG and a uEPG can be mapped to multiple different Domains

(Virtual or Physical).

BRKACI-2301 107


Supported Attributes for Micro EPG Classification

• Attribute support depends on

Domain type.

• For VMM domains, some

attributes are vendor specific

(i.e. vSphere Tags)

• Refer to Release Notes and

Virtualization Configuration

Guide for latest information

Supported attributes as of 3.1

Attributes Type Example Domains

MAC Address Network 5c:01:23:ab:cd:ef Phys, VMW,

MSFT

IP Address Network 10.10.1.0/24

10.20.21.1

Phys, VMQ,

MSFT

VNic Dn (vNIC domain name) VM A1:23:45:67:89:0b VMW, MSFT

VM Identifier VM vm-598 VMW, MSFT

VM Name VM HR_UI_WEB VMW, MSFT

Hypervisor Identifier VM esxi-host-01 VMW, MSFT

VMM Domain VM AVS-VMM-DC1 VMW, MSFT

Datacenter VM BRU-DC VMW, MSFT

Guest Operating System VM Windows 2008 VMW, MSFT

Custom Attribute VM AppTier=Web VMW, MSFT

vSphere TAGs VM PROD:ENV VMW

DNS Network acme.app.com (experimental)

BRKACI-2301 108


You can configure multiple attributes to select endpoints for a Micro EPG.

APIC implements Logical Operators for this since release 2.3.

BRKACI-2301 109


uEPGs with Attributes and Logical Operators- GUI Configuration (1/2)

BRKACI-2301 110



Select new “uSeg

Attributes” folder under

each specific uEPG

BRKACI-2301 111



Select new “uSeg


each specific uEPG

Click on ‘+’ to add

additional attributes to

Match Any/All. Or click ’+(‘

to add additional sections.

BRKACI-2301 112



Select new “uSeg


each specific uEPG

BRKACI-2301 113



Select new “uSeg


each specific uEPG

Select “Match Any” for

‘OR’ Logic.

Select “Match All” for

‘AND’ Logic.

BRKACI-2301 114



Selects VMs with Tag ‘APP:OpenCart-Apache’, or VMs with

’Custom Attribute app-tier=app1-app’ as long as they are

running on vCenter DC1-EAST datacenter BRKACI-2301 115


uEPG Match Precedence

• Attribute combinations may select a

VM to be on multiple EPGs at once

• Match Precedence selects the

winner

• Higher precedence wins


Some important things to keep in mind when using Micro EPGs …

BRKACI-2301 117


Considerations when using Micro EPG

• Be careful when using VM-attributes:

• Most attributes will imply immediate action on APIC, others (like vSphere Tags) rely on polling, will take longer to action.

• If a VM with multiple vNIC is classified, all vNIC may be on the same uEPG. Ensure you select vNIC-ID if using multiple vNICs or use IP/MAC attributes instead.

• Use of Intra-EPG contracts assumes you can use proxy-arp and no flooding is required.

• Watch out for applications that may require flooding.

• When using uEPG on VDS, currently there are some caveats

• SPAN filtering is at base EPG level, not per uEPG

• Stats are aggregated at base EPG level, not per uEPG

118BRKACI-2301







Agenda

Demo #1EPG Classification based on IP Address


[Flexibly] Classify based on IP Subnet

• Two subnets:

• One for application Virtual Machines

• One for Data Bases, Virtual and Physical

• We want to ensure classification based on IP subnet, regardless of encapsulation

• We want to keep maximum flexibility to group endpoints regardless of subnet

Subnet 10.41.41.0/24

Subnet 10.51.51.0/254

BRKACI-2301 121


ACI Logical Design – Single BD, two Base EPG

BD: ACME-BD10.41.41.254/24, advertise, share10.51.51.254/24, private, share

Base EPG1

Mapped to VMM DomainBase EPG2

Mapped to VMM and Physical Domain

• Subnet advertisement control: DB subnet not advertised

• EPG1 and EPG2 configured for IntraEPG-Isolation

• Proxy-ARP enabled

• No communication allowed in base EPGs

• Base EPG mapped to PHYSDOM and VMMDOM as required

BRKACI-2301 122


ACI Logical Design – uEPG to classify on IP Subnet


Base EPG1

Mapped to VMM DomainBase EPG2


• Create uEPG for each of the subnets (match on IP Subnet)

• Map EPGs to the corresponding VMM and PhysDoms

• Endpoints connected to EPG1 and EPG2 with IP address matching the subnets

will be placed in the correct uEPG have connectivity

• Endpoints with wrong IP address will have no connectivity at all

uEPG net-41

Match IP 10.41.41.0/24

Mapped to VMM

uEPG net-51

Match IP 10.51.51.0/24

Mapped to VMM & Phys

BRKACI-2301 123


ACI Logical Design - Details

N9K Leaf


Base EPG1 (isolated)

Mapped to VMM DomainBase EPG2 (isolated)


EPG2: vlan-1755 EPG2: vlan-1755VMware VDS

dvPortGroup EPG1 dvPortGroup EPG2

Consume Contract Provide

EPG1, EPG2 proxy-access

(icmp, tcp/3128)

ExternalAccess

(tn-common)

EPG1, EPG2 Ansible-Provisioning

(icmp, tcp/22)

AnsibleServer

(tn-common)

Contracts configured to allow

access to shared services from

base EPG.

Ansible Server

172.17.100.23

BRKACI-2301 124


ACI Logical Design - Details

N9K Leaf









(icmp, tcp/3128)

ExternalAccess

(tn-common)


(icmp, tcp/22)

AnsibleServer

(tn-common)

Contracts will allow our

provisioning system access to

endpoints on the base EPG.

Ansible Server

172.17.100.23

Isolated EPG block all other

communicationBRKACI-2301 125


ACI Logical Design – Details with uEPGs

N9K Leaf








EPG1, EPG2,

net-41, net-51

proxy-access

(icmp, tcp/3128)

ExternalAccess

(tn-common)

EPG1, EPG2,

net-41, net-51

Ansible-Provisioning

(icmp, tcp/22)

AnsibleServer

(tn-common)

uEPG net-41 uEPG net-51

web110.41.41.10

web110.41.41.10 Sql-01

10.51.51.12Sql-01

10.51.51.12

db110.51.51.10

db210.51.51.11



(icmp, tcp/3128)

ExternalAccess

(tn-common)


(icmp, tcp/22)

AnsibleServer

(tn-common)

BRKACI-2301 126


ACI Logical Design – Details with uEPGs

N9K Leaf








EPG1, EPG2,

net-41, net-51

proxy-access

(icmp, tcp/3128)

ExternalAccess

(tn-common)

EPG1, EPG2,

net-41, net-51


(icmp, tcp/22)

AnsibleServer

(tn-common)


web110.41.41.10

web110.41.41.10 Sql-01

10.51.51.12Sql-01

10.51.51.12

db110.51.51.10

db210.51.51.11

BRKACI-2301 127


ACI Logical Design – Classification done on IP, not PortGroup

N9K Leaf








EPG1, EPG2,

net-41, net-51

proxy-access

(icmp, tcp/3128)

ExternalAccess

(tn-common)

EPG1, EPG2,

net-41, net-51


(icmp, tcp/22)

AnsibleServer

(tn-common)


web110.41.41.10

web110.41.41.10 Sql-01

10.51.51.12Sql-01

10.51.51.12

db110.51.51.10

db210.51.51.11

uEPG configuration is not using

isolation. Traffic is allowed.

BRKACI-2301 128


DC1 DC2IP connectivity

vC

ente

r

Cluster-01

ACI Logical Design – Classification works across PODs


web110.41.41.10

web110.41.41.10

Sql-0110.51.51.12

Sql-0110.51.51.12

db110.51.51.10

db210.51.51.11

L2/L3


BRKACI-2301 129


Demo #1 Summary

• Decouple encapsulation configurations (Port-to-VLAN, PortGroup) from actual workload segmentation.

• Subnet-based segmentation with complete flexibility.

• Select entire subnets

• Select individual IPs, etc.

• Works across Bare Metal and Virtualization (VMware and Microsoft today)

• Combine with Contracts to provide distributed L3-4 Security


Video and Ansible playbooks for demo #1

• Ansible Playbooks:

https://goo.gl/M2fasN

• Demo Video:

https://youtu.be/sWZeeLDMkg4

BRKACI-2301 132

https://goo.gl/M2fasN

https://youtu.be/sWZeeLDMkg4

Demo #2Using VM Attributes, IP EPGs andAutomated deployments


Note: for this example we will use Ansible for automation.

Similar automation can be accomplished using other tools and/or a Cloud Management Platform.

BRKACI-2301 134


We will provision a simple PHP application that uses virtual machines

and bare metal servers.

BRKACI-2301 135


Acme’s Application

HTTP

HTTPS

SQL

Bare MetalVirtualized w/ VMware

HAProxy with Keepalived

CentOS running PHP App on

Apache

SQL DB Clustered


• FRONTEND and WEB Tiers run as VMs and share a subnet

• Traffic between FRONTEND and WEB must be filtered

• WEB applications require data from a DB running on a bare metal server

• White-List Model Approach to security (zero-trust)

Acme’s Application – Network Design

SERVER SUBNET

DB SUBNET

Physical SQL Databases

WEB APP FRONTEND

BRKACI-2301 137


Basic ACI Design Constructs – Objects shared from ’common’ tenant

Ansible Server

172.17.100.23

Squid-Proxy

5.0.7.249

L3Outtn-common

proxy-accessMyAcmeApp

External Access

0.0.0.0/0

Proxy-Access

5.0.7.249/32

We will use a Shared L3Out.

General EPG for default, specific

for restricting access to local

proxy or repo.

Global contracts from

tn-common to be

consumed by user

tenants.

Ansible-Provision

Exported Contract

Interface

(automatically enable

VRF-leaking)

BRKACI-2301 138


Basic ACI Design Constructs – AcmeTenant

BD: ACME-BD10.40.40.254/24, advertise, share

EPG: ServerNetwork (isolated)

Mapped to VMM DomainEPG: DBNetwork

Mapped to Physical Domain

BD: DB-BD10.50.50.254/24, private, share

BD: INFRA-BD10.30.30.254/24, private, share

Monitoring DHCP & DNS

tn-AcmeTenant

• Web and LB VMs

• Base EPG programmed with

IntraEPG Isolation.

• Mapped to VMM Domain to

creates dvPortgroup

• Physical Data Base Servers

• Base EPG programmed with

IntraEPG Isolation (if no

flooding required).

• Mapped to PhysDom and

static path or AEP

Common tenant

services


Basic ACI Design Constructs – AcmeTenant Base Contracts



• Exported from tn-common

• Consumed “Contract Interface”

from all tenant EPGs

• Allows tcp/22 and ICMP



• Exported from tn-common

• Consumed “Contract Interface”

from all tenant EPGs


• Global contract from tn-common

• Consumed by all EPGs



Demo Design – Lab Details

ACI Leaf

vPC Pairs

BRKACI-2301

VMware VDS (VMM-ACI-DC1)

vSphere

CLUSTER

DC1 – ACI POD1

Squid-Proxy

5.0.7.249

Ansible Server

172.17.100.23

143



ACI Leaf

vPC Pairs

BRKACI-2301


dvPortGroup ServerNetwork

vSphere

CLUSTER

DC1 – ACI POD1

Squid-Proxy

5.0.7.249

Ansible Server

172.17.100.23

144



ACI Leaf

vPC Pairs

BRKACI-2301



vSphere

CLUSTER

DC1 – ACI POD1

Squid-Proxy

5.0.7.249

Ansible Server

172.17.100.23

Proxy-Access

5.0.7.249/32

145


EPG: DBNetwork



ACI Leaf

vPC Pairs

BRKACI-2301



vSphere

CLUSTER

DC1 – ACI POD1

Squid-Proxy

5.0.7.249

Ansible Server

172.17.100.23

Proxy-Access

5.0.7.249/32

146


EPG: DBNetwork



Mapped to VMM Domain


ACI Leaf

vPC Pairs

BRKACI-2301



vSphere

CLUSTER

DC1 – ACI POD1

Squid-Proxy

5.0.7.249

Ansible Server

172.17.100.23

Proxy-Access

5.0.7.249/32

147


EPG: DBNetwork





ACI Leaf

vPC Pairs

BRKACI-2301



vSphere

CLUSTER

DC1 – ACI POD1

Squid-Proxy

5.0.7.249

Ansible Server

172.17.100.23

Proxy-Access

5.0.7.249/32

EPG Consume Contract EPG Provide

ServerNetwork

DBNetwork

proxy-access

(icmp, tcp/3128)

Proxy-Access

(tn-common)

ServerNetwork

DBNetwork


(icmp, tcp/22)

AnsibleServer

(tn-common)

ServerNetwork

DBNetwork

DNS

(udp/53, tcp/53)

DNS

ServerNetwork

DBNetwork

NAGIOS

(tcp/80, udp/162, udp/163)

Monitoring

148


EPG: DBNetwork





ACI Leaf

vPC Pairs

BRKACI-2301



vSphere

CLUSTER

DC1 – ACI POD1

Squid-Proxy

5.0.7.249

Ansible Server

172.17.100.23

Proxy-Access

5.0.7.249/32


ServerNetwork

DBNetwork

proxy-access

(icmp, tcp/3128)

Proxy-Access

(tn-common)

ServerNetwork

DBNetwork


(icmp, tcp/22)

AnsibleServer

(tn-common)

ServerNetwork

DBNetwork

DNS

(udp/53, tcp/53)

DNS

ServerNetwork

DBNetwork

NAGIOS

(tcp/80, udp/162, udp/163)

Monitoring

149


EPG: DBNetwork





ACI Leaf

vPC Pairs

BRKACI-2301



vSphere

CLUSTER

DC1 – ACI POD1

Squid-Proxy

5.0.7.249

Ansible Server

172.17.100.23

Proxy-Access

5.0.7.249/32


ServerNetwork

DBNetwork

proxy-access

(icmp, tcp/3128)

Proxy-Access

(tn-common)

ServerNetwork

DBNetwork


(icmp, tcp/22)

AnsibleServer

(tn-common)

ServerNetwork

DBNetwork

DNS

(udp/53, tcp/53)

DNS

ServerNetwork

DBNetwork

NAGIOS

(tcp/80, udp/162, udp/163)

Monitoring

150


Deploying the New Application - using uEPG to classify workloads (1/3)


tn-AcmeTenant

uEPG: FRONTENDMaster: ServerNetwork




tn-AcmeTenant


• Intra EPG Isolation Unenforced

• Contract Master: ServerNetwork

• Match Precedence: 100




tn-AcmeTenant





• Select based on VM name

• High match precedence to ensure

VM is not wrongly classified

elsewhere




tn-AcmeTenant


10.40.40.101 10.40.40.102




• Select based on VM name

• High match precedence to ensure

VM is not wrongly classified

elsewhere




tn-AcmeTenant





tn-AcmeTenant


uEPG: WEB-PRODMaster: ServerNetwork

• Intra EPG Isolation Enforced






tn-AcmeTenant






Classify a VM if it carries:

• app:myacmeapp

• tier: web

• env:prod

AND runs in VMM-ACI-DC1




tn-AcmeTenant






10.40.40.11 10.40.40.12 10.40.40.13

Classify a VM if it carries:

• app:myacmeapp

• tier: web

• env:prod

AND runs in VMM-ACI-DC1




tn-AcmeTenant


10.40.40.11 10.40.40.12 10.40.40.13



uEPG: DB-PRODMaster: DBNetwork

10.40.40.101 10.40.40.102




tn-AcmeTenant


10.40.40.11 10.40.40.12 10.40.40.13




10.40.40.101 10.40.40.102


• Contract Master: DBNetwork





tn-AcmeTenant


10.40.40.11 10.40.40.12 10.40.40.13




10.40.40.101 10.40.40.102







tn-AcmeTenant


10.40.40.11 10.40.40.12 10.40.40.13




10.40.40.101 10.40.40.102 10.50.50.200





Deploying the New Application - Leveraging Contract Inheritance

uEPGs configured to inherit

contracts from base EPG


Deploying the New Application - Application specific contracts

Restrict access as required for

each application tier


Deploying the New Application - Handling HAProxy Redundancy


10.40.40.101

• HAProxy redundancy using

KeepAlived

• VIP Address for the application

• Based on VRRP. Can work with

unicast or multicast.

• We will use unicast mode.

10.40.40.101

VIP - 10.40.40.110

- IntraEPG Contract:

allow IP protocol 112 (VRRP)

ACTIVE BACKUP



ACI Leaf

vPC Pairs

BRKACI-2301



vSphere

CLUSTER

DC1 – ACI POD1

Squid-Proxy

5.0.7.249

Ansible Server

172.17.100.23

External-Access

0.0.0.0/0

167


uEPG: DB-PROD


ACI Leaf

vPC Pairs

BRKACI-2301



vSphere

CLUSTER

DC1 – ACI POD1

Squid-Proxy

5.0.7.249

Ansible Server

172.17.100.23

External-Access

0.0.0.0/0

168


uEPG: DB-PROD


ACI Leaf

vPC Pairs

BRKACI-2301



vSphere

CLUSTER

DC1 – ACI POD1

Squid-Proxy

5.0.7.249

Ansible Server

172.17.100.23

External-Access

0.0.0.0/0

169


uEPG: FRONTEND

uEPG: DB-PROD


ACI Leaf

vPC Pairs

BRKACI-2301



vSphere

CLUSTER

DC1 – ACI POD1

Squid-Proxy

5.0.7.249

Ansible Server

172.17.100.23

External-Access

0.0.0.0/0

170


uEPG: FRONTEND uEPG: WEB-PROD

uEPG: DB-PROD


ACI Leaf

vPC Pairs

BRKACI-2301



vSphere

CLUSTER

DC1 – ACI POD1

Squid-Proxy

5.0.7.249

Ansible Server

172.17.100.23

External-Access

0.0.0.0/0

171



uEPG: DB-PROD


ACI Leaf

vPC Pairs

BRKACI-2301



vSphere

CLUSTER

DC1 – ACI POD1

Squid-Proxy

5.0.7.249

Ansible Server

172.17.100.23

External-Access

0.0.0.0/0

172



uEPG: DB-PROD


ACI Leaf

vPC Pairs

BRKACI-2301



vSphere

CLUSTER

DC1 – ACI POD1

Squid-Proxy

5.0.7.249

Ansible Server

172.17.100.23

External-Access

0.0.0.0/0


ExternalAccess

(tn-common)

MyAcmeApp

(icmp, tcp/80, tcp/443)

FRONTEND

ExternalAccess

(tn-common)

HAPROXY-STATS

(tcp/8181)

FRONTEND

FRONTEND KEEPALIVED-VRRP

(ip-112)

FRONTEND

FRONTEND HTTP

(tcp/80, icmp)

WEB-PROD

WEB-PROD MYSQL

(tcp/3306, icmp)

DB-PROD

173



uEPG: DB-PROD


ACI Leaf

vPC Pairs

BRKACI-2301



vSphere

CLUSTER

DC1 – ACI POD1

Squid-Proxy

5.0.7.249

Ansible Server

172.17.100.23

External-Access

0.0.0.0/0


ExternalAccess

(tn-common)

MyAcmeApp


FRONTEND

ExternalAccess

(tn-common)

HAPROXY-STATS

(tcp/8181)

FRONTEND


(ip-112)

FRONTEND

FRONTEND HTTP

(tcp/80, icmp)

WEB-PROD

WEB-PROD MYSQL

(tcp/3306, icmp)

DB-PROD

174



uEPG: DB-PROD


ACI Leaf

vPC Pairs

BRKACI-2301



vSphere

CLUSTER

DC1 – ACI POD1

Squid-Proxy

5.0.7.249

Ansible Server

172.17.100.23

External-Access

0.0.0.0/0


ExternalAccess

(tn-common)

MyAcmeApp


FRONTEND

ExternalAccess

(tn-common)

HAPROXY-STATS

(tcp/8181)

FRONTEND


(ip-112)

FRONTEND

FRONTEND HTTP

(tcp/80, icmp)

WEB-PROD

WEB-PROD MYSQL

(tcp/3306, icmp)

DB-PROD

175


vSphere

CLUSTER

DEV

DC2 – ACI POD2




177BRKACI-2301

Let’s see how this extends to more than one DC with Multi-POD

DC1 – ACI POD1

10.40.40.11 10.40.40.12 10.40.40.13

Proxy-Access

5.0.7.249/32



10.40.40.101 10.40.40.102

IP connectivity



vCenter-DC1 vCenter-DC2


vSphere

CLUSTER

DEV

DC2 – ACI POD2




178BRKACI-2301

We can launch VMs on DC2 that are connected to the same ServerNetwork, have same policies

DC1 – ACI POD1

10.40.40.11 10.40.40.12 10.40.40.13

Proxy-Access

5.0.7.249/32



10.40.40.101 10.40.40.102

IP connectivity






10.40.40.14

Ansible Server

172.17.100.23


vSphere

CLUSTER

DEV

DC2 – ACI POD2




179BRKACI-2301

We can create new uEPGs to allow specific policies for our development environment

DC1 – ACI POD1

10.40.40.11 10.40.40.12 10.40.40.13

Proxy-Access

5.0.7.249/32



10.40.40.101 10.40.40.102

IP connectivity




uEPG: WEB-DVMaster: ServerNetwork

10.40.40.14


vSphere

CLUSTER

DEV

DC2 – ACI POD2




180BRKACI-2301


DC1 – ACI POD1

10.40.40.11 10.40.40.12 10.40.40.13

Proxy-Access

5.0.7.249/32



10.40.40.101 10.40.40.102

IP connectivity





10.40.40.14


vSphere

CLUSTER

DEV

DC2 – ACI POD2




181BRKACI-2301


DC1 – ACI POD1

10.40.40.11 10.40.40.12 10.40.40.13

Proxy-Access

5.0.7.249/32



10.40.40.101 10.40.40.102

IP connectivity





10.40.40.14

• When development is completed,

we can “TAG” the VM to go in

production …


vSphere

CLUSTER

DEV

DC2 – ACI POD2




182BRKACI-2301

Promote workload into production by setting the right VM attributes and vMotion to right cluster

DC1 – ACI POD1

10.40.40.11 10.40.40.12 10.40.40.13

Proxy-Access

5.0.7.249/32



10.40.40.101 10.40.40.102

IP connectivity





10.40.40.14


vSphere

CLUSTER

DEV

DC2 – ACI POD2




183BRKACI-2301


DC1 – ACI POD1

10.40.40.11 10.40.40.12 10.40.40.13

Proxy-Access

5.0.7.249/32



10.40.40.101 10.40.40.102

IP connectivity





10.40.40.14


vSphere

CLUSTER

DEV

DC2 – ACI POD2




184BRKACI-2301


DC1 – ACI POD1

10.40.40.11 10.40.40.12 10.40.40.13

Proxy-Access

5.0.7.249/32



10.40.40.101 10.40.40.102

IP connectivity





10.40.40.14

When the VM has all correct attributes

AND moves to DC1, it goes into

production


vSphere

CLUSTER

DEV

DC2 – ACI POD2




185BRKACI-2301


DC1 – ACI POD1

10.40.40.11 10.40.40.12 10.40.40.13

Proxy-Access

5.0.7.249/32



10.40.40.101 10.40.40.102

IP connectivity





10.40.40.14

When the VM has all correct attributes

AND moves to DC1, it goes into

production

Load Balancer can be updated

by orchestrator and/or pull

endpoints from uEPG


Demo #2 Summary

Benefits of ACI Micro Segmentation Combined with Automation

• Leverage programmable network virtualization and policy to perform complete automation of application rollouts.

• Seamless segmentation for bare metal and virtual: no bottlenecks.

• Can use the automation tools of your choice. In the demo using open source Ansible.

• Orchestration layer needs minimal network knowledge.

• Works for Microsoft SCVMM, VMware vCenter and bare metal today

• Network Admin maintains full visibility.


Video and Ansible playbooks for demo #2

• Ansible Playbooks:

https://goo.gl/7zfiKd

• Demo Videos:

Video-01 - https://youtu.be/22zFTzKVPKc

Video-02 - https://youtu.be/FESF34J0ATs

Video-03 - https://youtu.be/q1u-uOKLhr4

BRKACI-2301 188

https://goo.gl/7zfiKd

https://youtu.be/22zFTzKVPKc

https://youtu.be/FESF34J0ATs

https://youtu.be/q1u-uOKLhr4

Reflect for a moment on how would you accomplish the same thing if running a

traditional network …


By using ACI, the Ansible playbook has no need to keep details of any rack, any

switch, any port, any VLAN, any IP Address …

BRKACI-2301 190


ACI enables micro segmentation that you can deploy in a gradual and

flexible way.

BRKACI-2301 191


Some people will do static configurations using the GUI or the

NX-OS CLI …

BRKACI-2301 192


… and others will use automation tools

BRKACI-2301 193


But you can certainly do a bit of both.

BRKACI-2301 194


Cisco Spark

Questions? Use Cisco Spark to communicate with the speaker after the session

1. Find this session in the Cisco Live Mobile App

2. Click “Join the Discussion”

3. Install Spark or go directly to the space

4. Enter messages/questions in the space

How

cs.co/ciscolivebot#BRKACI-2301


• Please complete your Online Session Evaluations after each session

• Complete 4 Session Evaluations & the Overall Conference Evaluation (available from Thursday) to receive your Cisco Live T-shirt

• All surveys can be completed via the Cisco Live Mobile App or the Communication Stations

Don’t forget: Cisco Live sessions will be available for viewing on-demand after the event at www.ciscolive.com/global/on-demand-library/.

Complete Your Online Session Evaluation

http://ciscolive.com/Online

http://www.ciscolive.com/global/on-demand-library/


Continue Your Education

• Demos in the Cisco campus

• Walk-in Self-Paced Labs

• Tech Circle

• Meet the Engineer 1:1 meetings

• Related sessions

198BRKACI-2301

Thank you

practical applications of - clnv.s3.amazonaws.com · epg, uepg, domain associations, contract...

Documents