Cisco Canada, profile picture
Uploaded byCisco Canada
3,086 views

Network Infrastructure Virtualization Case Study

The document discusses a customer case study regarding network virtualization deployed at the University of British Columbia (UBC), focusing on their business requirements and the design methodology employed. UBC adopted a scalable network architecture using VRFs (Virtual Routing and Forwarding) with MPLS VPN to manage a large number of departments and to achieve secure, high-performance routing while avoiding VLAN bridging issues. This case study illustrates how UBC effectively utilized Cisco's network virtualization design guides to address their unique networking needs across a vast campus infrastructure.

Downloaded 213 times
© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 1
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 Resources Internet are logically separated … Guest / partner access Departmental separation Regulatory compliance (HIPPA, PCI …) Non-Virtualized Network Building controls, video surveillance Mergers, acquisitions … and many others   Closed User Groups … Virtualized Network Private 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 Department Function Guests / A B 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, application) over Layer 3 infrastructure to services – attempting to gain network   Transport traffic over Shared 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 edge   Deny access to   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 Data plane virtualization VRF 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 S1 S2 S3 S4 R1 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
Ro ute Reflector Route Reflector 172.16.5.0/24 172.16.8.0/24 S1 S2 S3 S4 R1 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 Storage   Fusion router establishes routing 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 GreenVP VPN N   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 VPN Blue GreenVP VPN N   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 VPN Blue Global Table Red VPN Blue GreenVP VPN VPN N 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 Campuses located around BC is here 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 BC University of 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 Large No deliberate 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 tagging). CNSF - May, 2011 © 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 ip vrf MED-ADMIN mtu 8500 rd 65111:521 ip vrf forwarding MED-ADMIN route-target export 65111:521 ip address 172.16.10.253 255.255.255.0 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 standby preempt For DHCP forwarding 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 ip vrf MED-ADMIN mtu 8500 rd 65111:521 ip vrf forwarding MED-ADMIN route-target export 65111:521 ip address 172.16.10.253 255.255.255.0 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 (in this example, 4 VLANs total Vl2199 in this VRF, on this PE) CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 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 ip address 172.16.33.253 255.255.255.192 Named ip route vrf MED-ADMIN 0.0.0.0 0.0.0.0 172.16.2.249 name DEFAULT-ROUTE=MED-ADMIN Static Routes 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 exit-address-family interface Vlan627 ip vrf forwarding MED-ADMIN ip address 172.16.10.253 255.255.255.0 Redistribution of routes to other PEs (via MP-BGP) 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 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 – Gateway of last resort is 172.16.2.249 to network 0.0.0.0 Outer-3 172.16.0.0/16 is variably subnetted, 3 subnets, 3 masks C 172.16.2.248/29 is directly connected, Vlan185 B C 172.16.139.192/27 [200/0] via 192.168.1.3, 5w3d 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 C 172.16.0.0/16 is variably subnetted, 3 subnets, 3 masks 172.16.2.248/29 is directly connected, Vlan185   Secure B C 172.16.139.192/27 [200/0] via 192.168.1.3, 5w3d 172.16.5.128/25 is directly connected, Vlan431 network C B 172.16.33.192/26 is directly connected, Vlan2199 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 S* 172.16.10.0/24 is directly connected, Vlan627 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 Prefix Adjacency VPN Tag IP Header IP payload Tag pop (IGP) 172.16.139.92/27 Te1/1 19(+), 1193(+) Tag pop (VPN), 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 redundant Virtual OUTER-2# show ip route vrf MED-ADMIN Firewall instance … Routing Table: MED-ADMIN Codes: C - connected, S - static, R - RIP, M - mobile, B – BGP … hosted on an . . . FWSM pair (on the PEs). Gateway of last resort is 172.16.2.249 to network 0.0.0.0 ... 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 P 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 technical and business 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. Cisco Public 55
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

More Related Content

PDF
AWS DirectConnect 구성 가이드 (김용우) - 파트너 웨비나 시리즈
byAmazon Web Services Korea
 
PDF
[오픈소스컨설팅] 쿠버네티스와 쿠버네티스 on 오픈스택 비교 및 구축 방법
byOpen Source Consulting
 
PDF
[AKIBA.AWS] VGWのルーティング仕様
byShuji Kikuchi
 
