1

MANAGING INFRASTRUCTURE WITH APPLICATION POLICY

Mike Cohen Director of Product Management, Cisco

2

PROBLEMS TODAY IN NETWORKING •  Networks today are high touch, micromanaged

environments

•  Network configuration is an “art” completely divorced from the desired intent of the app developer!

•  Causes huge problems in scaling, coping with failures, and interoperability

•  SDN to date has not fixed this problem

3

TWO OPERATIONAL MODELS Imperative Control

Elem

ents  

Control  System  

Admin  

“Deploy  Applica-on  X”  

“Trunk  vlan”  

“Configure  acl”  

“Add  route  …”  

Manager  pushes  configura-on  changes  to  

devices.      “Let  my  web  servers  talk  to  my  app  servers”  

“Allow  Host  A  to  talk  to  Host  B”  

“Will  Do”  

Applicable  changes  made  

Faults  

Declarative Control

4

COMPARISON TO THE SERVER WORLD – DEVOPS! •  The DevOps movement is largely

based on Declarative Policy!

•  Millions of servers are managed in a highly scalable manner

•  Time of the network to catch up!

DevOps

LAMP Stack Java App Servers

MySQL Servers

5

COMPARISON TO TRADITIONAL SDN

Elem

ents  

Control  System  

Admin  

Policy Mgr

Control + Data Plane

APIC SDN Controller

Policy Mgr + Control Plane

Data Plane

OpenFlow + OVSDB Protocols TBD…

Imperative Control Declarative Control

6

ADVANTAGES OF DECLARATIVE MANAGEMENT Declarative management (ie. Promise Theory) is the voluntary cooperation of individuals or agents who publish their intentions via commitments to each other.

How do we represent our declarations / policy?

Key Advantages include: Scalability Simple, abstract way of managing

infrastructure Resiliency Promise interfaces provide an easy

way to cope with failures Interoperability Device complexity / versions is

hidden from users and control software

Ease of use Self-documenting, easily automated policies

Elem

ents  

Control  System  

Admin  

“Let  my  web  servers  talk  to  my  app  servers”  

“Allow  Host  A  to  talk  to  Host  B”  

“Will  Do”  

Applicable  changes  made  

Faults  

Declarative Control

7

POLICY

8

WHAT IS POLICY?

Cloud Management

System

User Intent

Operational Requirements

Infrastructure Capabilities

State of the System

Challenge: How to capture user intent through a policy abstraction!

9

I can speak french

I can talk about bees

Vous me rappelez des abeilles! Blah blah blah.

? subject

subject

…

contract

EPG

EPG

I Invoke you!

taboo

taboo

Providers Consumers

cont

ract

Peers Peers

Simple provider-consumer or client-server relationship governed by contract. Or symmetric peer-to-peer relationship like in a cluster.

10

appl

icat

ion

More than just a VM

Interconnected components

VM

VM

…

web

VM

VM

…

app

VM

VM

…

db internet

External Private Network

? App Tiers/Components

each is a collection of end-points with semantically identical properties

protected by contract membrane

WHAT IS AN APPLICATION?

11

à A compute, storage or service instance attaching to a fabric

NIC

vNIC

IP MAC Linux Container Namespace

end-points [ EP ]

à Things that connect to the fabric and use it to interface with other things

Network

NETWORK ENDPOINTS

12

à A compute, storage or service instance attaching to a fabric

EP

.

.

.

A collection of end-points with identical network behavior form a …

à Things that connect to the fabric and use it to interface with other things

EP EP … end-point group [ EPG ]

All EPs share common properties à  Connectivity à  Security/Access control à  QoS à  Services à  …

NETWORK ENDPOINTS

13

EP

.

.

.

EP EP

… end-point group [ EPG ]

All EPs share common properties à  Connectivity à  Security/Access control à  QoS à  Services à  …

Can flexibly map into à  application tier of multi-tier app à  segmentation construct (ala VLAN) à  a security construct à  ESX port group à …

Allows to specify rules and policies on groups of physical or virtual end-points without understanding of specific identifiers and regardless of physical location.

GROUP WEB

GROUP APP SERVER

policies

ENDPOINT GROUPS

14

EP

.

.

.

EP EP

GROUP WEB

GROUP APP SERVER

contract provider

consumer

Allows to specify rules and policies on groups of physical or virtual end-points without understanding of specific identifiers and regardless of physical location.

… …

…

filter action

filter action

filter action

filter action

identifies subject to which actions will be applied L4 port ranges TCP options …

identifies actions applied to the subject QoS Log Redirect into SVC graph …

End points in group WEB can access end-points in group APP SERVER according to rules specified in the contract

defined bi-directionally in the “provider” centric way

CONTRACTS

15

EXAMPLE: THREE-TIER APP

Group WEB Group APP Group DB

NW Public

NW Private

subnet

subnet

provide

provide

provide

provide provide provide

infra shared services

consume consume consume

L3 context Bridge domain Bridge Domain Bridge Domain

web contract

java contract

sql contract

mgmt contract

Outside consume consume

consume

16

ACTIVITIES IN THE OPEN SOURCE COMMUNITY

17

Network

Cloud Orchestration

Hypervisor / vSwitch

OVERVIEW – DRIVING OPEN SOURCE POLICY

Physical Network

•  Neutron API for app centric policy •  Future extensions to Heat / Nova / Horizon

Application centric policy management through an open source software stack

