Playing With Your Traffic: Exploring the - Defined Packet Control Within the IETF Joe Clarke, Distinguished Services Engineer BRKSDN-3014 Abstract

This talk covers technology being discussed and developed within the Internet Engineering Task Force (IETF). It is not currently available in a Cisco product release. Software Defined Networking (SDN) combined with Network Function Virtualization (NFV) provide unprecedented programmatic access to drive networks in new and exciting ways. These capabilities lead to dynamic service creation, with Service Function Chaining (SFC) completing the programmable picture, creating a “whole stack” view. Service chaining realizes network virtualization, allowing network services to exchange metadata and be seamlessly deployed into the packet path independent of their physical location. Service chaining, and its underlying standards such as Network Service Header (NSH) offer a innovative way to "software define" packet processing.

This session will show the value of service creation and the power that software-defined packet processing can afford. This session will describe a journey that starts by looking at how to program devices and virtual services using both Service Function Chaining and the Network Service Header. Further, this session will explore details of how policy and declarative intent drives the creation of service chains. Examples will be shown on how to inspect traffic, manipulate packets, and inject new flows. This session will focus heavily on programming. Code examples will be provided for both the data path service set and Service Function Chaining to highlight the power both technologies can provide.

Attendees should have a background in programming prior to attending this talk.

3 Why Play With Your Traffic?

0101010010100101101110111010001000111100110101010101

4 Why Play With Your Traffic

0101010010100101101110111010001000111100110101010101

5 Agenda

• Introduction to Data Path Programming

• Understanding Service Function Chaining (SFC) and Network Service Header (NSH)

• Programming With SFC/NSH

• Example Use Cases

• Key Takeaways Control What Is Data Path Programming? Plane

• Device programmability has typically focused on the control plane of the device • CLI • SNMP Data • Embedded Event Manager App Plane • NETCONF

• Data path programmability opens application developers up to the packets flowing through the device

• Can come in various forms • Instructing hardware how to forward packets (e.g., OpenFlow) • Attaching applications to the packet path of the device • Operations, Administration, and Maintenance

7 Why Is Data Path Programming Interesting?

• Vendors do not always design for every use case and scenario

• Data path programming fills the gap by opening the network to all levels of customization

• Make the network more relevant to your business • Create specific optimizations • Deliver unique, customized traffic behavior • Build new network services

• Enable new network architectures using existing hardware • Cloud applications • Network Function Virtualization • Network visualizations and analytics

8 Who Does What? Applications

• There are a lot of APIs and abstractions flying around out Business or Tech Transitions there

• There are a number of components and solutions that exist at various layers to enable applications • Cisco’s APIC controllers • OpenDaylight • Service Function Chaining • Openflow

• Who does what and with what technology depends on the use case

• Today, Cisco is helping out customers and partners through Topology With SDN Service Provisioning DevNet explore and become comfortable with these technologies

• And in turn, partners are also helping their customers realize the power of a more programmable network

9 Service Function Chaining (SFC) & Network Service Header (NSH) What Is A Service?

• An application? • Web portal for managing your {internet,bank,wireless} account • A CRM system • A productivity suite • A collection of resources? • Database • Compute • Storage • A transit packet processor? • Firewall • Load balancer • NAT gateway • Video Optimizer

11 Chaining Services Together

• A Service Chain is an ordered graph of specific network service functions through which packets must flow

• E.g.: Firewall  NAT  Load Balancer

Service Chain

12 Service Chaining Today

• Services are built using rudimentary service chaining techniques; accomplished via hop-by-hop switching/routing changes • Leading to a dependencies between the network & service topologies • Very complex: VLAN-stitching, Policy Based Routing (PBR), Routing tricks, etc. • Static: no dynamic, horizontal or vertical scaling, and requires network changes • Service functions are deployed based on physical network topology and physical network elements • Changes to service functions or ordering within a service chain require network changes • Example: Firewalls typically require “in” & “out” layer-2 segments; adding new FW means adding new layer-2 segments to the network topology • Inhibits optimal use of service resources; limits scale, capacity & redundancy

VLAN 3110

VLAN 110 VLAN 110

13 SFC – Creating a Services-layer Ecosystem Explosion

Policy EP1 web, SSH, DNS EP4 Policy View EPG EPG EP2 Green Any Red EP3

POLICY VIEW EP1 EP4 Service View IP Network vFirewall IP Network EP2 EP3 SERVICE VIEW EP1 EP4 Virtual Topology IP Network vSwitch vSwitch IP Network EP2 EP3

VIRTUAL TOPOLOGY Firewall VM EP1 EP4 Physical Topology PHYSICAL IP Network Ethernet Switch IP Network EP2 EP3 TOPOLOGY Compute

0 0 0 0 75 25 75 25 75 25 75 25 50 50 50 50 Whole Stack for Services for WholeStack RESOURCEResource VIEW View CPU Throughput Memory Storage 14 SFC – Creating a Services-layer Ecosystem Explosion