PDF
AWS Outpostsセミナー オンプレミスネットワークとの接続
byShuji Kikuchi
 
PDF
AWS Black Belt Online Seminar 2016 AWS上でのActive Directory構築
byAmazon Web Services Japan
 
PDF
AWS Black Belt Techシリーズ Amazon Cognito / Amazon Mobile Analytics
byAmazon Web Services Japan
 
PDF
Azure Log Analytics 概要
by喜智 大井
 
PPTX
AWSでEC2上にMTAを構築した話
by康宏 緒方
 
AWS DirectConnect 구성 가이드 (김용우) - 파트너 웨비나 시리즈
byAmazon Web Services Korea
 
[오픈소스컨설팅] 쿠버네티스와 쿠버네티스 on 오픈스택 비교 및 구축 방법
byOpen Source Consulting
 
[AKIBA.AWS] VGWのルーティング仕様
byShuji Kikuchi
 
AWS Outpostsセミナー オンプレミスネットワークとの接続
byShuji Kikuchi
 
AWS Black Belt Online Seminar 2016 AWS上でのActive Directory構築
byAmazon Web Services Japan
 
AWS Black Belt Techシリーズ Amazon Cognito / Amazon Mobile Analytics
byAmazon Web Services Japan
 
Azure Log Analytics 概要
by喜智 大井
 
AWSでEC2上にMTAを構築した話
by康宏 緒方
 

What's hot

PDF
AWS 기반 클라우드 아키텍처 모범사례 - 삼성전자 개발자 포털/개발자 워크스페이스 - 정영준 솔루션즈 아키텍트, AWS / 유현성 수석,...
byAmazon Web Services Korea
 
PDF
202110 AWS Black Belt Online Seminar AWS Site-to-Site VPN
byAmazon Web Services Japan
 
PDF
Ansible과 CloudFormation을 이용한 배포 자동화
byAWSKRUG - AWS한국사용자모임
 
PDF
VMware on AWS를 통한 하이브리드 클라우드 구축 적용 - 홍정진, AWS Partner SA/ VMC on AWS
byAmazon Web Services Korea
 
PDF
vSRX on Your Laptop : PCで始めるvSRX ～JUNOSをさわってみよう！～
byJuniper Networks (日本)
 
PDF
Azure Automation 概要
by喜智 大井
 
PDF
마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트)
byAmazon Web Services Korea
 
PDF
Github - Git Training Slides: Foundations
byLee Hanxue
 
PDF
PHP-FPM の子プロセス制御方法と設定をおさらいしよう
byShohei Okada
 
PDF
AWS Black Belt Tech シリーズ 2016 - Amazon SES
byAmazon Web Services Japan
 
PDF
はじめての vSRX on AWS
byJuniper Networks (日本)
 
PDF
AWS Black Belt Techシリーズ Amazon VPC
byAmazon Web Services Japan
 
PPTX
[Citrix on Nutanix] LoginVSI による MCSとPVS の比較検証
byWataru Unno
 
PDF
実践 WebRTC 〜最新事例と開発ノウハウの紹介〜
byYusuke Naka
 
PDF
AWS IoTにおけるデバイスへの認証情報のプロビジョニング
byAmazon Web Services Japan
 
PDF
vSphere 7 へのアップグレードについて
by富士通クラウドテクノロジーズ株式会社
 
PDF
オンプレミスRDBMSをAWSへ移行する手法
byAmazon Web Services Japan
 
PDF
Amazon S3による静的Webサイトホスティング
byYasuhiro Horiuchi
 
PDF
オンプレを少しずつコンテナ化する
byKenkichi Okazaki
 
PPTX
続・広く知ってほしいDNSのこと
byTomohiro Nakashima
 
AWS 기반 클라우드 아키텍처 모범사례 - 삼성전자 개발자 포털/개발자 워크스페이스 - 정영준 솔루션즈 아키텍트, AWS / 유현성 수석,...
byAmazon Web Services Korea
 
202110 AWS Black Belt Online Seminar AWS Site-to-Site VPN
byAmazon Web Services Japan
 
Ansible과 CloudFormation을 이용한 배포 자동화
byAWSKRUG - AWS한국사용자모임
 
VMware on AWS를 통한 하이브리드 클라우드 구축 적용 - 홍정진, AWS Partner SA/ VMC on AWS
byAmazon Web Services Korea
 
