CSIM START call simulator

CSIM START is a badly, if not undocumented Cisco IOS command that allows you to generate a voice call from a voice enabled router. It seems even if buggy, it could be really useful in situations where you are configuring or supporting configurations remotely and / or don't have live users to test configurations for you.

I have used it successfully with version 124-24.T3 with loop start analog POTS lines, but have seen demonstrations with older versions over PRI as well.

It seems that csim always returns a failed=1 code despite calls being made correctly.

I have found debug voip ccapi inout reflects the call generated by csim accurately.

A successful call looks like:

router#csim start 917167994818
csim: called number = 917167994818, loop count = 1 ping count = 0
csim err csimDisconnected recvd DISC cid(21)
csim: loop = 1, failed = 1
csim: call attempted = 1, setup failed = 1, tone failed = 0

A call to a number without a dial-peer match looks like:

router#csim start 917167994818
csim: called number = 089151, loop count = 1 ping count = 0

csim err:csim_do_test Error peer not found

qos pre-classify

Absolutely elegant discussion of qos pre-classify at href="http://packetlife.net/blog/2009/jun/17/qos-pre-classification.

I'm reposting it below (with crappy formatting) simply as a backup. Please give credit where credit is due.

QoS pre-classification

By stretch | Wednesday, June 17, 2009 at 10:37 a.m. UTC

Implementing quality of service provisions on virtual tunnel interfaces (VTIs) poses a challenge: QoS policy enforcement is normally applied only after tunnel encapsulation has taken place. Consider the following service policy applied to a GRE tunnel:

class-map match-all ICMP
match access-group name MATCH_ICMP
class-map match-all GRE
match access-group name MATCH_GRE
!
!
policy-map MyPolicy
class ICMP
class GRE
!
interface Tunnel0
ip address 192.168.0.1 255.255.255.252
tunnel source 10.0.0.1
tunnel destination 10.0.0.2
!
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.252
service-policy output MyPolicy
!
ip access-list extended MATCH_GRE
permit gre any any
ip access-list extended MATCH_ICMP
permit icmp any any

(Note that the policy map used as an example here does not actually enforce any policy; its class maps are included simply to illustrate the manner in which packets are being matched.)

In default operation, our QoS policy will be applied to packets exiting the physical interface only after they have undergone tunnel encapsulation.

When we generate ICMP traffic to the far end of the tunnel, we can verify that our policy only matches the packets as GRE traffic:

R1# ping 192.168.0.2 repeat 10

Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 8/10/24 ms
R1# show policy-map interface f0/0
FastEthernet0/0

Service-policy output: MyPolicy

Class-map: ICMP (match-all)
0 packets, 0 bytes
30 second offered rate 0 bps
Match: protocol icmp

Class-map: GRE (match-all)
10 packets, 1240 bytes
30 second offered rate 0 bps
Match: protocol gre

Class-map: class-default (match-any)
5 packets, 620 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any

This hinders our ability to differentiate between packets which have undergone tunnel encapsulation. However, enabling QoS pre-classification configures the tunnel interface to maintain a copy of the original packet in memory long enough for the physical interface policy to inspect it.

After enabling pre-classification, our policy is applied to the original "inner" header instead of the encapsulation header:

R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# interface tunnel0
R1(config-if)# qos pre-classify
R1(config-if)# ^Z
R1# clear counters f0/0
Clear "show interface" counters on this interface [confirm]
R1# ping 192.168.0.2 repeat 10

Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 4/8/12 ms
R1# show policy-map interface f0/0
FastEthernet0/0

Service-policy output: MyPolicy

Class-map: ICMP (match-all)
10 packets, 1240 bytes
30 second offered rate 0 bps
Match: access-group name MATCH_ICMP

Class-map: GRE (match-all)
0 packets, 0 bytes
30 second offered rate 0 bps
Match: access-group name MATCH_GRE

Class-map: class-default (match-any)
2 packets, 120 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
A couple side notes from my experiments on IOS 12.4(22)T:

I initially wrote the class maps to utilize NBAR (match protocol), but for some reason the ICMP class map didn't appear to take effect, so I switched to extended ACLs. Your mileage may vary.

Pre-classification seems to have no effect when applied to a VTI performing native IPsec encapsulation (versus a crypto map). Again, this may be IOS version-specific.

QoS conversions for extended pings sample

To emulate DSCP tagged traffic:

ef = dscp 46 = 101110 = tos 0xb8 (184) = ip prec 5
af31 = dscp 26 = 011010 = tos 0x68 (104) = ip prec 3
af32 = dscp 28 = 011100 = tos 0x70 (112) = ip prec 3
cs3 = dscp 24 = 011000 = tos 0x60 (96) = ip prec 3

voice_gw#ping ip
Target IP address: 10.10.10.1
Repeat count [5]: 100
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 10.20.10.1
Type of service [0]: 184 --->dscp is ef
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.

A simple way to calculate is to put your binary representation of the value into your calculator and add two zeros to the end (i.e. 101110 becomes 10111000).

If you are looking to emulate IP Precedence values, use 224,192,160,128,96,64,32,0 for IPP 7 to 0.