Technical Proposal: Virtual Campus Network Solution

Virtual Campus Network Solution
Technical Proposal
Issue
01
Date
2011-06-22
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address:
Huawei Industrial Base

Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website:
http://www.huawei.com
Email:
support@huawei.com
Issue 01 (2011-06-22)
Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd

Technical Proposal
Contents
Contents
1 Overview: Virtual Campus Network Solution ....................................................................... 1
1.1 Background ...................................................................................................................................................... 1
1.2 Virtual Campus Network Solutions .................................................................................................................. 3
1.2.1 Horizontal Virtualization Solution .......................................................................................................... 3
1.2.2 Vertical Virtualization Solution ............................................................................................................... 4
1.2.3 Integrated Network Deployment ............................................................................................................. 6
1.3 Market Positioning and Intended Customers ................................................................................................... 7
2 Horizontal Virtualization Design Proposal ............................................................................. 8

2.1 Overview .......................................................................................................................................................... 8
2.2 Network Topology Design ............................................................................................................................... 8
2.3 Core Layer Design ......................................................................................................................................... 10
2.4 Aggregation Layer Design ............................................................................................................................. 11
2.5 Access Layer Design ...................................................................................................................................... 14
2.6 Edge Network Design .................................................................................................................................... 15
3 Vertical Virtualization Design Proposal ................................................................................ 16

3.1 Overview ........................................................................................................................................................ 16
3.2 Physical Networking Design .......................................................................................................................... 16
3.3 VLAN Design ................................................................................................................................................ 16
3.4 IP, DHCP, and DNS Design ........................................................................................................................... 17
3.5 IGP Design ..................................................................................................................................................... 17
3.5.1 IGP Selection ........................................................................................................................................ 17
3.5.2 OSPF Design......................................................................................................................................... 18
3.5.3 IS-IS Design .......................................................................................................................................... 18
3.6 BGP Design .................................................................................................................................................... 19
3.7 MPLS Design ................................................................................................................................................. 19
3.8 VPN Design ................................................................................................................................................... 20
3.8.1 Intranet Service Isolation ...................................................................................................................... 20
3.8.2 Communication Between VPNs ........................................................................................................... 21
3.8.3 Internet Access: Internal User ............................................................................................................... 21
3.8.4 Campus Network Access: Branch Companies ...................................................................................... 23
3.8.5 Campus Network Access: Remote Users .............................................................................................. 24
3.8.6 Campus Network Access: SOHO Users ............................................................................................... 25
Issue 01 (2011-06-22)

ii

Technical Proposal
Contents
3.8.7 Campus Network Access: Customers ................................................................................................... 26

3.9 Reliability Design........................................................................................................................................... 27
3.9.1 IGP Reliability ...................................................................................................................................... 27
3.9.2 MPLS Reliability .................................................................................................................................. 28
4 Recommended Products ............................................................................................................ 29
Issue 01 (2011-06-22)

iii

Technical Proposal
1 Overview: Virtual Campus Network Solution
Overview: Virtual Campus Network

Solution
1.1 Background
An enterprise campus network is a high-speed network connecting large numbers of offices
and departments over a limited geographical area made up of interconnected LANs.
These large-scale enterprise campus networks must be capable of supporting a large number
of users and various terminals simultaneously accessing the network. Therefore, to implement
full-scale enterprise informatization, a high-performance, manageable, and reliable campus
network is required.
Figure 1-1 is an example of traditional campus network topology, using layered and modular
deployment models.
Layered deployment: A campus network is designed with a three-layer architecture,

comprised of the access, aggregation, and core layers. Different functions and features
are deployed on each layer, facilitating flexible network extension.
The 2-layer design is usually applied at the access layer, with a Layer 3 gateway
configured on an aggregation device. A dual-node design is used at the aggregation and
core layers to ensure node reliability.
Modular deployment: Enterprise network physical and logical structures are

implemented as a modular network structure, to facilitate network management and
expansion.
Issue 01 (2011-06-22)


Technical Proposal
Figure 1-1 Traditional campus network architecture
WAN
Internet
Data Center
As a growing number of new services are launched, traditional campus networks must expand,
and are therefore faced with the following problems:
Dual-node redundant design at the aggregation and core layers complicates network
structure and hinders network expansion.
Redundant structure causes loops on the network tree structure, and the scale of ring
networks grow proportionally with the size of enterprises. Loop-prevention protocols,
such as the Multiple Spanning Tree Protocol (MSTP), are usually configured to prevent
loops, and Virtual Router Redundancy Protocol (VRRP) is run to support node
redundancy backup, complicating network protocol deployment.
Department/group resource access permissions must be carefully controlled, and

end-to-end data isolation is necessary for secure service access, transmission, and
applications. However, the physical isolation technique is outdated and cannot meet
these demands, resulting in repetitious network constructions, dispersed management,
and inconvenient security policies.
Huawei's virtual campus network solution resolves these issues and prepares enterprises for
future growth by ensuring quick and flexible network expansion without compromising
service quality.
Issue 01 (2011-06-22)


Technical Proposal
1.2 Virtual Campus Network Solutions

