ONT Notes – Pre-classify and End-to-end QoS

  • VPNs (Didn’t ISCW cover this?)
    • Provide
      • Confidentiality
      • Integrity
      • Authentication
    • Types
      • Remote-access
        • Client-initiated
        • NAS-initiated
      • Site-to-site
        • LAN-to-LAN
        • Extranet
  • L3 Tunneling protocols
    • GRE
    • IPSec
  • Pre-classify allows traffic to be classified before being sent across a tunnel or crypto-ed.
    • qos pre-classify
    • Provides a view into the original IP headers
    • To classify on pre-tunnel header, apply the policy to the tunnel interface WITHOUT pre-classify.
    • To classify on post-tunnel header, apply the policy to the physical interface WITHOUT pre-classify.
    • To classify on pre-tunnel header, apply the policy to the physical interface WITH pre-classify.
  • SLA – agreement with provider to guarantee QoS mechanisms across their network based on your markings.
    • Assures availability, loss, throughput, delay, and jitter.
  • End-to-end QoS
    • To be effective, each hop in the path must have QoS configured similarly.
    • Necessary in three locations
      • Campus – within the customer network
      • The edges – customer facing the provider, provider facing customer
      • On the provider network
  • QoS tasks
    • Campus access switches
      • Speed/duplex settings
      • Classification
      • Trust
      • Phone/access switch configs
      • Multiple queues on switch ports, including priority for VOIP
    • Campus distribution
      • L3 policing and marking
      • Multiple queues on switch ports, including priority for VOIP
      • WRED
    • WAN edge
      • SLA definitions
      • LLQ
      • LFI
      • WRED
      • Shaping
    • Provider cloud
      • Capacity planning
      • PHB
      • LLQ
      • WRED
  • Enterprise campus QoS implementation
    • Implement multiple queues to avoid congestion
    • Assign VOIP and video to highest priority queue
    • Esablish trust boundaries
    • Use policing to rate-limit excess traffic
    • Use hardware QoS when possible
  • Control Plane Policing (CoPP)
    • Applies QoS policy to traffic destined for the router
      • Routing protocols
      • Management protocols
    • Can be used to avoid DOS attacks
    • Applied to control-plane in global config

ONT Notes – Congestion Avoidance, Policing, Shaping, and Link Efficiency

  • Tail drop drawbacks
    • TCP synchronization – Dropping TCP packets from different flows can cause them all to window down and back up again at the same time in cycles.
    • TCP starvation – Non-TCP or aggressive flows can starve everyone else out when TCP throttles back.
    • No differentiated drop – Tail drop doesn’t care who you are, so you get dropped if the queue is full.
  • RED – Random Early Detection
    • Avoids tail drop by randomly dropping packets from the queue before it gets full
    • Only dropped TCP flows slow down instead of everyone who has sent a packet since the queue filled
    • Queues are smaller.
    • Link utilization is more efficient
    • Configured with
      • Minimum threshold – start dropping when the queue is this size
      • Maximum threshold – if the queue is this big, start tail dropping
      • Mark probability denominator (MPD) – 1/MPD is the ratio of packets to drop when between the thresholds
  • WRED – Weighted RED
    • Based on IP precedence or DSCP values
    • Less-important packets are dropped more aggressively than important packets
    • Applied to an interface, VC or a class within a policy map
  • CBWRED – Class based WRED
    • Configured with CBWFQ
  • Policing
    • Limits subrate bandwidth (give you 100kbps on a T1)
    • Limits traffic of certain applications
    • Any traffic that exceeds police is dropped or re-classified; it’s a hard limit
    • Inbound or outbound
  • Shaping
    • Sets a limit but buffers any in excess
    • Requires memory to store the buffer
    • Buffers = delay and/or jitter
    • Outbound only
    • Can respond to network signals like BECNs and FECNs
  • Token and bucket
    • The queue is a bucket; if a byte of data needs to be sent, it needs a token.
    • If there are enough tokens, the traffic is considered conforming.
    • If there aren’t enough tokens, the traffic is considered exceeding, which triggers the drop (policing), re-classify (policing), or buffer (shaping).
  • Frame relay traffic shaping (FRTS)
    • Only controls frame relay traffic
    • Applied on subif or DLCI
    • Support fragmentation and interleaving
    • Reacts to FECNs and BECNs
  • Compression
    • Removed redundancy and patterns in data
    • Less data = less latency
    • Hardware compression or hardware-assisted compression does not involve the main CPU
    • Software compression does
    • Payload compression
    • Header compression
  • Link fragmentation and interleaving
    • Small data might be waiting for larger data pieces to finish sending
    • Chunks data into smaller fragments so they don’t have to wait
    • Interleaving shuffles flows in the Tx queue