Service Function Chaining

Full-Stack POLICY VIEW Open standards Open source (IETF, YANG, 3GPP) (ODL, OF, OVS)

SERVICE VIEW

VIRTUAL TOPOLOGY Multi-market industry, Customer Open PHYSICAL realizing NFV acceptance ecosystem TOPOLOGY and SDN

Whole Stack for Services for WholeStack RESOURCE VIEW

15 The “Big Idea”

“With a common Service Plane, service policies and context are end-to-end, and can leverage any transport.”

SF1 SF2 SF3 SF4 SF5 SF6

Any Transport Any Transport Any Transport Any Transport Any Transport

Carrier-E / Transport Public Cloud Biz CPE Edge DCI

Data Centers Peering

Internet DCI Hybrid Edge Cloud

Access Aggregation SP WAN Cloud The “Big Idea”

“With a common Service Plane, service policies and context are end-to-end, and can leverage any transport.”

Service Rich End-to-End Graphs Metadata Service Path

Policy distribution b/w and Policy Service Functions through NSH metadata Service creation through • Single FIB disposition based on graphs vs. linear Chains • Shares network and service context Service Path Index (SPI) Field • Ingress (e.g., VRF), • Tunnel encapsulation choices; • Support for all graph topologies classification/DPI, user/service (VXLAN-GPE, GRE, MPLS, etc.) • Collection of SFs form a graph context (e.g., Subscriber) consumed by services • NETCONF, YANG, GBP • Includes application-ID • OAM and Service Innovation Service Function Chaining Architecture High-level Component Structure

• Architecture components Service Chaining • Service Chaining Orchestration Orchestration • Define service chains & build service paths Control Plane • Control / Policy Planes • Instantiate service chains adhering to policy Policy Plane • Data Plane • Traffic steering & Metadata • Data plane architecture accessible through open APIs SF SF SF SF (Physical) (VM) (Physical) (VM)

Service Service Service Service

1 1 VLAN 1 1 VLAN

Service Function Service Service Function Service Forwarder (SFF) Forwarder (SFF)

Network Overlay (v)switch

(GRE, VXLAN, etc.) (v)switch Service Service Forwarding Classifier Forwarding Classifier

18 Service Function Chaining Terminology

• Service Classifier • Determines which traffic requires service and forms the logical start of a service path. • Service Function (SF) • Component used to provide some level of processing to received packets. • Service Function Forwarder (SFF) • Responsible for delivering traffic received from the network to one or more connected service functions according to information carried in the network service header as well as handling traffic coming back from the SF. • Service Path • A service path is the actual forwarding path used to realize a service chain • Think of service chain as an abstract “intent for packets”; the service path is the actual instantiation of the chain in the network. • Service Chain: Firewall  NAT  Load Balancer; Service Path: cl-fw1  cl-nat44  cl-iosslb

19 Evolving Service Chaining Example: Business Policy Drives Service Deployment INTERNET

• A service is rendered based on a business policy like …

• To all traffic between the Internet & web front end servers apply: Elastic SSL • De/Encryption with highest throughput / low latency and least $$ cost • Copy all “mobile” only transactions to a Big Data analytics system Elastic LB • Perform the copy at most optimal point ($$ cost & least latency impact) + WAF • Send all traffic through a load balancer/web application firewall

and IDS Elastic Copy • Additionally, deploy this policy with other features like: Elastic IDS • Service functions are both virtual and physical and vendor neutral Elastic • Compute & service elasticity; compute mobility Analytics

Elastic WEB FE

20 Service Function Chaining Network Service Header (NSH) 101 Network Service Header is a data-plane protocol that represents a service path in the network and provides a common service plane fully orchestrated top to bottom

• Two major components: path information and metadata IETF adopted protocol • Path information is akin to a subway map: it tells the packets where to go without requiring per flow configuration • Metadata is information about the packets, and can be used for policy • NSH is added to packet via a classifier • NSH is carried along the chain to services • Intermediate nodes do not need to be NSH aware • Non-NSH enabled services are supported

21 Network Service Header (NSH) The Missing Link To SFC

• A Network Service Header (NSH) contains metadata and service path information that is NSH added to a packet or frame and used to create a service plane. The packets and the NSH are then encapsulated in an outer header for transport.

Outer Encapsulation • More specifically NSH is composed of a 4-byte (GRE, VXLAN-GPE, …) base header, a 4-byte service path header, and four mandatory 4 byte context headers. Base Header • Base header: provides information about the service header and the payload Service Path Header • Service path header: provides path identification and location within a path Context Headers • Context headers: provide metadata that can be shared between network and service nodes Original Packet

22 The NSH From A CSR1Kv

GRE Encapsulation

Base Header

23 The NSH From A CSR1Kv

Service Path Header

24 The NSH From A CSR1Kv

Context Headers (Metadata)