1.2.1 Horizontal Virtualization Solution
In the horizontal virtualization solution, cluster/stack technology is used at the core,
aggregation, and access layers of the campus network so multiple physical devices can be
virtualized into a single logical device. This solution simplifies network structures and
protocol deployment and improves network reliability and manageability. Figure 1-2 shows
an example of the horizontal virtualization solution.
Figure 1-2 Example of the horizontal virtualization solution
CSS/
iStack
CSS/
iStack
LAG
LAG
CSS/
iStack
LAG
CSS
WAN
Internet
WAN
Data Center
Internet
Data Center
In the horizontal virtualization solution:
Cluster switch system (CSS) technology is used at the core layer to virtualize multiple
core switches (S9300s) into a single logical switch.
CSS or iStack technology is used at the aggregation layer or access layer to combine
multiple aggregation switches or access switches into a single logical switch.
Link aggregation groups (LAGs) bundle multiple physical interfaces into a single logical
interface to increase bandwidth and improve connection reliability.
Simplified Network Structure

The horizontal virtualization solution takes complex network topologies and virtualizes them
into simpler, easier to manage and maintain topologies.
In Figure 1-2, cluster/stack technology simplifies complex networks structure into layered,
simple network structures, improving network manageability.
The stack system virtualizes all the switches in each building into a single logical switch,
simplifying network structure, improving network robustness and reliability, and facilitating
network management and maintenance.
Simplified Protocol Deployment

On traditional campus networks, dual-node redundant backup is usually performed on devices
at the aggregation and core layers. As a result, many loops occur on the traditional campus
Issue 01 (2011-06-22)


Technical Proposal
network, which must be eliminated using protocols such as MSTP and VRRP. In addition,
redundant backup makes protocol deployment complicated.
The horizontal virtualization solution virtualizes multiple devices into a single logical device
using CSS/iStack technology at the aggregation and core layers. This solution changes the
mesh topology into a tree topology, where network layers are connected by a LAG. Using this
solution, you can prevent loops without deploying cumbersome protocols like MSTP and
VRRP.
Link Load Balancing and Redundant Backup

When CSS/iStack technology is used, network layers are connected by a LAG. This method
can implement link load balancing and redundant backup in either of the following modes:
Manual mode: Trunk links and load balancing are manually configured. In manual mode,
all the links in a trunk link participate in load balancing without acting as a redundant
backup.
Link Aggregation Control Protocol (LACP) mode: Load balancing and redundant backup
parameters are handled automatically during LACP negotiation. In LACP mode, M:N
load balancing and redundant backup can be implemented among the links of a trunk.
Here, M specifies the number of active links, which are responsible for forwarding data
and implement load balancing; N specifies the number of inactive links, which act as
backup links.
Flexible Network Expansion

You can expand interfaces, improve system processing capability, and increase uplink
bandwidth by simply adding new switches to the cluster/stack system.
1.2.2 Vertical Virtualization Solution

The vertical virtualization solution divides a physical network into several independent
logically isolated networks. This solution implements secure end-to-end data isolation
between terminals and services and provides on-demand resource allocation.
The vertical virtualization solution includes the following components:
User access control
User access security
Secure service isolation
Resource virtualization
The following section only describes secure service isolation and resource virtualization. For details
about user access control and user access security, see the Wired and Wireless Integrated Technical
Proposal and User Access Security Technical Proposal.
Secure Service Isolation

To isolate application data transmitted on a physical network inside a campus network, you
can configure virtual LANs (VLANs), tunnels, multi-VPN-instance CEs (MCEs), and virtual
private networks (VPNs). To implement service isolation on medium- and large-scale campus
networks, you can configure MPLS L3VPN technology for service isolation flexibility,
network management and expansion, and simplified network structures.
Issue 01 (2011-06-22)


Technical Proposal
MPLS L3VPN is widely used by Internet Service Provider (ISP) VPN solutions based on PEs.
In MPLS L3VPN, BGP advertises VPN routes and MPLS forwards VPN packets along the
ISP's backbone network. MPLS L3VPN networking is flexible and extensible, and MPLS
VPN supports MPLS QoS and MPLS TE.
On a campus network, an MPLS VPN can also be built up using Layer 3 switches, which
transmit all service data and provide secure service isolation, as shown in Figure 1-3.
Figure 1-3 MPLS L3VPN
P
PE
PE
CE
CE
CE
CE
PE
PE
CE
CE
In Figure 1-3:
Users access the campus network through access switches at the edge network and need
to be authenticated. After authentication, the policy server delivers policies to a gateway
according to the authenticated user names. The gateway adds users' access interfaces to
specified VLANs and then adds the authenticated users to specified VPNs according to
the binding between the VLANIF interfaces and the VPNs.
Data belonging to different applications and users is transmitted through different VPNs.
PEs create different forwarding entries for each VPN, and these VPNs transmit data
independent of each other. This mechanism provides an end-to-end service transmission
channel between users and the server, isolating data from different users and applications,
ensuring data transmission privacy and security.
Resource Virtualization
Traditional physical networks face the following problems:
Separately deployed security policies.
Increased Network complexity.
Repeated deployment of the application server.
Complicated data synchronization.
The virtual campus network solution resolves the above problems through a variety of
virtualization technologies.
The virtual campus network solution provides a centralized data center, uniform
Internet/WAN egress, and integrated network monitoring/management software, reducing
wasted resources. In this solution:
Issue 01 (2011-06-22)


Technical Proposal
The centralized data center doe not differentiate hardware servers and storage devices
when allocating resources to service applications running computation virtualization,
storage virtualization, and security virtualization techniques.
All the users on the campus network use the same Internet/WAN egress. The virtual
firewall and network address translation (NAT) multi-instance techniques provide
flexible security policies for users and services from different groups.
The integrated network monitoring/management software manages all resources and

monitors as well as manages all service traffic on the entire network.
1.2.3 Integrated Network Deployment

