Medical grade network_campus

Cisco Medical-Grade Network (MGN) 2.0—
Campus Architecture
Last Updated: September 16, 2010

2
C O N T E N T SC O N T E N T S
Campus Architecture Overview 8
Protected 9
Interactive 9
Responsive 10
Resilient 10
Healthcare Considerations in the Campus 10
Biomedical Devices 10
Layer-2 Biomedical Device Operation 11
Layer-3 Biomedical Device Operation 12
Hybrid Layer 2/Layer 3 Biomedical Device Operation 12
Clinical Systems and Devices 12
Layer 3 Operation 12
PACS, RIS Systems, and Modalities 13
Layer 3 Operation 13
Regulatory and Security 14
Other Considerations in the Campus 14
Campus Architecture Overview in Healthcare 15
Cisco Campus Architecture Overview 15
Campus Design Options 16
Layer 2 and Layer 3 Designs 17
Designing Highly Available Medical-Grade Campus Networks 18
Overview 18
Campus Architecture Considerations 18
Core Layer 19
Distribution Layer 20
Access Layer 22
Network Redundancy Considerations 24
Chassis-Based Switches 26
Stackable-Based Switches 26
Eliminating Single Points-of-Failure 27
In-the-Box Redundancy (ISSU, NSF and SSO) 28
In-Service Software Upgrades (ISSU) 28
NonStop Forwarding (NSF) and Stateful Switchover (SSO) 29
Best Practices for Optimal Convergence 30

3
C O N T E N T S
IGP/STP Selection 30
IGP (Routing Protocols) 32
STP 35
Achieving Six Sigma Availability 36
Design Option: Virtual Switching System (VSS) 36
Application of VSS 37
Virtual Switching System (VSS) Design 38
Environmental Considerations 42
Power Management 42
PoE 42
Redundant Power 42
Cooling—BTU Management 43
Convergence of Biomedical and General Purpose IT Networks 43
Overview 43
Biomedical Device Dependencies 44
Network Virtualization and Path Isolation 44
GRE Tunneling 46
VRF/VRF-Lite 46
MPLS Campus 46
Overlay Transport Virtualization (OTV) 47
IEC-80001 48
Quality-of-Service (QoS) Considerations 49
What is QoS? 49
QoS Models for Healthcare 50
QoS in Medical-Grade Networks 50
QoS in the Healthcare Campus 51
QoS Model for Medical-Grade Networks 52
Campus QoS Models 52
QoS Classification 52
Medical-Grade Network Applications 55
Voice 57
Video 58
Scavenger Class 58
Guest Traffic 59

4
C O N T E N T S
Biomedical Devices Classification 59
Control Plane Policing 60
AutoQoS 60
Wireless QoS 61
Voice and Collaboration Considerations 62
PoE 63
Cisco UC 8.0 SRND – PoE 64
Cisco Catalyst Switch PoE Support 64
Unified Communications Manager Resiliency 66
Healthcare VoWLAN Considerations 67
Site Surveys 67
Non-802.11 Device Interference 68
VoWLAN QoS 69
Cisco Compatible Extensions 70
Call Admission Control 70
VoWLAN Troubleshooting 70
Multicast 70
Security 71
Unified Secure Voice Messaging 72
Session Manager Edition 73
Unified Communications Endpoints 73
Remote Survivability 74
ISR 74
Voice QoS 75
TelePresence 75
HealthPresence 76
Change Management 76
Management Control Plane 78
Out-of-Band Management Techniques 79
Authentication and Access Control 81
Rapid Fault-Isolation Techniques 83
NTP Sync—PTP 1588 Time Stamping 83
First Failure Analysis—Syslog, SNMP, NetFlow, XML 84
Cisco.com Tools 85

5
C O N T E N T S
Cisco Notification Service 85
TAC Case Collection 85
Output Interpreter 85
Error Message Decoder 85
Bug Toolkit 86
Product Identification Tool 86
Gathering Basic Cisco Call Manager Traces 86
Smart Call Home—Ref 7.7.3 86
Applications 87
OS Tools 87
Embedded Event Manager 87
GOLD 88
Flex Links 89
UDLD 90
Layer 2 Traceroute 90
Smart Install 90
VPC 91
CDP 92
TDR Line Cards 92
Control Plane Policing 92
MLS Rate Limit 93
Management Plane Protection 93
Mini Protocol Analyzer/WireShark 93
SPAN/RSPAN/ERSPAN 94
Enhanced Object Tracking 95
Performance Routing 95
Autostate Messaging (6500) 96
Hardware Components 96
ASIC Thermals 96
Power Management 96
SEA 98
OBFL 99
Core Dump 99
Cisco Advanced Services 99

6
C O N T E N T S
Advanced Services Bug Scrub 99
Code Recommendations 99
Cisco SLA 100
Network Analysis 100
Network Optimization Services (NOS) 101
Cisco Remote Operation Services (CROS) 101
High Touch Technical Services 102
References 102

Corporate Headquarters:
Copyright 2010 Cisco Systems, Inc. All rights re
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
MGN 2.0 Campus Design Architecture
Campus Architecture Overview
The Cisco Medical-Grade Network (MGN) architecture is based on a set of best practices that apply
various foundational network technologies. This document is the third in a series of Cisco MGN 2.0
architecture guides that explores the best practices for campus architectures and technologies that are
critical to healthcare environments worldwide. The intent of this document is to present healthcare
considerations and design options for architecting a campus healthcare network. The network architect
should use Cisco's best practices for campus architectures as a foundation and be aware of the of the
many additional considerations for a healthcare environment.
This document is intended for IT and network professionals who are engaged in the design and
implementation of healthcare networks in a campus and/or acute care environment. This includes but is
not limited to the following:
• Chief Technology Officers (CTOs)
• Chief Information Officers (CIOs)
• Chief Security Officers (CSOs)
• Network and IT directors
• Network integrators
To properly frame the context in which the Cisco MGN 2.0 architecture is based, this document discusses
the attributes of a Cisco MGN. An MGN has the following basic characteristics:
• Protected
• Interactive
• Responsive
• Resilient

8
Campus Architecture Overview
Protected
Healthcare networks world-wide transmit data regarding patients ongoing care, diagnosis, treatment, and
financial aspects. From a clinically-focused regulatory perspective, Health Insurance Portability and
Accountability Act (HIPAA) is the key legislation in the United States. Globally, other standards exist
with much the same intent as HIPAA, but with varying degrees of specificity. These include the Personal
Information Protection and Electronic Documents Act (PIPEDA) in Canada and Directive 95/46/EC in
the European Union, among others. It is generally accepted that all clinically-focused networks must
provide security and protection for sensitive data, both at rest and in transit. Cisco has a variety of
security best practices that can be directly applied to help meet the regulatory compliance required by
healthcare organizations in all regulatory domains.
Networks can help meet the unique security requirements of healthcare organizations in various ways.
Because of this, do not assume that this document, or any of the Cisco MGN architecture guides, dictates
the only “approved” method of providing such security measures. This document simply highlights the
unique challenges that medical networks face on a global basis, and discusses Cisco best practices to
meet these challenges.
Note For more details on Cisco MGN security best practices, refer to the MGN 2.0 Security whitepaper at the
following URL: http://www.cisco.com/en/US/docs/solutions/Verticals/Healthcare/MGN_2.0.html
A protected medical network is not simply a set of firewalls at the perimeter of the network, nor does the
protection end when the information is written to disk or sent to an offsite vault. An MGN is considered
protected when all the industry best practices are applied to the entire healthcare environment.
Security challenges include remote vendor access mechanisms, clinical-workstation host security, and
the increasing use of smart phone technology. From a holistic perspective, it is an absolute requirement
in all healthcare-focused networks to create a security posture that addresses each of the devices,
technologies, and access methods used to transport, store, and access protected health information
(ePHI).
Note For more details on the Cisco SAFE architecture, refer to the Cisco SAFE Reference Guide at the
following URL:
http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/SAFE_RG/SAFE_rg.html
Interactive
Care providers interact with patients and clinical staff every minute of the day, in any number of settings.
Interactivity in the Cisco MGN provides the ability of the care providers and vendors to interact with the
network and its related clinical systems seamlessly. Technologies such as wireless, virtual private
network (VPN), and collaborative technologies extend the network into a borderless network.
Examples include a remote clinician who requires immediate access to clinical information, or a remote
vendor called in to troubleshoot a medical device that requires specialized diagnostics or corrective
action. In these examples, the network provides the fundamental mechanisms and services to provide the
level of required interaction, while at the same time providing such access in a highly secure manner, as
well as enabling compliancy with local regulatory guidelines and best practices.

9
Healthcare Considerations in the Campus
Note Cisco best practices with respect to borderless networks, VPN, remote access, wireless, voice over
wireless, video, and so on, are available on the Cisco Design Zone website at the following URL:
http://www.cisco.com/en/US/netsol/ns815/networking_solutions_program_home.html
Responsive
The term responsive as it relates to the Cisco MGN is often misunderstood as simply a network latency
or bandwidth-related concern. Although an MGN must exhibit attributes related to high performance,
responsive is not applied in this manner. Instead, it refers to the set of architectural attributes that the
network must exhibit to expand and respond to the changing clinical requirements.
To permit the rapid deployment and secure use of various systems, the network must be designed to be
elastic from the perspective of security requirements. Otherwise, the adoption of new systems with
various unique security policies would be less than optimal.
Resilient
For the network engineer, this term typically relates to architectures around that of high availability.
Indeed, this is exactly what is required by the industry for any MGN. Such networks are said to be six
sigma compliant, or achieve availability of 99.999 percent or better. Achieving such high availability
from the perspective of the care provider is sometimes a significant challenge because it means
approximately five minutes of downtime per year.
High availability usually results from eliminating a single points-of-failure and networks designed to
converge rapidly.
Healthcare providers, including acute and ambulatory care facilities, posses a diverse and unique set of
endpoints, clinical devices/systems, applications and regulatory requirements that are very different than
the standard enterprise facility. These unique requirements influences the design decisions that the
healthcare campus architect will be required to make.
Biomedical Devices
Biomedical devices can be classified into different categories or class of devices. There may be a handful
of different vendor products and models of devices. Depending on vendor and device model, the campus
architecture designs must be tailored to provide the necessary functionality, and to comply with the
requirements specified from the medical device vendor.
The following are some examples of typical medical devices used in an acute healthcare setting:
• Patient monitors
• Smart Infusion pumps
• Mobile radiology devices
• Pulse Oximeter Oxygen Saturation Sensors (SPO2)