25 The NSH From A CSR1Kv

Original Packet

26 But Sometimes More Is More

• The four 32-bit context headers really require one to think about what is absolutely needed to share between nodes and services

• But sometimes you need more • Mobility use cases want to transport IMEI and user info • Data Center use cases want to transport tenant and application information

• NSH allows for this with Type 2 variable length headers

27 Network Service Header (NSH) MD-Type 2 Format

0 1 2 3 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 0 0 0 0 Ver O C R R R R R R Length (6) MD Type 2 Next Protocol (8) Service Path Identifier (24) Service Index (8)

Optional Variable Length Context Headers

Original Packet Payload

0 1 2 3 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 0 0 0 0 TLV Class C Type R R R Length Variable Length Metadata

As many and as much as your use case requires 28 Service Function Chaining – Ecosystem

• Dedicated Service Function Chaining (SFC) Working Group in the Internet Engineering Task Force (IETF)

• Several vendors support this idea of Service Function Chaining with Network Service Header • Close to becoming a standard

• Hear ye, hear ye! Read all about it! • https://tools.ietf.org/html/rfc7498 (Problem Statement) • https://tools.ietf.org/html/rfc7665 (SFC Architecture) • https://tools.ietf.org/html/draft-ietf-sfc-nsh-01 (NSH)

29 Service Function Chaining – Ecosystem

30 The OpenDaylight Project

• An open source project formed by industry leaders and others under the Linux Foundation with the mutual goal of furthering the adoption and innovation of Software Defined Networking (SDN) through the creation of a common vendor supported framework.

• Focus: Customers with some programming resources that desire a free, community-supported SDN controller

• Downloads available from http://www.opendaylight.org

Platinum Gold Silver

31 OpenDaylight SDN Platform Linux Foundation Open Collaboration Source

SFC+NSH Software Network Defined Function Networking Virtualization Innovation

32 OpenDaylight SFC Implementation

▪ Released in Lithium, planning Beryllium

▪ Renderers: OVS, OF and REST

▪ Hackathon at IETF-92, 93, and 94

▪ GBP Integration.

▪ Application Identification, SFC , Reference Data plane, NSH client test tool, IPTables classifier. Opendaylight SFC Implementation

▪ Released in Lithium, planning Beryllium

▪ Renderers: OVS, OF and REST

▪ Hackathon at IETF-92, 93, and 94 sff_client.py --remote-sff-ip 10.0.1.41 --remote-sff-port 4789 --sfp-id 22 --sfp-index 255 --trace-req -- num▪-traceGBP-hops 3 Integration.

Sending Trace packet to Service Path and Service Index: (22, 255) Trace▪ response...Application Identification, SFC Traceroute, Reference Service-hop: 0. Service Type: dpi, Service Name: SF1, Address of Reporting SFF: ('10.0.1.41', 4789) Service-Datahop: 1. Serviceplane, Type: NSH firewall, client Service Name:test SF4, tool, Address IPTables of Reporting SFF:classifier. ('10.0.1.42', 4789) Service-hop: 2. Service Type: napt44, Service Name: SF5, Address of Reporting SFF: ('10.0.1.43', 4789) Trace end Group Based Policy (GBP)

• Policy is a top-level abstraction which ‘nodes’ are groups of endpoints and edges are the directional policy between them. • Policy specifies the semantic ‘what’ we want for network flows

35 Glossary SFC-GBP Integration Details EP - Endpoint NF - Network Function Policy SFC OpenDaylight 1. GBP defines policy:bar and Policy: actions. One of the actions is bar OpenStack “chain:foo” 2. GBP calls into SFC and asks for chain:foo SFC: 3. SFC creates the needed foo topology: OVS bridges and forwarding rules

4. SFC returns path-ID, starting EP A Infrastructure Network EP B index, first hop IP:port, and encapsulation to GBP 5. GBP creates the necessary classifier rules to direct

packets to the path and VNF1 NF2 VNF3 attach context headers (metadata) The ODL SFC Application

Service Chaining Orchestration

Control Plane

Policy Plane

SF SF SF SF (Physical) (VM) (Physical) (VM)

Service Service Service Service

1 1 VLAN 1 1 VLAN

Service Function Service Service Function Service Forwarder (SFF) Forwarder (SFF)

Network Overlay

(v)switch (v)switch Service Service Forwarding Classifier Forwarding Classifier

37 The ODL SFC Application

Service Chaining Orchestration

Control Plane

Policy Plane

• ODL contains an SFC application with: • REST API SF SF SF SF (Physical) (VM) (Physical) (VM)

• GUI Service Service Service Service 1 1 VLAN • YANG models 1 VLAN

Service Function Service Service Function Service • Includes a referenceForwarder (SFF) implementation Forwarder (SFF)

built on Python and using VXLANNetwork Overlay-GPE

(v)switch (v)switch Service Service for transport Forwarding Classifier Forwarding Classifier