Migrating CSM Serverfarms to Other Server VLANs

A coworker brought an interesting problem to me the other day.  He wanted to move a serverfarm from one server VLAN to another without taking an outage.  Since I didn’t want to have to come into the office late at night to do work, I decided to see what we could do.

It turned out to be pretty easy.  We tend to think of CSM VLANs as pairs — you have the client VLAN for the web servers where the vserver sits and the server VLAN where the serverfarm sits.  The CSM doesn’t know about these relationships; all it cares about is whether the servers are in a server VLAN, and we can use that to our advantage here.

Here’s a snippet of what the original config looked like (not really since I’m not telling you how my company’s network is set up). The original serverfarm included a serverfarm called SFARM-ORIG that included 192.168.0.10[12]. That farm is used by the vserver VSERV-ORIG that listens  to 1.1.1.1 on HTTP.  The probe is in there, too.

probe HTTP tcp
 port 80
!
serverfarm SFARM-ORIG
 real 192.168.0.101
  inservice
 real 192.168.0.102
  inservice
 probe HTTP
!
vserver VSERV-ORIG
 virtual 1.1.1.1 tcp http
 vlan 100
 serverfarm SFARM-ORIG
 inservice

To make the move, we start by creating a new vserver  and serverfarm that contains all the IPs invovled — both the original IPs that are already in service as well as the new IPs to which the servers will migrate.  The new vserver listens for 2.2.2.2.  In this case, we’re moving the servers to 10.10.1.10[12].

serverfarm SFARM-NEW
 real 192.168.0.101
  inservice
 real 192.168.0.102
  inservice
 real 10.10.1.101
  inservice
 real 10.10.1.102
  inservice
 probe HTTP
!
vserver VSERV-NEW
 virtual 2.2.2.2 tcp http
 vlan 200
 serverfarm SFARM-NEW
 inservice

When you first drop in the config, the original RIPs should come up as operational, and the new ones should fail since they don’t exist yet (duh!).  When everyone’s ready, you then move the service over to the new VIP and run off of that for a while to make sure everything’s working as expected.  When all the parties involved are happy, you can then start moving over the servers one at a time.  The probe should fail out a server pretty quickly, then, when the server is reconfigured and put on the right VLAN, the CSM should eventually see the new RIP come up and put it back in the available server pool for the farm.

Configured like that, you can move the servers whenever you would like, and the CSM will automatically detect the changes and act accordingly.  You just have to remember to remove the old IPs out of the serverfarm when a server moves.

Send any alternative study techniques questions my way.

ONT Notes – Queuing