vSRX on Your Laptop : PCで始めるvSRX ～JUNOSをさわってみよう！～
byJuniper Networks (日本)
 
Azure Automation 概要
by喜智 大井
 
마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트)
byAmazon Web Services Korea
 
Github - Git Training Slides: Foundations
byLee Hanxue
 
PHP-FPM の子プロセス制御方法と設定をおさらいしよう
byShohei Okada
 
AWS Black Belt Tech シリーズ 2016 - Amazon SES
byAmazon Web Services Japan
 
はじめての vSRX on AWS
byJuniper Networks (日本)
 
AWS Black Belt Techシリーズ Amazon VPC
byAmazon Web Services Japan
 
[Citrix on Nutanix] LoginVSI による MCSとPVS の比較検証
byWataru Unno
 
実践 WebRTC 〜最新事例と開発ノウハウの紹介〜
byYusuke Naka
 
AWS IoTにおけるデバイスへの認証情報のプロビジョニング
byAmazon Web Services Japan
 
vSphere 7 へのアップグレードについて
by富士通クラウドテクノロジーズ株式会社
 
オンプレミスRDBMSをAWSへ移行する手法
byAmazon Web Services Japan
 
Amazon S3による静的Webサイトホスティング
byYasuhiro Horiuchi
 
オンプレを少しずつコンテナ化する
byKenkichi Okazaki
 
続・広く知ってほしいDNSのこと
byTomohiro Nakashima
 

Viewers also liked

PDF
Advanced enterprise campus design. routed access (2015 milan)
byslide_site
 
PDF
Отказоустойчивость с использованием Cisco ASA Clustering
byCisco Russia
 
PPTX
Network proposal ppt
byFrankNitty II
 
PPSX
Network proposal
byWaldo Botha
 
PDF
A Reference Architecture for ETL 2.0
byDataWorks Summit
 
PPT
Case study of an active directory deployment
byManish Godawat
 
PPTX
Networking- computer connections
byHossian
 
DOCX
The latest development networks and communications (Microsoft Word)
byainizbahari97
 
KEY
Large scale ETL with Hadoop
byOReillyStrata
 
DOCX
Computer Network ASsignment
byBijay Bista
 
PDF
WRITTEN ASSIGNMENT FORMAT - LA 3.0 COMPUTER NETWORK & COMMUNICATION
bysalwahanim
 
PPTX
Network Proposal Power Point
byguest7fbe17
 
PDF
Reference architecture for Internet of Things
bySujee Maniyam
 
PPTX
Computer configuration
byanwarkamal786
 
Advanced enterprise campus design. routed access (2015 milan)
byslide_site
 
Отказоустойчивость с использованием Cisco ASA Clustering
byCisco Russia
 
Network proposal ppt
byFrankNitty II
 
Network proposal
byWaldo Botha
 
A Reference Architecture for ETL 2.0
byDataWorks Summit
 
Case study of an active directory deployment
byManish Godawat
 
Networking- computer connections
byHossian
 
The latest development networks and communications (Microsoft Word)
byainizbahari97
 
Large scale ETL with Hadoop
byOReillyStrata
 
Computer Network ASsignment
byBijay Bista
 
WRITTEN ASSIGNMENT FORMAT - LA 3.0 COMPUTER NETWORK & COMMUNICATION
bysalwahanim
 
Network Proposal Power Point
byguest7fbe17
 
Reference architecture for Internet of Things
bySujee Maniyam
 
Computer configuration
byanwarkamal786
 

Similar to Network Infrastructure Virtualization Case Study

PDF
Cisco Study: State of Web Security
byCisco Canada
 
PPT
SSL & TLS Architecture short
byAvirot Mitamura
 
PDF
1ip Tunneling And Vpn Technologies 101220042129 Phpapp01
byHussein Elmenshawy
 
PPTX
Cisco Presentation 1
bychangcai
 
PDF
The NGN Carrier Ethernet System: Technologies, Architecture and Deployment Mo...
byCisco Canada
 
PDF
Michael De Leo Global IPv6 Summit México 2009
byJaime Olmos
 
PPT
CCNA Security - Chapter 6
byIrsandi Hasan
 
PDF
Taller Redes Emergentes
byMundo Contact
 
