Dave

 Zacks            CCIE  8887  

Technical  Solu7ons  Architect  
#CNSF2011
© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 2
 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.
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
 #CNSF2011
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 4
  Groups and services
are logically separated …
Resources Internet
Guest / partner access
Departmental separation
Regulatory compliance (HIPPA, PCI …)
Building controls, video surveillance
Non-Virtualized Network
Mergers, acquisitions … and many others

 Closed User Groups …

Virtualized
Private
Network
Secure
Independent policies

 Service differentiation
is configured per group / service …
Dept A Dept B Partner Guest The same application
can be unique per group / service
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 5
 One physical network
supports many virtual networks
Separate Departments Separate Functions Guests / Partners

Virtual Virtual Virtual

Actual Physical Network Infrastructure

CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 6
 Service Access Control Path Isolation Services Edge
Branch – Campus WAN – MAN – Campus Data Center – Internet Edge – Campus

GRE MPLS

VRFs

Internet

Functions  Authenticate  Maintain traffic partitions  Provide access

client (user, device, over Layer 3 infrastructure to services –
application) attempting to
 Transport traffic over Shared
gain network access
isolated Layer 3 partitions Dedicated
 Authorize client
into a partition (VLAN)  Map Layer 3 isolated path  Apply policy per partition
to VLANs in access and services
 Deny access to edge  Isolate application
unauthenticated clients environments
if necessary
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 7
 Per VRF:
Virtual Routing Table
Virtual Forwarding Table
 Device virtualization –
Control plane virtualization VRF
VRF
Data plane virtualization
Global
Services virtualization

 Data path virtualization –

Hop-by-Hop – 802.1q

(VRF-Lite End-to-End)
IP
Multi-Hop –
(VRF-Lite+GRE, MPLS VPN)

VRF – Virtual Routing and Forwarding

CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 8
1. Create L2 VLANs
and trunk them to the first L3 device
2. Define VRFs at the first L3 devices (PE) PE
and map the L2 VLANs to the proper VRF
Enable MPLS
3. Enable MPLS on all
Layer 3 interfaces in the network
Label Switch
Router (LSR) P P
4. Enable MP-BGP on the
PE devices to exchange VPN routes
Enable MPLS
PEs become iBGP neighbors
PE
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)

CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 9
 iBGP requires a full mesh of neighbors
172.16.5.0/24 172.16.8.0/24
N * (N-1) / 2 = 8 * 7 / 2 = 28
S2 S3 S4
R1S1 R4

172.17.6.0/24 172.17.9.0/24

172.18.7.0/24 172.18.10.0/24

For Your
Reference
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 10
 Route Reflector Route Reflector

172.16.5.0/24 172.16.8.0/24

S2 S3 S4
R1S1 R4

172.17.6.0/24 172.17.9.0/24

172.18.7.0/24 172.18.10.0/24

For Your
Reference
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 11
 Firewall contexts in transparent mode Shared Services
act as L2 bridges E-mail
 Fusion router establishes routing Storage
Web
peering with the various VRFs …

The fusion router has complete knowledge

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

CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 13
 Shared Services Global Table

Red Blue Global Red Blue GreenV

VPN VPN Table VPN VPN PN

The global table is considered as another The global table is treated as a shared
VPN (in fact can be usually considered service – access to the global table
the “default VPN”) and it is front-ended from each VPN is subject to the policy
by its own security device enforcement provided by the Services Edge
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 14
 #CNSF2011
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 15
  UBC is one of the largest
Universities in Canada.

 The main UBC Campus is

located in Vancouver, BC
(UBCV).

 UBCV Campus is 1.55 square miles

in extent, covers several hundred
buildings in total.

 Three additional (smaller)

UBC
is here Campuses located around BC
You are here
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 16
 On a beautiful summer day …
June 25th, 2010

Clock Tower,
I.K Barber
adjacent to the I.K Barber
Learning Centre
Learning Centre,
University of
University of BC
BC
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 17
 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
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 18
 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
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 19
 Typical
No deliberate Large
Building
Fully resilient core
Access
Layer 2 loops network, based on
in the network OSPF routing
Distribution