Here are some more notes from my studies.  Of course, no one cares about them but me, but it’s my blog.  I’m sure someone will find it useful.  Please help to correct dumbass mistakes.

  • Congestion
    • Speed mismatch – traffic leaves a lower-bandwidth interface than the one it came in on
    • Aggregation problem – lots of links with one egress of equal bandwidth
    • Confluence problem – a bunch of traffic needs to egress out of the same interface
  • Queuing
    • Transmit queue (TxQ) – hardware queue; there’s only one you can’t touch
    • Software queue – where packets wait to be sent; there are many queue-types that you modified to police traffic
  • FIFO
    • If I beat you to the router, I leave the router first.
    • Possible long delays, jitter, and starvation
  • Priority queuing (PQ)
    • Four queues
      • High-priority
      • Medium-priority
      • Normal-priority
      • Low-priority
    • Scheduler starts from high and work to low
    • When the high queue is empty, it processes a packet from medium, then starts all over
    • Can you say starvation?
  • Round robin queuing (RR)
    • One packet from this queue, one from the next, etc., then start over again
  • Custom queuing (CQ)
    • Weighted round robin
    • Queues are given weights (bandwidth guarantees)
  • Weighted Fair Queuing (WFQ)
    • Default queuing on slow links ( < E1 )
    • Divides traffic into flows
    • Equal bandwidth is given to each flow
    • Provides faster scheduling to low-volume flows
    • Provides more bandwidth to higher-priority flows
    • Flows identified by a hash
      • Source IP
      • Destination IP
      • Protocol number
      • ToS
      • Source port
      • Destination port
    • Each unique has is a new flow
    • No way to allocate bandwidth among the flows
    • By default, up to 256 queues are made, but that is changeable to a power of 2 between 16 and 4096
    • If the max number of flows is reached, queues are reused for other flows
    • If a queue is full, a packet may be dropped.
    • WFQ early dropping drops packets when the queue reaches the congestive discard threshold (CDT)
    • Advantages
      • Simple configuration
      • No starvation
      • Guarantee processing of all flows
      • Drops packets from big-hitter flows
      • Faster service no low-hitters (interactive) flows
      • Standard on (nearly) all IOS devices
    • Disadvantages
      • Classification and scheduling are not configurable
      • Only on slow links
      • No guarantee of bandwidth or delay
  • Class-based Weighted Fair Queuing (CBWFQ)
    • User-defined queues for flexibility
    • Configured with class-maps via MQC
    • Weights are calculated based on values give in class-map
      • Bandwidth – guarantee this much bandwidth
      • Bandwidth percent – give me this much of the available bandwidth
      • Bandwidth remaining percent
    • Advantages
      • User-defined traffic classes
      • Each queue gets its own bandwidth
      • Scalability
    • Disadvantages
      • No delay guarantee (not good for real-time application like voice)
    • Configuring
        class-map TESTCM1
         match access-group 100
        !
        class-map TESTCM2
         match access-group 200
        !
        policy-map TESTPM
         class TESTCM1
          bandwidth 64
         class TESTCM2
          bandwidth 128
  • Low-latency Queuing
    • Includes strict priority queue for delay-sensitive data
    • Strict priority queue is policed to avoid starvation of other queues
    • Configured the same way as normal CBWFQ, but with the priority keyword
    • This configuration makes TESTCM2 a priority queue
    • class-map TESTCM1
       match access-group 100
      !
      class-map TESTCM2
       match access-group 200
      !
      policy-map TESTPM
       class TESTCM1
        bandwidth 64
       class TESTCM2
        priority bandwidth 128

ONT Notes – Classification, Marking, and NBAR

Here’s another set of notes from my ONT studies.  I’m sure someone will find it useful.  Please help to correct dumbass mistakes.

  • Classification is done with traffic desriptors
    • Ingress interface
    • CoS value on ISL or 802.1P frames
    • Source/destination IP address
    • IP Precedence or DSCP value
    • MPLS EXP
    • Application type
  • Layer 3 QoS
    • Type of Service (ToS) is 8-bit field.
    • First 3 bits of ToS are the IP precedence.
    • First 6 bits of ToS are the DSCP value.
    • Last 2 bits of ToS are explicit congestion notification (ECN).
  • Layer 2 QoS
    • Ethernet
      • Class of Service (CoS)
      • On 802.1P frame
      • 3-bit priority (PRI) field
        • 000 – Routine – Best-effort
        • 001 – Priority – Medium priority
        • 010 – Immediate – High priority
        • 011 – Flash – Call signaling
        • 100 – Flash-Override – Video conferencing
        • 101 – Critical – Voice bearer
        • 110 – Internet – Reserved
        • 111 – Network – Reserved
    • Frame Relay
      • 1-bit discard eligible (DE) field
    • ATM
      • 1-bit cell loss priority (CLP) field
    • MPLS (layer 2 1/2)
      • 3-bit experimental (EXP) field
      • By default, the 3 most significant ToS bits (IP Precedence bits) are copied to EXP
  • Per-hop Behavior (PHB)
    • “an externally observable fowarding behavior of a network node toward a group of IP packets that have the same DSCP value”
    • In other words, treat packets with the same DSCP value in the same manner – scheduling, queuing, policing, etc.
    • Behavior aggregate (BA) is a group of packets with the same DSCP value
  • DSCP
    • DSCP is chopped up into 4 PHBs
      • Class selector PHB – (000) old IP precedence compatibility
      • Default PHB – (000) best effort
      • Assured forwarding (AF) PHB – (001, 010, 011, 100) guarantee bandwidth
        • Provides 4 queues for 4 classes of traffic (AF1-4)
        • Also specifies drop preference (ex., AF41, A13) where second number is preference (higher is more probable to be dropped)
        • Each queue must have (W)RED to avoid drops
        • No queue is any better than the other
        • Backward compatible with IP precedence
      • Expedited forwarding (EF) PHB – (101) low delay
        • Minimum delay
        • Bandwidth guarantee
        • Policing
  • Trust boundaries
    • Establish DSCP values as close to the source as possible
      • On the device (IP phone), access switch, or distribution switch
      • The core should never assign DSCP values
    • Only trust DSCP values from devices you trust
    • Examine and rewrite values from untrust sources
  • Network-based Application Recognition (NBAR)
    • Protocol discovery – discovers what protocols you’re running on your network
    • Traffic statistics collection – keeps tracks of stats on each protocol
    • Traffic classification – NBAR protocols can be used in class-maps to define traffic to be services
    • Packet description language models (PDLMs) – table of what protocols NBAR recognizes
    • Limitations
      • Doesn’t work on EtherChannel interfaces
      • Only handles 24 URLs, hosts, or MIME types
      • Only analyzes first 400 bytes of the packets
      • Requires CEF
      • Doesn’t work on HTTPS, multicasts, or fragments
      • Ignored traffic destined for the router itself
    • NBAR commands
      • Router(config)# ip nbar pdlm pdlm-name : Update the PDLM table
      • Router(config)# ip nbar port-map protocol-name [tcp|udp] port-number : Adds an entry to the PDLM table
      • Router# show ip nbar port-map protocol-name : Shows what’s in the PDLM table
      • Router# show ip nbar protocol-discovery : Shows what’s been discovered
      • Router(config-cmap)# match protocol name : a class-map match for an NBAR-discovered protocol
    • Special protocol matching
      • Can match beyond the port number with deep packet inspection
      • Matches HTTP hostname, URL, or MIME type
      • Matches fast-track P2P
      • Matches RTP content

