CONFIGURING A P+V NETWORK FOR NEUTRON Big Switch Networks April, 2014.

CONFIGURING A P+V NETWORK FOR NEUTRON

Big Switch NetworksApril, 2014

MODERN NETWORKING: YOU ARE NEEDED

©2014 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL 3

AGENDA FOR TODAY

• Context: Modeling application connectivity in Nova vs Neutron• Big Switch P+V Fabric (lab release) moving parts• Hands-on 1: Configuring a P+V fabric from the CLI• Hands-on 2: Exploring the OpenStack integration• Advanced Topics• Next Steps

[Demo accounts available after the show at http://bsnlabs.bigswitch.com]

http://bsnlabs.bigswitch.com/



EVOLUTION OF NETWORK PROVISIONING

1993 2013

Terminal Protocol: Telnet Terminal Protocol: SSH


A MINDSET TRANSITION IN NETWORKINGMore change in the competitive frontier in last 2 years than previous 20 years

Speeds and feeds

Agility and automation

Ethernet, Fast Ethernet, Gigabit Ethernet, 10GE SDN Controllers, Fabrics, Linux Shells, Neutron

Do you ?


ANDROMEDA


A BRIEF HISTORY OF SDNJust entering the third inning

1) SDN for OpenFlow programming

2) SDN for vSwitch overlays

3) SDN for P+V Fabrics

We are here

http://ow.ly/wPu3T