The virtual campus network integrated network architecture composed of the horizontal and
vertical virtualization solutions:
CSS/iStack technology is used at the access, aggregation, and core layers to virtualize
hardware devices, simplifying network structure and protocol deployment and improving
network reliability and manageability.
Firewall boards or independent firewalls can be installed on aggregation switches to

ensure security of the data center and the Internet/WAN egress.
MPLS L3VPN isolates network resources on the entire network using path virtualization.
Figure 1-4 Integrated virtual campus network deployment

VPN-A VPN-B VPN-C
VPN-A VPN-B VPN-C
SSID-A SSID-B SSID-C
AP
AP
AP
DC
Internet
WAN
VPN-A VPN-B VPN-C Public
Issue 01 (2011-06-22)


Technical Proposal
1.3 Market Positioning and Intended Customers

The virtual campus network solution improves network manageability, reliability, and security,
and is applicable to institutions and enterprises composed of several departments with large,
complex network structures. Some examples include large-scale enterprise networks,
university campuses, large-scale mining and oil operations, and government administration
centers.
Issue 01 (2011-06-22)


Technical Proposal
2 Horizontal Virtualization Design Proposal
Horizontal Virtualization Design Proposal
2.1 Overview
The horizontal virtualization design refers to physical networking design and uses
cluster/stack technology at the core, aggregation, and access layers of the campus network to
virtualize multiple physical devices into a single logical device. This solution simplifies
network structures and protocol deployment and improves network reliability and
manageability.
2.2 Network Topology Design

Figure 2-1 shows an example network topology after horizontal virtualization has been
implemented.
Figure 2-1 Horizontally virtualized network topology
AP
AP
AP
DC
WAN
Issue 01 (2011-06-22)
Internet


Technical Proposal
The horizontal virtual campus network inherits the layered, modular design of traditional
networks while using cluster/stack technology to reduce connections between layers and
modules and simplify protocol deployment.
Layered Design
A campus network is divided into three layers: the access layer, aggregation layer, and core
layer:
Access layer: is the layer closest to users. Layer 2 access devices are deployed at the
access layer to connect user terminals to the campus network.
Aggregation layer: aggregates a large number of users to the core layer and functions as
users' Layer 3 edge gateway.
Core layer: implements high-speed transmission through the entire campus network.
Devices at the core layer are meshed. The core layer does not handle user management
or applications.
Modular Design
A campus network consists of different functional modules, including the internal network,
data center, edge network, and core network:
The internal network provides access interfaces for users.
The data center accommodates an enterprise's application servers.
The edge network connects branch networks, remote users, partners, and customers to
the campus network.
The core network connects to all the other modules.

For details about the data center design, see the Data Center Technical Proposal.
Cluster/Stack Design
CSS/iStack technology virtualizes devices at the access layer, aggregation layer, and core
layer to reduce network nodes and simplify network structure and protocol deployment.
Core devices in dual-node redundant backup mode are virtualized into a single logical
device (a cluster) using CSS technology. Devices in a cluster are meshed.
Aggregation devices in dual-node redundant backup mode are virtualized into a single
logical device using CSS or iStack technology. Each aggregation device is connected to a
core device through a trunk link, with no need for ring or dual-homing network
topologies.
Decide whether to use stack technology on access devices based on network

requirements, and design the uplink link according to whether stack technology is used
on aggregation devices:
Issue 01 (2011-06-22)
You are advised to use stack-compatible switches to form a stack, to reduce nodes
requiring management, and to use common switches as access devices to reduce
costs.
If CSS/iStack technology is used on aggregation devices, access devices are

connected to the aggregation devices through trunk links. When dual-node redundant
backup is configured on the aggregation devices, access devices are connected to the
aggregation devices in a ring network or are dual-homed to the aggregation devices.


Technical Proposal
2.3 Core Layer Design

The core layer implements high-speed transmission through the entire campus network, and
as such must provide high-bandwidth usage and rapid convergence.
The core layer design includes device backup and link backup:
Device backup: At the core layer, two devices are deployed at a physical location to
ensure uninterrupted network services if one device fails.
Link backup: Core devices are highly meshed or fully meshed, as shown in Figure 2-2.
The mesh topology prevents network interruptions caused by node failures if any links
fail.
Figure 2-2 Highly-meshed topology and fully-meshed topology
Fully-meshed topology
Highly-meshed topology
In the horizontal virtualization solution, two core devices in redundant backup mode can be
connected through dedicated stack cables and virtualized as one device using CSS technology.
This solution reduces the number of devices to manage and improves network reliability. In
this solution, devices are still meshed, as shown in Figure 2-3.
Figure 2-3 Virtualized core network
Virtualized core network

Non-virtualized core network
When two S9300 series switches are used to form a core network, they must satisfy the
following conditions to form a stack:
The device model is either S9306 or S9312.
Two main control boards of the same type (SRUA or SRUB) are installed on each device.
(The two devices can have the same or different main control boards.)
Issue 01 (2011-06-22)

10

Technical Proposal
A stacking card with four stack interfaces is installed on each main control board.
The two devices are connected by dedicated Quad Small Form-Factor Pluggable (QSFP)
high-speed cables as illustrated in Figure 2-4.
Stacking is enabled on the devices.
When the preceding conditions are met, a stack is automatically formed after the two S9300s
are powered on. After a competition, one switch becomes the master switch, and the other
becomes the backup switch.
Figure 2-4 Stack cable configuration
2.4 Aggregation Layer Design