38 Playing With ODL And SFC

• Download the DevNet VM from https://communities.cisco.com/community/ developer/dev-vm

• Follow the SFC wiki at https://wiki.opendaylight.org/view/Service_ Function_Chaining:Main to pull down the SFC module

• Play with the SFC REST API and GUI

39 Where Is SFC+NSH Supported?

• Almost all major Cisco platforms have a roadmap • ASR1K, ISR4400, CSR1Kv, ASR9K, Nexus 7K, Nexus 9K • Expect to see code releases this year that support SFC+NSH

• Services coming along, including 3rd parties • NBAR classification • Server Load Balancing • Firewalls

• Orchestration integration • APIC, OpenDaylight, Cisco Open SDN Controller

40 Why Is This Cool?

• SFC and NSH enable a more software-defined landscape by allowing service deployment to be fluid and independent of the network topology

• This is key in order to move from a purely physical network into network function virtualization (NfV) Today Tomorrow Physical appliances Virtual & physical appliances Static services Dynamic services Separate domains: physical vs. virtual Seamless physical & virtual interoperability Hop-by-hop service deployment Chain of “service functions” Underlay networks Dynamic overlay networks Topological dependent service insertion Insertion based on resources & scheduling No shared context Rich metadata Policy based on VLANs Policy based on metadata

41 How Does Data Path Programming Fit?

• The Data Path SF programming (VM) capabilities are being Service ported to use SFC and NSH for transport and SFC+NSH metadata exchange

Service Function

Forwarder (SFF) (v)switch

42 How Does Data Path Programming Fit?

• The Data Path SF Data(VM) Path programming Applications capabilities are being ServiceService ported to use SFC and NSH for transport and SFC+NSH metadata exchange

• This service becomes a service function into

which you can plug Service Function

your applications Forwarder (SFF) (v)switch

43 Programming With SFC+NSH Tapping Into The Service Path

CSR1Kv

GRE GRE

Service Function

45 Setting Up The Service Topology…Programmatically

• Given that SFC+NSH is industry-standard, there must be an industry-standard way to set up the service topology

• YANG+RESTCONF provides a way to configure devices using well-defined data models

• Instead of passing raw CLI, the modeled attributes can be sent using traditional REST calls

• YANG as a data modeling language is defined in RFC 6020

• RESTCONF is still being standardized in the IETF in draft-ietf-netconf-restconf- 09

46 Using RESTCONF To Program Devices

YANG interface model

TLS

https://tools.ietf.org/html/draft-ietf-netconf-restconf-07