(Help at: https://plus.google.com/hangouts/_/bigswitch.com/erik)

http://ow.ly/wPu3T

http://ow.ly/wPu3T

http://ow.ly/wPu3T

https://plus.google.com/hangouts/_/bigswitch.com/erik?hceid=ZXJpay5mcmVlbGFuZEBiaWdzd2l0Y2guY29t.tl7rspmb84krkojaogvc4j1qo4

https://plus.google.com/hangouts/_/bigswitch.com/erik?hceid=ZXJpay5mcmVlbGFuZEBiaWdzd2l0Y2guY29t.tl7rspmb84krkojaogvc4j1qo4

CONTEXT / DESIGN DECISIONS


NOVA NETWORKING AND NEUTRON IN CONTEXTApplication connectivity graph

WWWWWW

WWW

AppApp

DBDB

WWWApp

DBWWWApp

DB

WWWDB

WWWApp

DBWWW

WWW

TidyMosh Pit “Enterprise”

Threat isolation, fault isolation, troubleshoot-ability, compliance, implicit or explicit contract


NOVA NETWORKING AND NEUTRON IN CONTEXTEnforcing an application connectivity graph

WWWWWW

WWW

AppApp

DBDB

“Enterprise”Tools Frequently Available:

• Stateful firewalls

• Subnets / VLANs / Routes / ACLs

• Security Groups

• Host IP tables

Constraints Frequently Found:

• Organization demarc points

• Surrounding L2/L3 design

• Provisioning automate-ability

• Existing appliances

• …Intended as a sample of common cases, not an exhaustive list


NOVA NETWORKING AND NEUTRON IN CONTEXTCommon case Nova design, easily migrated to Neutron

WWWWWW

WWW

AppApp

DBDB

SG: Nova or Neutron Security Group, V/S: VLAN and Subnet

Public-facing VMs have 2nd IP address, afloating IP to public V/S

Each project gets one V/S (non-routable)

Each tier gets an SG w/ rules



Design considerations:

• Implementable with either Nova VLAN Mgr or Neutron

• L3 isolation of threats and faults

• Susceptible to classes of L2-based threats and faults (e.g. arp spoofing / snooping / storms)

• SGs are impractical to map to end points other than pairs of OpenStack VMs (LB, BM DB, Storage)

• Low effort to get going, but beware “enterprise” issues over time


NOVA UNDERLYING INFRASTRUCTURE VIEWCommon case Nova design, moving parts

Spine Switch/Router(static, all VLANs everywhere)

Nova Server (VLAN Mgr)

vSwitch / Host IP Tables

Leaf Switch/Router(static, all VLANs everywhere)

Nova common case design:• Provision a route-able north/south

VLAN (subnet used for floating IPs)• Provision non-routed tenant VLANs –

‘all VLANs everywhere’ design• Each project gets a VLAN and, if public

connectivity needed, floating IPs• Beware VLAN capacity limits


NOVA NETWORKING AND NEUTRON IN CONTEXTAdvanced “enterprise” case Neutron design

WWWWWW

WWW

AppApp

DBDB

Each tier gets a V/S



Design considerations:

• Neutron only (in practice)

• L2 and L3 isolation of threats and faults

• Simple to insert L3 services post deployment (next-hops)

• Maps to any kind of end point (OpenStack VMs, bare metal, LBs, FWs, etc.)

• Higher effort to get going, but maps to known “enterprise” practices over time

SG: Nova or Neutron Security Group, V/S: VLAN and SubnetNote: not mutually exclusive with SGsNote: often use floating IPs instead of routes for public connectivity

R

Each project gets a logical router with routes and ACLs


NOVA NETWORKING AND NEUTRON IN CONTEXTWhere and what is the logical router for each project?

• ML2-style systems: specified compute node(s) running OpenStack L3 agent

• Overlay/underlay systems (commercial) : distributed L3 agent enforced in the vSwitch and overlay gateways (VTEPs)

• Unified P+V fabrics (commercial): distributed L3 agent enforced in the vSwitch and physical fabric

SG: Nova or Neutron Security Group, V/S: VLAN and SubnetNote: not mutually exclusive with SGsNote: often use floating IPs instead of routes for public connectivity

R ?


ML2 UNDERLYING INFRASTRUCTURE VIEWCommon case ML2 design, moving parts

Spine Switch/Router(dynamic VLAN provisioning

and pruning)

Neutron Server w ML2 plug-in and

vendor DriverMechanism

vSwitchLeaf Switch/Router

(dynamic VLAN provisioning and pruning)

L3 Agent(w HA Proxy /

PaceMaker)


O/U UNDERLYING INFRASTRUCTURE VIEWCommon case O/U design, moving parts

Spine Switch/Router(static, all VLANs everywhere)

Neutron Server


(static, all VLANs everywhere)

L3 Agent

Overlay Controller (VMs or physical

appliance pair)

Overlay Gateway(aka VXLAN VTEP function)


P+V UNDERLYING INFRASTRUCTURE VIEWCommon case P+V design, moving parts

Spine Switch/Router(dynamic)

Neutron Server


(dynamic)

L3 Agent

P+V Controller (VMs or physical

appliance pair)

Overlay Gateway

BSN P+V CLOUD FABRIC INTRODUCTION


CLOUD FABRIC HARDWARE AND SOFTWAREBare Metal SDN

• Bare Metal Switch Hardware: The same hardware used by hyper scale data centers, purchased directly from OEM manufacturers

• Open Switch Hardware: Provided by Dell, a branded switch that ships with multiple OS options

• Switch Light SDN Switch OS, Switch Light vSwitch and SDN Controllers

• Different controllers for different uses (cloud fabric controller, monitoring fabric controller…)

• All configuration, software upgrades and the vast majority of troubleshooting happens on the controller to simplify everything

Bare Metal and Open Switch Hardware Switch Light and SDN Controllers


BSN P+V CLOUD FABRICMoving parts in an OpenStack deployment

Big Switch Controller (VMs or physical

appliance pair)

Switch Light OS on spine(2-6 40G bare metal switches)

Neutron Server

Switch Light vSwitch or OVS

Switch Light OS on leaf(10G/40G bare metal switches)


BSN CLOUD FABRIC

• Good for Nova: CLOS bandwidth scaling properties, provision every VLAN to every edge port with no performance penalty, centralized troubleshooting

• Good for Neutron: CLOS bandwidth scaling properties, physical leaf/spine and vSwitch provisioned through a unified controller, centralized troubleshooting, no o/u gateways, UI enhancements to simplify tenant provisioning and troubleshooting

HANDS ON, PART IBASIC INTRODUCTION

©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 25

START YOUR DEMO

Go ahead and start the demo.This button will launch some scripts and load the dashboard’s topology view. Once the topology appears take a moment to observe the different components of the topology.

Note: This demo features the manual configuration of BVS using the CLI. BVS can also be configured automatically with OpenStack. To get a glimpse of BVS automation with OpenStack click here.


CONNECTING TO YOUR CONTROLLER

Click on the topology’s BVS icon to launch the BVS CLI. This will launch a popup shell.

Go ahead and login with the credentials in your row on the sign up sheet.


GET COMFORTABLE

Drop into configuration mode and type “help” to bring up a list of all the commands the their descriptions. The BVS CLI is very intuitive. If you’re ever in doubt try using tab-complete or hitting “?” for available commands.


EXPLORING THE BASIC SHOW COMMANDS

Show switch

Show host

Show link


SHOW THE CURRENT CONFIGNote that the controller-node identifier is a dynamically generated value which can change between demos.

Note that there are three tenants that are created by automatically and can't be deleted - default, system and external.


EXPERIMENTING WITH THE REST API

Try turning on the REST API debugging feature so you can see the exact REST calls over the wire. Like the CLI, you too can make calls to the REST API. This gives you the powerful opportunity to write scripts against the API.

Turning off this feature is as easy as typing “no debug rest”.


LINUX SHELL

Other software can be loaded on to this basic linux image, and notice that linux monitoring / troubleshooting commands are available here. Use the exit command or Ctrl-D to exit from the linux shell and return to the CLI.


BASIC LINUX SHELL TOOLS WITHIN THE BVS CLI

Note that you can use some of the basic linux shell tools within the BVS CLI, most critically pipe, grep and concatenate. From within the CLI, access to the filesystem is limited (various security/permissions reasons) to a sandbox that is accessed using the "config://<filename>" convention. Output from there can be copied out to the controller filesystem as shown in the snippet below:


TESTING CONNECTIVITY

Hop back to the topology view and check out the VMs hanging off vSwitch11 and vSwitch12. Click on the server icon to hop into each VM’s cli or check their network device info. You will notice that VM1/2 sit in 10.0.1.0/24 while VM3 sits in 10.0.2.0/24, VM4/5 sit in 10.0.3.0/24 and VM6 sits in 10.0.4.0/24. Drop into VM1’s CLI and test connectivity to other VMs. VM1 should not be able to connect to any other VMs because it is in a different subnet.


LOOKING AT FLOWS ON THE CONTROLLER

Instead hop into VM2 and initiate an ongoing ping between VM2 and VM3. Then hop onto the BVS CLI and try typing “show switch all flow” for a view of all the flows on the network. You can get more granular by specifying a specific switch-alias as well.

You can also ask for more details about the flows. Apparently enough details that it won’t fit in one terminal line!

DISTRIBUTED INTRA-TENANT ROUTING


red-webred-app

Red Tenant

Inter VNS communication within the tenant via the Tenant Router Provide secure segmentation / Restriction via Router ACLs

VM1VM3 VM2

Tenant Virtual Router


EXPLORING BVS - CARVING UP L2 DOMAINS

CREATING YOUR FIRST TENANT:Set up a tenant called “red” with a “web” BVS (VM1, VM2) and an “app” BVS (VM3):

ip-10-164-58-91(config)# tenant red ip-10-164-58-91(config-tenant)# bvs-definition red-www ip-10-164-58-91(config-tenant-def-bvs)# interface-rule red-www-if1 ip-10-164-58-91(config-tenant-def-bvs-if-rule)# match ip 10.0.1.1/32 ip-10-164-58-91(config-tenant-def-bvs-if-rule)# exit ip-10-164-58-91(config-tenant-def-bvs)# interface-rule red-www-if2 ip-10-164-58-91(config-tenant-def-bvs-if-rule)# match ip 10.0.1.2/32 ip-10-164-58-91(config-tenant-def-bvs-if-rule)# exit ip-10-164-58-91(config-tenant-def-bvs)# exit ip-10-164-58-91(config-tenant)# bvs-definition red-app ip-10-164-58-91(config-tenant-def-bvs)# interface-rule red-app-if1 ip-10-164-58-91(config-tenant-def-bvs-if-rule)# match ip 10.0.2.3/32 ip-10-164-58-91(config-tenant-def-bvs-if-rule)# exit ip-10-164-58-91(config-tenant-def-bvs)#

Virtual Network Segments


DISTRIBUTED VIRTUAL ROUTING SERVICEConnecting VNSs

Each tenant is given its own virtual router, along with the special "system," "external" tenants and their virtual routers. The term "router" may be a bit of an aggrandizement, as the tenant's virtual router configuration is only used for packet forwarding purposes and is not intended to provide the services of a full fledged router (e.g. dhcp). However, it is intended to transparently act on the packet as either a router (gateway ARP replies and subsequent TTL decrement and MAC address swaps) or as an ethernet bridge. The gist is to allow a single way to configure connectivity between groups of hosts regardless of how those hosts' had their subnet boundaries originally configured.Create a route to connect red-www and red-app: First, let's ensure that red-www (VM1 and VM2) are currently not connected to red-app (VM3)


DISTRIBUTED VIRTUAL ROUTING SERVICEConnecting VNSs

Now configure the red tenant's router to connect red-www, red-app and the system tenant router (to be used later). Since the VMs are configured on the same L2 domain, no extra gateways are going to be needed so we can use the virtual router "shorthand" from within the red tenant submode.

ip-10-152-143-155(config)# tenant red ip-10-152-143-155(config-tenant)# router vrred ip-10-152-143-155(config-tenant-router)# interface vrred-www-if bvs red-www ip-10-152-143-155(config-tenant-router-intf)# exit ip-10-152-143-155(config-tenant-router)# interface vrred-app-if bvs red-app ip-10-152-143-155(config-tenant-router-intf)# exit ip-10-152-143-155(config-tenant-router)# interface vrred-vrsystem tenant system vrsystemip-10-152-143-155(config-tenant-router-intf)# exit ip-10-152-143-155(config-tenant-router)# route from bvs red-www to bvs red-app permit ip-10-152-143-155(config-tenant-router)# route from bvs red-app to bvs red-www permit ip-10-152-143-155(config-tenant-router)# exit ip-10-152-143-155(config-tenant)#

A virtual router routing rule can be specified by: • source: source can be one of the following: a specified

host, a ip subnet, a defined VNS, a defined tenant• destination: destination can also be one of the following: a

specified host, a ip subnet, a defined VNS, a defined tenant.

• next hop ip address: This is optional. Specifying a numerical next hop on a directly connected interface prevents the router from performing ARP on each destination address.

• outgoing interface: This is optional too. Specifying a directly connected outgoing interface forces the flow going through your planned route.

• action: permit or deny.


ADDING IP INTERFACES TO TENANT ROUTERWe can fix this by creating IP interfaces on the tenant router that it can route traffic.

ip-10-152-143-155(config)# tenant red ip-10-152-143-155(config-tenant)# router vrred ip-10-152-143-155(config-tenant-router)# interface vrred-www-if bvs red-www ip-10-152-143-155(config-tenant-router-intf)# ip 10.0.1.254/24 ip-10-152-143-155(config-tenant-router-intf)# exit ip-10-152-143-155(config-tenant-router)# interface vrred-app-if bvs red-app ip-10-152-143-155(config-tenant-router-intf)# ip 10.0.2.254/24 ip-10-152-143-155(config-tenant-router-intf)# exit ip-10-152-143-155(config-tenant-router)#

Now try pinging VM3 from VM1 and VM2 again… Success!


TEST PACKET IN

Let’s do a test packet in between VM1 and VM3 to understand what is going on here. Type “test packet-in src-host VM1 ether-type ip dst-host VM3”

Notice that there is now some information under “Virtual Routing Processing iterations”. You can find the source and destination BVS as well as the specific virtual router that handled the traffic between the two BVSs. Pretty cool.

HANDS ON, PART IIEXPLORING OPENSTACK INTEGRATION


INITIAL LOGIN TO THE DEMO

• Navigate to the demo hostname sent to you in your email. Append “bigdashboard” to the URL to access Big Switch’s plugin enabled OpenStack dashboard e.g. http://hostname/bigdashboard

• When prompted, login using the demo credentials sent to you in your email

http://hostname/bigdashboard


CREATE A TENANT USER AND PROJECT FOR THE USER

• Navigate to Admin> User • Click the top right hand button

“Create User” with following information:

User Name: TenantAPassword: bsn123Email: [email protected]

• Create a new Primary Project (Tenant) Project Name: ProjectA

1

2


LOGIN TO BIG DASHBOARD AS A TENANT USER

Logout and Log back in to the same URL with user created in previous step: http://hostname/bigdashboard You will only see the tenant level (Project A) resources with this TenantA login




START PROVISIONING NETWORKS

In this step, we will create three networks for “web”, “app”, and “db” tiers and assign them subnets 10.0.0.0/24 , 10.0.1.0/24, and 10.0.2.0/24 respectively.

Select Networks under Project > Manage NetworksOn the top right, Click “Create Network”

1

2


START PROVISIONING NETWORKS

Create the following 3 networks:

Network Name: “web”Subnet Name: “web”Network Address: “10.0.0.0/24 “

Network Name: “App”Subnet Name: “App”Network Address: “10.0.1.0/24 “

Network Name: “DB”Subnet Name: “DB”Network Address: “10.0.2.0/24 “Gateway IP: “10.0.2.1”

1

2


PROVISIONING NETWORKS

Your output should look like this after you are done with provisioning all the three networks.

Next Step is to create a tenant router for Inter-subnet routing.


PROVISIONING A ROUTER

Click on the “Routers” menu item under “Manage Networks”.

Click on the right top to create a new router

Router Name “TenantA-Router”.

Click on the router and you’ll find yourself in the router details page.

1

2

3


PROVISIONING ROUTER INTERFACES

As you can see there are no interfaces for this router. Click on the “Add Interfaces” button to begin adding interfaces. You will add three interfaces which are corresponding to the three Tenant subnets


PROVISIONING ROUTER INTERFACES

Select all the three interfaces one by one and add to the tenant router


PROVISIONING ROUTER INTERFACESOnce you are done adding all the three interfaces, verify the output under Routers > Interfaces tab.

Now, you should be able to communicate between the three subnets via the tenant router.

In next step, we will create virtual machine instances in each tier and test the routing functionality

DISTRIBUTED INTRA-TENANT ROUTING


AppWeb

TenantA

Web-001 DB-001

Tenant Virtual Router

AppApp-001

Big Switch Distributed Routing functionality provides distributing routing at each hypervisor level.

If two virtual machines communicating with each other whether they belong to same tenant or different tenant, routing happens local to the hypervisor host


LOOKING AT CONTROLLER CONFIG

In this step, we will log in to the BSN controller to find out what configuration has been pushed by OpenStack Plugin to configure Tenant Networks, Ports and Router. SSH to the Big Switch controller using the credentials provided to you. (ssh admin@BVS-Controller-IP). Once logged in, run the following commandShow run tenant “Tenant ID” -- Use the tab key to see all the available tenants To find out the Tenant ID on OpenStack, Navigate to Manage Networks > Networks > web

OpenStack ViewController CLI


LOOKING AT BSN CONTROLLER Interface ID on the OpenStack maps to BVS definition

Above steps involving BVS controller login was to show you the mapping between Openstack networking components to BVS controller


ISOLATING THE TIERS

The Big Switch OpenStack integration provides an easy way to enable network policy to restrict the communication among tenant network or communication of tenant networks to external networks. Navigate to the “Tenant A” router’s detailed page and click on the “Router Rules Grid” tab.

Note: This is a feature only available under “bigdashboard”.


ISOLATING THE TIERS

Disable communication between the database and the web tiers so that traffic must travel between the app tier to reach each tier.

With that done, go navigate back to the web virtual machines console and try to ping each virtual machine again.

NEXT STEPS


ADVANCED TOPICSAvailable in whitepapers or 1:1s with our field teams

• Designs for Nova and/or ML2• Configuring HA controller pairs and HA Neutron service pairs• Configuring ACLs in/out of critical infrastructure or bare metal hosts• Inserting an L3 service by using ‘next-hop’ on routing rules (e.g. stateful firewall in

between two tiers)• Configuring the ‘external’ tenant (demarc routers) – single and ecmp groups• Configuring dual homed hosts• Demonstrating multi-path across the fabric• Demonstrating resiliency against link failure, leaf failure, spine failure, controller

failure, control network failure• Demonstrating scale


NEXT STEPSWant to learn more?

• Demo accounts available at http://bsnlabs.bigswitch.com • Write to us at [email protected] • Write to me at [email protected]

• Or keep an eye out for announcements from us this summer


mailto:[email protected]

mailto:[email protected]

THANK YOU

CONFIGURING A P+V NETWORK FOR NEUTRON Big Switch Networks April, 2014.

Documents

Transcript of CONFIGURING A P+V NETWORK FOR NEUTRON Big Switch Networks April, 2014.