PPTX
Clavister security for virtualized environment
bynicolasotira
 
PDF
Alcatellucentsdn2013
bydeepersnet
 
PDF
Cisco Cloud Briefing and Experiences for Cloud Slam 2011
byCisco Collaboration
 
PPTX
Monetizing the Enterprise: Borderless Networks
byCisco Service Provider Mobility
 
PDF
Cisco tec rob soderbery - core enterprise networking
byCisco Public Relations
 
PPTX
ReadyCloud Collaboration, a Cisco Powered service
byGen-i
 
PPTX
Express Data - BYOD
byGen-i
 
PPTX
Express Data - BYOD
byGen-i
 
PPTX
From Physical to Virtual to Cloud
byCisco Security
 
PDF
Integrating network virtualization security in OpenStack Deployments.pdf
byOpenStack Foundation
 
PDF
Gaweł mikołajczyk. holistic identity based networking approach – an irreducib...
byYury Chemerkin
 
PDF
La experiencia de la Colaboración
byJosé Carlos Martín Marco
 
Cisco Study: State of Web Security
byCisco Canada
 
SSL & TLS Architecture short
byAvirot Mitamura
 
1ip Tunneling And Vpn Technologies 101220042129 Phpapp01
byHussein Elmenshawy
 
Cisco Presentation 1
bychangcai
 
The NGN Carrier Ethernet System: Technologies, Architecture and Deployment Mo...
byCisco Canada
 
Michael De Leo Global IPv6 Summit México 2009
byJaime Olmos
 
CCNA Security - Chapter 6
byIrsandi Hasan
 
Taller Redes Emergentes
byMundo Contact
 
Clavister security for virtualized environment
bynicolasotira
 
Alcatellucentsdn2013
bydeepersnet
 
Cisco Cloud Briefing and Experiences for Cloud Slam 2011
byCisco Collaboration
 
Monetizing the Enterprise: Borderless Networks
byCisco Service Provider Mobility
 
Cisco tec rob soderbery - core enterprise networking
byCisco Public Relations
 
ReadyCloud Collaboration, a Cisco Powered service
byGen-i
 
Express Data - BYOD
byGen-i
 
Express Data - BYOD
byGen-i
 
From Physical to Virtual to Cloud
byCisco Security
 
Integrating network virtualization security in OpenStack Deployments.pdf
byOpenStack Foundation
 
Gaweł mikołajczyk. holistic identity based networking approach – an irreducib...
byYury Chemerkin
 
La experiencia de la Colaboración
byJosé Carlos Martín Marco
 

More from Cisco Canada

PPTX
Cisco connect montreal 2018 - Network Slicing: Horizontal Virtualization
byCisco Canada
 
PDF
Cisco Connect Toronto 2018 DNA automation-the evolution to intent-based net...
byCisco Canada
 
PDF
Cisco connect montreal 2018 enterprise networks - say goodbye to vla ns
byCisco Canada
 
PDF
Cisco connect montreal 2018 collaboration les services webex hybrides
byCisco Canada
 
PDF
Cisco connect montreal 2018 sd wan - delivering intent-based networking to th...
byCisco Canada
 
PDF
Cisco Connect Toronto 2018 network-slicing
byCisco Canada
 
PDF
Cisco Connect Toronto 2018 DNA assurance
byCisco Canada
 
PDF
Cisco connect montreal 2018 saalvare md-program-xr-v2
byCisco Canada
 
PDF
Cisco Connect Toronto 2018 IOT - unlock the power of data - securing the in...
byCisco Canada
 
PDF
Cisco Connect Toronto 2018 DevNet Overview
byCisco Canada
 
PDF
Cisco Connect Toronto 2018 an introduction to Cisco kinetic
byCisco Canada
 
PDF
Cisco connect montreal 2018 net devops
byCisco Canada
 
PDF
Cisco Connect Toronto 2018 sixty to zero
byCisco Canada
 
PDF
Cisco Connect Toronto 2018 the intelligent network with cisco meraki
byCisco Canada
 
PDF
Cisco connect montreal 2018 vision mondiale analyse locale
byCisco Canada
 
PDF
Cisco connect montreal 2018 secure dc
byCisco Canada
 
PDF
Integration cisco et microsoft connect montreal 2018
byCisco Canada
 