10
Within each distinct device category, there may be a subsystem of servers also used to support the
medical devices application. For example, a typical patient monitor system may consist of the following
components:
• Bedside monitors
• Patient monitor central station
• Database server
In general, medical devices are embedded systems that are controlled by the device manufacturer. A key
design principle for medical devices is to keep them as reliable as possible by reducing the number of
unnecessary variables. By implementing only those features that are required by the product, a higher
degree of product stability can be achieved. To a certain degree, this has balanced the development cycle
of devices, where it is possible that certain Layer-3 routing functions may not be developed on certain
medical device platforms.
Due to this approach, some vendors require some network segmentation for their products to work on a
campus network. This often manifests itself into special requirements where a particular device platform
requires Layer-2 adjacencies to function on the network.
Generally, device life cycles are long (7 to 10 years), and some networked medical device systems
include software that was designed to operate on these Layer-2 private networks. However, some patient
monitor vendors today support Layer-3 routing and advanced multicast features that make it possible for
devices to coexist on a converged IP network.
Some of the main vendors and products in the patient monitoring space include Philips Intellivue, GE
Dash, Draeger Infinity, and Welch Allyn Propaq. These vendors support both wireless and wired
deployments as part of their overall architecture.
Many medical device vendors also specify latency and jitter requirements on the campus network. In
most cases, a reasonable packet latency time and jitter is expected and should be kept to a minimum
across the network. For example, some latency times in excess of 25 to 100 ms between any device
devices may cause application performance degradation or unpredictable behavior. Generally, jitter
should be no greater than 5 percent. Latency and jitter times should be measured on an ongoing basis
and under various network load conditions to ensure correct application performance.
In many vendor implementations, the patient monitors must stay in communication with the database
servers. If the patient monitors lose communication with the database server for longer than the defined
parameter (i.e., 15 to 30 seconds) the central servers may timeout and revert to local monitoring mode,
potentially resulting in loss of monitoring at the central stations.
Layer-2 Biomedical Device Operation
Some medical device manufacturers may have strict Layer-2 adjacency requirements. For example,
many patient monitors and centralized stations must reside on their own Layer 2 subnet. For these
vendors, patient monitors associate to a central station using legacy broadcast methods and do not allow
routing between subnets. In some cases, the vendor may require that the network be completely
dedicated for the patient monitoring application. This reduces the risk of system performance
interruptions caused by other devices residing outside the subnet.
Considerations for Layer-2 adjacency requirement over a converged IT network are scalability, network
performance, and path isolation. For more details, refer to the “Convergence of Biomedical and General
Purpose IT Networks” section on page 42.

11
Layer-3 Biomedical Device Operation
Some medical devices, however, can operate over a Layer-3 routed network. Patient monitor devices
vendors that support Layer 3 routing will require that their patient monitor associate to a central station
using multicast methods that allows for routing between subnets.
Multicast may be used for IGMP joins and Layer-3 waveform distribution and general topology, and care
group association used for “overview” functions. The “overview” session is a window displayed at the
bedside that shows the real-time waves, measurements, alerts, etc. for another patient. A user can request
an overview session or can permanently configure an overview session.
Unicast traffic can also be used for connection messages for device type, serial numbers, and equipment
labeling. Multicast is used for IGMP Layer-3 waveform distribution, general topology, and care group
associations generally used for overview sessions.
Hybrid Layer 2/Layer 3 Biomedical Device Operation
A Layer-2/Layer-3 hybrid design is another approach that some medical devices use. Here, devices may
operate within a simple routed environment but may have limited multicast functionality or have central
stations or database servers that may not be routable. Also, the devices may use a combination of
multicast and unicast to operate properly on the network. For example, multicast may be used by the
patient monitor to discover the central server, and use unicast to send the wave data to the central station.
In general, medical devices require that the campus network offer an increased level of uptime, a high
level of redundancy, minimal level of disruption in the network and in some cases, path isolation to
accommodate Layer 2 dependencies. Securing these types of devices on the network and ease of
management are also relevant requirements for medical devices.
Clinical Systems and Devices
Clinical systems may be comprised of electronic medical records (EMR) systems, backend servers, lab
systems, and pharmacy systems. In addition, these clinical systems refer to systems that support clinical
workflow and decision support, including EHR and computerized physician order entry (CPOE)
systems. Often these systems will include laboratory and pharmacy systems as well as imaging and
PACS application.
The EMR system is the clinical repository for the collection of clinical information for the patients under
care. Many EHR systems drive the workflows within a healthcare environment, allowing caregivers to
streamline patient care with attention to protocol and overall patient care. In many secondary or acute
care environments, the EHR system is the focal point of all clinical data that has been collected on the
patient.
Layer 3 Operation
Most clinical EHR systems operate over a Layer-3 routed network. These clinical systems often support
802.11 wireless standards as mobile workstation or computers on wheels (CoWs). This allows caregivers
to access data at the point of care in many different forms and at various locations. Healthcare
professionals can have real-time access to various applications in a clinical information system (CIS).
Some Computerized Physician Order Entry (CPOE) components (for example, from a single vendor)
may use a thin client-based delivery system while the medical administration component from the same
vendor uses a fat client-based approach.

12
EHR systems are comprised of different applications, some developed by different business units within
the software vendor, and others acquired through mergers and acquisitions. In general, clinical systems
and devices require that the campus network offer an increased level of uptime, especially for their EMR
applications. Requirements also include a high level of redundancy, increased throughput, and a minimal
level of disruption in the network.
PACS, RIS Systems, and Modalities
Radiology systems may comprise electronic Picture Archival and Communication (PACS) systems,
Radiology Information Systems (RIS), and modalities such as MRI, CT, and ultrasound.
PACS is at the core of medical image management. PACS is comprised of a cluster of an application,
database and web servers. The PACS' database is large, and contains the patient image studies. When a
modality (MRI, CAT scan, X-ray, ultrasound) acquires an image, it is first viewable on the modality
itself, where the radiologist or technologist performing the exam can verify that the image has been
properly acquired. The communication of acquired studies is typically transferred over the network
using the Digital Imaging and Communications in Medicine (DICOM) protocol.
The RIS is used by radiologists on a daily basis for scheduling the workflow and providing a means for
the radiologist to enter a diagnosis into the DICOM study. The RIS function can be built into the
diagnostic workstation, which is common with most vendors. Other deployments may separate the
DICOM diagnostic workstation/viewer from the RIS.
Layer 3 Operation
Most PACs applications and modalities operate over a Layer-3 routed network. Modalities may often be
geographically dispersed away from the PACs servers located in the data center, and connectivity is
established over a WAN. Modern imaging requires large amounts of resources because of the size of the
images, sometimes in the gigabit range.
The PACS architecture will dictate the quantity and function of the servers, but they all require high
availability, typically greater than 99.99%. When more than a single PACS server and/or multiple
modalities are present, it is often difficult to provide high availability and fault tolerance. PACS supports
centralized image storage for quick image access and retrieval across a distributed storage environment.
The applications of these products are produced through direct consultation with radiology or imaging
services providers to address many key concerns as the growth and complexity of imaging services
increases exponentially.
PACS, RIS systems, and modalities require that the campus network offer an increased level of uptime,
high availability, minimal level of disruption in the network, and increased throughput to handle access
to image transfer for storage, archival, and acquisition.

13
Regulatory and Security
With the dramatic rise in security breaches, theft of patient health data, and the increase in regulatory
requirements such as those mandated by the American Recovery and Reinvestment Act of 2009,
healthcare organizations and their business partners are now under intense pressure and scrutiny
regarding security and privacy. Many regulatory regimes including HIPAA, PCI, and EC 95/46 mandate
compliance with specific requirements as part of those regulations. The Cisco MGN security architecture
is designed to meet many of these regulatory bodies, not just a singular body1
.
With the worldwide focus on electronic health records (EHR), providing meaningful end-to-end security
architectures to provide securement to electronic protected health information (ePHI) is crucial for
anyone involved in security-related roles within the healthcare enterprise. Security must be considered
in the overall design as the dependency on EHR systems increases, as well as the requirement for more
efficient workflows that can be implemented without regard to the physical location of the clinician.
Healthcare security business requirements can be boiled down to two main categories: meeting
regulatory requirements and protecting patient privacy and safety. Healthcare organizations need to have
comprehensive plans around these two areas in order to mitigate security threats. A systems approach to
streamline IT risk management for security and compliance is needed.
Local country regulatory compliance and security/privacy require that the campus network offer an
increased level of security, access control, authorization, authentication and a high level of
visibility/network management.
For more information, refer to the MGN 2.0: Security Architectures whipepaper at the following URL:
http://www.cisco.com/en/US/docs/solutions/Verticals/Healthcare/MGN_2.0.html
Other Considerations in the Campus
Other considerations that influence the campus architecture in healthcare are voice and collaboration
integration, guest services, and future evolving convergence of biomedical data directly in the EMR
system.
Voice and collaboration services use end-to-end Cisco Unified Communication solutions to support
unique Cisco solutions such as HMI Collaboration, Nurse Connect, Expert-on-Demand, and
HealthPresence. Design considerations should include support for VoWLAN, PoE, QoS, and resiliency.
These topics are described in the “Voice and Collaboration Considerations” section on page 61.
Healthcare organizations and ambulatory-based providers are offering guest Internet services to not only
their patient community, but students and contractors as well. Providing Internet access to the patient
community provides much needed access to the outside world during a time when the individual may
need such communication mechanisms. The campus MGN should provide for integration of wireless
internet access services. Guest services generally require that the campus network offer an increased
level of security, acceptable use policy, posture, and network admission control.
For more information on guest services, refer to the MGN 2.0: Wireless Architectures whipepaper at the
following URL.
http://www.cisco.com/en/US/docs/solutions/Verticals/Healthcare/MGN_wireless_adg.html
1. Any specifically applicable regulatory requirements and compliance actions are to be evaluated on an
individual basis. Regulatory requirements may vary not only by the specific technology application but also
by nation. Cisco Systems makes no representations concerning the extent or nature of regulatory requirements
that may be implicated in any given technology application.