47 Configuring The Service Path With RESTCONF Class Maps import requests url = "https://10.1.1.1:8888/api/running/native/class-map" payload = "{\r\n \"ned:class-map\": [\r\n {\r\n \"name\": \"http\",\r\n \"prematch\": \"match-all\",\r\n \"match\": {\r\n \"access-group\": {\r\n \"index\": 101\r\n },\r\n }\r\n },\r\n {\r\n \"name\": \"all-ip\",\r\n \"prematch\": \"match-all\",\r\n \"match\": {\r\n \"access- group\": {\r\n \"index\": 103\r\n }\r\n }\r\n },\r\n {\r\n \"name\": \"ssh\",\r\n \"prematch\": \"match-all\",\r\n \"match\": {\r\n \"access- group\": {\r\n \"index\": 102\r\n }\r\n }\r\n }\r\n ]\r\n}" headers = { 'authorization': "Basic amNsYXJrZTptb3J0YXgx", 'content-type': "application/vnd.yang.data+json", 'accept': "application/vnd.yang.collection+json", } response = requests.request("PATCH", url, data=payload, headers=headers) Configuring The Service Path With RESTCONF Class Maps import requests url = "https://10.1.1.1:8888/api/running/native/class-map" payload = "{\r\n \"ned:class-map\": [\r\n {\r\n \"name\": \"http\",\r\n \"prematch\": \"match-all\",\r\n \"match\": {\r\n \"access-group\": {\r\n \"index\": 101\r\n },\r\n }\r\n },\r\n {\r\n \"name\": \"all-ip\",\r\n \"prematch\": \"match-all\",\r\n \"match\": {\r\n \"access- group\": {\r\n \"index\": 103\r\n }\r\n }\r\n },\r\n {\r\n \"name\": \"ssh\",\r\n \"prematch\": \"match-all\",\r\n \"match\": {\r\n \"access- group\": {\r\n \"index\": 102\r\n }\r\n }\r\n }\r\n ]\r\n}" headers = { 'authorization': "Basic amNsYXJrZTptb3J0YXgx", 'content-type': "application/vnd.yang.data+json", 'accept': "application/vnd.yang.collection+json", } response = requests.request("PATCH", url, data=payload, headers=headers) Configuring The Service Path With RESTCONF Policy Map import requests url = "https://10.1.1.1:8888/api/running/native/policy-map" payload = "{\r\n\"ned:policy-map\": [\r\n {\r\n \"name\": \"sfc- pol\",\r\n \"type\": \"service-chain\",\r\n \"class\": [\r\n {\r\n \"name\": \"http\",\r\n \"action-list\": [\r\n {\r\n \"action-type\": \"forward\",\r\n \"forward\": {\r\n \"service-path\": [\r\n {\r\n \"service-path-id\": 1,\r\n \"service-index\": 3\r\n }\r\n ]\r\n }\r\n }\r\n ]\r\n }\r\n ]\r\n }\r\n ]\r\n}" headers = { 'authorization': "Basic amNsYXJrZTptb3J0YXgx", 'content-type': "application/vnd.yang.data+json", 'accept': "application/vnd.yang.collection+json", } response = requests.request("PATCH", url, data=payload, headers=headers) Configuring The Service Path With RESTCONF Policy Map import requests url = "https://10.1.1.1:8888/api/running/native/policy-map" payload = "{\r\n\"ned:policy-map\": [\r\n {\r\n \"name\": \"sfc- pol\",\r\n \"type\": \"service-chain\",\r\n \"class\": [\r\n {\r\n \"name\": \"http\",\r\n \"action-list\": [\r\n {\r\n \"action-type\": \"forward\",\r\n \"forward\": {\r\n \"service-path\": [\r\n {\r\n \"service-path-id\": 1,\r\n \"service-index\": 3\r\n }\r\n ]\r\n }\r\n }\r\n ]\r\n }\r\n ]\r\n }\r\n ]\r\n}" headers = { 'authorization': "Basic amNsYXJrZTptb3J0YXgx", 'content-type': "application/vnd.yang.data+json", 'accept': "application/vnd.yang.collection+json", } response = requests.request("PATCH", url, data=payload, headers=headers) Configuring The Service Path With RESTCONF Service Function import requests url = "https://10.1.1.1:8888/api/running/native/service-chain" payload = "{\r\n \"service-chain\": {\r\n \"service-function\": [\r\n {\r\n \"name\": \"service1\",\r\n \"config-service-chain-sf-mode\": {\r\n \"description\": \"Service-Function-1\",\r\n \"encapsulation\": {\r\n \"gre\": {\r\n \"enhanced\": \"divert\"\r\n }\r\n },\r\n \"ip\": {\r\n \"address\": \"192.168.1.4\" \r\n \r\n }\r\n }\r\n }\r\n ]\r\n }\r\n}" headers = { 'authorization': "Basic amNsYXJrZTptb3J0YXgx", 'content-type': "application/vnd.yang.data+json", 'accept': "application/vnd.yang.data+json", } response = requests.request("PATCH", url, data=payload, headers=headers) Configuring The Service Path With RESTCONF Service Function import requests url = "https://10.1.1.1:8888/api/running/native/service-chain" payload = "{\r\n \"service-chain\": {\r\n \"service-function\": [\r\n {\r\n \"name\": \"service1\",\r\n \"config-service-chain-sf-mode\": {\r\n \"description\": \"Service-Function-1\",\r\n \"encapsulation\": {\r\n \"gre\": {\r\n \"enhanced\": \"divert\"\r\n }\r\n },\r\n \"ip\": {\r\n \"address\": \"192.168.1.4\" \r\n \r\n }\r\n }\r\n }\r\n ]\r\n }\r\n}" headers = { 'authorization': "Basic amNsYXJrZTptb3J0YXgx", 'content-type': "application/vnd.yang.data+json", 'accept': "application/vnd.yang.data+json", } response = requests.request("PATCH", url, data=payload, headers=headers) Configuring The Service Path With RESTCONF Service Function Path import requests url = "https://10.1.1.1:8888/api/running/native/service-chain" payload = "{\r\n \"service-chain\": {\r\n \"service-path\": [ \r\n {\r\n \"service-path-id\": \"1\",\r\n \"config-service-chain-path-mode\": {\r\n \"description\": \"Service-Chain-1\",\r\n \"service-index\": [\r\n {\r\n \"services\": {\r\n \"service-index-id\": \"3\",\r\n \"service-function\": \"service1\"\r\n }\r\n },\r\n {\r\n \"services\": {\r\n \"service-index-id\": \"2\",\r\n \"terminate\": {}\r\n }\r\n }\r\n ]\r\n }\r\n }\r\n ]\r\n }\r\n}\r\n" headers = { 'authorization': "Basic amNsYXJrZTptb3J0YXgx", 'content-type': "application/vnd.yang.data+json", 'accept': "application/vnd.yang.data+json”, } response = requests.request("PATCH", url, data=payload, headers=headers) Configuring The Service Path With RESTCONF Service Function Path import requests url = "https://10.1.1.1:8888/api/running/native/service-chain" payload = "{\r\n \"service-chain\": {\r\n \"service-path\": [ \r\n {\r\n \"service-path-id\": \"1\",\r\n \"config-service-chain-path-mode\": {\r\n \"description\": \"Service-Chain-1\",\r\n \"service-index\": [\r\n {\r\n \"services\": {\r\n \"service-index-id\": \"3\",\r\n \"service-function\": \"service1\"\r\n }\r\n },\r\n {\r\n \"services\": {\r\n \"service-index-id\": \"2\",\r\n \"terminate\": {}\r\n }\r\n }\r\n ]\r\n }\r\n }\r\n ]\r\n }\r\n}\r\n" headers = { 'authorization': "Basic amNsYXJrZTptb3J0YXgx", 'content-type': "application/vnd.yang.data+json", 'accept': "application/vnd.yang.data+json”, } response = requests.request("PATCH", url, data=payload, headers=headers) Classifier Configuration class-map match-all http Match all HTTP match access-group 101 class-map match-all all-ip (access-list 101 match access-group 103 permit tcp any any eq class-map match-all ssh www) Insert matched traffic match access-group 102 into service chain 1 ! and index 2 policy-map type service-chain sfc-pol class http forward service-path 1 service-index 3 ! Our service chain service-chain service-function service1 consists of one description Service-Function-1 service at 192.168.1.4 ip address 192.168.1.4 encapsulation gre enhanced divert ! service-chain service-path 1 description Service-Chain-1 service-index 3 service-function service1 service-index 2 terminate

56 Our Service Function

• We are essentially building our own SF right now

• We handle terminating the GRE and processing the encapsulated traffic • We’re free to get creative in our language choice 

• Service function is a Python script that runs on Linux

• We use the Python pcapy module from http://corelabs.coresecurity.com/index.php?action=view&type=tool&name= y

• GRE packets from the CSR are read using libpcap

57 Service Function Code def main(argv): if len(argv) < 1: print "Please specify a device on which to capture." sys.exit(1)

dev = argv[1]

print "Capturing on dev " + dev myip = commands.getoutput("/sbin/ifconfig " + dev).split("\n")[1].split()[1][5:]

tap = pcapy.open_live(dev, 65536, 0, 100) tap.setfilter("src not " + myip)

while (1): try: (hdr, pkt) = tap.next() Open a pcap live capture session, except socket.timeout: continue filtering on incoming packets. else: parse_incoming(pkt)

58 Service Function Code (cont.) … if iproto == socket.IPPROTO_GRE: # GRE header: If the packet is GRE, then parse the # Flags : 1 byte # Reserved Version : 1 byte GRE header to see if we have an NSH. # Protocol : 2 bytes # # NSH: # Version, OC bit, length : 2 bytes # MD Type : 1 byte # Next Protocol : 1 byte # Path ID : 3 bytes # Hop Index : 1 byte # Context Headers : 4 * 4 bytes = 16 bytes (for Type 1) gend = glen + ipend gpkt = pkt[ipend:gend]

ghdr = unpack("BBH", gpkt) gproto = socket.ntohs(ghdr[2]) …

59 Service Function Code (cont.)

… if frag_off == 0 and gproto == GREPROTO_NSH: print "Received GRE-encapsulated NSH packet from " + src_addr + " to " + dst_addr

nshend = nshlen + gend nshpkt = pkt[gend:nshend] Print the NSH base nsh = unpack("=HBBBBBBLLLL", nshpkt) and service path pathid = (nsh[3] << 16) + (nsh[4] << 8) + (nsh[5]) fields hop = nsh[6]

print " NSH Header Type : " + str(nsh[1]) print " Encapsulated Protocol : " + str(nsh[2]) If we have an Dive into the print " NSH Path ID : " + str(pathid) print " NSH Hop Index : " + str(hop) NSH Type 1, encapsulated packet if nsh[1] == 1: print the context if it’s IP print " NSH Context Header 0 : " + str(socket.ntohl(nsh[7])) print " NSH Context Header 1 : " + str(socket.ntohl(nsh[8])) headers print " NSH Context Header 2 : " + str(socket.ntohl(nsh[9])) print " NSH Context Header 3 : " + str(socket.ntohl(nsh[10])) if nsh[2] == NSH_IPV4: print "=== Parsing inner packet ===" parse_incoming(pkt[:elen] + pkt[nshend:], True)

…

60 Service Function Code (cont.)

Decrement the NSH We have to return the packet for the hop index original flow to continue.

… hop = hop - 1

new_nsh = pack("=HBBBBBBLLLL", nsh[0], nsh[1], nsh[2], nsh[3], nsh[4], nsh[5], hop, nsh[7], nsh[8], nsh[9], nsh[10]) pkt = pkt[:gend] + new_nsh + pkt[nshend:]

return_packet(iphdr, pkt) Create a new NSH … header and stick it into the packet; then send it on its way

61 Create a new IP Service Function Code (cont.) header reversing source and destination addresses def return_packet(iph, pkt): new_iph = pack("BBHHHBBH4s4s", iph[0], iph[1], iph[2], iph[3], iph[4], iph[5], iph[6], 0, iph[9], iph[8])

pkt = new_iph + pkt[ipend:]

s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_RAW) s.sendto(pkt, (socket.inet_ntoa(iph[8]), 0))