PDF
Cisco connect montreal 2018 compute v final
byCisco Canada
 
PDF
Cisco Connect Montreal 2018 Securité : Sécuriser votre mobilité avec Cisco
byCisco Canada
 
PDF
Cisco connect montreal 2018 iot demo kinetic fr
byCisco Canada
 
Cisco connect montreal 2018 - Network Slicing: Horizontal Virtualization
byCisco Canada
 
Cisco Connect Toronto 2018 DNA automation-the evolution to intent-based net...
byCisco Canada
 
Cisco connect montreal 2018 enterprise networks - say goodbye to vla ns
byCisco Canada
 
Cisco connect montreal 2018 collaboration les services webex hybrides
byCisco Canada
 
Cisco connect montreal 2018 sd wan - delivering intent-based networking to th...
byCisco Canada
 
Cisco Connect Toronto 2018 network-slicing
byCisco Canada
 
Cisco Connect Toronto 2018 DNA assurance
byCisco Canada
 
Cisco connect montreal 2018 saalvare md-program-xr-v2
byCisco Canada
 
Cisco Connect Toronto 2018 IOT - unlock the power of data - securing the in...
byCisco Canada
 
Cisco Connect Toronto 2018 DevNet Overview
byCisco Canada
 
Cisco Connect Toronto 2018 an introduction to Cisco kinetic
byCisco Canada
 
Cisco connect montreal 2018 net devops
byCisco Canada
 
Cisco Connect Toronto 2018 sixty to zero
byCisco Canada
 
Cisco Connect Toronto 2018 the intelligent network with cisco meraki
byCisco Canada
 
Cisco connect montreal 2018 vision mondiale analyse locale
byCisco Canada
 
Cisco connect montreal 2018 secure dc
byCisco Canada
 
Integration cisco et microsoft connect montreal 2018
byCisco Canada
 
Cisco connect montreal 2018 compute v final
byCisco Canada
 
Cisco Connect Montreal 2018 Securité : Sécuriser votre mobilité avec Cisco
byCisco Canada
 
Cisco connect montreal 2018 iot demo kinetic fr
byCisco Canada
 

Recently uploaded

PDF
WebXR in Android and Linux with OpenXR
byIgalia
 
PDF
Upskill to Agentic Automation - Working Smarter with AI: Real-World Tools for...
byDianaGray10
 
PDF
TrustArc Webinar - It’s Time to Rethink Privacy
byTrustArc
 
PDF
MathML Core in WebKit
byIgalia
 
PDF
From Pixels to Insights: Getting Started with Imagery in FME
bySafe Software
 
PDF
Unleash AI power with the Dell Pro 14 Plus - Interactive PDF
byPrincipled Technologies
 
PDF
Revolutionizing SQL Database Design for the Modern Era.pdf
bySQL DBM
 
PPTX
Expanding Your Toolbox: Beginners Guide to Controlling Kubernetes Logs
byEric D. Schabell
 
PPSX
AppSec Role Based Training OWASP Global AppSec USA 2025-11-06
byRobert Grupe, CSSLP CISSP PE PMP
 
PDF
Manage Networking in RHEL - RHCSA (RH124).pdf
byLinuxCert Guru
 
PPTX
Odoo_by_Infinys_All_in_One_Business_Solution_for_Small_Companies.pptx
byAgusto Sipahutar
 
PDF
Database Performance at Scale: The TL;DR
byScyllaDB
 
PDF
The Complete Crypto Airdrop Playbook: Strategies, Scams & Success Stories | 3...
by3verseTV
 
PDF
Manage Local Users and Groups - RHCSA (RH124)
byLinuxCert Guru
 
PDF
Manage Files Using CLI - RHCSA (RH124).pdf
byLinuxCert Guru
 
PDF
Configure and Secure SSH - RHCSA (RH124).pdf
byLinuxCert Guru
 
PDF
Access Linux File System in RHEL - RHCSA (RH124).pdf
byLinuxCert Guru
 
PDF
Control Access to Files - RHCSA (RH124).pdf
byLinuxCert Guru
 
PDF
Private Governance: How Decentralized Mechanisms Can Regulate the Crypto Economy
byFederico Ast
 
PPTX
Bulwark Pokemon League Top 8 graphic archive
byGc Howard
 