•  Policy API support / extensions •  Policy enforcement modules •  Service redirection

APP CENTRIC POLICY MODEL

APIC

18

GROUP-BASED POLICY IN OPENSTACK

Merchant Silicon OpenFlow

Software Overlay Etc.

ACI Fabric Compute Networking Storage

Dashboard Automation

Group-Based Policy Model Extensions (ACI-compatible)

GROUP POLICY MODEL

19

GROUP POLICY IN OPEN DAYLIGHT

Openflow, 3rd party switches, …

ACI Fabric

Group Policy REST API

Affinity “Native” OpenFlow

Project currently in “Incubation” Status in ODL. See: https://wiki.opendaylight.org/view/Project_Proposals:Application_Policy_Plugin

20

DATA MODEL

21

OPEN DAYLIGHT ARCHITECTURE

22

CISCO ACI

23

OPEN RESTFUL APIS CENTRALIZED POLICY MODEL

OPEN SOURCE

CONTROLLER

APIC

ACI BUILDING BLOCKS NEXT GENERATION NEXUS—TRADITIONAL NETWORKS

POLICY MODEL

ACI

BUILT-IN LINE RATE END POINT DIRECTORY

INTEGRATED OVERLAY 40G NON-BLOCKING FABRIC

SIMPLE, SECURE

>_ >_

50% SIMPLER CODE BASE

FUTURE PROOF UPGRADABLE

TO ACI

PROGRAMMABILITY AND AUTOMATION

NETWORK VIRTUALIZATION

SUPPORT

RESILIENCY: IN SERVICE PATCHING,

UPGRADE, FAST RESTART

ACI BUILDING BLOCKS FUTURE PROOF—SOFTWARE UPGRADABLE TO ACI

NEXUS 9500 and 9300 INNOVATIONS IN SOFTWARE HARDWARE AND SYSTEM DESIGN

PRICE POWER EFFICIENCY PROGRAMMABILITY PORT DENSITY PERFORMANCE

OPTIMIZED NX-OS SCALE OUT WITHOUT COMPROMISE COMMON BUILDING BLOCKS - ACCESS AND CORE

APIC

24

SYSTEMS TELEMETRY

ACI: RAPID DEPLOYMENT OF APPLICATIONS ONTO NETWORKS WITH SCALE, SECURITY AND FULL VISIBILITY

ENABLED BY PHYSICAL AND VIRTUAL INTEGRATION

TENANT HEALTH SCORE

LATENCY

VISIBILITY

VMs

Physical

Application Delivery Controller Firewall

Microsecond(s) 3

35

2

Packet Drops 0

SYSTEMS TELEMETRY

APPLICATION HEALTH SCORE

LATENCY

VISIBILITY

VMs

Physical

Application Delivery Controller Firewall

Microsecond(s) 5

16

8

Packet Drops 25

Physical Networking

L4–L7 Services

Multi DC WAN and Cloud

Compute Storage Hypervisors and Virtual Networking

25

REST API

ACI OPEN APIS AND ECOSYSTEM

NORTHBOUND PROGRAMMABILITY LAYER

Automation Enterprise Monitoring

Systems Management

Orchestration Frameworks

APIC

APIC SUPPORTS A RICH ECOSYSTEM BUILT AROUND OPEN NORTHBOUND AND SOUTHBOUND APIS

SOUTHBOUND PROGRAMMABILITY LAYER Fabric-attached Device API L4-7 Orchestration Scripting API

OVM

Hypervisor Management

26

HYPERVISOR SWITCH •  Develop extensions to Open vSwitch to support:

1.  Policy enforcement

2.  Service Redirection

3.  Linux containers

4.  Stateful services

27

APPENDIX

28

SERVICE INSERTION contract

Subject A

Subject B

Subject C

filter action

filter action

filter action

…

subj

ect

prio svc graph …

Service Graph Definition

term

in

out

term

out

in

FW SLB

Automatically derives parameters from EP, EPG, Tenant –level information

29

MULTIPLE CONTRACTS

EP

.

.

.

EP EP

EPG WEB

EPG APP SERVER

web contract

provider

consumer

ssh contract mgmt contract

EPs in EPG WEB can access EPs in EPG APP SERVER on subjects (L4 ports) specified in this contract, subjected to actions in this contract

EPs in EPG WEB can NOT access EPs in EPG APP SERVER on subjects (L4 ports) specified in these contracts

à Explicit white-list like model for specifying rules between groups

30

NW Internet

Outside

NW Intranet

web contract

http

https

ftp

EPG WEB For Internet

provide consume

consume EPG WEB For Intranet

provide

EPG Label Allows to chose a group of EPGs behind the contract

“NW Internet” can only access “EPG WEB For Internet”

“NW Intranet” can access both “EPG WEB For Internet” and “EPG WEB For Internet”

EPG CONSUMPTION LABELS

31

NW Internet

Outside

NW Intranet

web contract

http

https

ftp

EPG WEB For Internet

provide

consume

consume EPG WEB For Intranet

provide

Subject Label For a providing EPG, allows selection of supported subjects in the contract

“EPG WEB For Internet” only provides “https”

“EPG WEB For Intranet” provides “http”, “https” and “ftp”

SUBJECT LABELS

32

WHY IS NETWORKING SO HARD? à the rest is path optimization

A B

YES You can talk about this: { subject*, L4 Ports, … }

à End point A can talk to end point B

C D

NO You can’t

à End point C can’t talk to end point D