Arista EOS keynote

Arista EOS support hardware for Leaf ( ToR ), Spine, and Spline data center design layers. They have a wide product range supporting large layer-3 multipath ( 16 – 64-way ECMP ) with excellent optimal Layer 3-forwarding technologies. Multi-protocol Label Switching ( MPLS ) limits to static MPLS labels, which could become an operational nightmare and as of yet no Fibre Channel over Ethernet ( FCoE ) support.

Arista support massive Layer-2 Multipath with ( Multichassis Link aggregation ) MLAG. Validated designs with Arista Core 7508 switches ( offer 768 10GE ports ) and Arista Leaf 7050S-64 support over 1980 x 10GE server ports with 1:2,75 oversubscription. Thats a lot of 10GE ports if you think layer 2 domains should design to that scale?

 

Arista Deep buffers : Why are they important?

Important switch table you need to be concerned with for large 3 networks is size of Address Resolution Protocol ( ARP ) tables. When ARP tables becomes full and packets are offered with destination ( next hop ) that isn’t cached, network will experience flooding and suffer performance problems.

Arista Spine switches have very deep buffers, ideal for bursty and latency sensitive environment. Deep buffers are ideal when you have little knowledge of application traffic matrix as they can handle most types efficiently. Deep buffers are most useful at Spine layers as this is where concentration of traffic occurs. If you are concerned that ToR switches do not have enough buffers, then physically direct servers to chassis based switches in Core / Spine layer.

 

Optimal Layer 3 forwarding with Arista

Every data center has some mix of layer 2 bridging and layer 3 forwarding. Design selected depend on layer 2 / layer 3 boundary. Data centers that use MAC-over-IP usually have layer 3 boundary on ToR switch. While fully virtualized data centers that requires large layer 2 domains ( for VM mobility ); VLANs span Core or Spine layers. Either of these designs can result in suboptimal traffic flow. Layer 2 forwarding in ToR switches and layer 3 forwarding in Core may result in servers in different VLANs connected to the same ToR switches being hairpinned to the closest Layer 3 switch.

Solutions available that offer-optimal Layer 3 forwarding in the data center. These may include stacking ToR switches, architectures that present whole fabric as single layer 3 element ( Juniper QFabric ), and also controller-based architectures ( NEC’s Programmable Flow ). While these solutions may suffice for some business requirements they don’t optimal Layer 3 forward across whole data center while using sets of independent devices.

Arista Virtual ARP does this. All ToR switches share the same single IP and MAC with common VLAN. Configuration involves the same first-hop gateway IP address on a VLAN for all ToR switches and mapping MAC address to the configured shared IP address. Design ensures optimal Layer 3 forwarding between any two ToR endpoints and optimal inbound traffic forwarding.

 

Optimal VARP Deployment

Optimal VARP Deployment

 

It requires no type of protocol between the VARP-enabled devices and has no knowledge of primary and backup forwarding.

 

Load Balancing Enhancements

Arista 7150 is an ultra low latency 10GE switch ( 350 – 380 ns ). It offers load-balancing enhancements other than standard 5-tuple mechanism. Arista support new load-balancing profiles. Load balancing profiles allow you to decide what bit and byte of the packet you want to use as the hash for load-balancing mechanism. Offering more scope and granularity than traditional 5-tuple mechanism.

 

LACP fallback

With traditional Link Aggregation ( LAG ), LAG is enabled after the first LACP packet is received. Before receiving LACP packets the physical interfaces are not operational and are down / down. This is viable and perfectly OK unless you need auto provisioning.

 

LACP Fallback

LACP Fallback

 

What does LACP fallback mean? If you don’t receive a LACP packet and LACP fallback is configured then one of the links will still become active and will be UP / UP. Continue to use Bridge Protocol Data Unit BPDU ) guard on those ports as you don’t want a switch to bridge between two ports and create a forwarding loop.

 

Direct Server Return

7050 series support Direct Server Return. The load balancer in the forwarding path does not do NAT. Implementation includes configuring VIP on outside IP of load balancer and on loopback of internal servers. Important not to configure the same IP address on server LAN interfaces as ARP replies will clash. Load balancer sends the packet unmodified to server and server sends straight to client.

Requires layer 2 between load balancer and servers; load balancer needs to use MAC address between load balancer and servers. Possible to use IP which is called Direct Server Return IP-in-IP. Requires any type of layer 3 connectivity between load balancer and servers.

Arista 7050 IP-in-IP Tunnel supports basic load balancing so one can save cost of not buying an external load balancing device. It’s a scaled down model and you don’t get advanced features that you might with Citrix or F5 load balancers.

 

Link Flap Detection

Networks have a variety of link flaps. Networks can experience fast flapping, regular flapping and sometimes you get irregular flapping. Arista have a generic mechanism to detect flaps so you can create flap profiles which offers more granularity to flap management. Flap profiles can be configured on individual interfaces or globally. Possible to have multiple profiles on one interfaces.

 

Detecting Failed Servers

The problem is when we have scale-out applications and you need to detect server failures. When no load balancer appliance exists, this has to be with application-level keepalives or even worse Transmission Control Protocol  ( TCP ) timeouts. TCP timeout could take minutes. To improve performance Arista is using Rapid Indication of Link Loss ( RAIL ). RAIL improves convergence time of TCP based scale-out applications.

 

VMtracer

Allows switches to detect, which servers are connected to them permitting Vcenter to provision automatically. Enhancements include use of LLDP between switches and ESX.

 

VMtracer

VMtracer

OpenFlow Support

Support Openflow 1.0. Available on 7050 series.

Arista match 750 full entries or 1500 layer 2 match entries, which would be destination MAC addresses. They can’t match IPv6 or any ARP codes or inside ARP packets, which are part of Openflow 1.0. Limited support enables only VLAN or layer 3 forwarding. If matching on layer 3 forwarding, match either source or destination IP address and then rewrite the layer 2-destination address to the next hop.

Arista offer a mode called VLAN bind mode; configure certain amount of VLANs belonging to OpenFlow and another set of VLANs belonging to normal Layer 3. Type of Openflow implementation is known as “ships in the night”.

Arista also support a monitor mode. Monitor mode is regular forwarding with OpenFlow on top of it. Instead, of allowing openflow controller to forward forwarding entries, forwarding entries are programmed by traditional means via Layer 2 or Layer 3 routing protocol mechanism and Openflow processing is used in parallel to traditional routing. Openflow is then used to copy packets to SPAN ports offering granular monitoring capabilities.

 

DirectFlow

Direct Flow – I want all traffic from source A to destination A to go through normal path but any HTTP traffic go via firewall for inspection. i.e set output interface to X and similar entry for return path and now you have traffic going to the firewall but for port 80 only. Offers same functionality as Openflow but without central controller piece. DirectFlow can configure OpenFlow with forwarding entries through CLI or REST API and is used for Traffic Engineering ( TE ) or symmetrical ECMP. Direct Flow is easy to implement as you don’t need a controller. Just use a REST API that is available in EOS to configure the flows.

 

 

About Matt Conran

Matt Conran has created 156 entries.

Leave a Reply