Send the packet from whence it came using a raw socket

62 Service Function Code (cont.) If we get an encapsulated TCP packet, decode it, printing the payload if we have one. elif iproto == socket.IPPROTO_TCP: if do_print: print "TCP packet from " + src_addr + " to " + dst_addr tcpend = ipend + tcplen tcppkt = pkt[ipend:tcpend] tcphdr = unpack("=HHLLBBHHH", tcppkt)

if do_print: print " Src Port: " + str(socket.ntohs(tcphdr[0])) print " Dst Port: " + str(socket.ntohs(tcphdr[1]))

offset = tcphdr[4] >> 4 dstart = elen + iplen + (offset * 4)

if len(pkt) > dstart: if do_print: print " Packet data: " print " '" + pkt[dstart:] + "'"

63

Why Wasn’t All The Payload Printed?

• We only matched on traffic destined to TCP port 80

• We can apply classification in both directions if we want

• Let’s match the return traffic as well, and see how the app behaves access-list 101 permit tcp any any eq www access-list 101 permit tcp any eq www any

65 66 Sharing Metadata With NSH With Metadata Sharing Function Service Index Index 4

GRE

CSR1Kv Metadata GRE

GRE

Function

Service Index Index 3 GRE 67 Classifier Configuration class-map match-all http match access-group 101 Match all HTTP(S) class-map match-all all-ip match access-group 103 traffic on ports 80, class-map match-all ssh 443, and 8080 Insert matched traffic match access-group 102 into service chain 1 ! policy-map type service-chain sfc-pol and index 3 class http forward service-path 1 service-index 4 ! service-chain service-function service1 Our service chain description Service-Function-1 now consists of two ip address 192.168.1.4 encapsulation gre enhanced divert service at ! 192.168.1.232 and service-chain service-function service2 192.168.1.4 description Service-Function-2 ip address 192.168.1.232 encapsulation gre enhanced divert ! service-chain service-path 1 description Service-Chain-1 service-index 4 service-function service2