WebXR in Android and Linux with OpenXR
byIgalia
 
Upskill to Agentic Automation - Working Smarter with AI: Real-World Tools for...
byDianaGray10
 
TrustArc Webinar - It’s Time to Rethink Privacy
byTrustArc
 
MathML Core in WebKit
byIgalia
 
From Pixels to Insights: Getting Started with Imagery in FME
bySafe Software
 
Unleash AI power with the Dell Pro 14 Plus - Interactive PDF
byPrincipled Technologies
 
Revolutionizing SQL Database Design for the Modern Era.pdf
bySQL DBM
 
Expanding Your Toolbox: Beginners Guide to Controlling Kubernetes Logs
byEric D. Schabell
 
AppSec Role Based Training OWASP Global AppSec USA 2025-11-06
byRobert Grupe, CSSLP CISSP PE PMP
 
Manage Networking in RHEL - RHCSA (RH124).pdf
byLinuxCert Guru
 
Odoo_by_Infinys_All_in_One_Business_Solution_for_Small_Companies.pptx
byAgusto Sipahutar
 
Database Performance at Scale: The TL;DR
byScyllaDB
 
The Complete Crypto Airdrop Playbook: Strategies, Scams & Success Stories | 3...
by3verseTV
 
Manage Local Users and Groups - RHCSA (RH124)
byLinuxCert Guru
 
Manage Files Using CLI - RHCSA (RH124).pdf
byLinuxCert Guru
 
Configure and Secure SSH - RHCSA (RH124).pdf
byLinuxCert Guru
 
Access Linux File System in RHEL - RHCSA (RH124).pdf
byLinuxCert Guru
 
Control Access to Files - RHCSA (RH124).pdf
byLinuxCert Guru
 
Private Governance: How Decentralized Mechanisms Can Regulate the Crypto Economy
byFederico Ast
 
Bulwark Pokemon League Top 8 graphic archive
byGc Howard
 