A core device has a limited number of physical interfaces, limiting the number of users that
can simultaneously access the core layer. To increase the number of users capable of
accessing the core layer, an aggregation device aggregates a large number of access devices
and users and then connects them to the core device.
An aggregation device usually functions as a Layer 3 edge gateway between Layer2 and
Layer 3, facilitating user management, security management, and QoS scheduling.
An aggregation device needs to provide the following functions:
Access device dual-homing support: Aggregation devices must support master/backup

mode, and run VRRP to prevent network interruptions caused by aggregation-layer
failures.
Core layer dual-homing support: Aggregation devices are usually not meshed, so they
must support core device dual homing to ensure reliability.
Issue 01 (2011-06-22)

11

Technical Proposal
In the traditional aggregation layer design, two physical devices running VRRP are deployed
for each aggregation node. The two devices are connected to core devices forming a ring
network or are dual-homed to core devices, as shown in Figure 2-5.
In ring network topology, core devices and aggregation devices form a ring network. If
an aggregation node is dual-homed to two core devices, each of the two aggregation
devices is connected to a different core device. The deployment cost is low, but the link
usage is reduced. In addition, high performance aggregation switches must be used to
process complicated routing information.
In a dual-homed network, each aggregation device is dual-homed to two core devices,

and the two aggregation devices are connected to each other. This network does not
require high performance aggregation switches since the routing information is simple.
However, the deployment cost is high because there are several links, and uplink
interface usage is reduced (one of the uplink interfaces acts as a backup interface).
Figure 2-5 Ring network and dual-homed network topologies
VRRP
Ring topology
VRRP
Dual-homing topology
In the horizontal virtualization solution, aggregation devices in redundant backup mode are
virtualized into a single logical device using CSS/iStack technology, simplifying the network
structure and improving network reliability.
If S9300s are deployed as aggregation devices, the stacking design is the same as that in
section 2.3 "Core Layer Design
."
If deploying S5700 series switches as aggregation devices they must satisfy the following
conditions to form a stack:
All the devices are of the same series (EI or SI).
An EPTC-stack rear card with two stack interfaces is installed on each of the devices.
Devices are connected by dedicated PCI-E cables in a ring or chain topology, as shown
in Figure 2-6 and Figure 2-7.
Stacking is enabled on the devices.
When the preceding conditions are met, a stack is automatically formed when these devices
are powered on. After the stack is formed, one switch becomes the master switch, one
becomes the backup switch, and the others become slave switches.
Issue 01 (2011-06-22)

12

Technical Proposal
Figure 2-6 Chain stack
Master
Slave
Slave
Slave
Figure 2-7 Ring stack

Master
Slave
Slave
Slave
When two aggregation devices form a stack and the stack is dual-homed to two core devices,
the type of connection between the stack and core devices is dependent on whether the core
switches support CSS:
If the two core devices do not support CSS, the stack is connected to the two core
devices through two separate links.
If the two core devices support CSS, the stack is connected to the two core devices
through a trunk link.
Figure 2-8 Stack of two aggregation devices dual-homed to two core devices
Core devices do not support CSS
Issue 01 (2011-06-22)
Core devices support CSS

13

Technical Proposal
2.5 Access Layer Design

The access layer is the layer closest to users. Layer 2 access devices are deployed at the
access layer to connect user terminals to the campus network.
In traditional access layer design, each access device is connected to aggregation devices in a
ring topology or is dual-homed to two aggregation devices. For details, see section 2.4
"Aggregation Layer Design
."
In the horizontal virtualization solution, decide whether to use stack technology on access
devices based on network requirements, and design the uplink link according to whether stack
technology is used on aggregation devices:
You are advised to use stack-compatible switches to form a stack, to reduce nodes
requiring management, and to use common switches as access devices to reduce costs.
If CSS/iStack technology is used on aggregation devices, access devices are connected to

the aggregation devices through trunk links. When dual-node redundant backup is
configured on the aggregation devices, access devices are connected to the aggregation
devices in a ring network or are dual-homed to the aggregation devices.
Figure 2-9 Network topology examples with varying CSS implementations
Ring network where

access and aggregation
devices do not support
CSS
Dual-homed network where

access and aggregation
devices do not support CSS
Aggregation devices support CSS, access

devices do not
Access devices support CSS,

aggregation devices do not
Access and aggregation devices support

CSS
The stacking design for access devices (such as S2700/S3700/S5700s) is the same as that
described in section 2.4 "Aggregation Layer Design."
Issue 01 (2011-06-22)

14

Technical Proposal
2.6 Edge Network Design

The edge network acts as the border between the campus network and external networks,
connecting users on the campus network to the Internet and external users (including
customers, partners, branch companies, and remote users) to the campus network.
The edge network design must provide internet access for internal users and campus network
access for partner, branch companies, remote users, SOHO offices, and customers. The edge
network design is similar to campus network design. For details, see the Campus Network
Technical Proposal.
Issue 01 (2011-06-22)

15

Technical Proposal
3 Vertical Virtualization Design Proposal
Vertical Virtualization Design Proposal
3.1 Overview
The vertical virtualization solution divides a physical network into several independent
logically isolated networks. Isolating these networks provides a security buffer between
terminals and services and permits on-demand resource allocation. Huawei recommends
MPLS VPN technology for the vertical virtualization solution.
3.2 Physical Networking Design

In the vertical virtualization solution, a traditional campus network design can be
implemented for physical networking, such as the topology in Figure 1-1. For details about
traditional campus network design, see the Campus Network Technical Proposal. The
horizontal virtualization solution can be used to design physical networking, as shown in
Figure 2-1. For details, see chapter 2 "Horizontal Virtualization Design Proposal."
3.3 VLAN Design