ONT Notes – Intro to QoS

I’ll try to keep it a little shorter this time.

Major issues for converged enterprise networks

  • Available bandwidth: competition among applications
    • Fixes
      • Increase bandwidth: More power!
      • Properly queue based on classification and marking: QoS
      • Compress: cRTP, TCP header compression, etc.
  • Delay: Lead time to get a packet to the destination
    • Types of delay
      • Processing delay: routing, switch delay
      • Queuing delay: how long a frame stays in an output queue
      • Serialization delay:  how long to put the frame on the wire
      • Propagation delay: the time to cross the physical medium
  • Jitter (delay variation): Variation is the delay
    • Different delays mean different arrival times
    • De-jitter buffers save up packets to reduce jitter (like the old CD writers)
    • Fixes
      • More bandwidth
      • Prioritize sensitive data and forward first
      • Remark (reclassify) packets based on sensitivity
      • Enable L2 payload compression: make sure compression delay isn’t worse than the jitter
      • Use header compression
  • Packet loss: Packets are lost in the network somewhere
    • Fixes
      • More bandwidth
      • Increase buffers space: more room for the queue on the interface
      • Provide guaranteed bandwidth: Queuing and QoS
      • Congestion avoidance
        • Random Early Detection (RED) and weighted RED (WRED) drop packets before the queue is full
        • Selective dropping is better than FIFO or LIFO dropping

QoS History

  • Priority queuing: gives certain data the right-of-way for transmission
  • Weighted Fair Queuing (WFQ): prevents small packets from waiting too long for big packets
  • RTP priority queuing: Gives voice packets the right-of-way
  • CAC: Makes sure we don’t fill up the queue or pipe with voice traffic

Implementing QoS

  • Step 1: Identify traffic types and requirements
    • Network audit
    • Business audit
    • Define bandwidth requirements for each class found
  • Step 2: Classify the traffic
    • Common classes
      • VOIP
      • Mission-critical
      • Signal traffic: for VOIP
      • Transactional application: SAP, ERP
      • Best-effort: Everything else
      • Scavenger: Crap you don’t care about like P2P and your boss’s email
  • Step 3: Define policies for each class
    • Tasks for each class
      • Set max bandwidth
      • Set min bandwidth
      • Assign relative priorities
      • Apply congestion avoidance, congestion management, etc.

