Cisco Voice Guru

Refer to the following document for an excellent reference on Catalyst 3750 Qos:
https://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_note09186a0080883f9e.shtml

Priority Queuing

• Inbound priority queue: Q2 (of two queues)
• Outbound priority queue: Q1 (of four queues)

Normal Behavior with “mls qos” Enabled

• CoS is found in the 802.1p priority bits.  When entering the switch, these incoming incoming frames are marked to CoS 0.
• CoS 0 is referenced against the cos-to-dscp mappings configured on the switch.  By default, CoS 0 is mapped to DSCP 0.
• The frame is passed on through the switch with CoS 0 / DSCP 0

Three Options for CoS/DSCP Classification and Marking

• There are three methods used for classification and marking on Catalyst 3750 switches:
• Port-based configuration using the “mls qos” interface commands.
• MQC-based configuration using class-maps and policy-maps.
• VLAN-based configuration
• These three methods are mutually exclusive.  Meaning, you can only use one of these options at a time.  Otherwise, the subsequent optioned configured will overwrite the initial option configured.

Port-Based Methods

• Access Port (i.e. no Cisco IP phone connected).  Trust DSCP because there is not dot1q/ISL tag in the frames, which is where the CoS bits are stored.

interface FastEthernet 1/0/10
mls qos trust dscp

• Trust Port (i.e. Cisco phone).  The Cisco phone uses 802.1p frames for voice vlan traffic.  PC traffic is sent untagged, which pass through as DSCP 0 regardless of the trust state.

interface FastEthernet 1/0/20
mls qos trust cos

• Uplink Port (i.e. Router-facing)

interface FastEthernet 1/0/1
mls qos trust dscp

Additional Port-Based Commands

• “mls qos cos 3 override” – Sets tagged and untagged frames to the value defined.  This overrides any “mls qos trust [cos | dscp]” values.
• “switchport priority extend cos 0” – Configures the phone to reset PC-egressing traffic to CoS 0
• “mls qos trust device cisco-phone” – Trusts the CoS markings made by the Cisco IP phone.  It also prevents someone from plugging a PC directly into this switchport (i.e. not daisy-chaining through the phone’’s built-in switch) and receiving any preferential marking.

MQC-Based Classification and Marking Example

HQ-3750(config-std-nacl)#ip access-list extended ACL-VOICE-SIGNALING
HQ-3750(config-ext-nacl)#permit tcp any any eq 1720
HQ-3750(config-ext-nacl)#permit tcp any any eq 2000
HQ-3750(config-ext-nacl)#permit tcp any any eq 2428
HQ-3750(config-ext-nacl)#permit tcp any any eq 5060
HQ-3750(config-ext-nacl)#permit tcp any any range 11000 11999
HQ-3750(config-ext-nacl)#permit udp any any eq 1718
HQ-3750(config-ext-nacl)#permit udp any any eq 1719
HQ-3750(config-ext-nacl)#permit udp any any eq 2427
HQ-3750(config-ext-nacl)#permit udp any any eq 2428
HQ-3750(config-ext-nacl)#permit udp any any eq 5060
HQ-3750(config-ext-nacl)#exit

HQ-3750(config-std-nacl)#ip access-list extended ACL-VOICE-MEDIA
HQ-3750(config-ext-nacl)#permit udp any any range 16385 32767

HQ-3750(config)#class-map CLASS-VOICE-SIGNALING
HQ-3750(config-cmap)#match access-group name ACL-VOICE-SIGNALING
HQ-3750(config-cmap)#exit
HQ-3750(config)#class-map  CLASS-VOICE-MEDIA
HQ-3750(config-cmap)#match access-group name ACL-VOICE-MEDIA
HQ-3750(config-cmap)#exit

HQ-3750(config)#policy-map POLICY-VOICE
HQ-3750(config-pmap)#class CLASS-VOICE-SIGNALING
HQ-3750(config-pmap-c)#trust cos
HQ-3750(config-pmap-c)#exit
HQ-3750(config-pmap)#class CLASS-VOICE-MEDIA
HQ-3750(config-pmap-c)#set dscp af26
HQ-3750(config-pmap-c)#exit
HQ-3750(config-pmap)#exit

HQ-3750(config)#interface gigabitEthernet 1/0/13
HQ-3750(config-if)#switchport access vlan 10
HQ-3750(config-if)#switchport mode access
HQ-3750(config-if)#switchport voice vlan 100
HQ-3750(config-if)#spanning-tree portfast
HQ-3750(config-if)#service-policy input POLICY-VOICE
HQ-3750(config-if)#exit

Default Scheduler Configuration

The priority queue is disabled. Both the shaped and shared mode are configured for the SRR. Shaped mode weights override the shared mode value. Therefore, the net result is queue 1 is serviced in shaped mode and queues 2, 3, and 4 are serviced in shared mode. This means queue 1 is serviced with an absolute value that is (1/25) percent, or four percent, of the bandwidth. Queues 2, 3 and 4 are serviced at 25 percent of the bandwidth. If the bandwidth is available, then queues 2, 3 and 4 can be serviced at more than 25 percent of the bandwidth.

