Posts Tagged ‘vPC’

VMware Cloud on AWS with NSX: Communicating with Native AWS Resources

Friday, January 5th, 2018

VMware Cloud on AWS Communicating to Native AWS Resources
I’ve also posted this blog on the VMware Network Virtualization Blog site. If you haven’t already, please read my prior two blogs on VMware Cloud on AWS: VMware SDDC with NSX Expands to AWS and VMware Cloud on AWS – SDDCs Across Different AWS Regions; I’ve also posted these on the VMware Network Virtualization Blog. The prior blogs provide a good intro and information of some of the functionality and advantages of the service. In this blog post I expand the discussion to the advantages of VMware Cloud on AWS being able to communicate with native AWS resources. This is something that would be desired if you have native AWS EC2 instances you want VMware Cloud on AWS workloads to communicate with or if you want to leverage other native AWS services like AWS S3 VPC Endpoint or RDS. (more…)

Twitt

Cisco vPC with Dell S4810 at ToR

Saturday, September 21st, 2013

Cisco’s vPC technology is similar to Dell’s VLT; it enables an access/leaf switch or server to have single LAG connecting up to two separate switches. This allows for an non-blocking, multipathing scenario. You can read more about Dell’s VLT technology and its advantages on my prior blog, Dell Force10 – Layer 2 Multipathing via Virtual Link Trunking (VLT) In this blog, I will configure Cisco vPC between two Cisco Nexus 5548UP switches [NX-OS 5.1(3)N2(1)] down to a third ToR Cisco Nexus 5548UP switch [NX-OS 5.1(3)N2(1)]. I will then replace the third Cisco Nexus 5548UP switch at ToR with a Dell S4810 switch [FTOS 9.0]. (more…)

Twitt

Dell Force10 – Layer 2 Multipathing via Virtual Link Trunking (VLT)

Tuesday, December 18th, 2012

In this blog I use one Dell Force10 S50N [FTOS 8.4.2.7] and three Dell Force10 S4810 switches [FTOS 8.3.12.1] to demonstrate Dell Force10′s layer 2 mulipathing technology called Virtual Link Trunking (VLT). With VLT, you can create a LAG for a server, switch, or any device that supports LACP to two different upstream switches.

Traditionally, a LAG from an access switch or server could only connect to a single upstream switch. For redundanacy purposes, many users would implement stacking on the upstream switches and then use a port-channel/LAG up to the stacked switch now seen as one logical entity. However, stacking is not the preferred solution here. Two main reasons for this is that stacking provides a single control plane mechanism that is managed by the master switch; there is no hitless failover. Compare this to VLT which provides a dual control plane mechanism and is hitless in nature. Additionally, when upgrading the switch firmware, the entire stack would need to be brought down. With VLT, one switch can be upgraded at a time without bringing down the other switch.

Stacking is more seen at the ToR or access layer. The ToR switches are usually stacked and VLT is then used upstream to the aggregate and core switches. However, if the ToR switch supports VLT such as the S4810 does, VLT can also be used from the switch down to the server. 1 GbE switches like the Dell S50N and Dell S60 do not support VLT, so, in these cases, stacking can still be employed.

In the least recommended approach, if no VLT or stacking is used at the aggregate layer connecting to the ToR on a layer 2 network, spanning tree protocol (STP) would need to be employed to block redundant links. This would create link and switch level redundancy. The issue with this is that you lose half the ports/bandwidth on the switch. By leveraging VLT, you can have an active-active multi-path connection from an access server/switch to two upstream switches seen as one logical entity employing a dual control plane mechanism. No putting-up with STP or blocked ports! (more…)

Twitt