QoS Models

  • Best-effort: no QoS
    • Scalable
    • Easy
    • No service guarantee: doesn’t care what you’re trying to do
    • No service differentiation: all traffic is equal
  • Integrated Service (IntServ)
    • Hard-QoS
    • Uses RSVP to guarantee bandwidth through the entire path
    • Requires
      • Admission control
      • Classification
      • Polices the traffic (ceiling)
      • Queuing
      • Scheduling
    • Advantages
      • End-to-end resource admission control
      • Per-request policy admission control
      • Signaling of dynamic ports
    • Disadvantages
      • Continuous signaling
      • Not scalable
  • Differentiated Services (DiffServ)
    • Soft-QoS
    • Configured on each hop
    • Traffic is classified
    • Enforces different treatment on different classes
    • Defined based on business requirements
    • Benefits
      • Scalable
      • Supports lots of service levels
    • Drawbacks
      • No absolute guarantee of service
      • Complex configuration throughout network

QoS Implementation Methods

  • CLI
    • Old school
    • Not used any more
  • Modules QoS CLI (MQC)
    • Step 1: class-map
    • Step 2: policy-map
    • Step 3: service-policy
  • AutoQoS
    • Automatically generates classes and policies based on traffic it sees
    • Super-simple
    • Requires CEF, NBAR, and correct bandwidth statements
  • SDM QoS Wizard
    • Next, next, next
    • Can be used to implement, monitor, or troubleshoot QoS

ONT Notes – VOIP Networks

Here are some of the notes I’ve been taking while reading over the ONT book. I hope it benefits somebody.  Feel free to correct any stupid mistakes as a paraphrase to avoid a lawsuit.

There’s way too much info here.  I’ll refine the process a little better for the next topics.

Benefits of Packet Telephony Networks

  • More efficient use of bandwidth and equipment – Packet telephony networks don’t dedicate channels or a static bandwidth to a call; it’s just another network application.
  • Consolidate network expense – The common infrastructure (IP-based networks) keeps you from having to support another distinct network for voice like in traditional PBX implementations.
  • Improved employee productivity – The phone can be used for more than just phone calls by utilizing the XML interface to run applications or provide content from the network.
  • Access to new communications devices – IP phones can communicate with computers, network gear, PDAs, etc., and not just the PBX.

Packet Telephony Components

  • Phones – These include analog phone, digital phones, IP phones, softphones, etc.
  • Gateways – These devices connect the different devices that cannot access the IP network.  For example, making a 911 call from your IP phone requires a gateway that switches and converts your VOIP conversation to the PSTN.
  • Gatekeepers – These are devices that handle call routing (resolving an IP to an extension/phone number) and call admission control (CAC, grants permission to make the call).
  • Multipoint control units (MCUs) – These are conference bridges that connect a bunch of streams together and present it to all participants.  Some can do video as well.
  • Call agents – These are devices used in a centralized model that handle the call routing, address translation, call setup, call maintenance, and call termination.
  • Application and database servers – These provide required and optional services to the packet telephony network and include TFTP servers for configuration and OS download and XML servers for application use.
  • Digital signal processors (DSPs) – These guys converts signals from one form to another.  They convert analog to digital signals, digital to packetized data in the form of a codec, from codec to codec, etc.

Analog Interfaces

  • Foreign Exchange Office (FXO) – These are interfaces that expect to connect to a CO or equivalent.  You connect these to your wall jack to get access to the PSTN.
  • Foreign Exchange Station (FXS) – You connect your analog devices (phones, modems, faxes, etc.) to these guys to get dial tone.
  • Ear and Mouth (E&M) – These are the old-school way to connect PBXes together.

Digital Interfaces

  • Basic Rate ISDN (BRI) – These give you 2 64kbps channels (bearer channels) to run voice over.  It also includes a 16kbps D (delta) channel with 48kbps of framing overhead to give you 192kbps.
  • T1 (North America) – This is a channelized T1 or a Primary Rate ISDN (PRI).
    • Common Channel Signaling (CCS) – The D channel is dedicated to signaling, giving you 23 64kbps channels.
    • Channel Associated Signaling (CAS)  – There is no D channel, but every bearer channel dedicates a few data bits for its own signaling.
    • E1 (North America) – This is a channelized E1 or a Primary Rate ISDN (PRI).
      • Common Channel Signaling (CCS) – The D channel is dedicated to signaling, giving you 30 64kbps channels.
      • Channel Associated Signaling (CAS)  – There is still a dedicated D channel, so you still have 30 64kbps channels to use.

