Downloaded 220 times
Uploaded byAruba, a Hewlett Packard Enterprise company
Airheads Meetups: 8400 Presentation
This document provides an overview and introduction to the Aruba 8400 switch, which is designed for campus core and aggregation applications. It describes the hardware architecture including line cards, management modules, fabric modules, and power supplies. It also discusses the software architecture of ArubaOS-CX running on the 8400 and its high availability, programmability, security, and analytics capabilities. Example deployments of the 8400 as a campus core and aggregation solution are shown.
More Related Content
Similar to Airheads Meetups: 8400 Presentation
![Juniper_Wired_and_Wireless_Comparison_Guide_V6_201002[2] (1).pdf](https://cdn.slidesharecdn.com/ss_thumbnails/juniperwiredandwirelesscomparisonguidev620100221-220915203750-213a4689-thumbnail.jpg?width=640&height=640&fit=bounds)
More from Aruba, a Hewlett Packard Enterprise company
Airheads Meetups: 8400 Presentation
- 1. Introduction to Aruba 8400 Dikvan Oeveren – Aruba Consulting System Engineer
- 2.
- 3. 3 Aruba campus edgeswitch portfolio Campus, branch and SMB networks − Advanced Layer 3 − 24 or 48 port Gig − Smart Rate multi-gigabit Ethernet − Wire speed 40GbE − PoE+ models − Modular uplinks − Redundant power − 10 unit stacking − OpenFlow − Advanced Layer 3 − 6 and 12- slot compact chassis − Smart Rate multi-gigabit Ethernet − Wire speed 40GbE − Redundant mgmt. and power − 96 10GbE ports, 288 1 GbE ports − 288 ports full PoE+ capable − OpenFlow 5400R − Layer 2 − 8, 24 or 48 ports with 10/100 or Gig − sFlow, ACLs, IPv6 − Fanless & compact models − Models with 10GbE uplinks − PoE+ models 3810M 2530 − Standard Layer 3 with static, RIP routing & Access OSPF − 4 Unit VSF Stacking − 8, 24, 48 ports Gig − PoE+ models − Fixed 1GbE and 10GbE Uplinks − Internal Power supply − OpenFlow − Central support 2930F − Standard Layer 3 with static, RIP routing & OSPF − 10 Unit Backplane Stacking − Redundant power − Modular 10GbE and 40GbE uplinks − OpenFlow − Central support − 1440W PoE/Redundant Power 2930M 2540 − Layer 2 with static & RIP routing − 24, 48 ports Gig − PoE+ models − Fixed 10GbE Uplinks − Internal Power supply − Central support
- 4. 4 Aruba campus coreand aggregation switch portfolio Campus core and aggregation solutions − Advanced Layer 3, including IPv4/IPv6 routing, BGP, and VRF − 48 ports of 10G to support SFP/SFP+ and 6 ports of 40G to support QSFP+ − Up to 2.5Tbps of switching capacity and 1.9BPPS − Flexible bundle that includes 2x power supplies, 5x fans, and the unit (JL479A) − Supports SFP/SFP+ and QSFP+ Transceivers − Wire speed 10G and 40G − Redundant fan and power supplies − Advanced Layer 3, including IPv4/IPv6 routing, BGP, and VRF − 8-slot chassis with redundant mgmt. module, fan, fabric module, and power − Up to19.2Tbps of switching capacity and 7.14 BPPS − Flexible bundles that includes 32 ports of 10G and 8 ports of 40G (JL376A) − Line Modules: 32Px10G w/ MACsec, 8Px40G, and 6Px40G/100G − Wire speed 10, 40, and 100G − Up to 256 10G ports, 64 40G ports, and 48 ports of 100G ports 8400 3810M − Advanced Layer 3 and BGP − 16 to 24 ports of 10G − Flexible uplinks using 4 ports of 10G or 2 ports of 40G − Redundant power − 10 unit stacking − OpenFlow 8320 − Advanced Layer 3 and BGP − 6 and 12- slot compact chassis − Smart Rate multi-gigabit Ethernet − Wire speed 40GbE − Redundant mgmt. and power − 96 10GbE ports, 288 1 GbE ports − 288 ports full PoE+ capable − OpenFlow 5400R
- 5. 5 Introducing Aruba 8400: CampusAggregation & Core 8 RU x 26.0” Depth 240 lbs. populated 8 Line Card Slots 3 Fabric Card Slots 2 Management Slots 4 Power Supplies 18 Fan Modules 1.2 Tb/s Ingress + Egress Forwarding per Slot 1.8 Tb/s Fabric Interface In + Out 19.2 Tb/s, VoQ Dynamic Load Balanced Fabric 99.999% Available, Redundant Passive Chassis 9.6Tb/s of Line Rate Port Bandwidth
- 6. 6 8400 Hardware Architecture:Built for Scalability & HA 3 Fabric Modules w/ N+1 Redundancy N+N AC Power Supply 4x2500W PS Redundant Management Modules with X86 CPU for scalability 8 Line Card Slots Up to 1.2 Tbps AC Inlets 3 Rows of 6 Fans w/ N+1 Redundancy FRONTVIEWREARVIEW • Fully extensible fabric design – allows for seamless upgrades to future bandwidth scale • Line Cards: 32x10G, 8x40G, 6x100G • 0 to 40 degrees C • Front to Back Airflow • Mountable on 19 inch, 2 post rack 8 Rack Units. 17.4” W x 13.8” H x 26.0” D
- 7. 7 Front components Line cards Linecards Power supplies Management modules Front display card
- 8. 8 Rear components Fabric modules Fantrays Fan modules Power inlets Rear display card
- 9. 9 Line cards JL363A -Aruba 8400 32-port 10GbE SFP/SFP+ with MACsec Advanced Module – 10GbE x 32 SFP+ w/ MACsec – 1x external TCAM – Packet buffer: 1.5 GB – Note: MACsec not supported on ArubaOS-CX release 1 JL365A - Aruba 8400 8-port 40GbE QSFP+ Advanced Module – 40GbE x 8 QSFP – 1x external TCAM – Packet buffer: 1.5 GB JL366A - Aruba 8400 6-port 40GbE/100GbE QSFP28 Advanced Module – 100GbE x 6 QSFP – 2x external TCAM – Packet buffer: 3.0 GB – Requires 3 Fabric for 100% Throughput, estimate 80% with 2 Fabric
- 10. 10 Management modules JL368A -Aruba 8400 Management Module – Runs – ArubaOS-CX operating system – Management plane + control plane – 1+1 redundancy – Slots 5 and 6 – Detailed status display – CPU/memory/storage – Intel Broadwell-DE – DRAM: 32GB DDR4 DRAM – SSD: 120GB – External connectors – Console ports: RJ45 and MicroUSB – OOB Ethernet management
- 11. 11 Fabric modules JL367A -Aruba 8400 Fabric Module – 3 slots – located behind the fan trays – Best of Breed Merchant Silicon – Direct Plug Orthogonal Line Card to Fabric Connection – 180W / 614 BTU; 16.75 x 6.75 in.
- 12.
- 13. 13 Network Component /Layer Network Hardware Network Protocols Network Control Plane Controller Aruba Mobility Controller ARP > 128K (up to 512K) IPv4,v6 > 256K (up to 1M), 64K ACLs > 64K Multicast > 64K 3-4 Buildings (6-8 Agg Switches) OSPF, BGP (Internet), MLAG, ACL (policy routing), et al ARP > 64K (128K LPV) IPv4,v6 > 128K, 32K ACLs > 64K (256K) 24-48 Access (96-192x10G) OSPF, MLAG, VRF, ACLs (user policy aggregation), et al Access Switch Aruba 5400R, 3810, 2930 AP Aruba AP 320, AP 330 Core: 40/100G Agg: 10/25/40G Aruba 8400 deployment: Campus L3 core and aggregation Building 2-4 ports/LAG Aggregation Solution: 8400 Core Solution:8400
- 14. 14 Network Component /Layer Network Hardware Network Protocols Network Control Plane Controller Aruba Mobility Controller ARP > 128K (up to 512K) IPv4,v6 > 256K (up to 1M), 64K ACLs > 64K Multicast > 64K 3-4 Buildings (6-8 Agg Switches) OSPF, BGP (Internet), MLAG, ACL (policy routing), et al ARP > 64K (128K LPV) IPv4,v6 > 128K, 32K ACLs > 64K (256K) 24-48 Access (96-192x10G) OSPF, MLAG, VRF, ACLs (user policy aggregation), et al Access Switch Aruba 5400R, 3810, 2930 AP Aruba AP 320, AP 330 Aruba 8400 deployment: Campus L3 core, 8320 in aggregation Building 2-4 ports/LAG Aggregation Solution: 8320 Core Solution:8400 Core: 10/40/100G Agg: 10G
- 15.
- 16. 16 Innovative Highly available and faulttolerant, including rollback Built in visibility and analytics Secure Complete device, network, application security, and trusted Infrastructure Extensible Built for micro-services and integration with other workflow systems and services Programmable Open APIs for programmability using REST and Python ArubaOS-CX ArubaOS-CX: Heart of Aruba’s Campus Core and Aggregation Products
- 17. 17 ArubaOS-CX Philosophy – Databasedriven – All state expressed in an in-memory DB – No inter-process communication – Leverage Linux – Take advantage of the richness of open source community – Fully programmable – Everything must be configurable through programmatic API – Resilient – Daemons must be able to restart with the same state as when they went down – Supportable – Rich logging and debugging built in from the start
- 18. 18 Current State Database Management Interfaces VirtualL2/3 Interfaces Kernel sync ASIC Driver Drivers Chassis Management Active Line cardLine card ASIC Control HW LC CPU Protocols ASIC Sync Routing, ARP tables Legend Fully Active Mostly Dormant Data Control State Sync State caching History Database Network Analytic Engine Current State Database Virtual L2/3 Interfaces Kernel sync ASIC Driver Drivers Chassis Management Standby Protocols ASIC Sync Routing, ARP tables KernelKernel Line Cards Benefits • High modularity – easy to extend and maintain • Full visibility – everything is in one place • Full programmability – everything is modeled • Resiliency – agent that fails resyncs from the DB • High availability – easy to sync to standby MM ArubaOS-CX Software Architecture
- 19. 19 – Standby ismostly syncing current state database – Kernel tables are synced to speed up failover Kernel sync Routing, ARP tables – Almost all logic runs on Active – Active agents don’t know that standby exists – Current state database synchronizes continuously to standby Kernel Active Current State Database Standby Current State Database High Availability: Management Modules
- 20. 20 Time-series database: Built-in networkrecord Aruba Network Analytics Engine Applications APIs Simple UI LXC Container Applications Applications ArubaOS-CX Insights Programmability Manageability Usability Performance ArubaOS-CX Meets the Challenge with Innovation
- 21. 21 Minimally Modified LinuxKernel ASIC Driver In-memory Database — ALL Persistent and Ephemeral State SwitchD Routing Stack PVOS- ported L2, Multicast, … Mgmt. daemon HW / system daemon – Robust foundational elements – Database driven architecture delivers HA, fault tolerance and configuration roll back – Built for scale with best-in-breed sub- systems – Designed for feature velocity and easy replication across portfolio – Easy to maintain and patch – Powerful toolsets for automation, assurance, analytics – Full programmable using REST API’s – Enables distributed or centralized analytics using REST to subscribe for information – Root Cause analytics – 3rd Party customizations Web GUI/CLI Assurance Through Automated Monitoring and Policy Enforcement Delegated Policy Execution Distributed Data Extraction and Cloud Scalability Dynamic Programmability Fully Open and Programmatic SW Architecture
- 22. 22 Swagger API Browser –Online documentation – Easy to use – Simple testing – Standard tool
- 23.
- 24. 24 Switch Web UI REST API AirWaveand 3rd party tools Configuration and State Time Series Data Network Analytic Engine NAE Agents – Built-in – ASE – Custom Complement to AirWave Complete REST API for integration Policies can generate Syslog messages for legacy Web UI & REST API Auto-generated for each policy script Wide Monitoring Capabilities Configuration • Protocol and System State ASIC Counters • ACL’s Time series data recording capability Condition Trigger Language Flexible Actions Alert Level CLI command execution CLI command output capture Configuration checkpoint diff capture Syslog generation Script function callback Scripts upload, readable, can be customized Low system overhead and sandbox isolation Intelligence and Automation Full power of Python Parameters for customization Variables for persistent policy state Simple: Programmability for Network Operations…Driving Predictability Monitoring & Troubleshooting Made Easy
- 25. 25 Easy to Access Easyto Use Ramping Up • Aruba Solution Exchange hub for solutions • Links to useful resources, tutorials and help • GitHub posting of Aruba NAE Agents • Users can modify and enhance Aruba supplied scripts • Switch GUI to upload scripts and activate agents; pre-loaded and pre-activated • REST interface to also manage scripts and agents • Submit requests for scripts like feature requests in the ramp up period • Training tools Network Analytic Engine Accessibility
- 26. 26 NAE Communities – ArubaSolution Exchange (ASE) – NAE primary script portal – Public solutions integrate directly with NAE UI – Community can create custom NAE solutions – GitHub – Developer community – All Aruba NAE scripts will be posted to GitHub – Community can fork and enhance Aruba scripts – Global approval for HPE employees posting NAE scripts on GitHub – Airheads – Community to glue components together – NAE, Aruba Solutions Exchange and GitHub – Committed R&D investment in building NAE scripts and helping with community
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
Editor's Notes
- #10 If fully implemented
- #11 Quad Xeon Core @ 2.2 GHz
- #12 16 to each LC 8 (not-used) to each MM
- #16 That brings us to the architecture.
- #17 We have this great operating system. We’ve got great programmability. We’ve got a fully programmable set of APIs. This is secure from the ground up. Great security best practices. We’ve ensured that we have innovative solutions around visibility and analytics, Network Analytic Engine for example. And then we’re making sure that we integrate in extensible ways with the rest of the Aruba ecosystem. So, this is going to be huge, and this operating system, this brand new operating system’s going to be hugely important to driving this forward.
- #18 And some of the philosophies around the design of this solution. It’s driven around a central database. That central database is in-memory, and it ensures that there’s no inter-process communication. We wanted to take advantage of the Linux systems, best practices of the open source community. We had to ensure that we’re fully programmable, that everything must be configured, program it, and have it APIs. So, we have this great REST API with Swagger, and you can program anything. Resiliency, supportability, all these things were very key in delivering this great solution to the market.
- #19 So, this is the software architecture. And we have this current state database, the database that resides this, that holds programming and state. So, this database along the top is hugely important. And one of the things you notice is that there’s lines, they’re always north-south, and, ignoring a couple minor exceptions, all the lines are north-south. What that means is, there’s no inter-process communication outside of the database. And because the database is fully modeled, everybody knows the language to talk to the database, and therefore, they all know how to talk to each other. In a traditional network system, the various components would be talking to each other in different ways. OSPF would talk to BGP differently than OSPF would talk to RIP, and then when BGP wanted to talk to RIP, they had to come up with a new way to do that, or, to the hardware and 802.1X. We needed to ensure that all the specific interoperability and inter-process communications were modeled and simple and constrained, and that’s why we use this database, so the database holds all state within the entire system. And that’s hugely important, so that now, when we’re developing things, the teams don’t have to work on a protocol to communicate between Spanning Tree and the port. They just use the database. So, this really helps security, stability, and resiliency as we drive forward, Very important for this design.
- #20 This is great for high availability. We really only have to synchronize the database between the active and the standby module. Almost every bit of logic runs on the active management module. There’s a little bit of information on the standby module, just to make sure that certain tables are synchronized more regularly so we don’t have a large outage upon failover. But that’s really it. The processes themselves aren’t running, so, when you failover, OSPF gets to come back online, it gets all the routes from the database, and then it does a graceful restart with its neighbors. So, it makes for high availability to be very seamless, because all of this synchronization’s done, the active doesn’t even know a standby exists. This makes for a very great and compelling solution. And it makes for our HA to be much simpler than other HA systems, where every process is communicating with another process, to the line cards, to make sure everything is synchronized. All we do is, we make sure the database is synchronized. So, we’re really simplifying how these things work as you scale out across a large team and a large system, So, the database is a key here again.
- #21 That database was key to how we are ensuring our innovation. So, if you look at the Aruba Network Analytic Engine, we have this great time series database, it’s another database that we’re adding in, but it’s also based on the APIs. And the APIs are made possible because we have this database at the center of ArubaOS-CX. And so, we’re really able to use this and a simple user experience to provide additional insights and programmability into the network. Greatly important.
- #22 Programmatic architecture is this in-memory database, so it holds all this persistent sate within the network. So, we’re database driven. So, by ensuring this is the best-of-breed network architecture, we were able to ensure we have great reliability, and then we were able to add on top of that, powerful and new features. So, we’ve got a great Web UI, as well as we added the Network Analytic Engine. Great programmability.
- #23 We keep talking about programmability, we needed to make programmability easy and accessible, and so, we made sure we included the Swagger API browser. So, if you’ve used the Swagger API browser in many of the other Aruba products, this should be, to an extent, right at home. So, we have this great online documentation for the browser, so, this API. So, you can go and look and test out different commands, different features, and really dive into what you want to see. So, it makes it very easy to use to start experimenting with new solutions, new APIs. So, that’s one of the things we were really excited about, was being able to use this API browser to enable things like NAE. Since NAE resides on the REST APIs, you can go and explore new APIs with the NAE, and that helps you out.
- #24 Let’s dive into Network Analytic Engine. This is really interesting, impactful, and powerful.
- #25 And so, we look at monitoring and troubleshooting. We look at this as made easy. You have this switch with the Network Analytic Engine. It’s got its agents, whether it’s built-in or custom, and the Network Analytic Engine ties to the configuration and state database, ties into the time series database. And we’re looking at enhancing so we have this full power of Python parameters. You have the network admin, who isn’t excited about programming, they don’t have to program. They can connect to these scripts that are already built, and they can customize the parameters via our auto-generate UI, and they can just use the UI to customize these agents and scripts how they want. This is designed to run in a network switch. We don’t use copious amount of CPU, we are very constrained, we keep this in a sandbox to ensure that all of the network analytic agents behave nicely together. And of course, we’ve got this great time series database recording capability, so we can track these values over time. We’ve really enhanced this with this condition language where it’s human-readable. You can read and understand the conditions that we’re trying to do. “I want to monitor this value, and alert me when it’s greater than this one.” It’s simplified as much as possible to ensure that this is going to be a very approachable system. And you’ll be able to do all kinds of useful events and actions when the events occur—you can send an alert, you can send custom syslogs, the customized syslog. Because these are Network Analytic Engine events, they are more filtered, and more characterized than a standard switch event where it’s link up, link down, neighbor disconnected. We’re giving you great detail in that. We can say, “we’ve been in EX start for a minute, we’re stuck”, “OSPF’s stuck”. We can come up with lots of examples. These are very customized events, so they’re more important than the standard syslog. And we’re able to do all the CLI, so we can capture various CLI commands the instant the error occurs. That’s hugely powerful. And of course, we can monitor anything in the system because we’re fully programmable and auto-generated, based on the configuration and state database within the system, we’re going to auto-generate the entire database. So, all those counters, all those statistics are available for use by the Network Analytic Engine. And we’ve made sure that there’s a great web UI and REST API on top of this, and that it’s complimentary to AirWave.
- #26 …ensuring that we embrace a community, and we’re going to start with Aruba Solutions Exchange. The primary portal for a network administrator is going to be in the Aruba Solution Exchange. We’re going to be posting these on GitHub. You’ll have the UI, so you’ll be able to easily use this by entering the user’s UI and activating and downloading scripts. And, of course, we’re going to have the ability of engineering to assist with writing new scripts for critical customers and building out training tools.
- #27 And when we really dive into the community, there’s these three main components around the community that we’re focused on. We’ve got the Aruba Solution Exchange. This can be where the network administrator goes to find scripts. It’s easy to use, and we even have a connector in the 8400 where they can download scripts directly to the device without walking through the Aruba Solution Exchange UI. All the Aruba certified solutions will be posted on ASE, and they’ll be indicated as Aruba certified. GitHub’s going to be our developer community. So, these Python scripts that power the Network Analytic Engine, we’re going to take all the HPE Aruba generated scripts and post them on GitHub as well, and open them up for the community to embrace and contribute. They’ll be able to fork and enhance the Aruba certified scripts. And we’re going to keep investing on that. And then the other thing is, we’re going to work on ensuring that there’s global approval for HPE employees posting Network Analytic Engine scripts on GitHub, because we want to ensure that, SEs like you out in the field can easily work with the GitHub solutions or your customers, and build new scripts, new agents, take advantage of all this functionality and flexibility, and really dive into it. And then, of course, Airheads. We have this awesome user community in Aruba called Airheads. We’re going to embrace that and we’re going to work on using that community to glue these components together. So, we have this community, glue it together with Airheads. Also, the cool thing is, R and D is assisting and investing in building new scripts, helping with the community, customer requests—It’s really cool.
- #28 When we look at the portal here, this is the main webpage. And we have Analytics button up here, and it has a critical alert on the voice over IP, and there’s also another Analytic button to the side. And so, let’s look at this in detail.
- #29 So, this is an auto-generated UI. So, we’ve auto-generated the graph. It’s based on what was provided. But the code doesn’t generate the graph. And so, we have this really cool graph, and one of the things to note is there’s a purple diamond up here. And the purple diamond highlights configuration changes and checkpoints. So, if you click on a purple diamond, you’ll get a diff of this recent change, and the last change. And this is highly important because many network outages are caused by configuration errors. And then we have the red triangle, which is an alert. So, the red triangle is going to signify the alert and the status. And you’ll notice here, it’s marked on the UI, so we show you in time when that alert occurred. And we highlight the details down here, and we have our parameters in the status panel. So, this is how this UI looks. And, if you click on an alert, you can even get this little Navigate button which will take you to the spot in time when that alert occurs. So, if you had a couple alerts and one occurred several hours ago, you can click on Navigate and it will take you to when that alert occurred. Let’s look at the alert details.
- #30 So, this gives you some information, and it also gives you a couple of reports. So, we have some analysis reports that have been generated. So, this is really exciting. You see you have a critical alarm, it’s in the VoIP queue, well, let’s look at the service impact analysis.
- #31 And what we see here is, we are reaching out to ArubaOS switch devices and we are querying them and running an IP-SLA test. So, we’re checking the live MOS score from access switches connected to the 8400 and we’re graphing them here. And what we see is, several of the switches are being impacted by whatever caused this alert. That’s interesting.
- #32 And then we can dive into this deeper. And so, when we look into this deeper, we have top talkers here. When we look at the top talker, we see that it’s all this TCP traffic, this is the VoIP queue. So, we have a bunch of TCP traffic in a VoIP queue. That was strange, so obviously something with this top talker and this device is causing a problem in the network.
- #33 And so, we can look at that configuration diff, and we can see that quality of service got turned on, but we’re also remarking CS3, or DSCP 24, to local priority 7. So, we’re doing this remark, and this is causing the problem. This is really interesting. And so, now we can go and we can make changes and correct that. There’s a Revert button here, which will be a future release item. Thing here is, we can go and we can easily highlight the configuration or the cause of the problem, and then the admin can easily go in and make that change and address it. So, I really like talking through this to ensure that as you’re highlighting the demo that is posted on YouTube, highlight walking through the same thing, you can really go in detail and explain with the customers what’s happening.
- #34 And with that, definitely want to say thank you. This is a exciting opportunity to talk about the Network Analytic Engine. This is hugely powerful and we definitely see this is a game changing step towards ensuring increased automation, increased troubleshooting, and simplifying the network. So, with that, thank you.