You can keep your firewall (if you want to) Practical, simple and cost saving applications of OpenDaylight you can implement today

66  Download (0)

Full text


“You can keep your firewall (if you

want to)”

Practical, simple and cost saving applications of OpenDaylight you can implement today


What You Will Learn today (By Demonstration)

• 10,000 Foot Views of Software Defined Networking (SDN), OpenDaylight (ODL) and Service Function Chains (SFC)

• Solve real world data center problems with ODL


• ODL Service Function Chaining

• Feel free to contact me for any details I don't cover here


Top three emerging technologies of the decade?

My take…

Big Data



“Is SDN Hype?”

• “Big Data and DevOps have clear applications and use cases but Software Defined Networks appears to be a

solution in search of a problem.”

• “Most SDN activity is focused in Academia or dedicated ‘Network Function Virtualization (NFV)’ shops... not relevant to us.”

• "SDN/ NFV only applies to Greenfield Architectures."


“Who cares about networks?”


“Latency and Loss doesn’t apply to my Data Center”

• “Latency and Loss? I've got dozens of 10GbE ports!!!”

• Layer 2: Spanning tree protocol

• Blocks all but one path to prevent loops

• (Enable LACP/ LAG)

• Layer 3: Shortest path first

• Sends all traffic through a congested "one hop" path over a wide open "two hop" path

• (Try Traffic Engineering)

• Layer 4: Default TCP buffers

• Small buffers mean more round trips. Latency throttles throughput.


What are Network Services?

• Familiar Network Services

• Load Balancing

• Firewall

• Deep Packet Inspection (DPI)

• Access Control Lists

• Parental Control

• Other Network Services

• "Global State" (Routing)

• Broadcast Domain Scoping (VLAN)


10,000 Foot Overview

• 10,000 Foot view of SDN

• At any give time, use a centralized controller to move data through your network equipment as you see fit

• Doesn't seem like a big deal to non-network types but this is incredibly powerful!

• 10,000 Foot view of OpenDaylight

• Allows you to install network services as "Apps"

• Provides a single REST API to configure heterogeneous hardware

• This is a “no brainer” for developers but is HUGE for network engineers

• 10,000 Foot view of Service Function Chains

• “Service Overlay”


A Little More Detail: SDN Layers

• Top Layer  Northbound

• Network Apps & Orchestration

• Business logic to monitor and control network behavior

• Thread services together

• Middle Layer  Controller Platform

• Exposes "Northbound" APIs to the Application layer

• Lower Layer  Southbound


A Little More Detail: OpenDaylight

• OpenDaylight

• Open source project

• Modular/ Pluggable and flexible controller platform

• Java Virtual Machine (JVM)

• Dynamically Pluggable Modules for Network Tasks

• OSGi framework (local applications)/ bidirectional REST (local or remote) for the northbound API

• Network Apps

• House business logic and algorithms

• Gather network intelligence from the controler

• Run algorithms to perform analytics

• Orchestrate new rules (if any) via controller

• Southbound


A Little More Detail: SFC

SFC enables a “service topology”

Overlay built “on top” of existing network topology

Use any overlay or underlay technology to create service paths


SFC provides resources for consumption

Service Topology connects those resources

Quickly/ Easily add new service functions


One Caveat Before we begin

• WARNING: Software Defined Networking is incredibly powerful!

• You must protect your Southbound interfaces with the same regard as a firewall or any root privileges • ODL accommodates TLS for Southbound interfaces

• The security, identity and bureaucratic planes are orthogonal to the technology plane we discuss here • We do not discuss security, identity or policy but you must consider them when architecting your ODL


One more Caveat

• WARNING: If you are not a hands-on network engineer, this presentation may "spoil" you.

• To provide the following two OPSCON using legacy protocols may be impossible and at the very least requires intense, disciplined, meticulous network engineering.


DPI Bypass


OPSCON #1: Deep Packet Inspection Bypass

This scenario investigates how to reduce latency

• You have a data center that performs deep packet inspection (DPI) for inter-network flows

• DPI injects latency into the end to end (E2E) flow and increases Round Trip Time (RTT)



• Network gateways in Firewall/ DPI appliance