VOIP Signaling

  • H323. – ITU Standard that uses a whole mess of RFCs; distributed model
  • Media Gateway Control Protocol (MGCP) – IETF RFC 3435; centralized model
  • Session Initiation Protocol (SIP) – IETF standard; distributed model

Phone Call Stages

  • Call setup – connects the call between the endpoints
    • Call routing – figures out where the call is going
    • CAC (optional) – Do you have enough resources (i.e., an available channel or bandwidth) to make the call?
    • Call negotiation – negotiates the source and destination IPs, source and destination UDP ports, and codec.
  • Call maintenance – collects call statistics for on-demand or historical use
  • Call teardown – hanging up and terminating the connection

Digitizing Analog Signals

  • Sampling – Periodic capturing and recording of voice resulting in a pulse amplitude modulation (PAM) signal
  • Quantization – Assigning numerical values to the PAM signal
  • Encoding – Converting the quantization to binary
  • Compression (optional) – compressing the binary stream
  • Pulse code modulation (PCM) converts analog to digital, but it doesn’t use compression.  It takes 8000 samples per second and converts each sample to an 8-bit number, giving 64kbps of capacity.

Digital to Analog

  • Decompression (optional)
  • Decoding and filtering – binary is converted back to a PAM signal; filtering removes any noise from the conversion
  • Reconstructing the analog signal

The Nyquist Theorem

  • The number of samples required to accurately encode (and decode) a signal is twice the highest frequency of the signal.
  • Since telephone lines can only transmit up to 3400 Hz (4000 Hz for simplicity), the sample rate should be 8000 samples/second.

Measuring Compression Qualities

  • Mean opinion score (MOS) – ITU standard technique for measuring quality of codec; subjective score from 1 to 5
  • Perceptual speech quality measurement (PSQM) – Another ITU standard technique for measuring quality of codec; test equipment score from 0. to 6.5
  • Perceptual analysis measurement system (PAMS) – Developed by BT; predictive system
  • Perceptual evaluation of speech quality (PESQ) – Another ITU standard; combines PSQM and PAMS; objective measurement of factors including subjective values

Digital Signal Processors (DSPs)

  • Provide 3 major services – voice termination, transcoding, conferencing
  • Also performs compression (codec), echo cancellation, voice activity detection (VAD), comfort noise generation (CNG), and jitter handling
  • Conferencing among participants with the same codec is called a single-mode conference.
  • Conferencing among participants with different codecs is called a mixed-mode conference.

Protocols

  • VOIP calls run over Real Time Protocol (RTP).
  • RTP provides sequence reordering, time-stamping, and multiplexing
  • Rides on UDP ports 16384-32767
  • Voice does not need the reliability (retransmission) of TCP since retransmitted data is no longer useful (I already said that).
  • VOIP packets headers:
    • IP – 20 bytes
    • UDP – 8 bytes
    • RTP – 12 bytes
    • L2 headers vary depending on technology (Ethernet = 12 bytes, MPLS, etc.)
  • 2 10-ms packages are usually in one packet (20ms of voice)
  • G.711 (64kbps) produces 160 bytes from 20 ms of voice.
  • G.729 (8kbps) produces 20 bytes from 20 ms of voice.

cRTP

  • Compressed RTP (cRTP) reduces the headers
  • After the first packet lands, the IP, UDP, and RTP headers won’t change, so why send them again?
  • The headers are reduced to a hash.
  • cRTP reduces the headers to 4 bytes with a UDP checksum and 2 bytes without a UDP checksum.
  • Slow links only
  • Processing overhead
  • Finite delay in packetization

Packet Size Effect on Bandwidth

  • The size of a voice frame depends on:
    • Packet rate and packetization size – rate is inversely proporational to size
    • IP overhead – RTP, UDP, IP, cRTP overhead
    • L2 overhead -
    • Tunneling overhead – IPSec, GRP, MPLS, etc.
  • Codecs have different bandwidth
    • G.711 (PCM) – 8000 samples per second @ 8 bits per sample = 64 kbps
    • G.726 (Adaptive Differencial PCM – ADPCM) – Variable bit rate of 32 kbps, 24 kbps, or 16 kbps
    • G.722 (Wideband Speech Encoding) – 2 subbands using modified ADPCM of 64 kpbs, 56kbps, or 48 kbps
    • G.728
    • G.729 – 10 samples per 10-bit code = 8 kbps

