Thanks to everyone who was able to join us for DemoFriday™ with Arista Networks featuring Splunk and Palo Alto Networks! If you missed the demonstration and would like to check it out, it now is available in our archives. The presentation features an informative walk-through of OpenStack integration, a demo of DirectFlow (a controller-less OpenFlow) and how it’s used in conjunction with L4-7 devices like firewalls, and a demo of traffic visualization and logging with Splunk, Arista Networks and Palo Alto Networks integration.
Following is the Q&A between DemoFriday™ attendees and Arista’s presenters: TME/Systems Engineer, Kulin Shah and Data Center Technology and Network Expert, CCIE, Mickey Stewart.
Arista Networks strongly believes in the philosophy of openness and taking the correct engineering standpoint without creating vendor-specific lock-ins. As a result of this, Arista didn’t necessarily build its own vendor-specific Quantum/Neutron plug-in but rather submitted in a hardware driver plug-in that sits within the framework of the OVS plug-in, allowing the simultaneous use of the standard OVS plug-in in conjunction with the Arista hardware driver.
Q: How many flows do Arista Switches support?
Understanding the number of flows supported is more than a single-dimensional answer. OpenFlow v1.0 supports only a single table implementation underneath an agent. Our design philosophy was to stay in line with the standard. The TCAM resources on the Trident+ chipset are used in the 7050 series of switches. The current TCAM hardware supports 750 flow entries in the default table entries, and 1,500 for L2-only entries. These numbers could be inflated to a larger value by creating controller-specific agent implementations to inflate the flow table size by leveraging the MAC and host tables on the chip. This creates a non-standard and more importantly an unstable implementation from a software standpoint.
Q: Which versions of OpenFlow do you support?
Today Arista supports OF1.0, and 1.3 is on the roadmap for support over the next year.
Q: What’s the value of directly programming flows without a controller?
This gives the ability to embed the intelligence to program flows based on interface state and context of the switch without the need for an external controller. We can use the OF match criteria and set actions, with the extensible nature of our EOS to simplify the design.
Q: Do the scripts used to program flows on the switch over-complicate or add issues with support?
No, in fact, we are able to simplify the design for this explicit use-case without the need of an external controller.
Q: What’s the significance of integrating this solution with Splunk?
Splunk has native application “plug-ins” to consume data, such as system and traffic logs. In this case we have the PAN splunk application to log security policy events, along with traffic and session information, along with sFlow data statistics from the switch which can be correlated with netflow traffic stats coming directly from the PAN FW.
Q: Can the service scaling solution be deployed in a high-availability scenario?
Yes, the solution can be deployed using a single set of firewalls to load-balance traffic across, using an active and passive set of switches. The switches use OSPF to route across, with an active lower cost path, and if a switch dies, the other switch or set of switches become the active path based on the other route going away when OSPF converges.
Q: What are some of the use cases you are observing with your customers in regards to VXLAN?
The biggest use case for VXLAN, as we all realize, is tenancy and address virtualization, i.e., the ability to have application mobility across and over a Layer 3 network fabric, allowing for benefits of scale and stability in a Layer 3 design while allowing the plug-and-play and ease of deployment Layer 2 addressing benefits at the application layer. Outside of this, Arista’s IXP customers have leveraged an all-physical infrastructure design to form a highly scalable and future-proof Layer 2 domain (using VXLAN) over a Layer 3 network using standard, open protocols like OSPF and BGP.
Q: Thoughts/comments on what happens with the ML2 plugin in OpenStack?
The mechanism driver and type driver layer in the modular L2 plug-in would allow for multiple vendor plug-ins to work simultaneously in conjunction with the OVS and Linux bridge plug-ins as part of Neutron networking. Arista has been driving the blueprint for the hardware driver to really benefit the OpenStack community.
Watch the full demo now or take the following sneak peek to see what we’ll be covering.