| 리포트 | 기술문서 | 테크-블로그 | 글로벌 블로그 | 원샷 갤러리 | 통신 방송 통계  | 한국 ICT 기업 총람 |

제품 검색

| 네트워크/통신 뉴스 | 기술자료실 | 자유게시판 |  
 
 
섹션 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/UHD IoT SDN/NFV Wi-Fi Video Streaming KT SK Telecom LG U+ OTT Network Protocol CDN YouTube Data Center
 
스폰서채널 |

 

  스폰서채널 서비스란?
Network Infrastructure Virtualization Case Study
May 19, 2011 | By Cisco
코멘트 (0)
6
Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
Transcript
ⓒ 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 2
Dave Zacks CCIE 8887

Technical Solu7ons Architect This session focuses on a customer case study in which Network Virtualization has been deployed. The focus of this session is to cover the actual business requirements of the customer involved, how Network Virtualization met those requirements, the network design that was employed, and the benefits that were derived. Introducing the session will be a brief outline of Cisco\'s approach to Network Virtualization design methodology. The customer case study itself
will focus on a Campus Network Virtualization deployment. Presenting this case study will be Dave Zacks, a Technical Solution Architect with Cisco Systems. Attendees at this session will learn about virtualized network deployments, and how these can be used to provide unique and compelling architectural solutions, addressing both business and technical requirements.

ⓒ 2011 Cisco and/or its affiliates. CNSF - May, 2011 All rights reserved. Cisco Public 5
. Groups and services
are logically separated …
Guest / partner access
Departmental separation
Regulatory compliance (HIPPA, PCI …)
Building controls, video surveillance
Mergers, acquisitions … and many others
. Closed User Groups …
Private
Secure
Independent policies
. Service differentiation
is configured per group / service …
The same application
can be unique per group / service
Resources
Dept A Partner Guest
Internet
Dept B
Non-Virtualized Network
Virtualized
Network
ⓒ 2011 Cisco and/or its affiliates. CNSF - May, 2011 All rights reserved. Cisco Public 6
Actual Physical Network Infrastructure
Virtual
Separate Departments Separate Functions
Virtual Virtual
Guests / Partners
. One physical network
supports many virtual networks
Access Control Services Edge
Functions .Authenticate
client (user, device,
application) attempting to
gain network access
.Authorize client
into a partition (VLAN)
.Deny access to
unauthenticated clients
.Maintain traffic partitions
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
.Isolate application
environments
if necessary
Service
Data Center . Internet Edge . Campus
Internet
WAN . MAN . Campus
VRFs
GRE MPLS
Branch . Campus
Internet
WAN . MAN . Campus
VRFs
GRE MPLS
Branch . Campus
ⓒ 2011 Cisco and/or its affiliates. CNSF - May, 2011 All rights reserved. Cisco Public 8
. Device virtualization .
Control plane virtualization
Data plane virtualization
Services virtualization
VRF
VRF
Global
IP
802.1q
VRF . Virtual Routing and Forwarding
Per VRF:
Virtual Routing Table
Virtual Forwarding Table
. Data path virtualization .
Hop-by-Hop .
(VRF-Lite End-to-End)
Multi-Hop .
(VRF-Lite+GRE, MPLS VPN)
ⓒ 2011 Cisco and/or its affiliates. CNSF - May, 2011 All rights reserved. Cisco Public 9
1. Create L2 VLANs
and trunk them to the first L3 device
2. Define VRFs at the first L3 devices (PE)
and map the L2 VLANs to the proper VRF
3. Enable MPLS on all
Layer 3 interfaces in the network
4. Enable MP-BGP on the
PE devices to exchange VPN routes
PEs become iBGP neighbors
5. VPN traffic is now carried end-to-end
across the network, maintaining logical
isolation between the defined groups
Each frame is double-tagged
(IGP label + VPN label)
Enable MPLS
Enable MPLS
PE
Label Switch P P
Router (LSR)
PE
S1 S4
172.16.5.0/24
172.17.6.0/24
172.18.7.0/24
172.16.8.0/24
172.17.9.0/24
172.18.10.0/24
N * (N-1) / 2 = 8 * 7 / 2 = 28
iBGP requires a full mesh of neighbors
For Your
Reference
S1 S4
172.16.5.0/24
172.17.6.0/24
172.18.7.0/24
172.16.8.0/24
172.17.9.0/24
172.18.10.0/24
N * (N-1) / 2 = 8 * 7 / 2 = 28
iBGP requires a full mesh of neighbors
For Your
Reference
S1 S4
172.16.5.0/24
172.17.6.0/24
172.18.7.0/24
172.16.8.0/24
172.17.9.0/24
172.18.10.0/24
Route Reflector Route Reflector
For Your
Reference
S1 S4
172.16.5.0/24
172.17.6.0/24
172.18.7.0/24
172.16.8.0/24
172.17.9.0/24
172.18.10.0/24
Route Reflector Route Reflector
For Your
Reference
ⓒ 2011 Cisco and/or its affiliates. CNSF - May, 2011 All rights reserved. Cisco Public 12
. Firewall contexts in transparent mode
act as L2 bridges
Red
VPN
Blue
VPN
GreenV
PN
Campus Core
Shared Services
E-mail
Storage
Web