Calculating Total Bandwidth

  • Step 1 – Determine codec and packetization period: What does the codec require in bandwidth?  How many samples per packet (usually 2)?
  • Step 2 – Determine link-specific overhead:  Encapsulation?  cRTP?
  • Step 3 – Calculate packetization size:  Size of voice payload; codec bandwidth * packetization period / 8 = voice payload in bytes
  • Step 4 – Calculate total frame size: IP + UDP + RTP + Tunneling + data link + packetization size
  • Step 5 – Calculate packet rate: 1 / packetization period (ex., 20ms packetization period is 1/0.020 = 50 packets per second)
  • Step 6 – Calculate total bandwidth:  Total frame size * packet rate

VAD and Bandwidth

  • Common for 1/3 of conversation to be silence
  • VAD bandwidth savings depends on:
    • Type of audio: regular phone call (two-way), conf call (one-way), music on hold (MOH)
    • Background noise: noise may be detected as voice
    • Other factors:  language, culture may influence amount of silence

Enterprise VOIP Implementations

  • Consists of gateways, gatekeepers, Cisco Unified CallManagers (CCM), Cisco IP Phones
  • Routers can provide the voice gateway function by connecting the IP network to the WAN (and other gateways), PSTN, PBXes, etc.
  • Survivable Remote Site Telephony (SRST) allows local calling and use of PSTN while services are down

Functions of CCM

  • Call processing – routing, signaling, accounting
  • Dial plan administration -  call routing
  • Signaling and device control – configuration and instruction in case of events
  • Phone feature administration – button programming, profiles, etc.
  • Directory and XML
  • API for interface – allows custom programming for IP phones

Enterprise Deployment Models

  • Single-site: You have one site, and everything is there.
  • Multisite with centralized call processing: You have multiple sites, but the main site has the CCM cluster.
  • Multisite with distributed call processing: You have multiple sites, and each site has its own CCM cluster.
  • Clustering over WAN: You have multiple sites, and each site has a part of one big CCM cluster.

IOS Voice Commands

----- R1 -----
! FXS on 1/1/2
Dial-peer voice 1 POTS
 destination-pattern 120
 port 1/1/2

! Extension 230 is on R2
Dial-peer voice 2 R2
 destination-pattern 230
 session target ipv4:10.1.1.2

----- R2 -----
! FXS on 2/2/1
Dial-peer voice 1 POTS
 destination-pattern 230
 port 2/2/1

! Extension
Dial-peer voice 2 R2
 destination-pattern 120
 session target ipv4:10.1.1.1

Call Admission Control (CAC)

  • QoS can guarantee bandwidth but can only reserve so much (say, for 2 simultaneous calls).
  • CAC make sure that resources are available (denies a new call if 2 calls are already placed).
  • Dropped packets affect every call – not just the new ones

—–

Additional Reading

  1. H.323 Sources on Wikipedia
  2. MGCP – RFC 3435
  3. SIP – RFC 3261
  4. Nyquist Theorem on Wikipedia
  5. MPLS on Wikipedia

CSCtd31622 – CSM, Cookies, and the year 2010

It seems that we have another piece of evidence that Cisco doesn’t like the CSM.  From what I’m able to creatively interpret, the software developers didn’t think anyone would be running the CSM for very long, so they set a variable that expires CSM-inserted cookies at 01:01:50GMT on 1 January 20101.  If you’re using cookies to make connections sticky, that means you may see some unexpected results; this shouldn’t affect the web servers’ cookies.

The bug tookit lists 4.3(3) as the “first found in” version, but I’m fairly confident that it exists in every version before 4.3(3).  If you want to be sure you have the bug, you can run the show mod csm # variable command and look for the COOKIE_INSERT_EXPIRATION_DATE value.  It should look something like this.

Switch#sh mod csm 2 variable

variable                        value
----------------------------------------------------------------
ARP_INTERVAL                    300
ARP_LEARNED_INTERVAL            14400
ARP_GRATUITOUS_INTERVAL         15
ARP_RATE                        10
ARP_RETRIES                     3
ARP_LEARN_MODE                  1
ARP_REPLY_FOR_NO_INSERVICE_VIP  0
ADVERTISE_RHI_FREQ              10
AGGREGATE_BACKUP_SF_STATE_TO_VS 0
COOKIE_INSERT_EXPIRATION_DATE   Fri, 1 Jan 2010 01:01:50 GMT
...

