CONFIGURING A P+V NETWORK FOR
NEUTRON
Big Switch Networks
April, 2014
MODERN NETWORKING:
YOU ARE NEEDED
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]
©2014 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL
3
EVOLUTION OF NETWORK PROVISIONING
1993
2013
Terminal Protocol: Telnet
©2014 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL
Terminal Protocol: SSH
4
A MINDSET TRANSITION IN NETWORKING
More 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
©2014 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL
5
Do you
?
ANDROMEDA
©2014 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL
7
A BRIEF HISTORY OF SDN
Just entering the third inning
2) SDN for
vSwitch
overlays
1) SDN for
OpenFlow
programming
©2014 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL
We are here
3) SDN for P+V Fabrics
8
http://ow.ly/wPu3T
(Help at: https://plus.google.com/hangouts/_/bigswitch.com/erik)
CONTEXT / DESIGN DECISIONS
NOVA NETWORKING AND NEUTRON IN CONTEXT
Application connectivity graph
Mosh Pit
WWW
App
WWW
WWW
WWW
Tidy
WWW
DB
App
“Enterprise”
DB
WWW
WWW
WWW
WWW
DB
App
DB
App
App
Threat isolation, fault isolation, troubleshoot-ability, compliance,
implicit or explicit contract
©2014 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL
DB
DB
11
NOVA NETWORKING AND NEUTRON IN CONTEXT
Enforcing an application connectivity graph
Tools Frequently
Available:
Constraints Frequently
Found:
• Stateful firewalls
• Organization demarc
points
• Subnets / VLANs /
Routes / ACLs
• Security Groups
• Host IP tables
• Surrounding L2/L3
design
• Provisioning automateability
“Enterprise”
WWW
WWW
WWW
App
App
• Existing appliances
• …
DB
DB
Intended as a sample of common cases, not an exhaustive list
©2014 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL
12
NOVA NETWORKING AND NEUTRON IN CONTEXT
Common case Nova design, easily migrated to Neutron
Design considerations:
Public-facing VMs have 2nd IP address, a
floating IP to public V/S
•
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
WWW
WWW
WWW
Each tier gets an SG w/ rules
App
App
Each tier gets an SG w/ rules
DB
DB
Each tier gets an SG w/ rules
Each project gets one V/S (non-routable)
SG: Nova or Neutron Security Group, V/S: VLAN and Subnet
©2014 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL
13
NOVA UNDERLYING INFRASTRUCTURE VIEW
Common case Nova design, moving parts
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
Leaf Switch/Router
(static, all VLANs everywhere)
vSwitch /
Host IP Tables
Nova Server
(VLAN Mgr)
Spine Switch/Router
(static, all VLANs everywhere)
©2014 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL
14
NOVA NETWORKING AND NEUTRON IN CONTEXT
Advanced “enterprise” case Neutron design
Design considerations:
WWW
WWW
WWW
Each tier gets a V/S
R
App
•
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
App
Each tier gets a V/S
Each project
gets a logical
router with
routes and
ACLs
DB
DB
Each tier gets a V/S
SG: Nova or Neutron Security Group, V/S: VLAN and Subnet
Note: not mutually exclusive with SGs
Note: often use floating IPs instead of routes for public connectivity
©2014 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL
15
NOVA NETWORKING AND NEUTRON IN CONTEXT
Where and what is the logical router for each project?
• ML2-style systems: specified
compute node(s) running
OpenStack L3 agent
R ?
• 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 Subnet
Note: not mutually exclusive with SGs
Note: often use floating IPs instead of routes for public connectivity
©2014 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL
16
ML2 UNDERLYING INFRASTRUCTURE VIEW
Common case ML2 design, moving parts
L3 Agent
Leaf Switch/Router
(dynamic VLAN provisioning
and pruning)
(w HA Proxy /
PaceMaker)
vSwitch
Neutron Server w
ML2 plug-in and
vendor
DriverMechanism
Spine Switch/Router
(dynamic VLAN provisioning
and pruning)
©2014 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL
17
O/U UNDERLYING INFRASTRUCTURE VIEW
Common case O/U design, moving parts
Leaf Switch/Router
(static, all VLANs everywhere)
L3 Agent
vSwitch
Overlay Gateway
(aka VXLAN VTEP function)
Overlay Controller
(VMs or physical
appliance pair)
Neutron Server
Spine Switch/Router
(static, all VLANs everywhere)
©2014 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL
18
P+V UNDERLYING INFRASTRUCTURE VIEW
Common case P+V design, moving parts
Leaf Switch/Router
(dynamic)
L3 Agent
vSwitch
Overlay Gateway
P+V Controller
(VMs or physical
appliance pair)
Neutron Server
Spine Switch/Router
(dynamic)
©2014 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL
19
BSN P+V CLOUD FABRIC INTRODUCTION
CLOUD FABRIC HARDWARE AND SOFTWARE
Bare Metal SDN
Bare Metal and Open Switch Hardware
•
•
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
©2014 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL
Switch Light and SDN Controllers
•
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
21
BSN P+V CLOUD FABRIC
Moving parts in an OpenStack deployment
Switch Light OS on leaf
(10G/40G bare metal switches)
Switch Light vSwitch or
OVS
Big Switch Controller
(VMs or physical
appliance pair)
Neutron Server
Switch Light OS on spine
(2-6 40G bare metal switches)
©2014 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL
22
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
©2014 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL
23
HANDS ON, PART I
BASIC INTRODUCTION
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.
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
25
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.
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
26
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.
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
27
EXPLORING THE BASIC SHOW COMMANDS
Show switch
Show host
Show link
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
28
SHOW THE CURRENT CONFIG
Note 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.
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
29
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”.
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
30
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.
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
31
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:
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
32
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.
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
33
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 switchalias as well.
You can also ask for more details about the flows. Apparently enough details that it won’t fit in one terminal line!
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
34
DISTRIBUTED INTRA-TENANT ROUTING

Inter VNS communication within the tenant via the Tenant Router

Provide secure segmentation / Restriction via Router ACLs
Tenant Virtual
Router
VM3
VM2
red-app
red-web
VM1
Red Tenant
©2013 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
35
EXPLORING BVS - CARVING UP L2 DOMAINS
Virtual Network Segments
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)#
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
36
DISTRIBUTED VIRTUAL ROUTING SERVICE
Connecting 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)
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
37
DISTRIBUTED VIRTUAL ROUTING SERVICE
Connecting 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 vrsystem
ip-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)#
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
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.
38
ADDING IP INTERFACES TO TENANT ROUTER
We 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!
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
39
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.
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
40
HANDS ON, PART II
EXPLORING 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
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
42
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: TenantA
Password: bsn123
Email: TenantA@bigswitch.com
• Create a new Primary Project
(Tenant) Project Name: ProjectA
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
43
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/bigdashb
oard
You will only see the
tenant level (Project A)
resources with this
TenantA login
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
44
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
Networks
On the top right, Click
“Create Network”
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
45
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”
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
46
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 Intersubnet routing.
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
47
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.
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
48
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
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
49
PROVISIONING ROUTER INTERFACES
Select all the three
interfaces one by one
and add to the tenant
router
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
50
PROVISIONING ROUTER INTERFACES
Once 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
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
51
DISTRIBUTED INTRA-TENANT ROUTING
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
©2013 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
TenantA
Tenant Virtual
Router
Web-001
Web
App
App
DB-001
App-001
52
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-ControllerIP). Once logged in, run the following command
Show 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
Controller CLI
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
OpenStack View
53
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
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
54
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”.
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
55
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.
©2012 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM
56
NEXT STEPS
ADVANCED TOPICS
Available 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
©2014 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL
58
NEXT STEPS
Want to learn more?
• Demo accounts available at http://bsnlabs.bigswitch.com
• Write to us at info@bigswitch.com
• Write to me at kyle.forster@bigswitch.com
• Or keep an eye out for announcements from us this summer
©2014 BIG SWITCH NETWORKS, INC.
WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL
59
THANK YOU