Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "CONFIGURING A P+V NETWORK FOR NEUTRON Big Switch Networks April, 2014."— Presentation transcript:

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

2 MODERN NETWORKING: YOU ARE NEEDED

3 AGENDA FOR TODAY ©2014 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL 3 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

4 EVOLUTION OF NETWORK PROVISIONING 19932013 Terminal Protocol: TelnetTerminal Protocol: SSH ©2014 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL 4

5 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

6 Do you ?

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

8 A BRIEF HISTORY OF SDN Just entering the third inning ©2014 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL 8 1) SDN for OpenFlow programming 2) SDN for vSwitch overlays 3) SDN for P+V Fabrics We are here

9 http://ow.ly/wPu3T (Help at: https://plus.google.com/hangouts/_/bigswitch.com/erik)https://plus.google.com/hangouts/_/bigswitch.com/erik

10 CONTEXT / DESIGN DECISIONS

11 NOVA NETWORKING AND NEUTRON IN CONTEXT Application connectivity graph ©2014 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL 11 WWW App DB WWW App DB WWW App DB WWW DB WWW App DB WWW TidyMosh Pit“Enterprise” Threat isolation, fault isolation, troubleshoot-ability, compliance, implicit or explicit contract

12 NOVA NETWORKING AND NEUTRON IN CONTEXT Enforcing an application connectivity graph ©2014 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL 12 WWW App DB “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

13 NOVA NETWORKING AND NEUTRON IN CONTEXT Common case Nova design, easily migrated to Neutron ©2014 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL 13 WWW App DB SG: Nova or Neutron Security Group, V/S: VLAN and Subnet Public-facing VMs have 2 nd IP address, a floating 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

14 NOVA UNDERLYING INFRASTRUCTURE VIEW Common case Nova design, moving parts Spine Switch/Router (static, all VLANs everywhere) Nova Server (VLAN Mgr) ©2014 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL 14 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

15 NOVA NETWORKING AND NEUTRON IN CONTEXT Advanced “enterprise” case Neutron design ©2014 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL 15 WWW App DB 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 Subnet Note: not mutually exclusive with SGs Note: often use floating IPs instead of routes for public connectivity R Each project gets a logical router with routes and ACLs

16 NOVA NETWORKING AND NEUTRON IN CONTEXT Where and what is the logical router for each project? ©2014 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL 16 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 Subnet Note: not mutually exclusive with SGs Note: often use floating IPs instead of routes for public connectivity R ?

17 ML2 UNDERLYING INFRASTRUCTURE VIEW Common case ML2 design, moving parts Spine Switch/Router (dynamic VLAN provisioning and pruning) Neutron Server w ML2 plug-in and vendor DriverMechanism ©2014 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL 17 vSwitch Leaf Switch/Router (dynamic VLAN provisioning and pruning) L3 Agent (w HA Proxy / PaceMaker)

18 O/U UNDERLYING INFRASTRUCTURE VIEW Common case O/U design, moving parts Spine Switch/Router (static, all VLANs everywhere) Neutron Server ©2014 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL 18 vSwitch Leaf Switch/Router (static, all VLANs everywhere) L3 Agent Overlay Controller (VMs or physical appliance pair) Overlay Gateway (aka VXLAN VTEP function)

19 P+V UNDERLYING INFRASTRUCTURE VIEW Common case P+V design, moving parts Spine Switch/Router (dynamic) Neutron Server ©2014 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL 19 vSwitch Leaf Switch/Router (dynamic) L3 Agent P+V Controller (VMs or physical appliance pair) Overlay Gateway

20 BSN P+V CLOUD FABRIC INTRODUCTION

21 CLOUD FABRIC HARDWARE AND SOFTWARE Bare 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 HardwareSwitch Light and SDN Controllers ©2014 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL 21

22 BSN P+V CLOUD FABRIC Moving 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 ©2014 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL 22 Switch Light vSwitch or OVS Switch Light OS on leaf (10G/40G bare metal switches)

23 BSN CLOUD FABRIC ©2014 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL 23 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

24 HANDS ON, PART I BASIC INTRODUCTION

25 START YOUR DEMO ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 25 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.here

26 CONNECTING TO YOUR CONTROLLER Click on the topology’s BVS icon to launch the BVS CLI. This will launch a popup shell. ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 26 Go ahead and login with the credentials in your row on the sign up sheet.

27 GET COMFORTABLE ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 27 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.

28 EXPLORING THE BASIC SHOW COMMANDS Show switch Show host Show link ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 28

29 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

30 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

31 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

32 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:// " 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

33 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

34 LOOKING AT FLOWS ON THE CONTROLLER ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 34 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!

35 DISTRIBUTED INTRA-TENANT ROUTING ©2013 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 35 red-web red-app Red Tenant Inter VNS communication within the tenant via the Tenant Router Provide secure segmentation / Restriction via Router ACLs VM1 VM3 VM2 Tenant Virtual Router

36 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 ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 36

37 DISTRIBUTED VIRTUAL ROUTING SERVICE Connecting VNSs ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 37 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)

38 DISTRIBUTED VIRTUAL ROUTING SERVICE Connecting VNSs ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 38 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)# 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.

39 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)# ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 39 Now try pinging VM3 from VM1 and VM2 again… Success!

40 TEST PACKET IN ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 40 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.

41 HANDS ON, PART II EXPLORING OPENSTACK INTEGRATION

42 INITIAL LOGIN TO THE DEMO ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 42 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 http://hostname/bigdashboard When prompted, login using the demo credentials sent to you in your email

43 CREATE A TENANT USER AND PROJECT FOR THE USER ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 43 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

44 LOGIN TO BIG DASHBOARD AS A TENANT USER ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 44 Logout and Log back in to the same URL with user created in previous step: http://hostname/bigdashb oard http://hostname/bigdashb oard You will only see the tenant level (Project A) resources with this TenantA login

45 START PROVISIONING NETWORKS ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 45 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”

46 START PROVISIONING NETWORKS ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 46 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”

47 PROVISIONING NETWORKS ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 47 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.

48 PROVISIONING A ROUTER ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 48 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.

49 PROVISIONING ROUTER INTERFACES ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 49 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

50 PROVISIONING ROUTER INTERFACES ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 50 Select all the three interfaces one by one and add to the tenant router

51 PROVISIONING ROUTER INTERFACES ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 51 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

52 DISTRIBUTED INTRA-TENANT ROUTING ©2013 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 52 App Web TenantA Web-001 DB-001 Tenant Virtual Router App App-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

53 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 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 ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 53 OpenStack ViewController CLI

54 LOOKING AT BSN CONTROLLER Interface ID on the OpenStack maps to BVS definition ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 54 Above steps involving BVS controller login was to show you the mapping between Openstack networking components to BVS controller

55 ISOLATING THE TIERS ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 55 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”.

56 ISOLATING THE TIERS ©2012 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM 56 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.

57 NEXT STEPS

58 ADVANCED TOPICS Available in whitepapers or 1:1s with our field teams ©2014 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL 58 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

59 NEXT STEPS Want to learn more? ©2014 BIG SWITCH NETWORKS, INC. WWW.BIGSWITCH.COM PROPRIETARY AND CONFIDENTIAL 59 Demo accounts available at http://bsnlabs.bigswitch.comhttp://bsnlabs.bigswitch.com Write to us at info@bigswitch.cominfo@bigswitch.com Write to me at kyle.forster@bigswitch.comkyle.forster@bigswitch.com Or keep an eye out for announcements from us this summer

60 THANK YOU


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

Similar presentations


Ads by Google