Outer Core Data Center

Inner Core
Additional
Buildings

No VLAN bridging Layer 3 FHRP

across the core – provided by HSRP
routed links only Internet Edge at Outer Core layer
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 20
 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)!

CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 21
 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.

CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 22
 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?

CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 23
 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.
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 24
 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.
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 25
 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.
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 26
 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,
- VRF-Lite End-to-End, or
- MPLS VPNs

 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 27
 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  
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 28
 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.

CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 29
 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.
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 30
 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
CNSF - May, 2011
tagging).
© 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 31
 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.

CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 32
  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 VLAN definition – Layer 2
ip vrf MED-ADMIN
rd 65111:521
route-target export 65111:521
route-target import 65111:521
VRF definition – Layer 3

The RD is a 64-bit value Routes are imported

(unique per VRF). When added and exported within the VRF,
to the 32-bit IP address, this forms to populate the VRF’s
a unique 96-bit VPNv4 address. IP routing table.
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 33
  SVI definition on the PE router,
showing SVIs with VRF mapping,
and HSRP and DHCP Relay functionality enabled …

Outer Core (PE), VLANs and VRFs Outer Core (PE), SVI configuration
OUTER-2# show run int Vlan 627
vlan 627
!
name VLAN-627-MED-ADMIN
interface Vlan627
description VLAN-627-MED-ADMIN
mtu 8500
ip vrf MED-ADMIN
ip vrf forwarding MED-ADMIN
rd 65111:521
ip address 172.16.10.253 255.255.255.0
route-target export 65111:521
route-target import 65111:521 ip helper-address 10.10.5.1
ip helper-address 10.10.6.1
standby ip 172.16.10.254
standby priority 105
For DHCP forwarding standby preempt
standby authentication md5 key-string 7 <secret>
(within the VRF)
For HSRP
(within the VRF)
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 34
  VLANs are mapped into VRFs via definitions on SVIs.
“show ip vrf” shows all VLAN-to-VRF mappings …

Outer Core (PE), VLANs and VRFs Outer Core (PE), SVI configuration
OUTER-2# show run int Vlan 627
vlan 627
!
name VLAN-627-MED-ADMIN
interface Vlan627
description VLAN-627-MED-ADMIN
mtu 8500
ip vrf MED-ADMIN
ip vrf forwarding MED-ADMIN
rd 65111:521
ip address 172.16.10.253 255.255.255.0
route-target export 65111:521
route-target import 65111:521 ip helper-address 10.10.5.1
ip helper-address 10.10.6.1
standby ip 172.16.10.254
standby priority 105
OUTER-2# show ip vrf
standby preempt
Name Default RD Interfaces
standby authentication md5 key-string 7 <secret>
MED-ADMIN 65111:521 Vl185
Vl431 VLANs mapped into the VRF
Vl627
Vl2199
(in this example, 4 VLANs total
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Publicin this VRF, on this PE) 35
  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 Connected routes within the VRF
ip vrf forwarding MED-ADMIN (local SVIs on this PE router)
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 Static route to virtual firewall
ip address 172.16.10.253 255.255.255.0 (in this example, co-located
interface Vlan2199 on this PE router, via VLAN 185)
ip vrf forwarding MED-ADMIN Named
ip address 172.16.33.253 255.255.255.192 Static
Routes
ip route vrf MED-ADMIN 0.0.0.0 0.0.0.0 172.16.2.249 name DEFAULT-ROUTE=MED-ADMIN

CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 36
  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 Outer Core (PE), Redistribution
interface Vlan185 router bgp 65111
ip vrf forwarding MED-ADMIN !
ip address 172.16.2.253 255.255.255.248 address-family ipv4 vrf MED-ADMIN
redistribute connected
interface Vlan431 redistribute static
ip vrf forwarding MED-ADMIN no synchronization
ip address 172.16.5.253 255.255.255.128 network 0.0.0.0
interface Vlan627 exit-address-family
ip vrf forwarding MED-ADMIN
ip address 172.16.10.253 255.255.255.0
Redistribution of routes
interface Vlan2199
to other PEs (via MP-BGP)
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

CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 37
  Now that we have done all of our VLAN and VRF definitions,
SVI configuration, and route redistribution …
… let’s see the results …

Outer Core (PE), IP Routing Table

OUTER-2# show ip route vrf MED-ADMIN
Routing Table: MED-ADMIN
Codes: C - connected, S - static, R - RIP, M - mobile, B – BGP
Route via PE –
. . .
Outer-3
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, Vlan185
B 172.16.139.192/27 [200/0] via 192.168.1.3, 5w3d
C 172.16.5.128/25 is directly connected, Vlan431 Route via PE –
C
B
172.16.33.192/26 is directly connected, Vlan2199
172.16.155.128/26 [200/0] via 192.168.1.5, 5w3d Outer-5
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

CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 38
  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
B
172.16.2.248/29 is directly connected, Vlan185
172.16.139.192/27 [200/0] via 192.168.1.3, 5w3d  Secure
C
C
172.16.5.128/25 is directly connected, Vlan431
172.16.33.192/26 is directly connected, Vlan2199
network
B
B
172.16.155.128/26 [200/0] via 192.168.1.5, 5w3d
172.16.211.0/26 [200/0] via 192.168.1.5, 5w3d
segmentation
C 172.16.10.0/24 is directly connected, Vlan627
S* 0.0.0.0/0 [1/0] via 172.16.2.249
 Scalable
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 39
 Faculty
Virtual Firewall
From this …

To this …

CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 40
  Network maintenance and troubleshooting tasks
are readily adapted into a multi-VRF environment …

“ping” within a VRF “traceroute” within a VRF

OUTER-2# ping vrf MED-ADMIN 172.16.155.188 OUTER-2# traceroute vrf MED-ADMIN

172.16.155.188
Type escape sequence to abort.
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.155.188, Tracing the route to 172.16.155.188
timeout is 2 seconds:
1 10.1.1.1 [MPLS: Labels 165/27 Exp 0]
!!!!! 4 msec 0 msec 0 msec

Success rate is 100 percent (5/5), 2 172.16.155.188

round-trip min/avg/max = 1/1/1 ms 0 msec 0 msec 0 msec

OUTER-2# OUTER-2#

CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 41
  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

. . .

CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 42
 Logical Network Flow

PE

P
RED = traffic within the Red VRF
GOLD = MPLS-encapsulated traffic
PE

OUTER-2# show mls cef vrf

MED-ADMIN 172.16.139.92 Tag push IP Header IP payload

IGP Tag VPN Tag IP Header IP payload

Codes: + - Push Label
Tag pop VPN Tag IP Header IP payload
Prefix Adjacency
(IGP) Tag pop (VPN),
172.16.139.92/27 Te1/1 19(+), ©1193(+) IP Header IP payload
CNSF - May, 2011 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public
IP lookup 43
 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-ADMIN

Firewall instance … Codes: C - connected, S - static, R - RIP, M - mobile, B – BGP

. . .

… hosted on an Gateway of last resort is 172.16.2.249 to network 0.0.0.0

...
FWSM pair (on the PEs).
S* 0.0.0.0/0 [1/0] via 172.16.2.249
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 44
 Logical Network Flow

PE

Virtual FW

Policy
RED = traffic within the Red VRF
PURPLE = IP routed traffic (via OSPF)
PE
GREEN = traffic within the Green VRF

PE

Virtual FW

Policy

PE

CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 45
 Logical Network Flow

Border

P
RED = traffic within the Red VRF
PURPLE = IP routed traffic (via OSPF)

PE

Virtual FW

Policy

PE

CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 46
 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.
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 47
 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).
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 48
 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.
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 49
 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.
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 50
 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
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 51
 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 is also employing virtualization for

additional Campus services and functions.

CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 52
 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 out
a suite of virtualized DC services,
for high-performance, secure data access.
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 53
 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.
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 54
  Published –
Summer
2010

www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/case_study_c36-609342.html
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. 55
Cisco Public
 www.cisco.com/go/networkvirtualization
CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 56
 #CNSF2011
© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 57
 #CNSF2011
© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 58
Thank you.

#CNSF2011