In the vertical virtualization solution, VLANs isolate users on Layer 2 access networks.
VLANs can be bound to VPN instances (VRF) to implement end-to-end service isolation
while allowing users to use the same switchs access interface.
VLANs are usually classified into the following types:
Service-based VLANs: VLANs allocated based on the services they provide, for
example voice, data, and management services.
Department-based VLANs: VLANs allocated based on an enterprise's physical

departments, for example, finance, sales, or human resources.
Service- and department-based VLANs: VLANs allocated based on the services they
provide and the departments they provide them to. For example, an enterprise
implements unique data VLANs for each department and a single voice VLAN for the
entire network.
Issue 01 (2011-06-22)

16

Technical Proposal
Huawei recommends using service- and department-based VLANs in a virtual campus

network.
In addition to service VLANs, management and security VLANs are essential, for example,
guest VLANs and DMZ VLANs used in 802.1x authentication.
VLANs need to be deployed on both PEs and CEs in the vertical virtualization solution.
PE (for example, an aggregation switch): Edge interfaces of a PE functioning as a Layer

3 switch are configured as sub-interfaces or VLANIF interfaces and assigned different
VLAN IDs according to the departments to which these interfaces belong.
CE: Uplink interfaces of a CE functioning as a Layer 2 switch are configured as

VLANIF interfaces and assigned different VLAN IDs according to the services these
interfaces provide. These VLAN IDs are the same as the VLAN IDs of the PEs edge
interfaces.
To facilitate network management on an MPLS L3VPN, Huawei recommends setting the

same VLAN ID for the CEs uplink VLANIF interfaces at each site.
3.4 IP, DHCP, and DNS Design

See the Campus Network Technical Proposal.
3.5 IGP Design

3.5.1 IGP Selection
IS-IS and OSPF are the most widely used IGPs. Despite different implementation
mechanisms, they function similarly and have comparable performance. OSPF is different
from IS-IS in the following technical aspects:
IS-IS is more secure than OSPF. IS-IS packets are transmitted over Layer 2 links, and are
Layer 2 multicast packets, which are not routable. OSPF packets are transmitted at the
network layer, and are routable, making an OSPF device vulnerable to remote attacks.
IS-IS has higher extensibility than OSPF. IS-IS can support IPv6 by adding TLV fields to
packets. With the exception of OSPFv3, OSPF does not support IPv6.
Although IS-IS has many advantages, industry statistics show that OSPF is more commonly
used in enterprise networks than IS-IS for the following reasons:
On an enterprise network, there is a small risk that remote attacks will be launched
against OSPF devices.
Only private IPv4 addresses are required on an enterprise network, and IPv6 is not
required.
Both OSPF and IS-IS have their own unique characteristics, and enterprises should select
whichever IGP best suits their needs.
Issue 01 (2011-06-22)

17

Technical Proposal
All Huawei network products support IPv6, facilitating enterprise network transition from IPv4 to IPv6.
For more details, see "Solution > IPv6" at www.huawei.com.
3.5.2 OSPF Design

Area Partition
When deploying OSPF on an enterprise network, decide whether to use the layered design
based on the size of the network.
On a small-sized network, for example, a network with less than 2000 terminals, the
layered design is not recommended. All the network nodes can be deployed in Area 0
(backbone area).
On a large-sized network (or a network that will be extended to a large network), the
layered design is recommended. All the network nodes can be deployed in Area 0 and
aggregation nodes in the other areas.
Cost
Cost is dependent on transmission distance and link bandwidth. In addition, the cost depends
on the network traffic paths required by the enterprise services. Therefore, an enterprise
should plan the link cost according to its service characteristics and network topology.
Reliability
See section 3.9.1 "IGP Reliability."
Security
None.
3.5.3 IS-IS Design

NET
A Network Entity Title (NET) specifies the current IS-IS area address and router system ID.
NET format is AA.BBBB.CCCC.DDDD.SSSS.SSSS.SSSS.00, in which
AA.BBBB.CCCC.DDDD specifies an area ID, and SSSS.SSSS.SSSS specifies the system ID.
Generally, an enterprise can set the area ID to all 0s and use the loopback address as the
system ID. For example, if the loopback address is 10.112.58.113, the system ID will be
written as 0101.1205.8113, making the NET 00.0000.0000.0000.0101.1205.8113.00.
Area Partition
When deploying IS-IS on an enterprise network, decide whether to use the layered design
based on the size of the network.
On a small-sized network, for example, a network with less than 2000 terminals, the
layered design is not recommended. All the network nodes can be configured as Level-2
devices to facilitate network extension.
On a large-sized network (or a network that will be extended to a large network), the
layered design is recommended. All the network nodes can be deployed as Level-2
Issue 01 (2011-06-22)

18

Technical Proposal
devices and aggregation nodes as Level-1 devices. Generally, Level-l-2 devices are not
required.
Cost
Cost is dependent on transmission distance and link bandwidth. In addition, the cost depends
on the network traffic paths required by the enterprise services. Therefore, an enterprise
should plan the link cost according to its service characteristics and network topology.
Reliability
See section 3.9.1 "IGP Reliability."
Security
None.
3.6 BGP Design

