Cisco Cisco MDS 9500 Series Supervisor-2 Module Libro blanco

 

 

© 2006 Cisco Systems, Inc. All rights reserved. 

Important notices, privacy statements, and trademarks of Cisco Systems, Inc. can be found on cisco.com. 

Page 5 of 16 

 
 

Although there are numerous product and procedural reasons for building separate SANs, doing so does not come without additional costs. Some 

SANs might be full (no unused ports left), meaning that additional capital investment is required for expansion, even if there are other SANs with 

free (unused) ports that could otherwise be used. As such, SANs typically end up with stranded ports—unused ports in one fabric that cannot be 

used where they are required. 

The solution to the costly deployment problem of numerous SANs is not solved by simply merging all environments together into one logical and 

physical fabric. The ideal model is to be able to logically replicate the isolation, stability, and multiple management scopes offered by the SANs atop 

a common physical fabric in which ports can be easily deployed within fabrics in need. This solution is best termed as ‘virtualizing the fabric’ and 

involves an end-to-end architecture supported by integrated hardware and software mechanisms within the intelligent SAN switches themselves. 

Fabric virtualization is used to provide hardware-based traffic segregation and control plane fabric services on a virtual fabric basis. Cisco fabric 

virtualization is available on a per-port basis and uses VSANs, a technology that is now part of the ANSI T11 standard for virtual fabrics. Cisco’s 

VSAN technology works by prepending a virtual fabric header tag onto each frame as it enters the switch, with the tag indicating on which VSAN 

the frame arrived. This tag is subsequently used when the switch makes distributed hardware forwarding decisions. 

There are fundamental differences between the Cisco approach to fabric virtualization and those available from other vendors: Cisco frame 

forwarding application-specific integrated circuits (ASICs) are virtual fabric aware, using the industry-standard Virtual Fabric Trunking (VFT) 

extended headers (FC-FS-2 standard, section 10.2) in forwarding decisions. Other switches either do not offer any fabric virtualization capabilities 

or populate different forwarding tables into different linecards, essentially building a per-line-card partitioning feature out of inconsistently 

programming forwarding tables. 

VSANs can be used to provide any form of logical separation: production, development, test, open-systems hosts, tape, replication, cross-site 

connectivity, segregation by operating system, and so on. 

VSAN Trunking is the ability to trunk multiple VSANs across a single ISL or group of ISLs, enabling a common group of ISLs to be used as a pool 

for connectivity for multiple fabrics between switches. VSAN Trunking uses industry-standard VFT Extended Headers to provide traffic segregation 

across common trunked ISLs. 

The primary benefit of VSAN Trunking is in consolidating and reducing the number of distinct ISLs required between switches. For example, 

for organizations that have multiple fabrics between data centers (for example, individual fabrics for synchronous replication, IBM Fiber 

Connection [FICON], and open-systems tape), VSAN Trunking enables a common pool of ISLs to be used, reducing the number of individual 

ISLs. This typically results in substantial cost savings through a reduction in the number of dense wavelength-division multiplexing (DWDM) 

transponders or dark fibre pairs necessary to transport all the fabrics between sites. Furthermore, because individual fabrics often have very different 

load profiles, grouping them together can result in a higher overall throughput because individual fabrics can burst at the rate of all of the ISLs. 

Where priority needs to be given to specific traffic or devices, quality of service (QoS) can be combined with VSAN Trunking to provider a 

bandwidth allocation guarantee for specific devices or VSANs. 

The Cisco approach to SAN routing is called Inter-VSAN Routing (IVR). IVR provides the ability to selectively route traffic between different 

VSANs without merging the fabrics together. IVR can be used to simplify SAN designs and provide resiliency for many types of deployments: 

isolated fabrics for change control; primary data center and secondary data center connectivity; Storage Service Provider (SSP) or management 

segregation; consolidated tape; and separation of production, development, and test environments with selected connectivity to centralized storage 

devices.