Distribution1#show mls qos int gigabitEthernet 1/0/20 queueing
GigabitEthernet1/0/20
Egress Priority Queue : disabled
Shaped queue weights (absolute) :  25 0 0 0
Shared queue weights  :  25 25 25 25
The port bandwidth limit : 100  (Operational Bandwidth:100.0)
The port is mapped to qset : 1

Have a look at the marked up configuration below.  This is the result of running "auto qos voip trust" with just a bit of tweaking afterward.  A big thanks to Warren Heaviside for initially posting the majority of this content on the IPexpert online study list.

This maps a COS to DSCP value

mls qos map cos-dscp 0 8 16 26 32 46 48 56

This is the weighted ratio (not percentage) that the queues are serviced to send packets from each queue.

mls qos srr-queue input bandwidth 90 10

This is the percentage at which input/ingress queue 1 will begin tail dropping for thresholds 1 and 2.  Threshold 3 is not configurable and has a value of 100% assigned to it so it is not shown.

mls qos srr-queue input threshold 1 8 16

This is the percentage at which input/ingress queue 2 will begin tail dropping for thresholds 1 and 2.   Threshold 3 is not configurable and has a value of 100% assigned to it so it is not shown.

mls qos srr-queue input threshold 2 34 66

This is where you define how the two input/ingress queues will share the buffer space between them using percentage.

mls qos srr-queue input buffers 67 33

This is mapping CoS values to either input/ingress queues 1 or 2 and to thresholds 1,2 or 3 where 3 is the highest.

mls qos srr-queue input cos-map queue 1 threshold 2  1
mls qos srr-queue input cos-map queue 1 threshold 3  0   
mls qos srr-queue input cos-map queue 2 threshold 1  2
mls qos srr-queue input cos-map queue 2 threshold 2  4 6 7
mls qos srr-queue input cos-map queue 2 threshold 3  3 5

This is mapping DSCP’s to either input/ingress queues 1 or 2 and to thresholds 1,2 or 3 where 3 is the highest.

mls qos srr-queue input dscp-map queue 1 threshold 2  9 10 11 12 13 14 15
mls qos srr-queue input dscp-map queue 1 threshold 3  0 1 2 3 4 5 6 7 32
mls qos srr-queue input dscp-map queue 2 threshold 1  16 17 18 19 20 21 22 23
mls qos srr-queue input dscp-map queue 2 threshold 2  33 34 35 36 37 38 39 48
mls qos srr-queue input dscp-map queue 2 threshold 2  49 50 51 52 53 54 55 56
mls qos srr-queue input dscp-map queue 2 threshold 2  57 58 59 60 61 62 63
mls qos srr-queue input dscp-map queue 2 threshold 3  24 25 26 27 28 29 30 31
mls qos srr-queue input dscp-map queue 2 threshold 3  40 41 42 43 44 45 46 47

This is mapping COS’s to one of four output/egress queues and to thresholds 1,2 or 3 where 3 is the highest.

mls qos srr-queue output cos-map queue 1 threshold 3  5    
mls qos srr-queue output cos-map queue 2 threshold 3  3 6 7
mls qos srr-queue output cos-map queue 3 threshold 3  2 4
mls qos srr-queue output cos-map queue 4 threshold 2  1
mls qos srr-queue output cos-map queue 4 threshold 3  0

This is mapping DSCP’s to one of four output/egress queues and to thresholds 1,2 or 3 where 3 is the highest.

mls qos srr-queue output dscp-map queue 1 threshold 3  40 41 42 43 44 45 46 47  
mls qos srr-queue output dscp-map queue 2 threshold 3  24 25 26 27 28 29 30 31   
mls qos srr-queue output dscp-map queue 2 threshold 3  48 49 50 51 52 53 54 55
mls qos srr-queue output dscp-map queue 2 threshold 3  56 57 58 59 60 61 62 63
mls qos srr-queue output dscp-map queue 3 threshold 3  16 17 18 19 20 21 22 23
mls qos srr-queue output dscp-map queue 3 threshold 3  32 33 34 35 36 37 38 39
mls qos srr-queue output dscp-map queue 4 threshold 1  8
mls qos srr-queue output dscp-map queue 4 threshold 2  9 10 11 12 13 14 15
mls qos srr-queue output dscp-map queue 4 threshold 3  0 1 2 3 4 5 6 7

This is configuring the drop threshold values for each queue-set and four related output queues.

mls qos queue-set output 1 threshold 1 138 138 92 138
mls qos queue-set output 1 threshold 2 138 138 92 400
mls qos queue-set output 1 threshold 3 36 77 100 318
mls qos queue-set output 1 threshold 4 20 50 67 400

mls qos queue-set output 2 threshold 1 149 149 100 149
mls qos queue-set output 2 threshold 2 118 118 100 235
mls qos queue-set output 2 threshold 3 41 68 100 272
mls qos queue-set output 2 threshold 4 42 72 100 242

This is the percent amount of buffer space for "queue set 1" allocated to to each of the four queues.  In this case the expedite queue 1 is getting 10%.

mls qos queue-set output 1 buffers 10 10 26 54

This is the percent amount of buffer space for "queue set 2" allocated to to each of the four queues.  In this case the expedite queue 1 is getting 16%.

mls qos queue-set output 2 buffers 16 6 17 61

This turns on QoS globally for the switch, but the auto QOS macro does this.