BGP is not required in traditional enterprise campus networks since they do not require
multiple routing domains. MP-IBGP is required in the horizontal virtualization solution since
an MPLS L3VPN is required to transmit VPN routes between PEs.
MP-IBGP is an extension of BGP designed to support the VPN-IPv4 address family and IPv6
address family. MP-IBGP is used to advertise VPN routes on an L3VPN. When deploying
BGP on a campus network, focus on the following points:
MP-IBGP needs to be deployed on a local PE, and the remote PE needs to be configured
as the peer of the local PE.
Routing policies do not need to be configured on the campus network.
The number of routes on a campus network is limited, indicating a route reflector (RR)
does not need to be deployed.
The routing protocol authentication mechanism does not need to be deployed on the
campus network.
3.7 MPLS Design

The vertical virtualization solution requires MPLS L3VPN for logical network division and
service isolation, and MPLS needs to be deployed on VPNs.
For details about MPLS reliability design (including fast convergence, fault detection, and service
protection), see section 3.9.2 "MPLS Reliability."
MPLS Domain
The scope of the MPLS domain depends on a VPNs PE location. (For details, see section 3.8
"VPN Design.")
Issue 01 (2011-06-22)
If a PE is located at the aggregation layer, an MPLS domain contains core devices and
aggregation devices.

19

Technical Proposal
If a PE is located at the core layer, an MPLS domain contains only core devices.
MPLS needs to be enabled on every device in an MPLS domain. Huawei recommends setting
the label switching router (LSR) IDs as the loopback address.
LSR ID
LSR IDs need to be set for MPLS-enabled devices. Generally, the address of a loopback
interface (such as loopback0) is used as an LSR ID.
LSP
A label switched path (LSP) is a sequence of LSRs along the path from source to destination.
An LSP can be manually established using a hop by hop method or automatically established
using label distribution protocols (such as LDP and RSVP) or routing protocols (such as BGP
and OSPF).
The configuration workload of a static LSP is heavy; a static LSP scales poorly and manual
operations may result in errors. Therefore, static LSPs are not used unless absolutely
necessary.
RSVP can conserve resources, guarantee bandwidth, and provide highly reliable protection
for MPLS TE tunnels (CR-LSPs). RSVP-TE requires high network and device performance
and is usually used on carrier-class backbone networks. MPLS TE does not need to be
deployed on enterprise networks.
On enterprise networks, Huawei recommends establishing LSPs using LDP, which is simple
and easy to deploy.
LDP Session
To establish LSPs using LDP, LDP sessions are required.
In the vertical virtualization solution, Virtual Private Wire Service (VPWS), Virtual Private
LAN Service (VPLS), and LDP over TE are not required, so remote LDP sessions are not
required. Local LDP sessions only need to be established between neighboring LSRs, for
example, between core devices, or between core devices and aggregation devices.
3.8 VPN Design

In the vertical virtualization solution, terminals, servers, and network resources belonging to
different departments are assigned different VPNs to securely isolate services.
An enterprise network's VPN plan must allow VPN users to access the external network and
allow branch companies or external users to access the enterprise network.
3.8.1 Intranet Service Isolation

Intranet service isolation can be implemented using MPLS L3VPN, as shown in Figure 3-1.
Issue 01 (2011-06-22)

20

Technical Proposal
Figure 3-1 Intranet service isolation using MPLS L3VPN

Finance
CE
CE
Finance
VPN1
CE
Supply
VPN2
VPN1
P
PE
Supply
VPN2
R&D
VPN3
PE
CE
VPN1
VPN2
VPN3
VPN4
CE
CE
PE
PE
P
VPN3
CE
Manufact CE
uring
VPN2
VPN4
VPN1
In Figure 3-1:
Users access the campus network from CEs. Policies can be manually configured for
gateways or delivered to gateways by the policy server. The gateways then add users'
access interfaces to specified VLANs and deliver access control policies to the CEs.
Users are added to specific VPNs after VLANIF interfaces are bound to VPNs on access
devices or aggregation devices.
Servers add interfaces to specified VPNs based on their applications and access users and
transmit service data along different VPNs.
PEs create different forwarding entries for each VPN so each VPNs can transmit data
independently, and VPN routing information will not be passed on to other VPNs. This
mechanism provides a secure end-to-end service transmission channel between users and
the server, isolating data belonging to different user groups and applications, and
implementing campus network vertical virtualization.
3.8.2 Communication Between VPNs

Generally, after an MPLS L3VPN is created, VPN users can only access other users or
network resources in the local VPN.
In some cases, different VPNs need access to each other. In this situation, routes can be
advertised or imported into different VPNs by changing the VPN targets (export targets and
import targets) associated with VPN instances. This implements flexible VPN access in
multiple VPN networking topologies, including Intranet, Extranet, and Hub & Spoke.
For more details, see Huawei device VPN configurations (such as NE series routers or S9300
series switches) that support MPLS L3VPN.
3.8.3 Internet Access: Internal User

Internal users need to access the Internet edge network through the core device on the campus
network and then access the Internet through the Internet egress router. In this situation,
firewalls need to be deployed on the Internet edge network to ensure internal network
security.
Issue 01 (2011-06-22)

21

