Route map causing latency

[cc4252]

Found an odd one today.

Senario: Customer has two PVCs (on the same ATM interface) going from their remote site to their head end. One PVC is for Data the other PVC is for Voice. In order to accomplish the splitting of this traffic they are using a route map to send all Voice traffic down the Voice PVC, all traffic that does not match then uses the normal routing process and is generally supposed to go down the Data PVC.

As it stands this current configuration causes latency when they are attempting to open any files (opening an excel file takes over 20 seconds).

When the route map is removed and the Voice PVC is shut down (Voice is then regulated via QOS policy-maps) which causes all traffic (both Voice and Data0 to only go down the Data PVC, the latency goes away (opening that same excel file only takes 6 or 7 seconds).

Traffic on the router is minimal as traffic utilization generally stays under 20%,as does CPU utilization (generally under 10%).

The question prompted is, can one single route map cause such an noticibly increased delay as opposed to splitting this traffic using QOS (another process intensive application) which causes much less delay in data traffic.

Below is pertinant information:

Cisco 3640

IOS: 12.2(7c)

interface FastEthernet0/0.103

encapsulation dot1Q 103

ip address 172.20.203.254 255.255.255.128

ip helper-address 172.20.192.10

ip helper-address 172.16.6.13

ip policy route-map voice-pvc

no cdp enable

interface ATM1/0.2 point-to-point

description primary voice

bandwidth 256

ip address 172.20.35.137 255.255.255.252

ip directed-broadcast

pvc 13/100

protocol ip 172.20.35.138 broadcast

vbr-rt 256 256 201

encapsulation aal5snap

interface ATM1/0.1 point-to-point

description primary data

bandwidth 1256

ip address 172.20.33.137 255.255.255.252

ip directed-broadcast

pvc 5/100

protocol ip 172.20.33.138 broadcast

vbr-nrt 1536 1256 32

oam-pvc manage

encapsulation aal5snap

route-map voice-pvc permit 5

match ip address 110

set ip next-hop 172.20.35.138

access-list 110 permit ip 172.20.203.128 0.0.0.127 172.20.208.0 0.0.0.255

When a packet comes into interface FastEthernet0/0.103 it is checked by route-map voice-pvc. Using access-list 110 if the packet is sourced from any host on the network 172.20.203.128/25 and destined for any host on the network 172.20.208.0/24 then set the next hop ip address for 172.20.35.138 (which is the voice pvc 13/100 on ATM1/0.2). If the packet does not match then it will follow normal routing procedures mostly likely going out via a known route or default route out of the data pvc (5/100 on ATM1/0.1).

Any ideas??

[galenbuckley]

Have you tried enabling fast switched PBR on f0/0.103?

Router(config-if)#ip route-cache policy

[cc4252]

Sorry forgot to mention in the original post that ip cef is enabled on all the routers so technically routes are not supposed to be process switched. Trace routes take their intended path (simple really from host to remote router to head end router to server).

Also of note is that millisecond times on pings with the 2 PVC configuration is 60 miliseconds (with a 100 byte ping) and with new single PVC configuration (using QOS to split the voice) ping times are half that at 30 milliseconds.

[woodkarver]

Hello,

I believe (refering to the last reply) that route-cache switching is turned on by default on that model. It never hurts to check though.

What does your route table look like? What do you get when you enter, "show ip route xxx.xxx.xxx.xxx(remote IP for data traffic) or try the 172.20.33.138. Curios as to what it will show for next hop and routes available. What does a traceroute show with the route-map on and off?

Thanks and Good Luck.

George

[smif101]

Well with this configuration if you wanted to use vbr-rt then you need to change the encapsulation to aal5mux voice. But you want to use IP traffic for the voice instead and all it needs is a pipe. Because you have it setup as a CBR because you have the SCR and PCR the same you are not going to have any contention on the line if you set the ATM switches to give it a Sustained rate of 256. So what I would do is to change the config for the voice to be

vbr-nrt 256 256 32

and see if your pings go back down to the correct latency. If it doesn't stick with what works and use the one data link with the proper QoS in it. Also what type of ATM interface is this T1/OC3 or what, if it is a T1 lower the PCR and SCR of both interfaces to see if that helps.

[cc4252]

Ignore Double Post

[cc4252]

In the chance there is contention on the wire between both data and voice the ATM switch will chose the rt over the nrt (which is course this is intended by the customer as they were not using QOS to prioritze the different packets types, VOIP over regular IP). I was unaware that a pvc could cause contention with itself, if so I'd be interested in learning more.

In any case attempts to change the voice pvc to match the data pvc (voice using vbr-nrt) and vica versa (data using vbr-rt) as suggested above have both been done with the exact same results (slightly higher ping times and slower performance). Ah and the head end is a ATM DS3 and all the remote ends are ATM T1's.

[smif101]

Actually what I wanted you to do was to keep both pvc's to be vbr-nrt, because you need to make the encapsulation type be voice mux for the vbr-rt traffic. On the voice circuit make it

vbr-nrt 256 256 50

and on the data circuit make it keeping the encapsulation type aal5snap for both of them

vbr-nrt 1152 896 50

Giving the T1 the 25% overhead that it needs for administration that leaves 1.152Mbits. So keeping the voice at 256k that leaves 896k for the data. Try that and see how it works.

[cc4252]

Thanks for the info, I'll see if the changes for the pcr and scr work. One question on the voice mux encapsulation. The customer is using Voice Over IP to handle the voice traffic, is changing the encapsulation on the voice pvc to aal5mux voice a Voice Over ATM feature or can it be used effectively with Voice Over IP?