14
Campus Architecture Overview in Healthcare
Clearly, an emerging trend is the integration of medical device data into clinical systems. Here, medical
device data is converted to HL7 or XML format and integrate with any Electronic Medical Record
(EMR), Clinical Information Systems (CIS), and/or Alarm and Event Management system to enhance
workflow. This would save thousands of nursing hours and improve patient care.
Multiple technologies are required/combined to create healthcare network infrastructure. These
technologies are often deployed independently of one another, which lead to disjointed capabilities,
configuration conflicts, and management challenges. Ideally, each of these technologies should integrate
into a cohesive network platform capable of delivering network services that are protected, resilient,
responsive, and interactive, as discussed above. It is the interconnection and combination of these
technologies that provide value and enable clinical and business capabilities in the healthcare
environment.
The most basic foundational technologies that enable this interconnection are routing and switching
functions. Routing and switching features and protocols are well understood, but the configuration
practices and deployment approaches vary from customer to customer based on specific need and design
preferences. There are many considerations that factor into routing and switching design and tradeoffs
are often required due to the healthcare's unique set of endpoints, clinical applications, and regulatory
and privacy requirements.
Unfortunately, in many healthcare environments, legacy application or device support often result in
suboptimal designs or redundant overlay networks. As described in the previous section, many of the
older biomedical devices had limited networking capabilities and relied on broadcast traffic for
communication. This prevents many healthcare organizations from following best practices around the
size and scope of Layer 2 networks. Many medical device manufacturers also place support restrictions
on their solutions that require dedicated networks for hosting their solutions.
Innovation in biomedical devices and solutions has eliminated some of the legacy networking
constraints. This innovation, along with growing customer demand, has forced medical device
manufacturers to loosen support restrictions allowing convergence to take place. Multiple biomedical
device networks are now converging onto one production network, greatly reducing management
overhead, and allowing better use of valuable data which was previously isolated.
This convergence trend does create some new challenges for network designers and support staff. This
document discusses some of these challenges and offers some best practice recommendations for
designing MGN capable of supporting this convergence.
For more details on biomedical device convergence, refer to the “Convergence of Biomedical and
General Purpose IT Networks” section on page 42.
Cisco Campus Architecture Overview
Cisco MGN 2.0 campus architecture is one of the technology modules in the overall Cisco MGN
architecture. This section provides an overview of campus design considerations for the campus
architecture module within a healthcare environment. Figure 1 illustrates a typical MGN campus
architecture. Details about campus access, distribution, and core design considerations are provided in
the “Designing Highly Available Medical-Grade Campus Networks” section on page 17.
Design options should be considered when determining the location for shared services (i.e.,Wireless
LAN Controllers, NAC Servers, Network Analysis Module (NAM), and IPS). If the campus design calls
for a single distribution block, then the services block should connect to the distribution block in a

15
fully-meshed configuration, to support load balancing and redundancy. For larger networks that require
multiple distribution blocks, the service block may be better suited to connect to the core block, rather
than the distribution block.
Additionally, if a large distribution block requires increased demand for services, the service modules
can be directly integrated into the distribution switches. This option would enable the services to be
closer to the edge and users.
Figure 1 Example Campus Architecture for Healthcare
Campus Design Options
The use of hierarchical design principles provides the foundation for implementing Medical-Grade
campus networks. The hierarchical model can be used to design a modular topology using scalable
“building blocks” that allow the network to meet evolving business needs. The modular design makes
the network easy to scale, understand, and troubleshoot by promoting deterministic traffic patterns.
Access
Distribution Core
North Access 2
10G
10G
Nx10G
10G
Nx
10G
Nx 10G
Nx 10G
Services Block
NAM
Intrusion
Prevention
System
Network
Analysis
Module
NAC Server
Wireless LAN
Controller(s)
IP
South Access 1
South Access 2
North Access 1
Portable
Ultrasound
Smart
Infusion
Pump
Clinical
Workstation
Cisco
7925G
8o2.11n
AP
8o2.11n
AP
Point of
Sale
Device
LWAPP
LWAPP
Nursing
Station
CT/MR
CoW
Medication
Administration Cart
RFID
Tag
Patient
Monitor
229482
TelePresence

16
Cisco introduced the hierarchical design model, which uses a layered approach to network design in
1999 (see Figure 2), and it has been used globally in many different industries with great success. The
building block components are the access layer, the distribution layer, and the core (backbone) layer. The
principal advantages of this model are its hierarchical structure, modularity, ability to scale, and the
overall resulting performance and availability.
Figure 2 Hierarchical Campus Building Blocks
The interconnection of the layers described above can occur in a number of different ways using various
combinations of Layer 2 and Layer 3 technologies. The hardware platforms used to create these layers
also influences the design direction. For example, Virtual Switching System (VSS) is a feature used on
the Catalyst 6500 for constructing campus networks. This technology simplifies the configuration and
management of network elements and helps overcome some of the limitations of traditional Layer-2
network designs.
For more details on VSS, refer to the “Designing Highly Available Medical-Grade Campus Networks”
section on page 17.
There are also recent product innovations on other platforms, namely Nexus, that create additional
options for network designers. Features like overlay transport virtualization (OTV), virtual port channels
(VPC), and virtual device contexts (VDC) are emerging from the data center environments and are being
used in the campus core layer.
For more details on OTV, refer to the “Overlay Transport Virtualization (OTV)” section on page 46.
220590
WAN Internet
Data Center
High Speed Core
Distribution
Access