L2 L2 L2
EIGRP, OSPF,
eBGP, Static
(no ISIS)
. Fusion router establishes routing
peering with the various VRFs
The fusion router has complete knowledge
of all the routes existing in the VRFs
. The peering protocol may vary
depending on the path isolation strategy
Use IGP (EIGRP or OSPF)
for VRF-Lite deployments
Use eBGP for MPLS VPN scenarios
. The fusion router could typically
advertise only a default route
into the various VRFs
. A dedicated “Fusion” VRF may be
used in place of an external fusion
router device
ⓒ 2011 Cisco and/or its affiliates. CNSF - May, 2011 All rights reserved. Cisco Public 13
. Firewall contexts in routed mode
act as an L3 hop routing traffic
between interfaces
No routing protocol support on
firewall deployed in multi-context mode
Red
VPN
Blue
VPN
GreenV
PN
Campus Core
Shared Services
E-mail
Storage
Web

L3 L3 L3
eBGP
. The only recommended peering protocol
is eBGP, independently from the
Path Isolation technique adopted
in the Campus
Configuring static routing
is also possible
. The fusion router could typically
advertise only a default route
into the various VRFs
. A dedicated “Fusion” VRF may be used
in place of an external fusion router device
ⓒ 2011 Cisco and/or its affiliates. CNSF - May, 2011 All rights reserved. Cisco Public 14
The global table is considered as another
VPN (in fact can be usually considered
the “default VPN”) and it is front-ended
by its own security device
Red
VPN
Blue
VPN
Global
Table
Shared Services
The global table is treated as a shared
service . access to the global table
from each VPN is subject to the policy
enforcement provided by the Services Edge
Red
VPN
Blue
VPN
GreenV
PN
Global Table