Technical Proposal
On a large-scale campus network, private IP addresses are usually used to conserve IPv4
addresses. To enable internal users to access the Internet, a NAT device needs to be deployed
on the Internet edge network to translate private IP addresses to public IP addresses. The NAT
device can be an independent device or a module integrated into a firewall board or Internet
egress router.
S9300 firewall boards provide firewall and NAT functions and use NE40E routers or Access
Routers (ARs) as Internet egress routers.
Figure 3-2 Non-VPN internal users accessing the Internet
Internet
Access
layer
Aggreg
ation
layer
Core
layer
Edge
network
Internet
When the enterprise internal network is virtualized using MPLS L3VPN, VPN users will need
to access the Internet.
Generally, VPN users can only access resources in the local VPN but not public resources on
the Internet. In addition, if a dedicated Internet egress needs to be deployed for each VPN, the
cost is high and network structure becomes complex.
The optimal solution is to deploy an Internet egress for all the VPNs and allow VPN users to
connect to this Internet egress by using either of the following methods:
Deploy an Internet gateway server in each VPN, and configure default and static routes
to enable VPN users to access the Internet. For more details, see Huawei device VPN
configurations (such as NE series routers or S5700/S9300 series switches) that support
MPLS L3VPN.
This method costs a lot and is inflexible; therefore, it is not recommended on enterprise
campus networks.
Deploy virtual firewalls on a firewall device by binding VPN instances, security

instances, and configuration instances together. This method virtualizes a single firewall
into multiple firewalls. Each virtual firewall provides Internet access service for one
VPN, as shown in Figure 3-3.
This method is recommended for its low cost and flexibility.
Issue 01 (2011-06-22)

22

Technical Proposal
Figure 3-3 VPN users accessing the Internet through a virtual firewall
VPN1
VPN1
VPN1
VPN1
VPN2
vwf
vwf
1
vwf
2
3
Internet
vwf
vwf
1
vwf
2
3
VPN3
Access
layer
Aggreg
ation
layer
Core
layer
Edge
network
Internet
3.8.4 Campus Network Access: Branch Companies

A branch network is an extension to a campus network and can access resources on the
campus network without restrictions. No firewall needs to be deployed between a branch
network and the campus network. A branch network is connected to the campus network
through a WAN or the Internet, as shown in Figure 3-4.
If a branch network is connected to the campus network through the Internet, IPSec VPN
access is typically used to ensure data encryption. In addition, a VPN server is deployed on
the Internet egress of the campus network to manage user access.
The VPN server can be a dedicated device or a module on a firewall, and a dedicated VPN
server device can be attached to a firewall or an aggregation switch on the Internet edge
network.
Huawei AR supports IPSec VPN. If an AR is deployed at the edge of a branch network or a small-scale
headquarters network, the S9300 SPU can then be used as an IPSec VPN gateway on the headquarters
network.
Issue 01 (2011-06-22)

23

Technical Proposal
Figure 3-4 Branch network connecting to the campus network

Campus
network
Campus
network
el
Tunn
IPSe
c Tu
nnel
c
IPSe
WAN
Internet
Branch network
Branch network
Secure user isolation must be implemented when connecting a branch network to the campus
network. For example, on the headquarters network, a physical network may need to be
virtualized into multiple logical networks using MPLS L3VPN to ensure security. This can be
carried out in the following ways:
Deploy MPLS L3VPNs on the branch network. This method requires devices on the
branch network to support MPLS L3VPN. In most cases, however, this requirement is
not met.
Deploy MCEs on the branch network. If different MCEs need to communicate with each
other, MPLS L3VPNs are required to allow these MCEs to communicate within the
campus network. However, this wastes WAN interface bandwidth.
If the branch network connects to the campus network through the Internet, user isolation
needs to be implemented using the following methods:
Deploy multiple IPSec tunnels.
Deploy multiple GRE over IPSec tunnels.
3.8.5 Campus Network Access: Remote Users

Remote users expect to be able to access the campus network the same way as internal users.
Remote users usually access the campus network through the Internet. Encrypted user access
is required to ensure security. Currently, remote users access the campus network using
Secure Sockets Layer (SSL) VPNs and Layer 2 Tunnel Protocol (L2TP) VPNs.
Both technologies require a VPN server to be deployed on the edge network. The VPN server
can be attached to the firewall on the Internet edge network or to an aggregation switch, as
shown in Figure 3-5.
Issue 01 (2011-06-22)

24

Technical Proposal
Figure 3-5 Remote users accessing the campus network

Campus
network
Client
Tunnel
Tunnel
Internet
Client
SSL VPN allows remote users to access a VPN server using a Web browser without installing client
software. L2TP VPN requires L2TP dialup software.
3.8.6 Campus Network Access: SOHO Users

SOHO users expect to be able to access the campus network just like internal users. SOHO
users usually access the campus network through the Internet. Data transmitted during
Internet access to the campus network must be encrypted. IPSec VPN is recommended. The
deployment method of SOHO office access is similar to branch company access. For details,
see section 3.8.4 "Campus Network Access: Branch Companies."
Issue 01 (2011-06-22)

25

Technical Proposal
Figure 3-6 SOHO offices accessing the campus network using IPSec VPN
Campus
network
IPSe
c
IPSe
nnel
c Tu
Tunn
el
Internet
SO
HO
3.8.7 Campus Network Access: Customers

External customers can only access the demilitarized zone (DMZ) of the campus network.
Customers can access campus network resources such as the Web server, Email server, and
FTP server. These servers are deployed behind firewalls in either of the following modes:
These servers are deployed in a DMZ and attached to the aggregation switch on the edge
network, as shown in Figure 3-7.
A DMZ is deployed in the data center to hold the above-listed servers, as shown in
Figure 3-8.
Figure 3-7 DMZ deployed on the edge network
Internet
DMZ
Issue 01 (2011-06-22)

26

Technical Proposal
Figure 3-8 DMZ deployed in the data center
Internet
DMZ
Either private or public IP addresses can be configured for devices in a DMZ. If private IP
addresses are used, a NAT device must be deployed to enable external customers to access the
campus network. Huawei recommends deploying NAT and firewalls on S9300 firewall boards
and using NE40E routers or ARs as Internet egress routers.
3.9 Reliability Design