mls qos

Below is the configuration for the access port.  In this example, I have assigned Gig 1/0/2 the properties of queue-set 2 (defined in values above).  Priority-queue is enabled.  Therefore, anything in Q1 can burst up to the full capacity of the link.  Shape and share commands are ignored when “priority-queue out” is configured.

The shape command (1/x = y%) is configured for Q2.  This negates any share command set for that queue.  Q2 is allowed to consume up to 33% of the link capacity, minus what is currently in use by Q1.

Q3 and Q4 are configured according to the share command.  They are allowed to share bandwidth with each other up to 75% ( 60 / [60+20] ) and 25% ( 20 / [ 60 + 20] ) of the remaining link capacity, respectively.

Remember, priority-queue always overrides shaping.  Shaping always overrides sharing.

We are also telling the switch to trust any CoS markings coming inbound toward this switch port.  You must be very careful to trust either CoS or DSCP.  If a packet comes in marked as DSCP, but you are trusting CoS, you risk that packet being marked down to DSCP 0.  The same holds true for CoS trusting.

interface GigabitEthernet1/0/2
srr-queue bandwidth share 10 10 60 20  
srr-queue bandwidth shape  0  3  0  0  (COS 3 is mapped to queue 2
priority-queue out
mls qos trust cos
auto qos voip trust
queue-set 2

CRCX

Hello, voice peeps.  I’m back and at ‘em again.

I had a conversation with an engineer at CDW today and botched up my bandwidth calculations.  I know them, trust me.  However, I get confused at times between the values used for Locations-based CAC, GK-based CAC, RSVP, and QoS.  This post serves to redeem my conscience.

I’ve been unable to find a good article that clearly lays out the different values for each method.  Therefore, I took the initiative to contribute this reference sheet to the CCIE Voice and larger UC community.

DLCX

CUCM Locations-Based CAC Bandwidth Values
You can find this information in CUCM Admin > System > Locations > Add Location > Help > About This Page

• G.711 call uses 80 kbps
• G.722 call uses 80 kbps
• G.723 call uses 24 kbps
• G.728 call uses 16 kbps
• G.729 call uses 24 kbps
• GSM call uses 29 kbps
• Wideband call uses 272 kbps

Gatekeeper-Based CAC Bandwidth Values
A “debug h225 asn1” will reveal “bandWidth 1280” in the ARQ.  Note well, H225 debugs tack a 0 (zero) on the end of your values.  Therefore, 128 kbps (G.711) will show 1280 and 16 kbps (G.729) will show 160.

• G.711 call uses 128 kbps
• G.729 call uses 16 kbps

QoS Bandwidth Values
Best document is the QoS SRND, page 33.
[L2 (G.729 = 20 kbps; G.711 = 80 kbps) + L3] * 8 * 50 = Value per call

• 802.1Q Ethernet adds (up to) 32 bytes of Layer 2 overhead.
• Point-to-point protocol (PPP) adds 12 bytes of Layer 2 overhead.
• Multilink PPP (MLP) adds 13 bytes of Layer 2 overhead.
• Frame Relay adds 4 bytes of Layer 2 overhead; Frame Relay with FRF.12 adds 8 bytes.

RSVP Bandwidth Values
A “debug ip rsvp messages” will show the worst-case scenario bandwidth value used.  Look for “start requesting XX kbps” in the output.

The ip rsvp bandwidth value should be equal to (x-1 calls at normal scenario + 1 call at worst case scenario).  For example, two G.729 calls would be calculated as 24 + 40 = 64 kbps.  In the example below, I have configured RSVP for one G.729 calls (1-1 calls at normal scenario + 1 call at worst-case scenario of 40 kbps)

• G.711 call uses 96 kbps as a 10 ms worst-case scenario.
• G.729 call uses 40 kbps as a 10 ms worst-case scenario.

RSVP Bandwidth Calculations

RSVP bandwith calculations are based on worst-case scenario.  For G.729, this is 40 kbps.  For G.711, this is 96 kbps.

The ip rsvp bandwidth value should be equal to (x-1 calls at normal scenario + 1 call at worst case scenario).  For example, two G.729 calls would be calculated as 24 + 40 = 64 kbps.  In the example below, I have configured RSVP for one G.729 calls (1-1 calls at normal scenario + 1 call at worst-case scenario of 40 kbps)

G.729 with one 10-ms sample per frame
Bandwidth consumed: 40 kbps
Bandwidth consumed (cRTP): 9.6 kbps
Sample latency: 10 ms

G .711 with two 10-ms samples per frame
Bandwidth consumed: 96 kbps
Bandwidth consumed (cRTP): 80.8 kbps
Sample latency: 20 ms

39 kbps – Router Configuration

interface Serial0/0/1:0.1 point-to-point
bandwidth 1536
ip address 10.10.111.1 255.255.255.0
ip ospf mtu-ignore
snmp trap link-status
frame-relay interface-dlci 201
class AutoQoS-FR-Se0/0/1:0-201
auto qos voip
ip rsvp bandwidth 39

39 kbps – Debug Output

debug ip rsvp messages
HQ-RTR#

Call setup takes place from ext. 5002 @ 10.10.110.1 to 1002 @ 10.10.111.2
May 12 22:47:37.039: RSVP 10.10.110.1_17614->10.10.110.2_17324[0.0.0.0]: Received Path message from 10.10.110.1 (on sender host)
May 12 22:47:37.043: RSVP: new path message passed parsing, continue…
May 12 22:47:37.043: RSVP: Triggering outgoing Path refresh
May 12 22:47:37.043: RSVP session 10.10.110.1_17614[0.0.0.0]: Received RESV for 10.10.110.1 (receiver host) from 10.10.110.1
May 12 22:47:37.047: RSVP 10.10.110.2_17324->10.10.110.1_17614[0.0.0.0]: RESV: no path information for 10.10.110.1
May 12 22:47:37.047: RSVP 10.10.110.1_17614->10.10.110.2_17324[0.0.0.0]: Refresh Path psb = 4A362D90 refresh interval = 0mSec
May 12 22:47:37.047: RSVP 10.10.110.1_17614->10.10.110.2_17324[0.0.0.0]: Sending Path message to 10.10.111.2
May 12 22:47:37.047: RSVP session 10.10.110.2_17324[0.0.0.0]:
Outgoing Path, I/F=Se0/0/1:0.1, Layer=IP, NHOP=10.10.111.2, Prerouted=Y
IP   HDR: 10.10.110.1->10.10.110.2, TOS=0×00, Len=260, TTL=255, RA=Y
RSVP HDR: RRC=N, TTL=255, Len=236, Cksum=0
HQ-RTR#xACE8
May 12 22:47:37.079: RSVP: session [TBD]
Incoming Path, I/F=Se0/0/1:0.1, Layer=IP
IP   HDR: 10.10.110.2->10.10.110.1, TOS=0×00, Len=260, TTL=254, RA=Y
RSVP HDR: RRC=N, TTL=255, Len=236, Cksum=0xA1E9
May 12 22:47:37.083: RSVP 10.10.110.2_17324->10.10.110.1_17614[0.0.0.0]: Received Path message from 10.10.111.2 (on Serial0/0/1:0.1)
May 12 22:47:37.083: RSVP: new path message passed parsing, continue…
May 12 22:47:37.083: RSVP session 10.10.110.1_17614[0.0.0.0]: Received RESV for 10.10.110.1 (receiver host) from 10.10.110.1
May 12 22:47:37.083: RSVP 10.10.110.2_17324->10.10.110.1_17614[0.0.0.0]: reservation not found–new one
May 12 22:47:37.083: RSVP-RESV: Admitting new reservation: 4A36FB78
May 12 22:47:37.083: RSVP-RESV: Locally created reservation. No admission/traffic control needed

Admission requested at 40 kbps as seen in the debug.  However, we only have 39 kbps configured.
May 12 22:47:37.087: RSVP 10.10.110.2_17324->10.10.110.1_17614[0.0.0.0]: start requesting 40 kbps FF reservation for 10.10.110.2(17324) UDP-> 10.10.110.1(17614) on Serial0/0/1:0.1 neighbor 10.10.111.2
May 12 22:47:37.087: RSVP 10.10.110.2_17324->10.10.110.1_17614[0.0.0.0]: start requesting 40 kbps FF reservation for 10.10.110.2(17324) UDP-> 10.10.110.1(17614) on Serial0/0/1:0.1 neighbor 10.10.111.2
May 12 22:47:37.087: RSVP: session [TBD]
Incoming Resv, I/F=Se0/0/1:0.1, Layer=IP
IP   HDR: 10.10.111.2->10.10.111.1, TOS=0×00, Len=216, TTL=254, RA=N
RSVP HDR: RRC=N, TTL=255, Len=196, Cksum=0xA25C
May 12 22:47:37.087: RSVP session 10.10.110.2_17324[0.0.0.0]: Received RESV for 10.10.110.2 (Serial0/0/1:0.1) from 10.10.111.2
May 12 22:47:37.087: RSVP 10.10.110.1_17614->10.10.110.2_17324[0.0.0.0]: reservation not found–new one
May 12 22:47:37.087: RSVP-RESV: Admitting new reservation: 4A36FA38

Even though this call is running at 24 kbps, the RSVP algorithm will reject the call. RSVP sends an error message because there is not enough bandwidth configured for a worst-case scenario call.
May 12 22:47:37.091: RSVP 10.10.110.1_17614->10.10.110.2_17324[0.0.0.0]: Sending RESV ERROR message to 10.10.111.2
May 12 22:47:37.091: RSVP session 10.10.110.2_17324[0.0.0.0]:
Outgoing ResvError, I/F=Se0/0/1:0.1, Layer=IP, NHOP=10.10.111.2, Prerouted=N
IP   HDR: 10.10.111.1->10.10.111.2, TOS=0×00, Len=120, TTL=255, RA=N
RSVP HDR: RRC=N, TTL=255, Len=100, Cksum=0x1BEE
May 12 22:47:37.091: RSVP-RESV: reservation was not installed: 4A36FA38
May 12 22:47:37.091: RSVP-RESV: Deleting reservation: 4A36FA38
May 12 22:47:37.091: RSVP 10.10.110.1_17614->10.10.110.2_17324[0.0.0.0]: remove Serial0/0/1:0.1 RESV 10.10.110.2(17324) <- 10.10.110.1(17:17614)
May 12 22:47:37.091: RSVP 10.10.110.1_17614->10.10.110.2_17324[0.0.0.0]: remove sender host PATH 10.10.110.2(17324) <- 10.10.110.1(17:17614)

Call teardown takes place from 10.10.110.1 to 10.10.111.2
May 12 22:47:37.095: RSVP 10.10.110.1_17614->10.10.110.2_17324[0.0.0.0]: Sending PATH TEAR message to 10.10.111.2
May 12 22:47:37.095: RSVP session 10.10.110.2_17324[0.0.0.0]:
Outgoing PathTear, I/F=Se0/0/1:0.1, Layer=IP, NHOP=10.10.111.2, Prerouted=Y
IP   HDR: 10.10.110.1->10.10.110.2, TOS=0×00, Len=152, TTL=255, RA=Y
RSVP HDR: RRC=N, TTL=255, Len=128, Cksum=0xF436
May 12 22:47:37.095: RSVP 10.10.110.2_17324->10.10.110.1_17614[0.0.0.0]: Refresh RESV, req=4A378EB0, refresh interval=0mSec [cleanup timer is not awake]
May 12 22:47:37.099: RSVP 10.10.110.2_17324->10.10.110.1_17614[0.0.0.0]: Sending Resv message to 10.10.111.2
May 12 22:47:37.099: RSVP session 10.10.110.1_17614[0.0.0.0]:
Outgoing Resv, I/F=Se0/0/1:0.1, Layer=IP, NHOP=10.10.111.2, Prerouted=N
IP   HDR: 10.10.111.1->10.10.111.2, TOS=0×00, Len=216, TTL=255, RA=N
RSVP HDR: RRC=N, TTL=255, Len=196, Cksum=0x975F
May 12 22:47:37.107: RSVP 10.10.110.2_17324->10.10.110.1_17614[0.0.0.0]: remove receiver host RESV 10.10.110.1(17614) <- 10.10.110.2(17:17324)
May 12 22:47:37.107: RSVP 10.10.110.2_17324->10.10.110.1_17614[0.0.0.0]: remove Serial0/0/1:0.1 RESV request 10.10.110.1(17614) <- 10.10.110.2(17:17324)
May 12 22:47:37.107: RSVP 10.10.110.2_17324->10.10.110.1_17614[0.0.0.0]: Sending RESV TEAR message to 10.10.111.2
May 12 22:47:37.107: RSVP session 10.10.110.1_17614[0.0.0.0]:
Outgoing ResvTear, I/F=Se0/0/1:0.1, Layer=IP, NHOP=10.10.111.2, Prerouted=N
IP   HDR: 10.10.111.1->10.10.111.2, TOS=0×00, Len=108, TTL=255, RA=N
RSVP HDR: RRC=N, TTL=255, Len=88, Cksum=0×9015
May 12 22:47:37.123: RSVP: session [TBD]
Incoming ResvTear, I/F=Se0/0/1:0.1, Layer=IP
IP   HDR: 10.10.111.2->10.10.111.1, TOS=0×00, Len=108, TTL=254, RA=N
RSVP HDR: RRC=N, TTL=255, Len=88, Cksum=0x9B12
May 12 22:47:37.123: RSVP 10.10.110.1_17614->10.10.110.2_17324[0.0.0.0]: RESV TEAR message for 10.10.110.2 (Serial0/0/1:0.1) from 10.10.111.2
May 12 22:47:37.123: RSVP 10.10.110.1_17614->10.10.110.2_17324[0.0.0.0]: Dropping ResvTear with unrecognized LIH in HOP (may be due to a state which was already deleted)
May 12 22:47:37.131: RSVP: session [TBD]
Incoming PathTear, I/F=Se0/0/1:0.1, Layer=IP
IP   HDR: 10.10.110.2->10.10.110.1, TOS=0×00, Len=152, TTL=254, RA=Y
RSVP HDR: RRC=N, TTL=255, Len=128, Cksum=0xE937
May 12 22:47:37.131: RSVP 10.10.110.2_17324->10.10.110.1_17614[0.0.0.0]: PATH TEAR message for 10.10.110.1 (Serial0/0/1:0.1) from 10.10.110.2
May 12 22:47:37.131: RSVP 10.10.110.2_17324->10.10.110.1_17614[0.0.0.0]: remove Serial0/0/1:0.1 PATH 10.10.110.1(17614) <- 10.10.110.2(17:17324)

40 kbps – Router Configuration

interface Serial0/0/1:0.1 point-to-point
bandwidth 1536
ip address 10.10.111.1 255.255.255.0
ip ospf mtu-ignore
snmp trap link-status
frame-relay interface-dlci 201
class AutoQoS-FR-Se0/0/1:0-201
auto qos voip
ip rsvp bandwidth 40

40 kbps – Debug Output

debug ip rsvp messages
HQ-RTR#

Call setup takes place from ext. 5002 @ 10.10.110.1 to 1002 @ 10.10.111.2
May 12 22:41:32.123: RSVP 10.10.110.1_18566->10.10.110.2_17178[0.0.0.0]: Received Path message from 10.10.110.1 (on sender host)
May 12 22:41:32.123: RSVP: new path message passed parsing, continue…
May 12 22:41:32.123: RSVP: Triggering outgoing Path refresh
May 12 22:41:32.127: RSVP 10.10.110.1_18566->10.10.110.2_17178[0.0.0.0]: Refresh Path psb = 4A367BE4 refresh interval = 0mSec
May 12 22:41:32.127: RSVP 10.10.110.1_18566->10.10.110.2_17178[0.0.0.0]: Sending Path message to 10.10.111.2
May 12 22:41:32.127: RSVP session 10.10.110.2_17178[0.0.0.0]:
Outgoing Path, I/F=Se0/0/1:0.1, Layer=IP, NHOP=10.10.111.2, Prerouted=Y
IP   HDR: 10.10.110.1->10.10.110.2, TOS=0×00, Len=260, TTL=255, RA=Y
RSVP HDR: RRC=N, TTL=255, Len=236, Cksum=0xABC7
May 12 22:41:32.127: RSVP session 10.10.110.1_18566[0.0.0.0]: Received RESV for 10.10.110.1 (receiver host) from 10.10.110.1
May 12 22:41:32.131: RSVP 10.10.110.2_17178->10.10.110.1_18566[0.0.0.0]: RESV: no path information for 10.10.110.1
May 12 22:41:32.163: RSVP: session [TBD]
Incoming Resv, I/F=Se0/0/1:0.1, Layer=IP
IP   HDR: 10.10.111.2->10.10.111.1, TOS=0×00, Len=216, TTL=254, RA=N
RSVP HDR: RRC=N, TTL=255, Len=196, Cksum=0xA13B
May 12 22:41:32.163: RSVP session 10.10.110.2_17178[0.0.0.0]: Received RESV for 10.10.110.2 (Serial0/0/1:0.1) from 10.10.111.2
May 12 22:41:32.167: RSVP 10.10.110.1_18566->10.10.110.2_17178[0.0.0.0]: reservation not found–new one
May 12 22:41:32.167: RSVP-RESV: Admitting new reservation: 4A378CE0
May 12 22:41:32.167: RSVP-RESV: reservation was installed: 4A378CE0
May 12 22:41:32.171: RSVP: session [TBD]
Incoming Path, I/F=Se0/0/1:0.1, Layer=IP
IP   HDR: 10.10.110.2->10.10.110.1, TOS=0×00, Len=260, TTL=254, RA=Y
RSVP HDR: RRC=N, TTL=255, Len=236, Cksum=0xA7C9
May 12 22:41:32.171: RSVP 10.10.110.2_17178->10.10.110.1_18566[0.0.0.0]: Received Path message from 10.10.111.2 (on Serial0/0/1:0.1)
May 12 22:41:32.171: RSVP: new path message passed parsing, continue…
May 12 22:41:32.171: RSVP session 10.10.110.1_18566[0.0.0.0]: Received RESV for 10.10.110.1 (receiver host) from 10.10.110.1
May 12 22:41:32.171: RSVP 10.10.110.2_17178->10.10.110.1_18566[0.0.0.0]: reservation not found–new one
May 12 22:41:32.171: RSVP-RESV: Admitting new reservation: 4A378BA0
May 12 22:41:32.171: RSVP-RESV: Locally created reservation. No admission/traffic control needed
May 12 22:41:32.171: RSVP 10.10.110.2_17178->10.10.110.1_18566[0.0.0.0]: start requesting 40 kbps FF reservation for 10.10.110.2(17178) UDP-> 10.10.110.1(18566) on Serial0/0/1:0.1 neighbor 10.10.111.2
May 12 22:41:32.171: RSVP 10.10.110.2_17178->10.10.110.1_18566[0.0.0.0]: start requesting 40 kbps FF reservation for 10.10.110.2(17178) UDP-> 10.10.110.1(18566) on Serial0/0/1:0.1 neighbor 10.10.111.2
May 12 22:41:32.175: RSVP 10.10.110.2_17178->10.10.110.1_18566[0.0.0.0]: Refresh RESV, req=4A386734, refresh interval=0mSec [cleanup timer is not awake]
May 12 22:41:32.175: RSVP 10.10.110.2_17178->10.10.110.1_18566[0.0.0.0]: Sending Resv message to 10.10.111.2
May 12 22:41:32.175: RSVP session 10.10.110.1_18566[0.0.0.0]:
Outgoing Resv, I/F=Se0/0/1:0.1, Layer=IP, NHOP=10.10.111.2, Prerouted=N
IP   HDR: 10.10.111.1->10.10.111.2, TOS=0×00, Len=216, TTL=255, RA=N
RSVP HDR: RRC=N, TTL=255, Len=196, Cksum=0x9D3F

Call establishment takes place between ext. 5002 @ 10.10.110.1 and 1002 @ 10.10.111.2
May 12 22:41:40.947: SCCP:rcvd OpenReceiveChannel
May 12 22:41:40.947: OpenReceiveChannelMsg Info:
conference_id = 33555486, pass_through_party_id = 33554602
msec_pkt_size = 20, compression_type = 11
qualifier_in.ecvalue = 0, qualifier_in.g723_bitrate = 0, call_ref = 44240084, stream_pass_through_id = 16777216rfc2833_payload_type = 101
May 12 22:41:40.951: SCCP:send OpenReceiveChannelAck
May 12 22:41:40.951: SCCP:rcvd StartMediaTransmission
May 12 22:41:40.951: StartMediaTransmissionMsg Info:
conference_id = 33555486, pass_through_party_id = 33554602
remote_ip_addr = 192.168.23.102, remote_port = 26376
msec_pkt_size = 20, compression_type = 11
qualifier_out.precedence_value = 184, qualifier_out.ssvalue = 0
qualifier_out.max_frames_per_pkt = 0, qualifier_out.g723_bitrate = 0, call_ref = 44240084, stream_pass_through_id = 16777216rfc2833_payload_type = 101
May 12 22:41:40.955: SCCP:rcvd OpenReceiveChannel
May 12 22:41:40.955: OpenReceiveChannelMsg Info:
conference_id
HQ-RTR# = 33555486, pass_through_party_id = 33554600
msec_pkt_size = 20, compression_type = 11
qualifier_in.ecvalue = 0, qualifier_in.g723_bitrate = 0, call_ref = 44240084, stream_pass_through_id = 16777216rfc2833_payload_type = 101
May 12 22:41:40.959: SCCP:send OpenReceiveChannelAck
May 12 22:41:40.967: SCCP:rcvd StartMediaTransmission
May 12 22:41:40.967: StartMediaTransmissionMsg Info:
conference_id = 33555486, pass_through_party_id = 33554600
remote_ip_addr = 10.10.110.2, remote_port = 17178
msec_pkt_size = 20, compression_type = 11
qualifier_out.precedence_value = 184, qualifier_out.ssvalue = 0
qualifier_out.max_frames_per_pkt = 0, qualifier_out.g723_bitrate = 0, call_ref = 44240084, stream_pass_through_id = 16777216rfc2833_payload_type = 101
May 12 22:41:40.979: RSVP session 10.10.110.1_18566[0.0.0.0]: Received RESV for 10.10.110.1 (receiver host) from 10.10.110.1
May 12 22:41:40.979: RSVP 10.10.110.2_17178->10.10.110.1_18566[0.0.0.0]: reservation found–processing possible change: 4A378BA0
May 12 22:41:40.979: RSVP 10.10.110.2_17178->10.10.110.1_18566[0.0.0.0]: Resv changed: POLICY_DATA, FLOWSPEC,
May 12 22:41:40.979: RSVP 10.10.110.2_17178->10.10.110.1_18566[0.0.0.0]: process_reservation_change: Triggering outgoing Resv due to incoming Resv change
May 12 22:41:40.979: RSVP-RESV: accept_reservation_change: 4A378BA0
May 12 22:41:40.979: RSVP-RESV: Locally created reservation. No admission/traffic control needed
May 12 22:41:40.979: RSVP 10.10.110.2_17178->10.10.110.1_18566[0.0.0.0]: start requesting 24 kbps FF reservation for 10.10.110.2(17178) UDP-> 10.10.110.1(18566) on Serial0/0/1:0.1 neighbor 10.10.111.2
May 12 22:41:40.983: RSVP 10.10.110.2_17178->10.10.110.1_18566[0.0.0.0]: Refresh RESV, req=4A386734, refresh interval=0mSec [cleanup timer is not awake]
May 12 22:41:40.983: RSVP 10.10.110.2_17178->10.10.110.1_18566[0.0.0.0]: Sending Resv message to 10.10.111.2
May 12 22:41:40.983: RSVP session 10.10.110.1_18566[0.0.0.0]:
Outgoing Resv, I/F=Se0/0/1:0.1, Layer=IP, NHOP=10.10.111.2, Prerouted=N
IP   HDR: 10.10.111.1->10.10.111.2, TOS=0×00, Len=136, TTL=255, RA=N
RSVP HDR: RRC=N, TTL=255, Len=116, Cksum=0xA5F8
May 12 22:41:40.999: RSVP: session [TBD]
Incoming Resv, I/F=Se0/0/1:0.1, Layer=IP
IP   HDR: 10.10.111.2->10.10.111.1, TOS=0×00, Len=136, TTL=254, RA=N
RSVP HDR: RRC=N, TTL=255, Len=116, Cksum=0xA9F4
May 12 22:41:40.999: RSVP session 10.10.110.2_17178[0.0.0.0]: Received RESV for 10.10.110.2 (Serial0/0/1:0.1) from 10.10.111.2
May 12 22:41:40.999: RSVP 10.10.110.1_18566->10.10.110.2_17178[0.0.0.0]: reservation found–processing possible change: 4A378CE0
May 12 22:41:40.999: RSVP 10.10.110.1_18566->10.10.110.2_17178[0.0.0.0]: Resv changed: POLICY_DATA, FLOWSPEC,
May 12 22:41:40.999: RSVP 10.10.110.1_18566->10.10.110.2_17178[0.0.0.0]: process_reservation_change: Triggering outgoing Resv due to incoming Resv change
May 12 22:41:40.999: RSVP-RESV: accept_reservation_change: 4A378CE0
May 12 22:41:40.999: RSVP-RESV: reservation was installed: 4A378CE0

10 seconds later, Call teardown takes place between ext. 5002 @ 10.10.110.1 and1002 @ 10.10.111.2
May 12 22:41:50.179: RSVP 10.10.110.1_18566->10.10.110.2_17178[0.0.0.0]: remove sender host PATH 10.10.110.2(17178) <- 10.10.110.1(17:18566)
May 12 22:41:50.179: RSVP 10.10.110.1_18566->10.10.110.2_17178[0.0.0.0]: Sending PATH TEAR message to 10.10.111.2
May 12 22:41:50.179: RSVP session 10.10.110.2_17178[0.0.0.0]:
Outgoing PathTear, I/F=Se0/0/1:0.1, Layer=IP, NHOP=10.10.111.2, Prerouted=Y
IP   HDR: 10.10.110.1->10.10.110.2, TOS=0×00, Len=152, TTL=255, RA=Y
RSVP HDR: RRC=N, TTL=255, Len=128, Cksum=0xF315
May 12 22:41:50.183: RSVP 10.10.110.1_18566->10.10.110.2_17178[0.0.0.0]: remove Serial0/0/1:0.1 RESV 10.10.110.2(17178) <- 10.10.110.1(17:18566)
May 12 22:41:50.183: RSVP 10.10.110.2_17178->10.10.110.1_18566[0.0.0.0]: remove receiver host RESV 10.10.110.1(18566) <- 10.10.110.2(17:17178)
May 12 22:41:50.183: RSVP 10.10.110.2_17178->10.10.110.1_18566[0.0.0.0]: remove Serial0/0/1:0.1 RESV request 10.10.110.1(18566) <- 10.10.110.2(17:17178)
May 12 22:41:50.183: RSVP 10.10
HQ-RTR#.110.2_17178->10.10.110.1_18566[0.0.0.0]: Sending RESV TEAR message to 10.10.111.2
May 12 22:41:50.187: RSVP session 10.10.110.1_18566[0.0.0.0]:
Outgoing ResvTear, I/F=Se0/0/1:0.1, Layer=IP, NHOP=10.10.111.2, Prerouted=N
IP   HDR: 10.10.111.1->10.10.111.2, TOS=0×00, Len=108, TTL=255, RA=N
RSVP HDR: RRC=N, TTL=255, Len=88, Cksum=0x2E6B
May 12 22:41:50.191: SCCP:rcvd CloseReceiveChannel
May 12 22:41:50.191: CloseReceiveChannelMsg Info:
conference_id = 33555486, pass_through_party_id = 33554602, call_ref = 44240084, port_handling = 0
May 12 22:41:50.207: RSVP: session [TBD]
Incoming PathTear, I/F=Se0/0/1:0.1, Layer=IP
IP   HDR: 10.10.110.2->10.10.110.1, TOS=0×00, Len=152, TTL=254, RA=Y
RSVP HDR: RRC=N, TTL=255, Len=128, Cksum=0xEF17
May 12 22:41:50.207: RSVP 10.10.110.2_17178->10.10.110.1_18566[0.0.0.0]: PATH TEAR message for 10.10.110.1 (Serial0/0/1:0.1) from 10.10.110.2
May 12 22:41:50.207: RSVP 10.10.110.2_17178->10.10.110.1_18566[0.0.0.0]: remove Serial0/0/1:0.1 PATH 10.10.110.1(18566) <- 10.10.110.2(17:17178)
May 12 22:41:50.211: RSVP: session [TBD]
Incoming ResvTear, I/F=Se0/0/1:0.1, Layer=IP
IP   HDR: 10.10.111.2->10.10.111.1, TOS=0×00, Len=108, TTL=254, RA=N
RSVP HDR: RRC=N, TTL=255, Len=88, Cksum=0×3267
May 12 22:41:50.211: RSVP 10.10.110.1_18566->10.10.110.2_17178[0.0.0.0]: RESV TEAR message for 10.10.110.2 (Serial0/0/1:0.1) from 10.10.111.2
May 12 22:41:50.211: RSVP 10.10.110.1_18566->10.10.110.2_17178[0.0.0.0]: Dropping ResvTear with unrecognized LIH in HOP (may be due to a state which was already deleted)
May 12 22:41:50.379: SCCP:rcvd StopMediaTransmission
May 12 22:41:50.379: StopMediaTransmissionMsg Info:
conference_id = 33555486, pass_through_party_id = 33554602, call_ref = 44240084, port_handling = 0
May 12 22:41:50.383: SCCP:rcvd CloseReceiveChannel
May 12 22:41:50.383: CloseReceiveChannelMsg Info:
conference_id = 33555486, pass_through_party_id = 33554600, call_ref = 44240084, port_handling = 1
May 12 22:41:50.383: SCCP:rcvd StopMediaTransmission
May 12 22:41:50.383: StopMediaTransmissionMsg Info:
conference_id = 33555486, pass_through_party_id = 33554600, call_ref = 44240084, port_handling = 1
HQ-RTR#

The blueprint is a detailed outline of the topics likely to appear on the lab exam. This blueprint introduces pre-configurations of basic tasks (such as phone registration, basic application integration, basic dial plan, etc.), in order to devote additional focus on expert level skills (advanced configuration and troubleshooting) assessments. As usual, knowledge of troubleshooting is an important skill and candidates are expected to diagnose and solve issues as part of the CCIE lab exam. The topics listed are guidelines and other relevant or related topics may also appear.

Read the rest of this entry »