.UBC is one of the largest
Universities in Canada.
.The main UBC Campus is
located in Vancouver, BC
(UBCV).
UBC
is here
You are here
.UBC is one of the largest
Universities in Canada.
.The main UBC Campus is
located in Vancouver, BC
(UBCV).
UBC
is here
You are here
On a beautiful summer day …
June 25th, 2010
I.K Barber
Learning Centre
University of BC
On a beautiful summer day …
June 25th, 2010
I.K Barber
Learning Centre
University of BC
.
50,332 students . 4,669 faculty . 8,953 staff
Source: www.ubc.ca (as of November, 2008)
.
Number of Ethernet switches installed = 2,709
.
Number of wired Ethernet ports = approx. 60,000
.
Number of VLANs allocated = 3,394
.
All core network links are 10 Gigabit Ethernet
.
Core network links are Jumbo Frame-enabled
.
Number of Wireless APs deployed = approx. 2,000
.
Total Internet bandwidth used = approx. 1750Mbps
.
UBC has adopted a standardized
Campus network architecture.
.
Due to the size of UBC’s Vancouver Campus,
a four-layer network architecture has been used .
Access Layer . Stackable Layer 2 switches
Distribution Layer . Mixture of stackable and chassis
switches, mostly Layer 2 but with some Layer 3 termination
Outer Core Layer . All remaining Layer 3 terminations
Inner Core Layer . Layer 3 routing between
Outer Core platforms
No deliberate
Layer 2 loops
in the network
Fully resilient core
network, based on
OSPF routing
No VLAN bridging
across the core .
routed links only
Layer 3 FHRP
provided by HSRP
at Outer Core layer
Typical
LargeBuilding
Distribution
Outer Core
Access
Inner Core
Additional
Buildings
Data Center
Internet Edge
No deliberate
Layer 2 loops
in the network
Fully resilient core
network, based on
OSPF routing
No VLAN bridging
across the core .
routed links only
Layer 3 FHRP
provided by HSRP
at Outer Core layer
Typical
LargeBuilding
Distribution
Outer Core
Access
Inner Core
Additional
Buildings
Data Center
Internet Edge
.
UBC departments and faculties use VLANs
to segregate functions within buildings .
servers, students, faculty, staff, admin, labs, etc.
.
Any port within a building at UBC can be on
any VLAN within that building (or building complex).
.
Some large UBC buildings, holding multiple
departments, have over 100 VLANs.
.
Don’t forget . VLANs are a form of virtualization
(at Layer 2)!
.
Statement of the Problem .
Nineteen faculties . and over 200 departments.
Several thousand subnets, Campus-wide.
Faculties / departments have space in many buildings.
Example . Faculty of Arts has space in 31 buildings.
Many UBC faculties / departments require secure
connections within, and between, their areas.
To this end, many have implemented
their own firewall solutions.
Proliferation of
different firewall
types
Performance issues
as the Campus
scales to 10GE
Difficult to support
and troubleshoot
Many UBC faculties / departments
want a single, fully redundant
firewall system for their subnets
and VLANs, Campus-wide.
How to accommodate this?
Proliferation of
different firewall
types
Performance issues
as the Campus
scales to 10GE
Difficult to support
and troubleshoot
Many UBC faculties / departments
want a single, fully redundant
firewall system for their subnets
and VLANs, Campus-wide.
How to accommodate this?
.
Technically, it would be possible to
bridge VLANs across the core UBC network .
This has often been requested historically.
.
However, in practice this creates many difficulties …
It does not scale well.
The proliferation of Layer 2 loops in a fully-resilient
network design leads to many blocking / forwarding ports .
this is considered to be undesired in UBC’s network design.
.
As a consequence, bridging of VLANs
across the core is not supported by UBC.
.
To meet their needs, UBC looked towards
a Network Virtualization solution.
.
VRFs (Virtual Routing and Forwarding instances) .
provide for a separate IP routing table per
department or faculty . even when
distributed over multiple buildings.
.
VRFs provide the required
segmentation . to provide
a “virtual network” for the
department or faculty
involved.
.
Within a VRF
High-performance routing for the department / faculty.
.
Between VRFs
Traffic flows across Virtual Firewalls, hosted on UBC’s
Catalyst 6500-based Firewall Services Modules (FWSMs).
Each Virtual Firewall can be managed separately
by the department / faculty involved
(aids in scaling manageability).
.
No need for VLAN bridging
The UBC core network remains entirely
routed . promotes stability, maintains
core network policies.
.UBC needed a solution that could scale to handle
the number of departments / faculties on Campus.
.The options for a Network Virtualization
deployment include …
-VRF-Lite with GRE Tunnels,
#NAME?
#NAME?
.For the scale requirements
of UBC, an MPLS VPN
deployment model was chosen.
.UBC needed a solution that could scale to handle
the number of departments / faculties on Campus.
.The options for a Network Virtualization
deployment include …
-VRF-Lite with GRE Tunnels,
#NAME?
#NAME?
.For the scale requirements
of UBC, an MPLS VPN
deployment model was chosen.
CNSF - May, 2011 ⓒ 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 28
. When designing, planning, and
building their Network Virtualization
deployment, UBC used Cisco’s
Network Virtualization
Design Guides extensively …
NV Access Control Design Guide
NV Path Isolation Design Guide
NV Services Edge Design Guide
www.cisco.com/go/designzone
. MPLS VPN uses Multi-Protocol BGP (MP-BGP)
for exchanging MPLS tags (for creating isolated domains).
The first step was
implementing the
Route Reflectors
for MP-BGP.
UBC used a pair
of Cisco 7200
routers for
this purpose.
.The next step was determining where to place the
P (Provider) and PE (Provider Edge) routers.
UBC uses
Catalyst 6509
switches, which
support MPLS.
The Inner Core
6509s are the
P routers.
The Outer Core
6509s are the
PE routers.
ⓒ 2011 Cisco and/or its affiliates. All rights CNSF - May, 2011 reserved. Cisco Public 31
. After determining the P and PE router locations,
it was necessary to set up the appropriate routing.
All of the Outer
Core 6509s peer
(MP-BGP) with the
two Route Reflectors .
for MPLS VPN
(VRF) route exchange.
The Inner Core
routers are not
aware of VRFs .
(and do not run MP-BGP .
OSPF only, with MPLS
tagging).
. Providing for Layer 3 VLAN termination,
mapping into VRFs, and First Hop redundancy were the next tasks.
VLANs terminate
at the Outer Core
layer, and are
mapped into
VRFs using SVIs.
HSRP is used
across the PE
router pair for
first-hop redundancy.
.Providing for Layer 3 VLAN termination,
mapping into VRFs, and First Hop redundancy were the next tasks.
VLANs terminate
at the Outer Core
layer, and are
mapped into
VRFs using SVIs.
HSRP is used
across the PE
router pair for
first-hop redundancy.
ⓒ 2011 Cisco and/or its affiliates. All rights CNSF - May, 2011 reserved. Cisco Public 33
. VLAN and VRF definitions at the PE routers …
Note . VRFs are only defined on the PE routers where the VRFs need
to terminate … not all VRFs are defined on all PE routers …
Outer Core (PE), VLANs and VRFs
vlan 627
name VLAN-627-MED-ADMIN
ip vrf MED-ADMIN
rd 65111:521
route-target export 65111:521
route-target import 65111:521
VLAN definition . Layer 2
VRF definition . Layer 3
The RD is a 64-bit value
(unique per VRF). When added
to the 32-bit IP address, this forms
a unique 96-bit VPNv4 address.
Routes are imported
and exported within the VRF,
to populate the VRF’s
IP routing table.
ⓒ 2011 Cisco and/or its affiliates. All rights CNSF - May, 2011 reserved. Cisco Public 34
Outer Core (PE), VLANs and VRFs
vlan 627
name VLAN-627-MED-ADMIN
ip vrf MED-ADMIN
rd 65111:521
route-target export 65111:521
route-target import 65111:521
. SVI definition on the PE router,
showing SVIs with VRF mapping,
and HSRP and DHCP Relay functionality enabled …
Outer Core (PE), SVI configuration
OUTER-2# show run int Vlan 627
!
interface Vlan627
description VLAN-627-MED-ADMIN
mtu 8500
ip vrf forwarding MED-ADMIN
ip address 172.16.10.253 255.255.255.0
ip helper-address 10.10.5.1
ip helper-address 10.10.6.1
standby ip 172.16.10.254
standby priority 105
standby preempt
standby authentication md5 key-string 7 <secret> For DHCP forwarding
(within the VRF)
For HSRP
(within the VRF)
. VLANs are mapped into VRFs via definitions on SVIs.
“show ip vrf” shows all VLAN-to-VRF mappings …
Outer Core (PE), VLANs and VRFs
vlan 627
name VLAN-627-MED-ADMIN
ip vrf MED-ADMIN
rd 65111:521
route-target export 65111:521
route-target import 65111:521
OUTER-2# show ip vrf
Name Default RD Interfaces
MED-ADMIN 65111:521 Vl185
Vl431
Vl627
Vl2199
VLANs mapped into the VRF
(in this example, 4 VLANs total
in this VRF, on this PE)
OUTER-2# show run int Vlan 627
!
interface Vlan627
description VLAN-627-MED-ADMINmtu 8500
ip vrf forwarding MED-ADMIN
ip address 172.16.10.253 255.255.255.0
ip helper-address 10.10.5.1
ip helper-address 10.10.6.1
standby ip 172.16.10.254
standby priority 105standby preemptstandby authentication md5 key-string 7 <secret>
Outer Core (PE), SVI configuration
.Connected routes and static routes within the VRF
are redistributed into MP-BGP …
making these routes available on other PEs
that also host this VRF …
Outer Core (PE), Connected / Static
interface Vlan185
ip vrf forwarding MED-ADMIN
ip address 172.16.2.253 255.255.255.248
interface Vlan431
ip vrf forwarding MED-ADMIN
ip address 172.16.5.253 255.255.255.128
interface Vlan627
ip vrf forwarding MED-ADMIN
ip address 172.16.10.253 255.255.255.0
interface Vlan2199
ip vrf forwarding MED-ADMIN
ip address 172.16.33.253 255.255.255.192
ip route vrf MED-ADMIN 0.0.0.0 0.0.0.0 172.16.2.249 name DEFAULT-ROUTE=MED-ADMIN
Static route to virtual firewall
(in this example, co-located
on this PE router, via VLAN 185)
Connected routes within the VRF
(local SVIs on this PE router)
Named
Static
Routes
router bgp 65111
!
address-family ipv4 vrf MED-ADMIN
redistribute connected
redistribute static
no synchronizationnetwork 0.0.0.0
exit-address-family
Outer Core (PE), Connected / Static Outer Core (PE), Redistribution
interface Vlan185
ip vrf forwarding MED-ADMIN
ip address 172.16.2.253 255.255.255.248
interface Vlan431
ip vrf forwarding MED-ADMIN
ip address 172.16.5.253 255.255.255.128
interface Vlan627
ip vrf forwarding MED-ADMIN
ip address 172.16.10.253 255.255.255.0
interface Vlan2199
ip vrf forwarding MED-ADMIN
ip address 172.16.33.253 255.255.255.192
ip route vrf MED-ADMIN 0.0.0.0 0.0.0.0 172.16.2.249 name DEFAULT-ROUTE=MED-ADMIN
Redistribution of routes
to other PEs (via MP-BGP)
.Connected routes and static routes within the VRF
are redistributed into MP-BGP …
making these routes available on other PEs
that also host this VRF …
OUTER-2# show ip route vrf MED-ADMIN
Routing Table: MED-ADMINCodes: C - connected, S - static, R - RIP, M - mobile, B . BGP
. . .
Gateway of last resort is 172.16.2.249 to network 0.0.0.0
172.16.0.0/16 is variably subnetted, 3 subnets, 3 masks
C 172.16.2.248/29 is directly connected, Vlan185B 172.16.139.192/27 [200/0] via 192.168.1.3, 5w3dC 172.16.5.128/25 is directly connected, Vlan431C 172.16.33.192/26 is directly connected, Vlan2199B 172.16.155.128/26 [200/0] via 192.168.1.5, 5w3dB 172.16.211.0/26 [200/0] via 192.168.1.5, 5w3dC 172.16.10.0/24 is directly connected, Vlan627S* 0.0.0.0/0 [1/0] via 172.16.2.249
Outer Core (PE), IP Routing Table
.Now that we have done all of our VLAN and VRF definitions,
SVI configuration, and route redistribution …
… let’s see the results …
Route via PE .
Outer-3
Route via PE .
Outer-5
.
Now we have Campus-wide “virtual networks”
for departments and faculties, on demand!
Outer Core (PE), IP Routing Table
OUTER-2# show ip route vrf MED-ADMIN
Routing Table: MED-ADMIN .
Simplified
Codes: C - connected, S - static, R - RIP, M - mobile, B . BGP
. . . departmental
Gateway of last resort is 172.16.2.249 to network 0.0.0.0 routing table
172.16.0.0/16 is variably subnetted, 3 subnets, 3 masks
C 172.16.2.248/29 is directly connected, Vlan185
.
Secure
B 172.16.139.192/27 [200/0] via 192.168.1.3, 5w3d
C 172.16.5.128/25 is directly connected, Vlan431
network
C 172.16.33.192/26 is directly connected, Vlan2199
B 172.16.155.128/26 [200/0] via 192.168.1.5, 5w3d
segmentation
B 172.16.211.0/26 [200/0] via 192.168.1.5, 5w3d
C 172.16.10.0/24 is directly connected, Vlan627
S* 0.0.0.0/0 [1/0] via 172.16.2.249
.
Scalable
From this …
To this …
FacultyVirtual Firewall
From this …
To this …
FacultyVirtual Firewall
OUTER-2# ping vrf MED-ADMIN 172.16.155.188
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.155.188,
timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5),
round-trip min/avg/max = 1/1/1 ms
OUTER-2#
OUTER-2# traceroute vrf MED-ADMIN
172.16.155.188
Type escape sequence to abort.
Tracing the route to 172.16.155.188
1 10.1.1.1 [MPLS: Labels 165/27 Exp 0]
4 msec 0 msec 0 msec
2 172.16.155.188
0 msec 0 msec 0 msec
OUTER-2#
“ping” within a VRF “traceroute” within a VRF
.Network maintenance and troubleshooting tasks
are readily adapted into a multi-VRF environment …
.
Network maintenance and troubleshooting tasks
are readily adapted into a multi-VRF environment …
“show ip arp” within a VRF
OUTER-2# show ip arp vrf MED-ADMIN
Protocol Address Age (min) Hardware Addr Type Interface
Internet 172.16.2.250 204 0034.a984.4c80 ARPA Vlan185
Internet 172.16.2.249 169 0086.c873.d200 ARPA Vlan185
Internet 172.16.2.254 -0000.0c07.ac00 ARPA Vlan185
Internet 172.16.2.253 -0018.a4e4.d700 ARPA Vlan185
Internet 172.16.5.253 -0018.a4e4.d700 ARPA Vlan431
Internet 172.16.33.202 10 0019.e8db.7da3 ARPA Vlan2199
Internet 172.16.5.177 3 001c.f257.4581 ARPA Vlan431
Internet 172.16.10.14 28 001e.a599.b9a7 ARPA Vlan627
Internet 172.16.10.25 1 001a.02ec.3af2 ARPA Vlan627
. . .
IP Header IP payload IGP Tag VPN Tag
IP Header IP payload VPN Tag
Header IP payload
IP Header IP payload
Logical Network Flow
OUTER-2# show mls cef vrf
MED-ADMIN 172.16.139.92
Codes: + - Push Label
Prefix Adjacency172.16.139.92/27 Te1/1 19(+), 1193(+)
PE
P
PE
Tag push
RED = traffic within the Red VRF
GOLD = MPLS-encapsulated traffic
Tag pop(IGP) Tag pop (VPN),
IP lookup
IP Header IP payload IGP Tag VPN Tag
IP Header IP payload VPN Tag
Header IP payload
IP Header IP payload
Logical Network Flow
OUTER-2# show mls cef vrf
MED-ADMIN 172.16.139.92
Codes: + - Push Label
Prefix Adjacency172.16.139.92/27 Te1/1 19(+), 1193(+)
PE
P
PE
Tag push
RED = traffic within the Red VRF
GOLD = MPLS-encapsulated traffic
Tag pop(IGP) Tag pop (VPN),
IP lookup
.
Traffic between VRFs will traverse a Virtual Firewall .
… these are hosted on UBC’s FWSMs …
UBC operates
multiple FWSMs,
distributed around
Campus.
The default route in
each departmental VRF
points to that VRF’s
OUTER-2# show ip route vrf MED-ADMIN
redundant Virtual
Routing Table: MED-ADMINCodes: C - connected, S - static, R - RIP, M - mobile, B . BGP
Firewall instance …
. . .
Gateway of last resort is 172.16.2.249 to network 0.0.0.0
… hosted on an
...
FWSM pair (on the PEs).
S* 0.0.0.0/0 [1/0] via 172.16.2.249
Logical Network Flow
PE
Virtual FW
PE
PE
P
RED = traffic within the Red VRF
PURPLE = IP routed traffic (via OSPF)
GREEN = traffic within the Green VRF
Virtual FW
Policy
Policy
PE
Logical Network Flow
PE
Virtual FW
PE
PE
P
RED = traffic within the Red VRF
PURPLE = IP routed traffic (via OSPF)
GREEN = traffic within the Green VRF
Virtual FW
Policy
Policy
PE
Logical Network Flow
Border
P
PE
RED = traffic within the Red VRF
PURPLE = IP routed traffic (via OSPF)
Virtual FW
Policy
PE
Logical Network Flow
Border
P
PE
RED = traffic within the Red VRF
PURPLE = IP routed traffic (via OSPF)
Virtual FW
Policy
PE
.
Previously, UBC did not provide Campus-wide multicast .
… inability to securely limit multicast use.
.
Now with Network Virtualization, UBC can
provision multicast support in some VRFs, and not in others.
.
UBC employs both intra-VRF (MVPN) and inter-VRF
(Extranet MVPN) in their Campus multicast deployment.
.
Benefit . UBC can now securely enable
multicast on-demand, within and between
VRFs, Campus-wide.
This opens up many new possibilities
for educational data delivery.
.UBC is virtualizing their Data Center .
using industry-leading virtualized load-balancing,
Virtual Machine, and virtualized storage technologies.
.Virtual Load Balancing .
UBC is leveraging the capabilities of their ACE
platforms to create per-department / faculty virtual
load balancer instances, associated with the
department / faculty VRFs and Virtual Firewalls.
.Benefit . allows for individualized,
high-performance load-balancing,
with separated management
(aids in scaling, manageability,
and solution customization).
.UBC is virtualizing their Data Center .
using industry-leading virtualized load-balancing,
Virtual Machine, and virtualized storage technologies.
.Virtual Load Balancing .
UBC is leveraging the capabilities of their ACE
platforms to create per-department / faculty virtual
load balancer instances, associated with the
department / faculty VRFs and Virtual Firewalls.
.Benefit . allows for individualized,
high-performance load-balancing,
with separated management
(aids in scaling, manageability,
and solution customization).
.Virtual Machines . can be mapped into VLANs …
which are mapped into VRFs …
Direct VM access, at high speed, from anywhere on Campus
VMs within the DC can be protected behind
departmental / faculty Virtual Firewalls as needed.
.New virtualized services can be spun up on demand
in the DC, and mapped out to departments and faculties .
Fully secured by the UBC virtualized network infrastructure.
.Benefit . allows rapid adoption of VM services .
Hosted in the UBC Data Center,
securely integrated Campus-wide.
.
Virtual Storage . UBC is using Nexus 5000 switches
and IP-based NAS storage to front-end their SAN.
This NAS storage can be virtualized, mapped into VLANs / VRFs,
provided to Virtual Machines, and located behind virtual firewalls.
.
This allows UBC to deploy virtualized, IP-based storage .
Mapped into their virtualized Campus and
Data Center network topology, for secure,
flexible access.
.
Benefit . allows high-performance,
virtualized, IP-accessible storage
Securely integrated into, and made available
seamlessly across, the UBC virtualized
network architecture.
.
UBC is examining the use of IPv6 on Campus .
Small deployments underway, with a larger Campus deployment under
consideration / in planning.
Catalyst 6500
core switches
offer support
for 6VPE
capability.
Cisco Catalyst 6500:
Building IPv6-Ready Campus Networks -
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/solution_overview_c22-531339.html
.
Response from UBC Faculties and Departments .
Demand for UBC’s virtualized network deployment
has been strong since inception in January, 2009.
Departments and faculties have seen the
advantages of virtualized networking, and are
embracing the many benefits which UBC’s
virtualized network infrastructure provides.
.
UBC has derived many technical benefits
from their Network Virtualization deployment …
Scalable deployment for departmental / faculty segmentation.
End-to-end high performance .
High-performance IP / MPLS routing within a VRF.
Ability to consolidate and scale virtualized
firewalls, for traffic moving between VRFs.
Ability to securely deploy multicast
(MVPN / Extranet MVPN).
Ability to securely roll outa suite of virtualized DC services,
for high-performance, secure data access.
.
UBC has derived many business benefits
from their Network Virtualization deployment …
The network design reflects UBC organizational boundaries.
For the first time, security is
an integral part of network deployment.
The network design can scale to 10Gbps+,
low-performance firewalls are no longer a constraint.
UBC departments and faculties can locate services anywhere
on Campus (including within the UBC DC), and enjoy the
same secure, high-performance, seamless access.
Economies of scale, “greener” .
using centralized services.
www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/case_study_c36-609342.html
.Published .
Summer
2010
www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/case_study_c36-609342.html
.Published .
Summer
2010
www.cisco.com/go/networkvirtualization