This section only describes reliability solutions in the vertical virtualization solution. For the reliability
design for the non-virtualization solution of the campus network, see the Campus Network Technical
Proposal.
3.9.1 IGP Reliability

Deploy OSPF or IS-IS as the IGP on the enterprise campus network.
OSPF Reliability
Huawei recommends configuring OSPF fast convergence, which includes the following
features:
BFD for OSPF: rapidly detects link failures.
Partial Route Calculation (PRC): speeds up OSPF route convergence.
Intelligent timer: speeds up route convergence and improves network stability.
Issue 01 (2011-06-22)

27

Technical Proposal
IS-IS Reliability
Huawei recommends configuring IS-IS fast convergence, which includes the following
features:
BFD for IS-IS: rapidly detects link failures.
Incremental SPF (ISPF): speeds up IS-IS route convergence.
PRC: speeds up IS-IS route convergence.
LSP fast flooding: speeds up LSDB synchronization.
Intelligent timer: speeds up route convergence and improves network stability.
Among the preceding features, BFD for IS-IS, LSP fast flooding, and intelligent timer need to
be configured manually, and ISPF and PRC are enabled by default.
3.9.2 MPLS Reliability

LDP reliability features must be deployed to use LDP LSPs as VPN tunnels.
On an enterprise network, LDP reliability is implemented as follows:
If there are primary and backup paths for an LSP (for example, an aggregation device is
dual-homed to two core devices), configure synchronization between LDP and IGP on
the node residing on both the primary and backup paths and on the egress node. This
prevents traffic loss caused during a switchover between the primary and backup paths
when IGP convergence is faster than LDP convergence, as shown in Figure 3-9.
Figure 3-9 Synchronization between LDP and IGP

Primary LSP
Core layer
Backup LSP
IGP Sync
IGP Sync
Aggregation
layer
Access
layer
Dynamic BFD provides millisecond-level fault detection for LDP LSPs and reduces the
manual configuration workload. Huawei recommends configuring dynamic BFD on two
ends of an LDP LSP to detect faults.
If there are primary and backup paths for an LSP as shown in Figure 3-9, configure LDP
Auto FRR on the egress of the LSP to automatically establish a backup LSP. This speeds
up traffic switchover and reduces traffic loss when a fault occurs.
If two main control boards are installed on an LSR, deploy LDP GR on the LSR to ensure
uninterrupted MPLS forwarding during a main control board active/standby switchover or
during an LSR software upgrade.
Issue 01 (2011-06-22)

28

Technical Proposal
4 Recommended Products
Recommended Products
Huawei recommends the following products for use in the virtual campus network solution.
Table 4-1 List of recommended products
Product
Product Model
Access switch
S5700, S3700, S2700
Aggregation switch
S9300, S5700
Core switch
S12800, S9300
WLAN AC
S9300 AC card
Edge router
AR3200, NE40E
Firewall
S9300 firewall card
NMS
iTec Professional Edition
Issue 01 (2011-06-22)

29

Technical Proposal: Virtual Campus Network Solution

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Technical Proposal: Virtual Campus Network Solution

Hochgeladen von

Copyright:

Verfügbare Formate

Virtual Campus Network Solution

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Industrial Base

Huawei Proprietary and Confidential

Virtual Campus Network Solution

2 Horizontal Virtualization Design Proposal ............................................................................. 8

3 Vertical Virtualization Design Proposal ................................................................................ 16

Huawei Proprietary and Confidential

Virtual Campus Network Solution

3.8.7 Campus Network Access: Customers ................................................................................................... 26

4 Recommended Products ............................................................................................................ 29

Huawei Proprietary and Confidential

Virtual Campus Network Solution

1 Overview: Virtual Campus Network Solution

Overview: Virtual Campus Network

Layered deployment: A campus network is designed with a three-layer architecture,

Modular deployment: Enterprise network physical and logical structures are

Huawei Proprietary and Confidential

Virtual Campus Network Solution

1 Overview: Virtual Campus Network Solution

Figure 1-1 Traditional campus network architecture

Department/group resource access permissions must be carefully controlled, and

Huawei Proprietary and Confidential

Virtual Campus Network Solution

1 Overview: Virtual Campus Network Solution

1.2 Virtual Campus Network Solutions

In the horizontal virtualization solution:

Simplified Network Structure

Simplified Protocol Deployment

Huawei Proprietary and Confidential

Virtual Campus Network Solution

1 Overview: Virtual Campus Network Solution

Link Load Balancing and Redundant Backup

Flexible Network Expansion

1.2.2 Vertical Virtualization Solution

User access control

User access security

Secure service isolation

Secure Service Isolation

Huawei Proprietary and Confidential

Virtual Campus Network Solution

1 Overview: Virtual Campus Network Solution

Separately deployed security policies.

Increased Network complexity.

Repeated deployment of the application server.

Complicated data synchronization.

Huawei Proprietary and Confidential

Virtual Campus Network Solution

1 Overview: Virtual Campus Network Solution

The integrated network monitoring/management software manages all resources and

1.2.3 Integrated Network Deployment

Firewall boards or independent firewalls can be installed on aggregation switches to

Figure 1-4 Integrated virtual campus network deployment

VPN-A VPN-B VPN-C

SSID-A SSID-B SSID-C

Huawei Proprietary and Confidential

Virtual Campus Network Solution

1 Overview: Virtual Campus Network Solution

1.3 Market Positioning and Intended Customers

Huawei Proprietary and Confidential