17
Designing Highly Available Medical-Grade Campus Networks
Layer 2 and Layer 3 Designs
As described previously, the interconnection of the layers can occur in a number of different ways using
various combinations of Layer 2 and Layer 3 technologies. Biomedical devices, clinical applications,
and associated security requirements influence the Layer 2 and Layer 3 designs. An understanding of
these unique requirements is necessary to properly design the campus network for the healthcare
environment.
Overview
In general, high availability of 99.999% and above can only be achieved when hardware redundancy
exists in the network and when diagnostics are capable of recognizing a fault condition and failing over
to a secondary or load-sharing device. In general, this diagnostic capability is superior at the protocol
level with redundant chassis’s, and when the appropriate protocol is properly configured. However, keep
in mind that the overall goal is to provide a highly available end-to-end MGN that includes clinical
systems and biomedical devices. However, many times, the clinical systems (EHR, EMR, Practice
management, Lab, Pharmacy, Radiology, and so on) are not architected to provide 99.999% availability.
From the viewpoint of the network infrastructure, however, the following practices are measures of
redundancy in a larger network topology:
• No single point-of-failure (redundant chassis', stackable switches) especially towards the core of the
network
• Redundant supervisor, fan, and power modules in access layer devices
• Redundant power and fan in core/distribution devices
• Protocols implemented that can quickly detect faults and failover appropriately
• Redundant network services (where access or network capability is limited by a service(e.g., DNS)
Campus Architecture Considerations
The hierarchical model is used to design a modular topology using scalable “building blocks” that allow
the network to meet evolving business needs. The modular design makes the network easy to scale,
understand, and troubleshoot by promoting deterministic traffic patterns. Cisco introduced the
hierarchical design model, which uses a layered approach to network design in 1999 (see Figure 3), and
it has been used globally in many different industries with great success. The building block components
are the access layer, the distribution layer, and the core (backbone) layer. The principal advantages of
this model are its hierarchical structure, modularity, ability to scale, and the overall resulting
performance and availability.

18
Figure 3 Hierarchical Campus Network Design
In a hierarchical design, the capacity, features, and functionality of a specific device are optimized for
its position in the network and the role that it plays. This promotes scalability and stability. The number
of flows and their associated bandwidth requirements increase as they traverse points of aggregation and
move up the hierarchy from access to distribution to core. Functions are distributed at each layer. A
hierarchical design avoids the need for a fully-meshed network in which all network nodes are
interconnected.
The building blocks of modular networks are easy to replicate, redesign, and expand. There should be
no need to redesign the whole network each time a module is added or removed. Distinct building blocks
can be put in-service and taken out-of-service without impacting the rest of the network. This capability
facilitates troubleshooting, problem isolation, and network management. Mission-critical clinical
applications such as EMR and patient vital-signs monitoring take advantage of designs these designs.
Core Layer
High availability in a typical hierarchical model, the individual building blocks are interconnected using
a core layer. The core serves as the backbone for the network, as shown in Figure 4. The core needs to
be fast and extremely resilient because every building block depends on it for connectivity. Current
hardware-accelerated systems have the potential to deliver complex services at wire speed. However, in
the core of the network a “less is more” approach should be taken. A minimal configuration in the core
reduces configuration complexity, limiting the possibility for operational error.
119801
WAN Internet
Data Center
Access
Core
Distribution
Access
Distribution

19
The campus core is the network infrastructure that provides access to network communication services
and resources to end users and devices spread over a single geographic location. Its architectural design
promotes non-blocking, rapid convergence, and ultra-high nonstop availability. The core is the
cornerstone of the entire campus network, providing connectivity between end users including both data
center and remote resources.
Figure 4 Core Layer
Although it is possible to achieve redundancy with a fully-meshed or highly-meshed topology, that type
of design does not provide consistent convergence if a link or node fails. Also, peering and adjacency
issues exist with a fully-meshed design, making routing complex to configure and difficult to scale. In
addition, the high port count adds unnecessary cost and increases complexity as the network grows or
changes. The following are some of the other key design considerations to in mind.
Design the core layer as a high-speed, Layer-3 switching environment using only hardware-accelerated
services. Layer 3 core designs are superior to Layer 2 and other alternatives because they provide the
following:
• Faster convergence around a link or node failure.
• Increased scalability because neighbor relationships and meshing are reduced.
• More efficient bandwidth utilization.
• Use redundant point-to-point Layer 3 interconnections in the core (triangles, not squares) wherever
possible, because this design yields the fastest and most deterministic convergence results.
• Avoid Layer 2 loops and the complexity of Layer 2 redundancy, such as Spanning Tree Protocol
(STP) and indirect failure detection for Layer-3 building block peers.
Distribution Layer
The distribution layer acts as a services and control boundary between the access and the core. It layer
aggregates nodes from the access layer, protecting the core from high-density peering (see Figure 5).
Additionally, the distribution layer creates a fault boundary providing a logical isolation point in the
event of a failure originating in the access layer. Typically deployed as a pair of Layer 3 switches, the
distribution layer uses Layer 3 switching for its connectivity to the core of the network and Layer 2
services for its connectivity to the access layer. Load balancing, quality-of-service (QoS), and ease of
provisioning are key considerations for the distribution layer.
119802
Core
Access
Distribution

20
The distribution layer uses Layer 3 switching for its connectivity to the core of the network and either
Layer 2 or Layer 3 services for its connectivity to the access layer. Network services contained within
the distribution layer include Wireless LAN controllers, network analysis, network access controllers,
and intrusion prevention appliances.
Figure 5 Distribution Layer
High availability in the distribution layer is provided through dual equal-cost paths from the distribution
layer to the core and from the access layer to the distribution layer (see Figure 6). This results in fast,
deterministic convergence in the event of a link or node failure. When redundant paths are present,
failover depends primarily on hardware link failure detection instead of timer-based software failure
detection. Convergence based on these functions, which are implemented in hardware, is the most
deterministic.
Figure 6 Distribution Layer—High Availability
119803
Access
Distribution
119801
WAN Internet
Data Center
Access
Core
Distribution
Access
Distribution

21
Layer 3 equal-cost load sharing allows both uplinks from the core to the distribution layer to be used.
The distribution layer provides default gateway redundancy using the Gateway Load Balancing Protocol
(GLBP), Hot Standby Router Protocol (HSRP), or Virtual Router Redundancy Protocol (VRRP). This
allows for the failure or removal of one of the distribution nodes without affecting endpoint connectivity
to the default gateway.
You can achieve load balancing on the uplinks from the access layer to the distribution layer in many
ways, but the easiest way is to use GLBP. GLBP provides HSRP-like redundancy and failure protection.
It also allows for round-robin distribution of default gateways to access layer devices, so the endpoints
can send traffic to one of the two distribution nodes.
Access Layer
The access layer is the first point of entry into the network for edge devices such as medical devices,
computers on wheels, modalities, end stations, and IP phones (see Figure 7). The switches in the access
layer are connected to two separate distribution layer switches for redundancy. If the connection between
the distribution layer switches is a Layer 3 connection, then there are no loops and all uplinks actively
forward traffic.
The access layer provides the intelligent demarcation between the network infrastructure and the
computing devices. It provides a security, QoS, and policy trust boundary and is a key element in
enabling multiple services.
Figure 7 Access Layer
A robust access layer provides the following key features:
• High availability (HA) supported by many hardware and software attributes.
• Inline power (PoE) for IP telephony and wireless access points, allowing customers to converge
voice onto their data network and providing roaming WLAN access for users.
• Foundation services.
The hardware and software attributes of the access layer that support high availability include the
following:
• System-level redundancy using redundant supervisor engines and redundant power supplies. This
provides high availability for critical user groups.
• Default gateway redundancy using dual connections to redundant systems (distribution layer
switches) that use GLBP, HSRP, or VRRP. This provides fast failover from one switch to the backup
switch at the distribution layer.
119804
Access
Distribution
To Core

22
• Operating system high-availability features, such as Link Aggregation (EtherChannel or 802.3ad),
which provide higher, effective bandwidth while reducing complexity.
• Prioritization of mission-critical network traffic using QoS. This provides traffic classification and
queuing as close to the ingress of the network as possible.
• Security services for additional security against unauthorized access to the network through the use
of tools such as 802.1x, port security, DHCP snooping, Dynamic ARP Inspection, and IP Source
Guard.
• Efficient network and bandwidth management using software features such as Internet Group
Membership Protocol (IGMP) snooping. IGMP snooping helps control multicast packet flooding for
multicast applications.
• Disable PagP (port aggregation protocol) for user-facing ports.
• Disable DTP (dynamic trunking protocol) for user-facing ports.
• Enable BPDU Guard (bridge protocol data units), that protects the network by disabling a port
connected to a misconfigured device sending spanning tree BPDUs.
Network Redundancy Considerations
When designing a campus network, the network engineer needs to plan the optimal use of the highly
redundant devices. Careful consideration should be given as to when and where to make an investment
in redundancy to create a resilient and highly available network. As shown in Figure 8, the hierarchical
network model consists of two actively forwarding core nodes, with sufficient bandwidth and capacity
to service the entire network in the event of a failure of one of the nodes. This model also requires a
redundant distribution pair supporting each distribution building block. Similarly to the core, the
distribution layer is engineered with sufficient bandwidth and capacity so that the complete failure of
one of the distribution nodes does not impact the performance of the network from a bandwidth or
switching capacity perspective.

23
Figure 8 Redundant Network Nodes
Campus network devices can currently provide a high level of availability within the individual nodes.
The Cisco Catalyst 6500 and 4500 switches can support redundant supervisor engines and provide
Layer-2 Stateful Switchover (SSO), which ensures that the standby supervisor engine is synchronized
from an Layer 2 perspective and can quickly assume Layer 2 forwarding responsibilities in the event of
a supervisor failure.
The Catalyst 6500 also provides Layer-3 Non-Stop Forwarding (NSF), which allows the redundant
supervisor to assume Layer-3 forwarding responsibilities without resetting or reestablishing neighbor
relationships with the surrounding Layer-3 peers in the event of the failure of the primary supervisor.
When designing a network for optimum high availability, it is tempting to add redundant supervisors to
the redundant topology in an attempt to achieve even higher availability. However, adding redundant
supervisors to redundant core and distribution layers of the network can increase the convergence time
in the event of a supervisor failure.
In the hierarchical model, the core and distribution nodes are connected by point-to-point Layer-3 routed
fiber optic links. This means that the primary method of convergence for core or distribution node failure
is loss of link. If a supervisor fails on a non-redundant node, the links fail and the network converges
around the outage through the second core or distribution node. This allows the network to converge in
60 to 200 milliseconds for EIGRP and OSPF.
When redundant supervisors are introduced, the links are not dropped during an SSO or NSF
convergence event if a supervisor fails. Traffic is lost while SSO completes, or indirect detection of the
failure occurs. SSO recovers in 1 to 3 seconds, depending on the physical configuration of device in
question. Layer 3 recovery using NSF happens after the SSO convergence event, minimizing Layer-3
119976
WAN Internet
Data Center
Access
Core
Distribution
Access
Distribution
Redundant
Nodes

24
disruption and convergence. For the same events, where 60 to 200 milliseconds of packet loss occurred
without redundant supervisors when dual-supervisor nodes were used in the core or distribution, 1.8
seconds of loss was measured.
The access layer of the network is typically a single point-of-failure, as shown in Figure 9.
Figure 9 Potential Single Points-of-Failure
While the access nodes are dual-connected to the distribution layer, it is not typical for endpoints on the
network to be dual-connected to redundant access-layer switches (except in the data center). For this
reason, SSO provides increased availability when redundant supervisors are used in the access layer and
the Layer 2/Layer 3 boundary is in the distribution layer of the network. In this topology, SSO provides
for protection against supervisor hardware or software failure with 1 to 3 seconds of packet loss and no
network convergence. Without SSO and a single supervisor, devices serviced by this access switch would
experience a total network outage until the supervisor was physically replaced or, in the case of a
software failure, until the unit is reloaded.
If the Layer 2/Layer 3 boundary is in the access layer of the network, a design in which a routing protocol
is running in the access layer, then NSF with SSO provides an increased level of availability. Similarly
to the Layer-2/Layer-3 distribution layer topology, NSF with SSO provides 1 to 3 seconds of packet loss
without network convergence compared to total outage until a failed supervisor is physically replaced
for the routed access topology.
Campus topologies with redundant network paths can converge faster than topologies that depend on
redundant supervisors for convergence. NSF/SSO provide the most benefit in environments where single
points-of-failure exist. In the campus topology, that is the access layer. If you have a Layer-2 access layer
design, redundant supervisors with SSO provide the most benefit. If you have a routed access layer
design, redundant supervisors with NSF with SSO provide the most benefit.
119977
Access
Core
Distribution
Potential
Single Points
of Failure

25
Chassis-Based Switches
Cisco chassis-based switches are modular switching platforms that provides the scalability, flexibility,
and redundancy required for building large, switched intranets and can be used in both wiring closet and
backbone healthcare applications.
Cisco Catalyst switches offer an extremely high level of manageability, security, scalability, and
investment protection, resulting in lower total cost-of-ownership (TCO) for wiring closet deployments.
With its support for hot-swappable modules, power supplies, and fans, chassis-based switches deliver
high availability for healthcare networks. Dual-redundant switching engines, active uplinks, power
supplies, and a passive backplane design ensure full system redundancy for mission-critical healthcare
environments.
One key advantage with chassis based switches is support for the In-Service Software Updates feature
(ISSU) that provides for hitless upgrades. This eliminates downtime associated with software upgrades
or version changes by allowing changes while the system remains in service. Dual Supervisor engines
also provide Active GbE or 10GbE uplinks which preserves the topology.
Since the switches support discrete line cards, line cards can be replaced (i.e., line card or supervisor)
individually and significantly reduce downtime. Also, redundant supervisor engines may be installed to
rapidly recover from supervisor failures. Supervisor engines may also be upgraded after purchase,
increasing performance and adding new features without losing any investment in the rest of the switch.
Stackable-Based Switches
Cisco Catalyst stackable switches uses Cisco StackWise technology using the capabilities of a stack of
switches. Individual switches intelligently join to create a single switching unit with a 32-Gbps
switching stack interconnect. Configuration and routing information is shared by every switch in the
stack, creating a single switching unit. See Figure 10.
Switches can be added to and deleted from a working stack without affecting performance. These new
switches support Cisco EnergyWise technology, which helps companies manage the power consumption
of their network infrastructure and network-attached devices, thereby reducing their energy costs and
carbon footprints.
http://www.cisco.com/en/US/products/ps5718/Products_Sub_Category_Home.html#~all-prod
Figure 10 Stack-based Switches
The switches are united into a single logical unit using special stack interconnect cables that create a
bidirectional closed-loop path. This bidirectional path acts as a switch fabric for all the connected
switches. Network topology and routing information is updated continuously through the stack
interconnect. All stack members have full access to the stack interconnect bandwidth. The stack is
managed as a single unit by a master switch, which is elected from one of the stack member switches.

26
Stackable switches at the access are typically used for small closet areas that serve fewer users and
devices. Stackable switches can be easily added to the Stackwise to allow port density growth on an as
needed basis. In addition, stackable switches take up less footprint and space and can help resolve some
the environmental and power issues that older hospitals face in regards to their access closets.
Eliminating Single Points-of-Failure
The hierarchical network model stresses redundancy at many levels to remove a single point-of-failure
wherever the consequences of a failure are serious. At the very least, this model requires redundant core
and distribution layer switches with redundant uplinks throughout the design. The hierarchical network
model also calls for EtherChannel interconnection for key links where a single link or line card failure
can be catastrophic.
When it comes to redundancy, however, you can have too much of a good thing. Take care not to
over-duplicate resources. There is a point of diminishing returns when the complexity of configuration
and management outweighs any benefit of the added redundancy. See Figure 11.
Figure 11 Over-Duplicated Resources
In Figure 11, the addition of a single switch to a very basic topology adds several orders of magnitude
in complexity. This topology raises the following questions:
• Where should the root switch be placed?
• What links should be in a blocking state?
• What are the implications of STP/RSTP convergence?
• When something goes wrong, how do you find the source of the problem?
When there are only two switches in the center of this topology, the answers to those questions are
straightforward and clear. In a topology with three switches, the answer depends on many factors.
119850

27
However, the other extreme is also a bad thing. You might think that completely removing loops in a
topology that requires the spanning of multiple VLANs across access-layer switches might be a good
thing. After all, this eliminates the dependence of convergence on STP/RSTP. However, this approach
can cause its own set of problems, including the following:
• Traffic is dropped until HSRP becomes active.
• Traffic is dropped until the link transitions to forwarding state, taking as long as 50 seconds.
• Traffic is dropped until the MaxAge timer expires and until the listening and learning states are
completed.
In-the-Box Redundancy (ISSU, NSF and SSO)
In-Service Software Upgrades (ISSU)
The ISSU process allows you to perform a Cisco IOS software upgrade or downgrade while the system
continues to forward packets. Cisco IOS ISSU eliminates downtime associated with software upgrades
or version changes by allowing changes while the system remains in service (see Figure 12). Cisco IOS
software high availability features combine to lower the impact that planned maintenance activities have
on network service availability, with the results of less downtime and better access to critical systems. It
is supported on Cisco 6500 and Cisco 4500 platforms.
SSO mode supports configuration synchronization. When images on the active and standby Route
Processors (RPs) are different, this feature allows the two RPs to be kept in synchronization although
they may support different sets of commands.
Figure 12 ISSU States During the ISSU Process
127257
5
Standby
New
Active
New
2
Standby
New
Active
Old
Acceptversion
Abortversion
Abortversion
Switchover
4
Standby
Old
Active
New
3
Standby
Old
Active
New
Commitversion Runversion
Loadversion
Commitversion Runversion
Loadversion
1
Standby
Old
Active
Old

28
Prerequisites for Performing ISSU
• Ensure that both the active and the standby RPs are available in the system.
• The new and old Cisco IOS software images must be loaded into the file systems of both the active
and standby RPs before you begin the ISSU process.
• Stateful Switchover (SSO) must be configured and working properly. If you do not have SSO
enabled, see the Stateful Switchover document for further information on how to enable and
configure SSO.
• Nonstop Forwarding (NSF) must be configured and working properly. If you do not have NSF
enabled, see the Cisco Nonstop Forwarding document for further information on how to enable and
configure SSO.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image
support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on
Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at
the login dialog box and follow the instructions that appear.
NonStop Forwarding (NSF) and Stateful Switchover (SSO)
The Cisco NonStop Forwarding with Stateful Switchover (SSO) is a supervisor redundancy mechanism
in Cisco IOS Software that allows extremely fast supervisor switchover at Layers 2 to 4. Supervisor
cards are supported on the Cisco Catalyst 4500 and 6500 product families.
SSO allows the standby RP to take control of the device after a hardware or software fault on the active
RP. SSO synchronizes startup configuration, startup variables, and running configuration, and dynamic
runtime data. Dynamic runtime data includes Layer-2 protocol states for trunks and ports, hardware
Layer 2 and Layer 3 tables (MAC, Forwarding Information Base [FIB], and adjacency tables), access
control lists (ACL), and QoS tables. SSO mode supports configuration synchronization. When images
on the active and standby RPs are different, this feature allows the two RPs to be kept in synchronization
although they may support different sets of commands.
Cisco NSF is a Layer 3 function that works with SSO to minimize the amount of time a network is
unavailable to its users following a switchover. The main objective of Cisco NSF is to continue
forwarding IP packets following an RP switchover. Cisco NSF is supported by the EIGRP, OSPF, For
example, NSF allows the redundant supervisor to assume Layer-3 forwarding responsibilities without
resetting or reestablishing neighbor relationships with the surrounding Layer-3 peers in the event of the
failure of the primary supervisor A router running System-to-Intermediate System (IS-IS), and Border
Gateway Protocol (BGP) protocols can detect an internal switchover and take the necessary actions to
continue forwarding network traffic using Cisco Express Forwarding (CEF) while recovering route
information from the peer devices. With Cisco NSF, peer networking devices continue to forward
packets while route convergence completes and do not experience routing flaps.

29
Best Practices for Optimal Convergence
IGP/STP Selection
The many potential advantages of using a Layer-3 access design include the following:
• Improved convergence
• Simplified multicast configuration
• Dynamic traffic load balancing
• Single control plane
• Single set of troubleshooting tools (for example, ping and traceroute)
Of these, perhaps the most significant is the improvement in network convergence times possible when
using a routed access design configured with EIGRP or OSPF as the routing protocol. Comparing the
convergence times for an optimal Layer 2 access design (either with a spanning tree loop or without a
loop) against that of the Layer 3 access design, you can obtain a four-fold improvement in convergence
times, from 800-900msec for the Layer 2 design to less than 200 msec for the Layer 3 access. (See
Figure 13.)
Figure 13 Comparison of Layer 2 and Layer 3 Convergence
Although the sub-second recovery times for the Layer-2 access designs are well within the bounds of
tolerance for most enterprise networks, the ability to reduce convergence times to a sub-200 msec range
is a significant advantage of the Layer-3 routed access design. To achieve the convergence times in the
Layer 2 designs shown above, you must use the correct hierarchical design and tune HSRP/GLBP timers
in combination with an optimal Layer-2 spanning tree design. This differs from the Layer 3 campus,
148421
0
200
400
600
800
1000
1200
1400
1600
1800
2000
MaximumVoiceLoss(msec.)
OSPF L3 AccessL2 802.1w & OSPF L2 802.1w & EIGRP EIGRP L3 Access

30
where it is necessary to use only the correct hierarchical routing design to achieve sub-200 msec
convergence. The routed access design provides for a simplified high availability configuration. The
following section discusses the specific implementation required to meet these convergence times for the
EIGRP and OSPF routed access design.
Note For additional information on the convergence times, see the High Availability Campus Recovery
Analysis design guide, located at the following URL:
http://www.cisco.com/en/US/netsol/ns815/networking_solutions_program_home.html.
Only use Layer-2 looped topologies if it cannot be avoided. In general practice, the most deterministic
and best-performing networks in terms of convergence, reliability, and manageability are free from
Layer-2 loops and do not require STP to resolve convergence events under normal conditions. However,
STP should be enabled to protect against unexpected loops on the access or user-facing interfaces.
In the reference hierarchical design, Layer-2 links are deployed between the access and distribution
nodes. However, no VLAN exists across multiple access layer switches. Additionally, the
distribution-to-distribution link is a Layer-3 routed link. This results in a Layer-2 loop-free topology in
which both uplinks from the access layer are forwarding from an Layer-2 perspective and are available
for immediate use in the event of a link or node failure (see Figure 14).
Figure 14 Layer 2 Loop-Free Topology
For STP design and deployment and configuration, refer to the Campus Network High Available Design
Guide at the following URL:
http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/HA_campus_DG/hacampusdg.html
IGP (Routing Protocols)
Both small and large enterprise campuses require a highly available, intelligent network infrastructure
with securement to support business solutions such as voice, video, wireless, and mission-critical data
applications. The use of hierarchical design principles provides the foundation for implementing campus
networks that meet these requirements. The hierarchical design uses a building block approach
leveraging a high-speed routed core network layer to which multiple independent distribution blocks are
attached. The distribution blocks comprise of two layers of switches: the actual distribution nodes that
act as aggregators and the wiring closet access switches.
119818
Access
Distribution
Layer 3
Layer 2 links
HSRP model
HSRP Active
VLAN 20,140
Layer 2 links
HSRP Active
VLAN 40,120
10.1.20.0
10.1.120.0
VLAN 20 Data
VLAN 120 Voice
10.1.40.0
10.1.140.0
VLAN 40 Data
VLAN 140 Voice

31
In larger IP environments, Cisco recommends that most enterprise organizations standardize on OSPF,
ISIS, or EIGRP for IP routing. These protocols support variable length subnet mask (VLSM),
summarization, and enhanced feature capabilities, including routing protocol safeguards. A lack of
routing standardization can result in poor routing hierarchy, poor convergence times, added complexity,
and poor manageability.
IP routing protocol hierarchy is an extension of normal device hierarchy that adds resiliency to IP
routing.
• Creating routing domains and summarizing contiguous IP blocks towards the core of the network
can accomplish IP routing hierarchy.
• OSPF forces hierarchy by requiring well-defined routing areas.
• Larger IP networks may also have an additional core IP layer configured using the BGP protocol to
help scale the environment and to help contain routing problems due to link/device instability or
device resource limitations.
Summarization is a key aspect of IP routing protocol design that helps reduce required routing resource
requirements and reduces or prevents the affect of link flapping on routing protocol cores.
Summarization also helps reduce link overhead on WAN links that can be a significant amount of traffic
over a WAN connection.
• IP networks with over 1000 subnets should have well defined areas with IP summarization towards
the core of the network. This summarization is normally configured at OSPF area boundaries or
distribution router interfaces connected to the network core.
• Networks with over 1000 routes should consider stub routing for access sites or routing filters to
advertise major network blocks and/or default routes.
• Larger scale IP networks with over 5000 subnets should consider a BGP core to limit routing
protocol overhead. The need for a BGP core should be closely examined and weighed against adding
summarization and routing protocol safeguards to the existing IGP (interior gateway protocol)
routing domain.
• IP Summarization should also be examined for WAN access sites to reduce routing protocol
overhead on network devices and network links.
Routing protocol safeguards are configurable, protective mechanisms that prevent routes from being
readvertised back into the originating domain. Routing protocol safeguards prevent WAN sites from
advertising routes back into the core, and protect against routing protocol configuration mistakes, such
as accidentally advertising the default route into the core from a WAN location.
• Route filters should be configured on the appropriate interfaces to protect against bogus routes and
non-originating routes.
• In LAN environments another safeguard is to configure passive-interface on access VLANs to
prevent core routing across user or server subnets and to generally reduce routing protocol overhead
where it is not required.
HSRP is a software feature that permits redundant IP default gateways on server and client subnets. On
user or server subnets that require default gateway support, HSRP provides increased resiliency by
providing a redundant level-3 IP default gateway. In redundant user and server subnets HSRP should be
configured in a manner optimal for the particular environment.
In the typical hierarchical campus design, distribution blocks use a combination of Layer 2, Layer 3, and
Layer 4 protocols and services to provide for optimal convergence, scalability, security, and
manageability. In the most common distribution block configurations, the access switch is configured as
a Layer 2 switch that forwards traffic on high speed trunk ports to the distribution switches. The

32
distribution switches are configured to support both Layer 2 switching on their downstream access
switch trunks and Layer 3 switching on their upstream ports towards the core of the network, as shown
in Figure 15.
Figure 15 Traditional Campus Design Layer 2 Access with Layer 3 Distribution
The function of the distribution switch in this design is to provide boundary functions between the
bridged Layer 2 portion of the campus and the routed Layer 3 portion, including support for the default
gateway, Layer-3 policy control, and all the multicast services required.
Note Although access switches forward data and voice packets as Layer 2 switches, in the Cisco campus
design they use advanced Layers 3 and 4 features supporting enhanced QoS and edge security services.
An alternative configuration to the traditional distribution block model illustrated above is one in which
the access switch acts as a full Layer-3 routing node (providing both Layer 2 and Layer 3 switching),
and the access-to-distribution Layer-2 uplink trunks are replaced with Layer 3 point-to-point routed
links. This alternative configuration, in which the Layer 2/3 demarcation is moved from the distribution
switch to the access switch (as shown in Figure 16) appears to be a major change to the design, but is
actually simply an extension of the current best practice design.
Core
Access
Distribution
VLAN 3 Voice
VLAN 103 Data
VLAN 2 Voice
VLAN 102 Data
VLAN n Voice
VLAN 100 + n Data
132702
Layer 3
Layer 2
HSRP Active
Root Bridge
HSRP
Standby

33
Figure 16 Routed Access Campus Design—Layer 3 Access with Layer 3 Distribution
In both the traditional Layer 2 and the Layer 3 routed access design, each access switch is configured
with unique voice and data VLANs. In the Layer 3 design, the default gateway and root bridge for these
VLANs is simply moved from the distribution switch to the access switch. Addressing for all end
stations and for the default gateway remain the same. VLAN and specific port configuration remains
unchanged on the access switch. Router interface configuration, access lists, “ip helper”, and any other
configuration for each VLAN remain identical, but are now configured on the VLAN Switched Virtual
Interface (SVI) defined on the access switch, instead of on the distribution switches. There are several
notable configuration changes associated with the move of the Layer 3 interface down to the access
switch:
• It is no longer necessary to configure an HSRP or GLBP virtual gateway address as the “router”
interfaces for all the VLANs are now local.
• Similar with a single multicast router, for each VLAN it is not necessary to perform any of the
traditional multicast tuning such as tuning PIM query intervals or to ensure that the designated
router is synchronized with the active HSRP gateway.
For details on Configuraiton Layer 3 access, refer to the following URL:
http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/HA_campus_DG/hacampusdg.html
STP
Highly available networks require redundant paths to ensure connectivity in the event of a node or link
failure. Various versions of Spanning Tree Protocol (STP) are used in environments that include
redundant L2 loops. STP lets the network deterministically block interfaces and provide a loop-free
topology in a network with redundant links
Figure 17 STP Operation
Core
Access
Distribution
VLAN 3 Voice
VLAN 103 Data
VLAN 2 Voice
VLAN 102 Data
VLAN n Voice
VLAN 00 + n Data
132703
Layer 3
Layer 2
119817
STOP
A
B

34
Network hierarchy and redundancy will not improve availability if the network protocol design does not
meet Cisco leading-practices. Cisco supports a generous assortment of protocols and features; however,
the two protocols that have the greatest potential impact to overall network availability are the spanning
tree protocol for LAN environments at Layer 2, and IP at Layer 3. Other protocols and features that
pertain to improved network availability include hot standby routing protocol (HSRP), stateful
switchover (SSO), and nonstop forwarding (NSF).
STP at Layer 2 is designed to support failover recovery at the device level due to link or device failures.
Spanning tree can be left at a default configuration; however this can often lead to sub-optimal
convergence and potential loop conditions. The biggest problem with spanning tree domains is the
failure to identify a loop condition, which generally results in a loss of multiple devices within the
spanning tree domain until the devices are rebooted and the condition repaired.
The best spanning tree domains with the highest availability tend towards fewer devices with more
stringent spanning tree configuration templates. For user access devices with non-redundant access
connectivity, simple spanning tree domains of one access device and two redundant distribution links
and devices is recommended. For servers with dual NICs a larger spanning tree domain is required with
an additional access device. In addition, the following spanning tree configuration steps or features are
generally recommended. Keep in mind that a Cisco design review is always recommended to identify
leading-practices for any individual design topology.
• Configure the root bridge at the distribution level
• Configure only Layer 3 between distribution switches unless HA servers are required with
connections to multiple access switches.
• Configure RPVST+ within loop spanning tree domains.
• Consider the Root Guard feature.
• Disable PagP (port aggregation protocol) for user-facing ports.
• Disable DTP (dynamic trunking protocol) for user-facing ports.
• Enable BPDU Guard (bridge protocol data units), that protects the network by disabling a port
connected to a misconfigured device sending spanning tree BPDUs.
Achieving Six Sigma Availability
Highly available networks are a combination of well-designed networks, thoughtfully implemented
processes and procedures and a robust set of tools for proactively managing the network environment.
Table 1 highlights the timescales associated with high availability.
For a service to be “six-sigma”, it can only be unavailable for 31.53 seconds every year. Multiplied by
the number of services, number of users, and the number of devices in a given network, managing to
sustain a “six-sigma” network is a daunting and resource-intensive task.
Table 1 High Availability Time Scales
Availability Downtime Per Year
99.9% 8.76 hours (31536 seconds)
99.99% 52.56 minutes (3153.6 seconds)
99.999% (five-9s) 5.25 minutes (315.36 seconds)
99.9999% (six-sigma) 31.53 seconds

35
Achieving such high availability from the care provider’s perspective is sometimes a significant
challenge as it equates to approximately 5 minutes of downtime per year.
Within data centers that host EMR/EHR systems, such availability at the network layer can indeed be
achieved. In some cases, however, the applications used to support the clinical staff are simply not
architected to achieve this level of availability and often result in downtimes from the caregiver’s
perspective that well exceeding these goals. These outages are mainly due to software upgrades or
patches being applied, or in some cases upstream systems such as payers or external testing labs.
Design Option: Virtual Switching System (VSS)
Virtual Switching System or VSS enables unprecedented functionality and availability of healthcare
campus networks by integrating network and systems redundancy into a single node. The end-to-end
healthcare network enabled with VSS capability allows flexibility and availability described in this
document.
The single logical node extends the integration of services in a healthcare campus network beyond what
has been previously possible, without significant compromise. Integration of wireless, Firewall Services
Module (FWSM), Intrusion Prevention System (IPS), and other service blades within the VSS allow for
the adoption of an array of service ready for campus design capabilities. For example, VSS
implementation allows for the applications of Internet-edge design (symmetric forwarding) and data
center interconnection (loop-less disaster recovery). Though this document only discusses the
application of VSS in a healthcare campus at the distribution layer, it is up to the network designer to
adapt the principles illustrated in this document to create new applications and not limit the use of VSS
to the campus environment.
The key underlying capability of VSS is that it allows the clustering of two physical chassis together into
a single logical entity. See Figure 18.
Figure 18 Conceptual Diagram of VSS
This virtualization of the two physical chassis into a single logical switch fundamentally alters the
design of campus topology. One of the most significant changes is that VSS enables the creation of a
loop-free topology. In addition, VSS also incorporates many other Cisco innovations—such as Stateful
Switch Over (SSO) and Multi-chassis EtherChannel (MEC)—that enable nonstop communication with
increased bandwidth to substantially enhance application response time. Key business benefits of the
VSS include the following:
• Reduced risk associated with a looped topology
• Nonstop business communication through the use of a redundant chassis with SSO-enabled
supervisors
• Better return on existing investments via increased bandwidth form access layer
Switch 1 + Switch 2
Virtual Switch Domain
Virtual
Switch Link
= VSS–Single
Logical Switch
227020

36
• Reduced operational expenses (OPEX) through increased flexibility in deploying and managing new
services with a single logical node, such as network virtualization, Network Admission Control
(NAC), firewall, and wireless service in the campus network
• Reduced configuration errors and elimination of First Hop Redundancy Protocols (FHRP), such as
Hot Standby Routing Protocol (HSRP), GLBP, and VRRP
• Simplified management of a single configuration and fewer operational failure points
In addition, the ability of the VSS to integrate services modules, bring the full realization of the Cisco
campus fabric as central to the services-oriented campus architecture.
Application of VSS
Application of VSS in a multilayer design can be used wherever the need of Layer-2 adjacency is
necessary, not just for application but for flexibility and practical use of network resources. Some of the
use cases are as follows:
• Medical devices and applications requiring Layer-2 adjacency. data VLANs spanning multiple
access-layer switches
• Simplifying Layer-2 connectivity by spanning VLANs per building or location
• Network virtualization (patient and guest VLAN supporting transient connectivity, healthcare
partner, and payor connectivity)
• Conference, media room and public access VLANs spanning multiple facilities
• Network Admission Control (NAC) VLAN (quarantine, posture, and patching) for patient guest
services and visiting physicians/clinicians who use their smart phones and laptop computers
• Partner (payor) resources requiring spanned VLANs
• Wireless VLANs without centralized controller
• Network management and monitoring (SNMP, SPAN)
VSS boosts nonstop communications through:
• Interchassis stateful failover results in no disruption to applications that rely on network state
information (for example, forwarding table info, NetFlow, Network Address Translation [NAT],
authentication, and authorization). VSS eliminates L2/L3 protocol reconvergence if a virtual switch
member fails, resulting in deterministic subsecond virtual switch recovery.
• EtherChannel (802.3ad or Port Aggregation Protocol (PAgP) for deterministic subsecond Layer-2
link recovery, removing the dependency on Spanning Tree Protocol (STP) for link recovery.
On the access side of VSS, downstream devices still connect to both physical chassis, but Multichassis
EtherChannel (MEC) presents the virtual switch as one logical device. MEC links can use
industry-standard 802.1ad link aggregation or port aggregation protocol. Either way, MEC eliminates the
need for spanning tree. All links within a MEC are active until a circuit or switch failure occurs, and then
traffic continues to flow over the remaining links in the MEC.
On the core side of VSS, devices also use MEC connections to attach to the virtual switch. This
eliminates the need for redundancy protocols such as HSRP or VRRP, and also reduces the number of
routes advertised. As on the access side, traffic flows through the MEC in an “active/active” pattern until
a failure, after which the MEC continues to operate with fewer elements. For more information refer to
the following document:
http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/VSS30dg/campusVSS_DG.html

37
Virtual Switching System (VSS) Design
To better understand the application of the VSS to the campus network, it is important to adhere to
existing Cisco architecture and design alternatives. This section illustrates the scope and framework of
Cisco campus design options and describes how these solve the problems of high availability, scalability,
resiliency, and flexibly. It also describes the inefficiency inherent in some design models.
The process of designing a healthcare campus architecture is challenged by clinical application, high
availability, and security requirements. The need for nonstop communication is becoming a basic
starting point for most healthcare networks. The business case and factors influencing these designs are
discussed in following design framework:
Enterprise Campus 3.0 Architecture: Overview and Framework
http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/campover.html
VSS at the Distribution Block
The Campus 3.0-design framework covers the functional use of a hierarchy in the network in which the
distribution block architecture (also referred as access-distribution block) governs a significant portion
of campus design focus and functionality. The access-distribution block comprises two of the three
hierarchical tiers within the multi-tier campus architecture: the access and distribution layers. While
each of these two layers has specific services and feature requirements, it is the network topology control
plane design choices (the routing and spanning tree protocols) that are central to how the distribution
block is glued together and how it fits within the overall architecture. There are two basic design options
for how to configure the access-distribution block and the associated control plane:
• Multilayer or multi-tier (Layer 2 in the access block)
• Routed access (Layer 3 in the access block)
While these designs use the same basic physical topology and cabling plant, there are differences in
where the Layer-2 and Layer-3 boundaries exist, how the network topology redundancy is implemented,
and how load balancing works, along with a number of other key differences between each of the design
options. Figure 19 depicts the existing design choices available.
Figure 19 Traditional Design Choices
L3 Core
NSF/SSO
L3 Distribution
NSF/SSO
Multilayer Design Routed Access Design
L3 Access
4500 and 6500
NSF/SSO
L2 Access
4500 and 6500
SSO
L2 Access
3750/3750E
Stackwise
L3 Access
3750/3750E
Stackwise
+ NSF
226914

38
The multilayer design is the oldest and most prevalent design in customer networks while routed access
is relatively new. The most common multilayer design consists of VLANs spanning multiple
access-layer switches to provide flexibility for applications requiring Layer-2 adjacency (bridging
non-routable protocols) and routing of common protocol, such as IPX and IP. This form of design suffers
from a variety of problems, such as instability, inefficient resources usage, slow response time, and
difficulty in managing end host behavior. See Figure 20.
Figure 20 Multilayer Design—Looped Topology
In the second type of multilayer design, VLANs do not span multiple closets. In other words VLAN =
Subnet = Closet. This design forms the basis of the best-practice multilayer design in which confining
VLANs to the closet eliminate any potential spanning tree loops (see Figure 21). However, this design
does not allow for the spanning of VLANs. As an indirect consequence, most legacy networks have
retained a looped Spanning Tree Protocol (STP)-based topology—unless a network topology adoption
was imposed by technology or business events that required more stability, such as implementation of
voice over IP (VoIP).
Loop Free Topology
All VLANs spans All Access-switches
226915
VLAN 10 VLAN 10VLAN 10
Core
L2

39
Figure 21 Multilayer Design—Loop Free Topology
When VSS is used at the distribution block in a multilayer design, it brings the capability of spanning
VLANs across multiple closets, but it does so without introducing loops. Figure 22 illustrates the
physical and logical connectivity to the VSS pair.
Figure 22 Virtual Switch at the Distribution Layer
With VSS at the distribution block, both multilayer designs transform into one design option as shown
in Figure 23, where the access layer is connected to single logical box through a single logical
connection. This topology allows the unprecedented option of allowing VLANs to span multiple closets
in loop-free topology.
Loop Free Topology
VLAN = Subnet = Closet
226916
Core
L3
Physical Network
226917
Logical Network
Core Core

40
Figure 23 VSS-Enabled Loop-Free Topology
The application of VSS is wide ranging. VSS application is possible in all three tiers of the hierarchical
campus—core, distribution, and access—as well as the services block in both multilayer and
routed-access designs. However, the scope of this document is intended as an application of VSS at the
distribution layer in the multilayer design. It also explores the interaction with the core in that capability.
Many of the design choices and observations are applicable in using VSS in routed-access design,
because it is a Layer-3 end-to-end design. However, the impact of VSS in multilayer is the most
significant because VSS enables a loop-free topology along with the simplification of the control plane
and high availability.
In summary, VSS provides the following key benefits to healthcare providers:
• Eliminates the need for existing gateway redundancy protocols such as HSRP/VRRP/GLBP.
• Multichassis EtherChannel (MEC) is a Layer-2 multipathing technology that creates simplified
loop-free topologies, eliminating the dependency on Spanning Tree Protocol, which may also be
activated to protect strictly against any user misconfiguration. VSS uses EtherChannel (802.3ad or
Port Aggregation Protocol (PAgP) for deterministic sub second Layer-2 link recovery, removing the
dependency on Spanning Tree Protocol for link recovery.
• Enables true server high availability. Servers are connected via a MEC link, with at least 2 Gb of
bandwidth. Provides fault tolerance benefits as well. Enables standards-based link aggregation for
the server network interface cards (NIC Teaming) across redundant data center switches,
maximizing server bandwidth throughput and increasing the number of standards-based components
in the data center and eliminates the requirement to configure proprietary NIC vendor availability
mechanisms.
• Reduced network management. Less links, fewer peering relationships to manage, and one
configuration file to manage. Single point of management, IP address, and routing instance for the
VSS switch. Removes the need to configure redundant switches twice with identical policies.
• Enhance fast software upgrades (EFSUs). Allows you to upgrade the code on your core network
equipment, with very minimal impact to the users.
VSS Loop Free Topology
VLANs spans Access-switches
226918
Core

41
• Flexible deployment options. The underlying physical switches do not have to be collocated. The
two physical switches are connected with standard 10-Gigabit Ethernet interfaces and as such can
be located any distance based on the distance limitation of the chosen 10-Gigabit Ethernet optics.
• Interchassis stateful failover results in no disruption to applications that rely on network state
information (for example, forwarding table information, NetFlow, Network Address Translation
[NAT], authentication, and authorization). VSS eliminates L2/L3 protocol reconvergence if a virtual
switch member fails, resulting in deterministic sub-second virtual switch recovery.
• Conserves bandwidth by eliminating unicast flooding caused by asymmetrical routing in traditional
campus designs and optimizes the number of hops for intra campus traffic using multichassis
EtherChannel enhancements.
• VSS leverages existing multilayer switching architecture. VSS enhances our customers existing
multilayer switching architecture by simplifying and maintaining the fundamental architecture,
resulting in an easy adoption of the technology.
Environmental Considerations
Environmental aspects are another network design element that must be considered. As with any highly
available network, single points-of-failure should be eliminated if at all possible. Loss of power is a
potential point-of-failure and probably one of the most common causes of network outages.
Power Management
Healthcare environments have some unique requirements due to the nonstop operations of many
healthcare facilities and the criticality of the mission at hand. Backup generators are typically deployed
in acute care settings, but often in a limited fashion. These generators often do not have the capacity to
support the entire facility for a reasonable amount of time, so certain areas are deemed critical and
protected while other areas are left unprotected. Understanding these restrictions and protecting the
appropriate network equipment to maintain critical network services is very important.
PoE
Power over Ethernet (PoE) is increasingly being used in healthcare environments to support the
explosion of wireless access points and IP-based communication systems. Although aggregate power
may not change substantially during steady state operation, the distribution points and backup provisions
may change substantially. Wiring closets with a high concentration of PoE ports will require more AC
circuit capacity and backup provisions then a lightly loaded closet. The number of Uninterruptible Power
Supply (UPS) units scattered across a facility may be reduced as more devices shift to PoE and use a
more centralized UPS approach within the wiring closets.
Redundant Power
Redundancy can be achieved by leveraging network devices with dual-power supply capabilities and
UPS equipment and/or backup generators where feasible.

42
Convergence of Biomedical and General Purpose IT Networks
Cooling—BTU Management
Equipment cooling must also be considered. As power distribution shifts to wiring closets the heat
generated in the wiring closet increases as well. Many wiring closets were not originally designed to
handle the power load and dissipate the heat generated in a PoE environment. Data centers and larger
wiring closets (main distribution facilities (MDF)) are often well engineered to handle power and
cooling requirements, but smaller closets (intermediate distribution facilities (IDF)) are often
overlooked.
Overview
There is a growing trend that is focused on the convergence of biomedical and general purpose IT
networks. This trend is driven by the need to manage the growing costs of healthcare through leveraging
the reliability, high availability, and speed of a well designed IT network.
In the past, all biomedical devices lived on dedicated networks and frequencies. Often these networks
did not have connectivity to IT resources and usage of IT networks for biomedical device needs was not
a viable option. These biomedical networks often were so specialized and expensive, they often did not
require high availability because the bedside was the most important functionality.
Today, vendors have the same cost-cutting concerns and are often in other lines of business where they
touch IT networks. Over time, these biomedical devices have adopted IP stack support and are using
traditional LAN/WAN network and traditional wireless frequencies.
Medical devices used in healthcare provide a wide variety of function from monitoring, notification, and
delivery of medicine. Most of these devices often are under restrictions from regulatory bodies or other
such public agencies, which restrict the modification in any way except as governed by a defined
regulatory process1
. The end result may be very dated and unpatched operating systems running mission
critical systems.
This unpatched device, now on an IT network (due to the convergence), creates a hole or path to which
a worm, virus, or bot can take hold and being infected is not the end all, but how it affects these critical
systems. Most of the systems end up unavailable or unable to report back to central stations.
When building networks that house not only IT or general purpose machines but also healthcare or
biomedical devices, there are tools and architectures that lend them to be reliable, highly available with
securement.
1. For example, a device classified as falling under US Food and Drug Administration regulation may likely
require the device manufacturer's validation testing of safety and effectiveness, and, regulatory body
notification / approval prior to a modification being allowed for deployment into the field. Such testing,
notification / approval may require a manufacturer's significant investments in time and resources.

43
Biomedical Device Dependencies
Biomedical devices such as patient monitoring (PM), ventilators, and infusion pumps are the fastest
growing population of network connected devices (wired or wireless) in the provider space. For example,
some larger healthcare providers expect to have 150,000 biomedical devices on the converged IP
network in the next 3 to 4 years. Medical Device Manufacturer's (MDMs) continue to introduce devices
that are IP-enabled and this trend continues to pick up momentum. Hospitals use a variety of these
biomedical devices.
Today, however, many biomedical devices require Layer-2 support to communicate back to their
associated backend server or central station. In this case, patient monitors and centralized stations must
reside on their own dedicated Layer-2 subnet. In some cases, the vendor also requires that the network
be completely dedicated for the patient monitoring application. This reduces the risk of system
performance interruptions caused by other devices residing outside the subnet. As increasingly number
of biomedical devices become IP-enabled, hospitals are looking at ways converge these devices onto to
their IT converged network.
Network Virtualization and Path Isolation
Network virtualization (see Figure 24) and path isolation is critical to building a campus architecture
inclusive of biomedical devices that is highly available, reliable, and secure. While trunking Layer 2
VLANs throughout the converged IT network is possible, it is not a viable option when promoting a
reliable, scalable network.
Figure 24 Example of the Many-to-One Mapping of Virtual to Physical Networks
221035
Virtual Network
Physical Network Infrastructure
Virtual Network Virtual Network

44
Path isolation solutions (see Figure 25) use a mix of Layer 2 and Layer 3 technologies to best address
LAN virtualization for typical LAN designs. Cisco offers the following path isolation options:
• Generic routing encapsulation (GRE) tunnels create closed user groups on the hospital LAN. This
might be used to provide for L2 connectivity for centralized medical device servers to other remote
servers/databases.
• Virtual routing and forwarding (VRF)-Lite, also called Multi-VRF Customer Edge, is a lightweight
version of MPLS. VRF-Lite allows network managers to use a single routing device to support
multiple virtual routers. They can then use any IP address space for any given VPN, regardless of
whether it overlaps or conflicts with other VPNs' address spaces.
• Multiprotocol label switching (MPLS) VPNs also partition a campus network for closed user
groups. In the past, MPLS was not widely deployed in enterprise networks because of the lack of
support on LAN switches. With the introduction of the Cisco Catalyst 6500 Series, MPLS
technology is now affordable for healthcare facilities.
• Overlay Transport Virtualization (OTV) is a feature of the Nexus OS operating system that
encapsulates Layer-2 Ethernet traffic within IP packets, allowing Ethernet traffic from a local area
network (LAN) to be tunneled over an IP network to create a “logical data center” spanning several
data centers in different locations. This is an emerging technology that may have benefits in the
future for providing path isolation. For details about OTV, refer to the “Overlay Transport
Virtualization (OTV)” section on page 46.
Figure 25 Functional Elements Needed in Virtualized Campus Networks
For further detail about individual technologies, refer to the Network Virtualization—Path Isolation
Design Guide at the following URL:
http://www.cisco.com/en/US/docs/solutions/Enterprise/Network_Virtualization/PathIsol.html
221036
GRE
VRFs
MPLS
Access Control
Functions
Path Isolation Services Edge
Branch - Campus WAN – MAN - Campus
Authenticate client (user,
device, app) attempting to
gain network access
Authorize client into a
Partition (VLAN, ACL)
Deny access to
unauthorized clients
Maintain traffic partitioned over
Layer 3 infrastructure
Transport traffic over isolated
Layer 3 partitions
Map Layer 3 Isolated Path to VLANs
in Access and Services Edge
Provide access to services:
Shared
Dedicated
Apply policy per partition
Isolated application environments
if necessary
Data Center - Internet Edge -
Campus
IP
LWAPP

45
GRE Tunneling
Generic routing encapsulation (GRE) is a tunneling protocol used to transport packets from one network
through another network. Some medical device manufacturers have used GRE tunneling in converged
networks to allow Layer-2-based medical device applications to communicate with the discrete medical
devices, over Layer-3 routed networks.
VRF/VRF-Lite
Virtual Routing and Forwarding (VRF) is a technology that allows multiple instances of a routing table
to coexist within the same router at the same time. Because the routing instances are independent, the
same or overlapping IP addresses can be used without conflicting with each other.
VRF or VRF-Lite are two methods of virtualizing the network and providing path isolation.
The simplest form of VRF implementation is VRF-Lite. In this implementation, each router within the
network participates in the virtual routing environment in a peer-based fashion. While simple to deploy
and appropriate for small-to-medium enterprises and shared data centers, VRF-Lite does not scale to the
size required by large hospitals, because there is the need to implement each VRF-instance on every
router. See Figure 26.
Figure 26 VRF and VRF-Lite
MPLS Campus
Multiprotocol Label Switching (MPLS) VPN is a path isolation option inside the healthcare network to
logically isolate traffic between devices belonging to separate groups (i.e., medical devices and patient
care devices).
The main advantage of MPLS VPN when compared to other path isolation technologies is the capability
of dynamically providing any-to-any connectivity without facing the challenges of managing many
point-to-point connections (as for example is the case when using GRE tunnels). MPLS VPN facilitates
full mesh of connectivity inside each provided segment (or logical partition) with the speed of
provisioning and scalability found in no other protocol. In this way, MPLS VPN allows the consolidation
of separate logical partitions into a common network infrastructure.
Campus
Core
VRF Blue
VRF Red
VRF Green
VLAN 21 Red
VLAN 22 Green
VLAN 23 Blue
226031
L3Si Si
Layer 2
Trunks
Layer 2
Trunks

Medical grade network_campus

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Medical grade network_campus

Similar to Medical grade network_campus (20)

Recently uploaded

Recently uploaded (20)

Medical grade network_campus