The “real fix” is to upgrade to 4.3(3.1) or 4.2(12.1).  Of course that means a reboot of the CSM and an outage and all that.  A workaround includes setting the COOKIE_INSERT_EXPIRATION_DATE variable to some time in the future.  The bug text gives an example of some time in 2020, but any time in the distant future will do.  Assuming your CSM is in slot 2 and you’ve selected 1 Jan 2020 at 00:00:00 for your expiration, you would do this.

Switch(config)#mod csm 2
Switch(config-module-csm)#variable COOKIE_INSERT_EXPIRATION_DATE "Web, 1 Jan 2020 00:00:00 GMT"

That’s much easier than upgrading the CSM, eh?  If you’re still using your CSM by 2020, you can set it again if you want, but you’ll be well past the EOL on that guy (4.1 goes EOL on 13 Oct 20122)

Send any space shuttle launch tickets questions my way.

Sources:

1: CSCtd31622 *
2: Cisco EOL/EOS for CSM 3.1.x and 4.1.x *

*  May require CCO access

Here’s To Another Year

Here we are at the end of another year.  It’s been a pretty good one for me – the wife got a new job, we have a new house, we’re in good health.  I hope that you, too, have had a great year.

Here are some highlights from 2009 to read over while your boss is out on vacation.  I know that I’m a little wiser thanks to the many, many network-related blogs out there, and I hope that I was able to give someone an answer or just some new knowledge in 2009.

I wish you and yours good luck in the new year!

Send any New Year’s party invitations questions my way.  See you next year.

ISCW Down, Three To Go

I took and passed the ISCW test today.  I was super-nervous going into it, which is weird for me, but I finally calmed down after the first few questions.  Here’s my take.  I don’t want to get into any trouble so I’m not going to include very much detail.

The testing center wasn’t very good at all.  It’s in an old building on the busiest road in town, and the noise from the street was barely dampened by the 1960s building materials.  I can tell you that there are three different pipes in the walls since their vibrations resonated through the room every time somebody flushed or brewed some coffee.  There was also a little foot traffic, which can be expected anywhere; they were working through some software problems on another testing station and were very respectful, so it wasn’t too bad.  The worst part of the whole ordeal, though, was the Microsoft class I sat through while taking the test.  They were across the hall, but it sounded like they were in the room with me.  Usually, you hear the instructor yelling at the top of his lungs so the whole class can hear, but I could hear questions being asked and papers being moved.  I think I can go pass a test of AD replication, though.  I certainly won’t be using that facility for any more tests.

The test itself was fair and pretty close to where it should be.  The questions were well rounded and covered the book from front to back.  I missed a few due to my ADD kicking in and not letting me finish reading all the answers.  At least twice, I saw a more appropriate answer just as I released the mouse from the Next button.  :(

There were lots of interactive items- a lot more than I thought there would be or that there should be.  I can understand a few do-this-do-that things, but there were at least ten interactive questions, whether they be “put these in order”, “match the definition”, or “tell me what’s going on”.  Some of these had multiple parts that I had to click back and forth to get all the answers.  One of them in particular could have been more easily presented as an exhibit at the top of a question than a question that really zaps your time.  There were a few SDM questions, but I made it through those by clicking around until I found the info.

There were two simulations that were very straightforward and very easy.  The sim would present the scenario and tell you what the end result should be along with any details.  I found that some details had to be configured in the order the details were presented to finish the lab.  Not all of them, mind you, but enough of them to get annoying; I really expected something a little more robust.  The contextual help and autocomplete worked, though, so that’s a plus.

I had a big issue with time, and, if that happens to me, it can happen to anyone.  The test started with a multi-part interactive question that took me a long time to figure out through the nerves and discord.  I would guess that I got a simulation or interactive question in 8 of the first 11 questions, and, at one point, I looked at the clock to see I had 40 minutes and 38 questions left, so I started picking up the pace.  Luckily, after question 41, the testing gods showed mercy and ended the suffering.

Overall, I give the test an 8 out of 10.  It was very honest and frank with none of the nonesense of trying to trick me.  All of the problems I had were either from my lack of knowledge or my being so easily distracted this morning.  As Cisco goes, it’s not a bad test at all.

Send any ear plugs questions my way.