• VLAN steer (bent pipe) traffic through DPI (via gateways) for inter-network flows • Can we create logic to DPI only once?


One Approach

Put logic (i.e. rules) in the DPI appliance to bypass certain flows

This, however consumes resources and can saturate the backplane


Better Approach

Use the OpenDaylight controller and put logic in the switch!


DPI Bypass Demo

Approach #1: RESTCONF API


Step 1: Start ODL Platform via Client

Platform includes controller


Validate Topology


Baseline: Two DPI = Severe Latency

Ping from Client (h1) to Server (h3) shows 40+ ms latency

mininet> h1 ping h3 PING ( 56(84) bytes of data. 64 bytes from icmp_seq=1 ttl=62 time=42.1 ms

64 bytes from icmp_seq=2 ttl=62 time=41.3 ms 64 bytes from icmp_seq=3 ttl=62 time=41.1 ms ^C

--- ping statistics ---


Baseline: End to End (E2E) Path

Traceroute shows a path through the two DPI gateways, as expected

mininet> h1 traceroute -n h3

traceroute to (, 30 hops max, 60 byte packets 1 21.180 ms 21.028 ms 20.837 ms

2 42.565 ms 42.482 ms 42.418 ms 3 * * 43.144 ms


Configure Switch via ODL Platform REST API

• Use these headers:

Accept: application/xml

Authorization: Basic YWRtaW46YWRtaW4=

• Then post the following flows (next slide) to Switch 2's table zero:

PUT flow with ID 202 to


PUT flow with ID 303 to



The Switch Accepts the Flows

$ sudo ovs-ofctl -O OpenFlow13 dump-flows s2

cookie=0x0, duration=350.260s, table=0, n_packets=0, n_bytes=0,

priority=200,ip,nw_dst= actions=set_field:f6:2f:25:06:ab:27->eth_dst,output:4

cookie=0x1, duration=33.552s, table=0, n_packets=0, n_bytes=0,

priority=200,ip,nw_dst= actions=set_field:f2:3e:8d:a4:71:07->eth_dst,output:5


Latency Reduced

Ping now shows that the second, slow DPI is no longer in the path:

mininet> h1 ping h3

PING ( 56(84) bytes of data.

64 bytes from icmp_seq=1 ttl=63 time=21.3 ms 64 bytes from icmp_seq=2 ttl=63 time=20.9 ms 64 bytes from icmp_seq=3 ttl=63 time=20.7 ms ^C


Latency Reduced

Traceroute Confirms that the flow bypasses the second DPI

mininet> h1 traceroute -n h3

traceroute to (, 30 hops max, 60 byte packets 1 21.117 ms 20.796 ms 20.423 ms


DPI Bypass Demo


SFC Approach: Create a “Service Overlay”

1. Register Firewalls in service pool

• “Service Functions”

2. Configure switches to forward

packets based on controller logic

• “Service Function Forwarders”

3. Configure SFC Logic

• … Next Slide



SFC Workflow (Highly Abstracted!)

Register (Previous Slide)

• Service Functions (Appliances) -- AKA Network Services

• Service Function Forwarders (ODL SFC Controlled Switches)

Create Service Function “Chains”

• “Chain” of Network Services

• I.e. First Firewall, then Apply Parental Control, then Virus Scan etc.

Create Service Function Paths and Rendered Service Paths

• Selects path through actual appliance (SF) instances e.g.

• RSP-1 = Firewall-1, Parental-Control-1, Virus-Scan-1

• RSP-7 = Firewall-3, Patental-Control-1, Virus-Scan-2

Create “Classifier”


DPI Bypass Demo

Approach #2: ODL SFC




Configure via REST API


• GUI Populated

• Controller then injects logic into SFF via flows

$ sudo ovs-ofctl dump-flows sff1 -OOpenFlow13


Test 1: Configure Classifier to Use RSP-1


shows WGET goes

through both service functions

Total time: 0.341 seconds


Test 2: Configure Classifier to Use RSP-3


shows WGET goes

through only one service


Total time: 0.178 seconds

SFF-1: No




Egress Bypass


OPSCON #2: Bypass DPI on Egress

• Scenario: You have a product distribution system where Egress throughput >> Ingress throughput.

• You perform Deep Packet Inspection on flows between External (EXT) hosts and your Demilitarized Zone (DMZ) Proxies.



• You implement a DPI "router on a stick," to ensure Inter-network communications pass through the DPI. • A switch bent pipes the traffic at layer 2



The Egress traffic will increase past the capacity of the DPI appliance

You realize that there are cheaper methods of securing your egress flows then upgrading


Egress Security

• With egress flows you want to ensure that return/ ACK traffic does not include exploits and that egress flows do not facilitate zombies or phone home exploits.

• Some ideas:

• Ensure only approved ports

• Access Control Lists

• iptables

• Host firewalls

• Mitigate against malicious code over approved ports:

• HIDS on Servers


Trade Solutions

• END GOAL: You want to have DPI inspection on ingress flows, but not egress, since the other security measures will cover the egress flows.

• One approach is to put logic on your DPI appliance to say "don't scan egress flows," but that wastes capacity/ resources and could saturate the backplane

• An approach with legacy Network protocols is very difficult to implement and results in asymmetric routes (will break things)


The Goal

When EXT initiates, pass through DPI

When DMZ initiates:

• Bypass DPI on PUT (Egress)


Detailed Diagram

1. ACL

2. Scan all EXT


3. Bypass DMZ PUT

4. Scan DMZ GET


OpenFlow Logic

1. ACL only allows permitted flows

2. For Ingress ( EXT-> DMZ ) flows, allow normal path to virus scan via gateway 3. For Egress ( DMZ -> EXT ) PUT flows, intercept packet

1. Change destination MAC from Gateway to EXT 2. Change destination Port from Gateway to EXT 3. Decrement TTL by one

4. For Egress (DMZ -> EXT) GET flows (Treat as ingress) 1. DMZ uses dummy IP for EXT server

2. Switch intercepts packet



Note: This will be a real time demo




Baseline: Push a file from DMZ to EXT

mininet> dmz curl --upload-file test.txt

• EXT Server Shows Successful PUT - - [10/Jul/2015 14:50:22] "PUT /test.txt HTTP/1.1"


Install the Flows via RESTCONF API

Either via POSTMAN or CURL

curl -v -H "Content-Type: application/xml" -X PUT --data "@fw_demo_404.xml" -u admin:admin

http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:3/table/0/flow/404 2>&1 | grep HTTP/1.1 curl -v -H "Content-Type: application/xml" -X PUT --data "@fw_demo_505.xml" -u admin:admin

http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:3/table/0/flow/505 2>&1 | grep HTTP/1.1 curl -v -H "Content-Type: application/xml" -X PUT --data "@fw_demo_606.xml" -u admin:admin

http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:3/table/0/flow/606 2>&1 | grep HTTP/1.1 curl -v -H "Content-Type: application/xml" -X PUT --data "@fw_demo_707.xml" -u admin:admin

http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:3/table/0/flow/707 2>&1 | grep HTTP/1.1 curl -v -H "Content-Type: application/xml" -X PUT --data "@fw_demo_808.xml" -u admin:admin

http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:3/table/0/flow/808 2>&1 | grep HTTP/1.1 curl -v -H "Content-Type: application/xml" -X PUT --data "@fw_demo_909.xml" -u admin:admin


DMZ PUT a file to EXT

mininet> dmz curl --upload-file test.txt

• The EXT server shows this second, successful put - - [10/Jul/2015 14:50:22] "PUT /test.txt HTTP/1.1" 200 - - - [10/Jul/2015 14:53:05] "PUT /test.txt HTTP/1.1" 200 -


Plumb Statistics via API

• You can see a Match on the flow through the REST API:



Test DMZ to EXT GET (Ingress)

• Use a Dummy IP to trigger a flow match.

• The egress port of the switch will NAT it back to the real destination IP.


EXT Server Shows Successful Get - - [10/Jul/2015 14:50:22] "PUT /test.txt

HTTP/1.1" 200 - - - [10/Jul/2015 14:53:05] "PUT /test.txt

HTTP/1.1" 200 -


Verify All EXT

DMZ Traffic Scan





Related subjects :