Thank you.
View All (819)
4G (2) 4G Evolution (1) 5G (36) 5g (1) 802.11 (1) 802.1X (1) ALTO (1) ANDSF (1) AT&T (2) Acceleration (1) Adobe HDS (3) Akamai (6) Amazon (3) Apple HLS (4) Authentication (1) BRAS (2) BT (1) Backbone (4) Backhaul (12) BitTorrent (1) Broadcasting (3) C-RAN (13) C-RAN/Fronthaul (12) CCN (4) CDN (52) CDNi (1) COLT (1) CORD (1) CPRI (2) Cache Control (1) Caching (5) Carrier Cloud (2) Carrier Ethernet (9) Channel Zapping (4) China Mobile (1) China Telecom (1) Cloud (10) Cloudfront (1) DASH (2) DCA (1) DHCP (3) DNS (1) DSA (1) Data Center (7) Dynamic Web Acceleration (1) EDGE (1) EPC (5) Energy (1) Ericsson (5) Ethernet (8) FEO (2) Fairness (1) Fronthaul (5) GiGAtopia (1) Gigabit Internet (2) Global CDN (1) Google (5) HLS (1) HTTP (1) HTTP Adaptive Streaming (18) HTTP Progressive Download (3) HTTP Streaming (1) HetNet (1) Hot-Lining (1) Hotspot 2.0 (2) Huawei (3) ICN (4) IP (1) IP Allocation (1) IP Routing (8) IPTV (15) Intel (1) Internet (1) Interoperability (2) IoST (1) IoT (14) KT (22) LG U+ (3) LTE (70) LTE MAC (1) LTE-A (2) Licensed CDN (1) M2M (3) MEC (3) MPLS (25) MVNO (1) Market (4) Metro Ethernet (7) Microsoft (2) Migration (1) Mobile (4) Mobile Backhaul (1) Mobile Broadcasting (1) Mobile CDN (2) Mobile IP (1) Mobile IPTV (3) Mobile Video (1) Mobile Web Perormance (1) Mobility (1) Multi-Screen (7) Multicast (7) NFC (1) NFV (2) NTT Docomo (2) Netflix (6) Network Protocol (31) Network Recovery (3) OAM (6) OTT (31) Ofcom (1) Offloading (2) OpenFlow (1) Operator CDN (14) Orange (1) P2P (4) PCC (1) Page Speed (1) Programmable (1) Protocol (7) Pseudowire (1) QoS (5) Router (1) SCAN (1) SD-WAN (1) SDN (15) SDN/NFV (15) SK Telecom (22) SON (1) SaMOG (1) Samsung (2) Security (6) Service Overlay (1) Silverlight (4) Small Cell (3) Smart Cell (1) Smart Grid (2) Smart Network (2) Supper Cell (1) Telefonica (1) Telstra (1) Terms (1) Traffic (2) Traffic Engineering (1) Transcoding (3) Transparent Cache (2) Transparent Caching (14) VLAN (2) VPLS (2) VPN (9) VRF (2) Vendor Product (2) Verizon (2) Video Optimization (4) Video Pacing (1) Video Streaming (14) Virtual Private Cloud (1) Virtualization (3) White Box (1) Wholesale CDN (4) Wi-Fi (13) WiBro(WiMAX) (4) Wireless Operator (5) YouTube (4) eMBMS (4) eNB (1) 망이용대가 (1) 망중립성 (1) 스마트 노드 (1)

 

 

     
         
     

 

     
     

넷매니아즈 회원 가입 하기

2020년 1월 현재 넷매니아즈 회원은 49,000+분입니다.

 

넷매니아즈 회원 가입을 하시면,

► 넷매니아즈 신규 컨텐츠 발행 소식 등의 정보를

   이메일 뉴스레터로 발송해드립니다.

► 넷매니아즈의 모든 컨텐츠를 pdf 파일로 다운로드

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

비밀번호 확인
코멘트 작성시 등록하신 비밀번호를 입력하여주세요.
비밀번호