service-index 3 service-function service1 68 service-index 2 terminate Our Service Functions

• The first SF is an adaptation of our trusty Python script • Sets a value of “80” in NSH Type 1 context header 4 (Shared Service Context) • Decrements service index by 1 on matching traffic • Sets service index to 1 on other traffic

• The second SF checks the metadata in the Type 1 context headers • It will dissect the traffic only if context header 4 is set to 80 • Saves expensive inspection of uninteresting traffic

• Think back to being able to determine mobile traffic, then steer that to an analytics SF

69 Service Function Index 3 Code Building off of our previous Python Service Function script…

…

res = parse_incoming(pkt[:elen] + pkt[nshend:], False)

if res == 80: If it’s clear text HTTP, hop = hop - 1 send it to the next SF Test the packet else: and set context hop = 1 metadata accordingly.

context_header4 = socket.htonl(res)

new_nsh = pack("=HBBBBBBLLLL", nsh[0], nsh[1], nsh[2], nsh[3], nsh[4], nsh[5], hop, nsh[7], nsh[8], nsh[9], context_header4)

70 Service Function Index 3 Code (cont.)

… elif iproto == socket.IPPROTO_TCP: … if dst_port == 80 or dst_port == 8080 or src_port == 80 or src_port == 8080: return 80

Return a value to set in the NSH context header

71 72 Example Use Cases SFC+NSH Dump Packets For

• Take the encapsulated packet obtained from GRE packet and it them to a PCAP file

• Run wireshark in a way so that it streams the contents of the file • tail -f -c +0b FILENAME.pcap | wireshark –k –i –

• This is an easier way of tying SFC+NSH to wireshark without modifying the wireshark code

74 The PCAP Code from scapy.all import Ether from scapy.utils import PcapWriter … def main(argv): … pcapfile = PcapWriter("nsh.pcap", append=True, sync=True) … if frag_off == 0 and gproto == GREPROTO_NSH: … scapyPkt = Ether(_pkt=pkt[:elen] + pkt[nshend:]) pcapfile.write(scapyPkt)

Again, we’ll take our Python script and use the scapy Python module to write the encapsulated frame out to a file. Only those frames with NSH will be written.

75 76 SFC+NSH: Classifying Traffic

• The encapsulated packets can also be changed

• Let’s say we want to mark our HTTP traffic with the DSCP value of Assured Forwarding 41

• Modify the Python script to rewrite the inner IP header with the new ToS byte

• We can also pass that same information in an NSH context header

