Playing with AOS-CX Switch Simulator: a good tool to start learning about Aruba...
Playing with AOS-CX Switch Simulator: a good tool to start learning about Aruba...in our “industry” it is very important to "do stuff". Here are 2 PoC: Traditional and VXLAN EVPN SPINE-LEAF.
Hi everyone,
these weeks I’m working with some stuff in order to maintain them “fresh” in my mind...sadly it’s very complicated because I don’t have enough RAM or storage space, and a brain upgrade it’s not possible. But as always, first things first, here's a musical recommendation to boost your attitude... -> my oldest daughter plays basketball and every weekend I take her to her games. We have several rituals and one of them is listening to music on the way from home to the basketball court, with the volume all the way up!. Our pre-game song is ... AC/DC - Thunderstruck (1990) ... THUNDER!!! ...that is the same as my refreshing weeks.
Well, let's get down to business...What is AOS-CX Switch Simulator?, check this → Explore Aruba CX Switches with the AOS-CX Switch Simulator and this → Improve your networking skills with the AOS-CX Switch Simulator
“AOS-CX is the operating system running in Aruba CX Switches. Created in 2017, this software platform has proved to be highly resilient, scalable, and programmable. Now you can create your own CX networking virtual learning and experimenting environment using the AOS-CX Simulator. You can connect different topologies, and configure features, protocols, technologies and solutions. And you can experiment with different troubleshooting tools, try the Network Analytics Engine to automate monitoring, and even create your own scripts and test their behavior ”.
One important thing here is that this is a “simulator”, not a real device, and not all features of hardware devices are supported, please read the release notes.
In the following link you will find multiple lab guides → Lab Guides → very well explained.
In this post I will show you 2 labs, LAB 1 → a “Traditional architecture” (vsx, ospfv2 and ospfv3, IPv4 and IPv6 multicast services) and LAB 2 → a “spine-leaf architecture” with VXLAN EVPN.
LAB 1 (Traditional architecture): VSX, OSPFv2/3 and IPv4/6 multicast routing
In this lab we will use an access layer and a distribution/core/or collapsed core layer. The access layer will be formed by 4 AOS-CX simulators (LEAF01-LEAF04) and third switch that is located at second level ToR (ToR-Level2)...yes this is my lab and I do what I want to do...ha,ha,ha...it’s a joke, it’s only for demonstration purposes. The core/distribution/or collapsed core is formed by 2 S AOS-CX simulators (SPINE01-SPINE02). There are 2 VSX in place, one in core/distribution layer SPINE01 and SPINE02, and one in access layer, LEAF03 and LEAF04. But wait please, what the hell is vsx? → VSX. I you don’t want to open the link, this is the ChatGPT response...ha,ha,ha….: “VSX is a technology that allows two physical switches to be configured and managed as a single logical switch. This can be useful in a variety of scenarios, such as improving network resiliency by creating a redundant network architecture, or simplifying network management by reducing the number of devices that need to be managed. With VSX, both switches are configured to act as a single switch, and they share a common control plane, which allows for failover and redundancy in case one switch fails. The switches also have separate data planes, which ensures that traffic flows are isolated between the switches. Overall, VSX is a powerful technology that can help improve network reliability and simplify network management.”...certainly the best structured paragraph of the post, I know...my english is a shit I’m working on that since decades ago.
There is not L3 services at access layer, only L2 with vlan segmentation. L3 interfaces, vlan interfaces, are defined at core/distribution layer, and in order to avoid first hop redundancy protocols like, vrrp, hsrp or glbp, we use the functionality Active gateway over VSX: “Active gateway is a first hop redundancy protocol that eliminates a single point of failure. The active gateway feature is used to increase the availability of the default gateway servicing hosts on the same subnet. An active gateway improves the reliability and performance of the host network by enabling a virtual router to act as the default gateway for that network. If you have enabled active gateway, VRRP is not required. Active gateway is similar to VRRP in that routed traffic from the VSX node is sourced from the switch interface MAC and not the virtual MAC address (VMAC). Each active gateway sends a periodic broadcast hello packet to avoid VMAC aging on the access switches. The switch views the active gateway IP as a self IP address. Active gateway is preferable over VRRP because with VRRP traffic is still pushed over the ISL link, resulting in latency in the network.”
The following image shows the LAB topology:
Although this LAB is not in the lab guides, Lab Guides, all the features configured here are there...why?, because I don’t like copy and paste all the stuff.
LAB 1 configurations
This is the VSX configuration (SPINE01)...one important note here is that you can synchronize multiple configuration items between the nodes that form the VSX:
It’s time to check ospfv2/v3 config:
Here goes the router pim(6) config (loopback 1 interface is the ipv4 anycast address):
And now msdp config (in this case only for ipv4 address family):
LAB 1 (Traditional architecture) state information
What about state info?...We will start with lacp interfaces:
Reviewing VSX status:
And another important info, vsx mac-address-table:
And why not, check vsx route table:
As you can see the external routes (10.10.109.0/24) and internal routes (10.10.100.0/24, 10.10.101.0/24) are in from both SPINE nodes:
It’s very easy get unique routes, routes that belongs to one node, in this case SPINE01:
Of course you can get similar IPv6 information:
What about ospfv2/3 status?...here we goooo…Ospf interfaces...IPv4/6:
Ospfv2/3 neighbors:
DB/Route info (IPv4/6):
And now, multicast time...pim/6 status...here goes the pim neighbors (IPv4 and IPv6). In this case the extwernal PE1001 device des not support ipv6 pim, thus we don’t test it:
Once we have checked the network status, it is time to inject multicast traffic. In this case we will send ipv4 and ipv6 multicast flows from the server01. The client01 connected to LEAF01 and the client02 sited outside the data center, connected to PE1001, will subscribe to that flow. Came on!!! Thunderstruck!!!!
IPv4 multicast: 239.10.100.100
I advise you to use cvlc or similar tool for generation of multicast flows. This setup is a little bit more real than pings and igmp static groups, or...Here goes the cvlc command to generate a low* bandwidth multicast flow… *reduce the bandwidth usage is essential in a lab:
Generate multicast flow from Server01:
Client01 and Client02: and here is the command to “subscribe” to that multicast flow:
The graph is the following:
Of course we have the state information:
And of course we have the streaming data in both clients:
We have similar results with ipv6 multicast...Here go the commands to generate and retrieve multicast data:
And the flow…Oh mama!!!
领英推荐
Some IPv6 state info:
LAB 2: VXLAN BGP EVPN
I warn you, this lab will be very short, my wife has threatened me with divorce if I don't stop "labing" ...NOW!!!, pero ...”AHORA MISMO”!!! This was a real thunderstruck...oh mama!
You will find valuable information in the lab guides, but as in the previous LAB, this setup is not related to specific LAB guide. Again, please read carefully the release notes of CX simulator, there are some features that are not implemented, remember, this a S-I-M-U-L-A-T-O-R.
In this LAB I deploy a SPINE-LEAF topology formed by 2 SPINEs (SPINE01-SPINE02) and 4 LEAFs nodes (LEAF01-LEAF04). The LEAF01 and LEAF02 form a VSX. Here is the topology:
There is a data plane limitation in CX simulator when you work with VSX and VXLAN, but the control plane it’s OK. Another limitation I have found is that symmetric IRB does not seem to be supported in CX simulator.
Here go some configurations, the first one →SPINE01:
Here goes LEAF01:VSX config:
LEAF01: OSPF and BGP config:
LEAF01: EVPN and VRF config:
LAB 2 (VXLAN BGP EVPN) state information
Underlay IGP status (ospf), SPINE01:
Underlay IGP status (ospf), LEAF01, ECMP (Equal Cost Multi-Path) in place to remote VTEPs:
BGP sessions at Route Reflector, SPINE01:
BGP at LEAF01, check BGP EVPN status and remote VTEP (LEAF04 – 10.255.255.104) info:
And now mac-addresses, ARPs and other stuff….Verify connectivity between Sever01 and Client01:
State info at LEAF01:
State info at LEAF04:
And of course, all of these thanks to BGP:
*NOTE: After several tests and captures I must say that with CX simulator there is a kind of ingress replication, that is, the ingress VTEP replicates each frame to the remote VTEPs, perhaps is an issue with my config:
Switches running the AOS-CX software are fully programmable with a REST (REpresentational State Transfer) API...this is a gift. The REST API supports two access modes:
- read-write (default)
- read-only
In the read-write access mode:
The AOS-CX REST API Reference shows most of the supported read and write methods for all switch resources.
The REST API can access and change every configurable aspect of the switch as modeled in the configuration and state database.
In the read-only access mode:
Most switch resources support only GET methods, but some resources allow PUT or POST methods. For example, you can use POST to log into the switch, use PUT to upload a new running configuration, or use POST to upload a new firmware version.
For most switch resources, the AOS-CX REST API Reference does not show any write methods (POST, PUT, and DELETE) the resource might support. To show those write methods, read-write mode must be enabled.
You can access the API documentation from any device, it helps a lot when creating your tools:
Here is an example of how you can get the BGP EVPN neighbor status:
If you've read any of my previous posts you'll know I'm a fan of executing commands remotely...this lab is no exception:
Conclusion
It is important to do "things", and in our IT world even more so. Aruba has done a great job with CX simulator, allowing us to test solutions from a leading vendor. If you haven't tried Aruba or CX simulator I recommend you to do so, you will surely improve your network skills.
Documentation