Network Infrastructure Virtualization Case Study

  • 1.
    © 2010 Ciscoand/or its affiliates. All rights reserved. Cisco Confidential 1
  • 2.
    Dave  Zacks            CCIE  8887   Technical  Solu7ons  Architect   #CNSF2011 © 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 2
  • 3.
    This session focuseson 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
  • 4.
    #CNSF2011 CNSF - May,2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 4
  • 5.
      Groups andservices Resources Internet are logically separated … Guest / partner access Departmental separation Regulatory compliance (HIPPA, PCI …) Non-Virtualized Network Building controls, video surveillance Mergers, acquisitions … and many others   Closed User Groups … Virtualized Network Private 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
  • 6.
      One physicalnetwork supports many virtual networks Department Function Guests / A B Partners Virtual Virtual Virtual Actual Physical Network Infrastructure CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 6
  • 7.
    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, application) over Layer 3 infrastructure to services – attempting to gain network   Transport traffic over Shared 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 edge   Deny access to   Isolate application unauthenticated clients environments if necessary CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 7
  • 8.
    Per VRF: Virtual Routing Table Virtual Forwarding Table   Device virtualization – Control plane virtualization VRF Data plane virtualization VRF 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
  • 9.
    1.  Create L2VLANs 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
  • 10.
    iBGP requires afull mesh of neighbors 172.16.5.0/24 172.16.8.0/24 N * (N-1) / 2 = 8 * 7 / 2 = 28 S1 S2 S3 S4 R1 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
  • 11.
    Ro ute Reflector Route Reflector 172.16.5.0/24 172.16.8.0/24 S1 S2 S3 S4 R1 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
  • 12.
      Firewall contextsin transparent mode Shared Services act as L2 bridges E-mail Storage   Fusion router establishes routing 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 GreenVP VPN N   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
  • 13.
      Firewall contextsin 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 VPN Blue GreenVP VPN N   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
  • 14.
    Shared Services Global Table Red VPN Blue Global Table Red VPN Blue GreenVP VPN VPN N 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
  • 15.
    #CNSF2011 CNSF - May,2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 15
  • 16.
      UBC isone 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 Campuses located around BC is here You are here CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 16
  • 17.
    On a beautifulsummer day … June 25th, 2010 Clock Tower, I.K Barber adjacent to the I.K Barber Learning Centre Learning Centre, University of BC University of BC CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 17
  • 18.
      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
  • 19.
      UBC hasadopted 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
  • 20.
    Typical Large No deliberate 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
  • 21.
      UBC departmentsand 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
  • 22.
      Statement ofthe 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
  • 23.
    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
  • 24.
      Technically, itwould 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
  • 25.
      To meettheir 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
  • 26.
      Within aVRF 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
  • 27.
      UBC neededa 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
  • 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   CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 28
  • 29.
      MPLS VPNuses 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
  • 30.
      The nextstep 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
  • 31.
      After determiningthe 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). CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 31
  • 32.
      Providing forLayer 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
  • 33.
      VLAN andVRF 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
  • 34.
      SVI definitionon 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 ip vrf MED-ADMIN mtu 8500 rd 65111:521 ip vrf forwarding MED-ADMIN route-target export 65111:521 ip address 172.16.10.253 255.255.255.0 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 standby preempt For DHCP forwarding 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
  • 35.
      VLANs aremapped 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 ip vrf MED-ADMIN mtu 8500 rd 65111:521 ip vrf forwarding MED-ADMIN route-target export 65111:521 ip address 172.16.10.253 255.255.255.0 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 (in this example, 4 VLANs total Vl2199 in this VRF, on this PE) CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 35
  • 36.
      Connected routesand 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 ip address 172.16.33.253 255.255.255.192 Named ip route vrf MED-ADMIN 0.0.0.0 0.0.0.0 172.16.2.249 name DEFAULT-ROUTE=MED-ADMIN Static Routes CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 36
  • 37.
      Connected routesand 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 exit-address-family interface Vlan627 ip vrf forwarding MED-ADMIN ip address 172.16.10.253 255.255.255.0 Redistribution of routes to other PEs (via MP-BGP) 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 CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 37
  • 38.
      Now thatwe 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 – Gateway of last resort is 172.16.2.249 to network 0.0.0.0 Outer-3 172.16.0.0/16 is variably subnetted, 3 subnets, 3 masks C 172.16.2.248/29 is directly connected, Vlan185 B C 172.16.139.192/27 [200/0] via 192.168.1.3, 5w3d 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
  • 39.
      Now wehave 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 C 172.16.0.0/16 is variably subnetted, 3 subnets, 3 masks 172.16.2.248/29 is directly connected, Vlan185   Secure B C 172.16.139.192/27 [200/0] via 192.168.1.3, 5w3d 172.16.5.128/25 is directly connected, Vlan431 network C B 172.16.33.192/26 is directly connected, Vlan2199 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 S* 172.16.10.0/24 is directly connected, Vlan627 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
  • 40.
    Faculty Virtual Firewall From this … To this … CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 40
  • 41.
      Network maintenanceand 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
  • 42.
      Network maintenanceand 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
  • 43.
    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 Prefix Adjacency VPN Tag IP Header IP payload Tag pop (IGP) 172.16.139.92/27 Te1/1 19(+), 1193(+) Tag pop (VPN), IP Header IP payload CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public IP lookup 43
  • 44.
      Traffic betweenVRFs 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 redundant Virtual OUTER-2# show ip route vrf MED-ADMIN Firewall instance … Routing Table: MED-ADMIN Codes: C - connected, S - static, R - RIP, M - mobile, B – BGP … hosted on an . . . FWSM pair (on the PEs). Gateway of last resort is 172.16.2.249 to network 0.0.0.0 ... 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
  • 45.
    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 P PE Virtual FW Policy PE CNSF - May, 2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 45
  • 46.
    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
  • 47.
      Previously, UBCdid 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
  • 48.
      UBC isvirtualizing 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
  • 49.
      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
  • 50.
      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
  • 51.
      UBC isexamining 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
  • 52.
      Response fromUBC 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 technical and business 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
  • 53.
      UBC hasderived 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
  • 54.
      UBC hasderived 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
  • 55.
      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. Cisco Public 55
  • 56.
    www.cisco.com/go/networkvirtualization CNSF - May,2011 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public 56
  • 57.
    #CNSF2011 © 2010 Ciscoand/or its affiliates. All rights reserved. Cisco Confidential 57
  • 58.
    #CNSF2011 © 2010 Ciscoand/or its affiliates. All rights reserved. Cisco Confidential 58
  • 59.
    Thank you. #CNSF2011