77 Modifying DSCP Code from scapy.utils import checksum … IPTOS_DSCP_AF41 = 0x88 … if nsh[2] == NSH_IPV4: context_header4 = socket.htonl(IPTOS_DSCP_AF41) … new_nsh = pack("=HBBBBBBLLLL", nsh[0], nsh[1], nsh[2], nsh[3], nsh[4], nsh[5], hop, nsh[7], nsh[8], nsh[9], context_header4)

Add our new DSCP value to the NSH, which makes it easier for other services to know the desired code point value.

78 Modifying DSCP Code (cont.) Set the ToS byte to the desired code point and elif iproto == socket.IPPROTO_TCP: recalculate the IP checksum … if do_print: new_iph = pack("BBHHHBBH4s4s", iphdr[0], IPTOS_DSCP_AF41, iphdr[2], iphdr[3], iphdr[4], iphdr[5], iphdr[6], 0, iphdr[8], iphdr[9]) cksum = checksum(new_iph) new_iph = pack("BBHHHBBH4s4s", iphdr[0], IPTOS_DSCP_AF41, iphdr[2], iphdr[3], iphdr[4], iphdr[5], iphdr[6], socket.htons(cksum), iphdr[8], iphdr[9]) return new_iph + pkt[ipend:]

Add the new IP header to the packet, and return it for re-

encapsulation. 79 Modifying DSCP: The Results

Without the app running…

80 Modifying DSCP: The Results (cont.)

…Now with the app running

81 Now It’s Your Turn! Where To Go Now

• Go to the DevNet Zone to see more about device and network programmability.

• Download the OpenDaylight suite from https://www.opendaylight.org/downloads or the DevNet VM from https://communities.cisco.com/community/developer/dev-vm

• Read the SFC wiki at https://wiki.opendaylight.org/view/Service_Function_Chaining:Main to get started with SFC+NSH within ODL

• Start to prototype applications that take advantage of software-defined packet control

83 SDN @ CiscoLive

• Recommended Learning Path on SDN http://www.ciscolive.com/emea/ • 60+ Sessions • Technical Seminars • Breakout Sessions • Hands-on Labs • Panel Discussion

• DevNet Zone

• Demos, MTE, Lunch&Learn, Use Filters in Content Catalog Whisper Suites,and more .... https://cisco.rainfocus.com/scripts/catalog/cleu16.jsp Enterprise SDN @ CiscoLive Monday Advanced APIC Enterprise Module: SDN Controller for the Campus and Branch - TECSDN-3600 Monday Enterprise SDN: Architectures and Key Concepts - TECSDN-2602 Monday Enterprise SDN: Advanced Network Programming - Hands-On Lab TECSDN-3602 Tuesday APIC-EM: Controller Workflow and Use Cases - BRKARC-3004 Tuesday IWAN management via APIC-EM (SDN Controller) - BRKSDN-2099 Tuesday CCIE Skill Transformation to SDN Kungfu Master - BRKSDN-4005 Wednesday SDN Enabled QoS-A Deep Dive - BRKSDN-2046 Wednesday Hitchhiker's Guide to Device APIs - BRKSDN-1119 Wednesday Containers on routers and switches: Run your apps and tools natively on Cisco boxes - BRKSDN-2116 Wednesday Cisco Application Policy Infrastructure Controller Enterprise Module (APIC-EM) – Hands on Lab - LTRSDN-1914 Thursday APIC-EM: The evolution from traditional management to SDN-led, policy-based automation - BRKNMS-2031 Thursday Cisco Open SDN Controller Hands-on Lab - LTRSDN-1913 Thursday Deploying Cisco IOS Autonomic Networking Infrastructure - BRKSDN-2047 DNS-AS: Done with SDN and Tired of Dealing with Snowflake Network Complexity? Thursday Change the Game with a Simple TXT String! - BRKSDN-3004 Friday Solutions Enablement by Cisco Open SDN Controller - BRKSDN-1020

More SDN Sessions in the Recommended Learning Path85 DevNet @ CiscoLive

• DevNet Zone https://developer.cisco.com/site/DevNetZone/ • Listed in Content Catalog • Multiple EN SDN and DevOps related: • APIC-EM • Open Service-Containers • Analytics • NeXt • DNA • Discuss with the Experts face-2-face • Lots of Hands-on

86 Enterprise SDN @ CiscoLive

Cisco Live Berlin Preview: Key Innovations in Enterprise Software BRKSDN-CL001

Preview Webcast in December 2015  Recording / Slides available from https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=88347 https://cisco.jiveon.com/docs/DOC-689325

87 Beyond CiscoLive

• DevNet and DevNet Express Events https://developer.cisco.com/site/devnet/events-contests/events/

• EMEAR Enterprise SDN Master Class Starting in spring 2015

• EMEAR Enterprise SDN Partner QuickBet Engage via your local Blackbelt and/or us

• DevNet, dCloud and cisco.com devnet.cisco.com, https://devnet.cisco.com/site/apic-em , www.cisco.com/go/apicem What Solutions Will You Build With

89 Thank you