Catalyst 4500/4900 and 6500/6500-E 6500/6500- E QoS Design (Hidden)
WAN and Branch QoS Design
Architectural Framework Align with Business Drivers
QoS Lives Here
Why Campus QoS Designs Is Important Business and Technical Drivers
New Applications and Business Requirements –Explosion of Video Apps –Impact of HD –Blurring of Voice/Video/Data application boundaries
New Standards and RFCs –RFC 4594, FCoE
New Platforms and Technologies –New Switches, Supervisors, Linecards, features, syntax
New Business Requirements Cisco Visual Networking Index Findings
Internet video is now over one-third of all consumer Internet traffic, and will approach 40 percent of consumer Internet traffic by the end of 2010 (not including video exchanged through P2P file sharing). The sum of all forms of video (TV, video on demand, Internet, and P2P) will continue to exceed 91% of global consumer traffic by 2014.
Internet video alone will account for 57% of all consumer Internet traffic in 2014. Real-time video is growing in importance. By 2014, Internet TV will be over 8% of consumer Internet traffic, and ambient video will be an additional 5% of consumer Internet traffic. Globally, P2P TV is now over 280 petabytes per month.
New Application Requirements The Impact of HD on the Network 5 4 3
s p b M 2
Min Max
1 0 (H.323) DVD
(H.264) 720p
(H.264) 1080p
User demand for HD video has a major impact on the network –(H.264) 720p HD video requires twice as much bandwidth as (H.263) DVD –(H.264) 1080p HD video requires twice as much bandwidth as (H.264) 720p
New Application Requirements Trends in Voice, Video and Data Media Applications Data
Convergence
Video
Voice
Web Email Messaging
Data Apps
• IP Video Conf
• IP Telephony
• App Sharing • Web/Internet • Messaging • Email
Leveraging
Media Explosion • Internet Streaming • Internet VoIP Unmanaged • YouTube • MySpace • Other • IP Video Conf • Surveillance Video • Video Telephony • HD Video Conf • VoD Streaming
Voice
Data Apps
• IP Telephony • HD Audio • Softphone • Other VoIP
Collaborative Media A A d p -H p o c
T e l e P r e s e n c e W e b E x
• App Sharing • Web/Internet • Messaging • Email
Experience
Borderless Medianet Architecture
M a n a g e m e n t – P o l i c y
for Video & Collaboration – New S R ND 4.0 Deliver the network optimised for video anytime, anywhere, any device webex Cisco Video & Voice Applications
Media Services Interface (MSI) APIs Enable Rich Media Solutions
Marking (a.k.a. colouring) is the process of setting the value of the DS field so that the traffic can easily be identified later, i.e. using simple classification techniques. •Marking occurs at L3 or L2 e.g. 802.1P user priority fi eld
Traffic marking can be applied unconditionally, e.g. mark the DSCP to 34 for all traffic received on a particular interface, or as a conditional result of a policer Conditional marking can be used to designate in- and out-of-contract traffic: –Conform action is “mark one way” –Exceed action is “mark another way”
Single rate policer has 2 states – conform or exceed.
Congestion can occur whenever there are speed mismatches (oversubscription) When routers receive more packets than they can immediately forward, they momentarily store the packets in “buffers” (full buffers = packets dropped)
Difference between buffers and queues – Buffers are physical memory locations where packets are temporarily stored whilst waiting to be transmitted – Queues do not actually contain packets but consist of an ordered set of pointers to locations in buffer memory where packets in that particular queue are stored – Buffer memory generally shared across different queues (so more Q‟s is not necessarily better)
Routers generally use IOS-based software queuing
Campus QoS Considerations Allocating Buffer Capacity Each port has a finite amount of memory that is specifically reserved for buffering traffic during times of contention. Although the total amount of buffer capacity for egress traffic may be fixed for a given port, how that memory is distributed amongst the queues is configurable.
SP Queue Real Time Traffic Queue 3
Control Traffic
B/W SP Queue B/W Queue 3
Queue 2 Transactional TCPbased applications with specific strict latency requirements.
Queue 1 Mixed TCP and UDP applications with no real latency requirements.
Critical Data B/W Queue 2
Low Priority/ BE B/W Queue 1 Large buffer allocation for BE traffic (queue 1), with minimal bandwidth weighting (more latency)
Small buffer allocation for critical data (queue 2), with heavier bandwidth weighting
***Allocating more memory to a given queue can increase packet latency, which
QoS Components - Dropping
Queues cannot grow to an infinite length as buffer memory space is not infinite
Dropping algorithms are used to drop packets as queue depths build, how we drop is important. Two main type of dropping algorithm are used today: –Tail drop – normally the default behaviour (Thresholds) •Normally applied to VoIP/Video (UDP) traffic
•If applied to TCP traffic, can cause Global Synchronisation –Random Early Discard – designed to improve throughput for TCP based applications
Dropping- Congestion Avoidance Algorithms TAIL DROP WRED 3
Queue 3 1
0 1
2
1
2
0
2
0
1
3
Congestion avoidance algorithms manage the tail of the queue (Which packets get 0 dropped first when queuing buffers fill) 3 Variants based on Tail Drop and RED (Random Early Discard) based on weight
WRED - Drops packets according to their DSCP markings – WRED works best with TCP-based applications, like data
2
Queueing algorithms manage 0the front of the queue ( Which packets get sent first ) 3
Weighted Tail-drop and Weighted RED
3
Congestion Avoidance helps prevent Global Sync
TCP Global Synchronisation and RED Tail Drop
RED
[Courtesy of Sean Doran, then at Ebone]
Without RED, below 100% throughput – Simple FIFO with tail drop – Tail drop results in session synchronisation – RED enabled starting 10:00 second day, ~100% throughput
With RED - Session synchronisation reduced RED distributes drops over various sessions to desynchronise TCP sessions improving
Queuing and Scheduling Strict priority queue Scheduler
N Weighted queues
Link
Queued packets
Schedulers determine which queue to service next - Different schedulers service queues in different orders
Most common types of schedulers –FIFO – is the most basic queuing type and is default when no QoS is enabled –Priority scheduling – the queue is serviced if a packet is present –Weighted bandwidth scheduling – Weighted Round Robin (WRR), simple, each queue is weighted e.g. Custom Qing
Virtual Output Queues HOL Blocking Problem: Cars going to Pub are forced to wait for congested stadium traffic to clear.
Footy
Beer/Chips/Beer
Pub
Virtual Output Queues (Cont.)
Solution: Add another lane dedicated to Pub customers!
Footy
Beer/Chips/Beer
Pub
Policing vs. Shaping
Policing typically drops out-ofcontract traffic
Effectively policing acts to cut the peaks off bursty traffic Shaping typically delays out of contract traffic Shaping acts to smooth the traffic profile by delaying the peaks –Resulting packet stream is “smoothed” and net throughput for TCP traffic is higher with shaping –Shaping delay may have an impact on some services such as VoIP and video
c i f f a r T
c i f f a r T
Policing
c i f f a r T
Shaping
c i f f a r T
Time
Time
Policed Rate
Time Shaped Rate
Time
Shaping
Shapers can be applied in a number of ways, e.g. : R
–To enforce a maximum rate across all traffic on a physical or logical interface
B
Link
Shaper
–To enforce a maximum rate across a number of traffic classes
Scheduler
R B
Link
Shaper
R
–To enforce a maximum rate to an individual traffic class – Hierarchical QoS
B
Shaper
Scheduler
Link
Link-Specific Operations- Compression and Link-Fragmentation / Interleaving Serialisation Can Cause Excessive Delay
Voice
Data
Data
Data
Data
Voice
Data
Fragmentation and Interleaving minimises Serialisation Delay –Serialisation delay is the finite amount of time required to put frames on a wire –For links ≤ 768 kbps serialisation delay is a major factor affecting latency and jitter
–For such slow links, large data packets need to be fragmented and interleaved with smaller, more urgent voice packets
Compression – can reduce L3 VoIP BW by:
Signalling and CAC - MediaNet Resource Reservation Protocol (RSVP) This App Needs
Protect Voice from Voice etc
16K BW and 100 msec Delay
3 Types – Gway, Probes (IPSLA) and RSVP.
Handset
RSVP QoS services –Topology Aware CAC –Uses existing Routing Protocols –Dynamically adjusts to link and topology changes
RSVP provides the policy to WFQ and LLQ to maintain Voice quality
Reserve 16K BW on this Line
Handset
Multimedia Station
I Need 16K BW and 100 msec Delay
Campus QoS Design
Agenda Business and Technical Drivers for QoS Design Update
Components of QoS
Campus QoS Design Considerations and Models
Catalyst 2960/2975/3560/3750 G/E/X QoS Design
Catalyst 2960/2975/3560/3750 G/E/X AutoQoS
WAN and Branch QoS Design
Campus QoS Design Considerations and Models
Campus Network Design Infrastructure Services Required of the Campus TelePresence High Availability - Implement strategy for sub-second failover - Implement HA architecture with NSF/SSO, VSS, VPC etc. Live Latency and Bandwidth Optimisation Broadcasts - GigE access & VOD - 10GigE distribution/core - Implement IP multicast and/or stream splitting services Confidentiality Digital - Authentication of endpoints and users (e.g. 802.1x) Signage -Comply to security policies with data protection strategies, -such as encryption (e.g. Cisco TrustSec)
Si
Si
Video-conferencing
Si Si
Si
Si
Si
Campus Network Design Infrastructure Services Required of the Campus TelePresence
Real-Time Application Delivery - Implement granular QoS service policies to manage application service levels - Access layer protection, ensures endpoints are fair consumers
Live Broadcasts & VOD Si
Si
Si Si
Si
Digital Signage Si
Si
Campus QoS Design Strategic QoS Design Principles Always perform QoS in hardware rather than software when a choice exists (eg in Switches)
Classify and mark applications as close to their sources as technically and administratively feasible Police unwanted traffic flows as close to their sources as possible (waste of resource) Enable queuing policies at every node where the potential for congestion exists (control Loss!) Have a QoS Policy Defined for your business
Campus QoS Design QoS Design Considerations Where is QoS Applied
Internal DSCP
Trust States and Operations
Trust Boundaries
Endpoint-Generated Traffic Classes
AutoQoS
Campus QoS Considerations Where Is QoS Required Within the Campus? FastEthernet GigabitEthernet TenGigabitEthernet
Drop Drop Remark to CS1 Remark to CS1 Drop Remark to CS1
) s d e e t i c r i l o o p P p u g s n i d u n e a u d Q e r s i s u e q r e g r n f I i (
Campus Egress QoS Models Queuing and Dropping and Buffer-Sizing Recommendations
Catalyst Queuing is done in hardware and varies by platform/linecard and is expressed as: 1P x Qy T – Example: 1P3Q8T means:
1 PQ
–
3 non-priority queues, each with
–
8 drop-thresholds per queue
Best Effort
Minimum queuing capabilities for medianet is 1P3QyT
Realtime (PQ) should be less than 33% of link
Best-Effort Queue should be guaranteed at 25% of link
Scavenger/Bulk queue should be minimally provisioned
WRED is preferred congestion-avoidance mechanism
Buffers for BE and Guaranteed BW queues can be directly proportional to BW allocation
≥ 25%
Realtime ≤ 33%
Scavenger/Bulk ≤ 5%
– Example: 25% BW for BE Queue can be matched with 25% Buffer Allocation
Buffers for PQ and Scavenger/Bulk Queue can be indirectly proportional to BW allocation – Examples: 30% BW for PQ can be complemented with 15% Buffer Allocation
Guaranteed BW
Campus QoS Design Agenda
Business and Technical Drivers for QoS Design Update
Campus QoS Design Considerations and Models
Catalyst 2960/2975/3560/3750 G/E/X QoS Design
Catalyst 4500/4900 & 4500-E/4900M QoS Design (In Deck)
Classification • Inspect incoming packets • Based on ACLs or configuration, determine classification label
Queues
SRR
SRR
Classify
Ingress
Ring
Ingress Queues
Policer Policer
Marker Marker
Policing • Ensure conformance to a specified rate • On an aggregate or individual flow basis • Up to 256 policers per Port ASIC • Support for rate and burst
Egress Ingress Queue/ Schedule Congestion Control • Two queues/port • Act on policer ASIC shared decision servicing • Reclass or drop • One queue is out-of-profile configurable for strict priority servicing • WTD for congestion control (three thresholds per queue) • SRR is performed Marking
Egress Queue/ Schedule Congestion Control • Four SRR queues/port shared or shaped servicing • One queue is configurable for strict priority servicing • WTD for congestion control (three thresholds per queue) • Egress queue shaping • Egress port rate limiting
Traffic is classified on ingress, based on trust-states, access-lists, or class-maps. Because the total inbound bandwidth of all ports can exceed the bandwidth of the stack or internal ring, ingress queues are supported
The Catalyst 2960 and 2975 can police to a minimum rate of 1 Mbps; all other platforms within this switch product family can police to a minimum rate of 8 kbps. The Catalyst 3560 and 3750 support multilayer switching and as such correspondingly support per-VLAN or per-port/per-VLAN policies.
The Catalyst 3560 and 3750 support IPv6 QoS.
The Catalyst 3560 and 3750 support policing on 10 Gigabit Ethernet interfaces.
The Catalyst 2960/2975/3650/3750 support Shaped Round Robin (BW limits) , Shared Round Robin (shares unused BW), as well as strict priority queue scheduling
Modular QoS and the Hierarchical Queuing Framework (HQF) class-map match-any VOIP
1. Traffic classification – “class-map”
– identify traffic and assign to classes
2. Define the Diffserv policy – “policy-map” – Assign classes to a policy – Define the Diffserv treatment for each class
3. Attach the Diffserv policy to a logical/physical interface – “service-policy” – The point of application of a QOS policy
match ip dscp 40 match access-group 100 class-map match-any BUS match access-group 101 class-map match-all CTRL match access-group 103 match access-group 104 ! policy-map DIFFSERV_POLICY class VOIP priority police 64000 class BUS bandwidth remaining percent 90 ! interface Serial0 ip address 192.168.2.2 255.255.255.0 service-policy output DIFFSERV_POLICY
Hierarchical Queuing Framework – Structure
policy-map CHILD class child-c1 Apply class-based queuing to any bandwidth 400 traffic class at the parent or child level class child-c2 bandwidth 400 Allows for different service levels policy-map PARENT class parent-c1 Traffic in class parent-c2 will have bandwidth 1000 more „scheduling time‟ than parent-c1 service-policy CHILD Fair-Queue can be applied to a user class parent-c2 defined class bandwidth 2000 service-policy CHILD
Trust Models Trust-CoS Model Trust-DSCP Model Conditional-Trust Model
Marking Models (Included in Deck) Per-Port Marking Model Per-VLAN Marking Model
Policing Models (Included in Deck) Per-Port Policing Model Per-Port/Per-VLAN Policing Model
Queuing Models Ingress Queuing 1P1Q3T Model Egress Queuing 1P3Q3T Model
Catalyst 2960/2975/3560/3750 G/E/X QoS Design Enabling QoS and Trust Model Examples Enabling QoS:
mls qos C3750-E(config)#
(I must, I must enable QoS!)
Trust-CoS Model Example:
Verified with: show mls qos
•
mls qos map cos-dscp 0 8 16 24 32 46 48 56 C3750-E(config)# ! CoS 5 (the sixth CoS value, starting from 0) is mapped to 46 C3750-E(config)#interface GigabitEthernet 1/0/1 mls qos trust cos C3750-E(config-if)# ! The interface is set to statically trust CoS
Trust-DSCP Model Example: mls qos trust dscp C3750-E(config-if)#
Conditional-Trust Model Example (can be combined with Trust-CoS/DSCP): mls qos trust device cisco-phone C3750-E(config-if)#
Verified with: •show mls qos interface
Catalyst 2960/2975/3560/3750 G/E/X QoS Design 1P1Q3T Ingress Queuing Model Application
Catalyst 2960/2975/3560/3750 G/E/X QoS Design 1P1Q3T Ingress Queuing Model Example – Part 1 of 3 ! This section configures the ingress queues mls qos srr-queue input priority-queue 2 bandwidth 30 C3750-E(config)# ! Q2 is enabled as a strict-priority ingress queue with 30% BW
mls qos srr-queue input threshold 1 80 90 C3750-E(config)# ! Q1 thresholds are configured at 80% (Q1T1) and 90% (Q1T2) ! Q1T3 is implicitly set at 100% (the tail of the queue) ! Q2 thresholds are all set (by default) to 100% (the tail of Q2)
Catalyst 2960/2975/3560/3750 G/E/X QoS Design 1P3Q3T Egress Queuing Model
1P3Q3T
Application
DSCP
Network Control Internetwork Control
(CS7) CS6
VoIP
EF
Broadcast Video
CS5
Multimedia Conferencing Realtime Interactive
AF4 CS4
CS7 CS6
Multimedia Streaming
AF3
CS3
Queue 2
Q2T2
Signaling
CS3
(30%)
Q2T1
Transactional Data
AF2
Network Management
CS2
Bulk Data Scavenger
AF1 CS1
AF4 AF3 AF2 CS2
CS1 AF1 DF
Queue 4 (5%)
Q4T2 Q4T1
Default Queue Queue 3 (35%) Q2T3
EF Q1 CS5 CS4 Priority Queue
Campus QoS Design
Agenda Business and Technical Drivers for QoS Design Update
Components of QoS
Campus QoS Design Considerations and Models
Catalyst 2960/2975/3560/3750 G/E/X QoS Design
Catalyst 2960/2975/3560/3750 G/E/X AutoQoS
WAN and Branch QoS Design
Catalyst 2960/2975/3560/3750 G/E/X AutoQoS
AutoQoS
Simplifies the deployment of QoS Policies
Uses a set of Standard configurations that can be modified
Currently all switch platforms support AutoQoS-VoIP Best practice QoS designs for IP Telephony deployments
Catalyst 2K/3K now supports AutoQoS for Medianet AutoQoS SRND4
Supports not only IP Phones, but also TelePresence & IPVS cameras Autoprovisions ingress trust, classification, marking & policing Autoprovisions ingress queuing (as applicable) Autoprovisions egress queuing
Catalyst 2960/2975/3560/3750 G/E/X/S QoS Design - AutoQoS for Medianet
QoS auto-configuration for 12 application classes RFC 4594-based
Ingress trust (static or conditional) Includes policers for best effort to prevent misuse
Ingress & Egress Buffer & Threshold configuration Includes modifications from existing AutoQoS-VoIP to new
Ingress & Egress CoS- & DSCP-to-Queue Mappings Includes modifications from existing AutoQoS-VoIP to new
Feature will include a method to retain legacy Auto-QoS (AutoQoS-VoIP) configuration An upgrade will not force a configuration change
Released in 12.2(55)SE (2010)
Catalyst 2960/2975/3560/3750 G/E/X QoS Design - AutoQoS SRND4 Models auto qos voip [ cisco-phone | cisco-softphone | trust ] auto qos trust { cos | dscp } auto qos video [ cts | ip-camera ] auto qos classify Multimedia Conferencing Classifier Signaling Classifier Transactional Data Classifier Bulk Data Classifier Scavenger Classifier Best Effort (Class-Default)
auto qos classify { police } Yes Mark AF41 Mark CS3 Mark AF21 Mark AF11 Mark CS1 Mark DF
mls qos trust cos ! AutoQoS has configured the port to static CoS-trust
auto qos trust spanning-tree portfast
Layer 3 Routed Interface Example: C3750-E(config-if)# auto qos trust interface GigabitEthernet1/0/48 description L3-ROUTED-INTERFACE no switchport ip address 10.0.1.103 255.255.255.0 …
mls qos trust dscp ! AutoQoS has configured the port to static DSCP-trust
Catalyst 2960/2975/3560/3750 G/E/X QoS Design AutoQoS SRND4 – auto qos voip cisco-phone C3750-X(config-if)#auto qos voip cisco-phone
Class-maps omitted for brevity
! This section defines the AutoQoS-VoIP-Cisco-Phone (SRND4) Policy-Map
policy-map AUTOQOS-SRND4-CISCOPHONE-POLICY class AUTOQOS_VOIP_DATA_CLASS set dscp ef police 128000 8000 exceed-action policed-dscp-transmit ! Voice is marked to DSCP EF and policed (to remark) if exceeding 128 kbps
class AUTOQOS_VOIP_SIGNAL_CLASS set dscp cs3 police 32000 8000 exceed-action policed-dscp-transmit ! Signaling is marked to DSCP CS3 and policed (to remark) if exceeding 32 kbps
class AUTOQOS_DEFAULT_CLASS set dscp default police 10000000 8000 exceed-action policed-dscp-transmit ! An explicit default class marks all other IP traffic to DF ! and polices all other IP traffic to remark (to CS1) at 10 Mbps !
Data Centre Ethernet QoS (OverSubsription) FCoE – RFC 3643 Feature
Benefit
Priority-based Flow Control (PFC) CoS Based BW Management
Provides CoS flow control using Pause. Supports lossless requirement for storage traffic with 8 independent V Lanes Grouping classes of traffic into “Service Lanes” IEEE 802.1Qaz, CoS based Enhanced Transmission
Congestion Notification (BCN/QCN)
End to End Congestion Management for L2 network
Data Centre Bridging Capability Exchange Protocol L2 Multi-path for Unicast & Multicast Lossless Service
Auto-negotiation for Enhanced Ethernet capabilities DCBX Eliminate Spanning Tree for L2 topologies Utilise full Bi-Sectional bandwidth with ECMP
Provides ability to transport various traffic types (e.g. Storage, RDMA)
Cisco Nexus 1000V Quality of Service (See DC Specific Sessions)
Nexus 1000V provides traffic classification, marking and policing Police traffic to/from VMs Mark traffic leaving the ESX host
Can be configured multiple ways Individual Eths or vEths Port-Channels Port Profiles
Policies can be applied on input or output
Statistics per policy (input/output) per interface
Nexus 5K/7K - QoS Feature Sets Applied at egress port ASIC
(See DC Specific Sessions)
Applied at ingress forwarding engine (egress pipe)
Egress Classification
Class-map matching criteria:
ACL-based (L2 SA/DA, IP SA/DA, Protocol, L4 port range, L4 protocol specific field) CoS IP Precedence DSCP Protocols (non-IP) QoS Group Discard Class
Router Interface to Switch Port : • No Trust (IOS Default) • (Optional) LLQ/CBWFQ policies (only if potential for congestion exists in WAN-to-LAN direction)
Enterprise WAN QoS Design - Implementation Dual-LLQ Design and Operation policy-map WAN-EDGE class VOIP priority 1000 class TelePresence priority 15000 class CALL-SIGNALING bandwidth x class TRANSACTIONAL bandwidth y class BULK-DATA bandwidth z class class-default fair-queue
Packets IN
•All LLQ traffic is serviced by a single strict-priority queue. • This PQ is serviced on a First-In-First-Out basis • VOIP and TelePresence receive an EF PHB, but VIDEO cannot interfere with VOIP.
1Mbps VOIP Policer 15Mbps TP Policer
FQ
Total 16Mbps PQ shared by VoIP and TelePresence FIFO entrance into the queue
TX Ring Call-Signalling CBWFQ Transactional CBWFQ Bulk Data CBWFQ Default Queue
CBWFQ Scheduler
Packets OUT
Cisco Medianet WAN & Branch Design WAN Edge Models Are Not Restricted By Hardware Queues 4-Class Model
Realtime
8-Class Model
12-Class Model
Voice
Voice Realtime Interactive
Interactive Video Streaming Video
Signaling / Control
Critical Data
Call Signaling
Multimedia Conferencing Broadcast Video Multimedia Streaming Call Signaling
Network Control
Network Control Network Management
Critical Data
Transactional Data Bulk Data
Best Effort
Best Effort
Best Effort
Scavenger
Scavenger
Cisco Medianet WAN & Branch Design RFC 4594-Based WAN Edge Models
References and Key Takeaways
Resources Cisco Visual Networking Index http://www.cisco.com/en/US/netsol/ns827/networking_solutions_sub_solution. html Overview of a Medianet Architecture http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/vrn.html Enterprise Medianet Quality of Service Design 4.0 http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_ SRND_40/QoSIntro_40.html
QoS is necessary where ever there is the possibility of congestion Explosion Explosion of video and rich-media applications are requiring a re-engineering of network QoS policies Cisco has a RFC 4595-based end-to-end QoS strategy for medianet The Campus QoS SRND presents a unified and consistent set of recommendations across platforms AutoQoS for Medianet Medianet is already already available on the 2K/3K 2K/3K to simplify and expedite QoS deployment
Q &A
Complete Your Online Session Evaluation Complete your session evaluation:
Directly from your mobile device by visiting www.ciscoliveaustralia.com/mobile and login by entering your badge ID (located on the front of your badge) Visit one of the Cisco Live internet stations located throughout the venue Open a browser on your own computer to access the Cisco Live onsite portal