Configuration RSVP

Unanswered Question
Feb 13th, 2007

Got some problems with RSVP configuration on pilot.

The first PATH message is sent but the return PATH is not.

Topology :

PBX -- R1(Gw/Gk) -- R2(Wan) ----- R3(Wan) -- R4(Gw/Gk) -- PBX

Here are configurations files:

R3_Site1_Zone2#sh tech

------------------ show running-config ------------------

Building configuration...

Current configuration : 2000 bytes

!

version 12.3

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname R3_Site1_Zone2

!

boot-start-marker

boot-end-marker

!

!

no aaa new-model

!

resource policy

!

mmi polling-interval 60

no mmi auto-configure

no mmi pvc

mmi snmp-timeout 180

ip subnet-zero

ip cef

!

!

no ip dhcp use vrf connected

!

!

no ip domain lookup

no ftp-server write-enable

!

!

!

!

!

!

!

!

!

!

!

!

!

!

username pat password 0 <removed>

!

!

class-map match-any gold

match dscp af31

match access-group 101

class-map match-any voice

match dscp ef

!

!

policy-map qos

class voice

priority 200

class gold

bandwidth 150

class class-default

fair-queue

!

!

!

!

interface FastEthernet0/0

ip address 192.168.1.1 255.255.255.0

duplex auto

speed auto

fair-queue 64 256 1

ip rsvp bandwidth 20 20

!

interface FastEthernet0/1

no ip address

shutdown

duplex auto

speed auto

!

interface Serial0/1/0

bandwidth 512

no ip address

encapsulation frame-relay

load-interval 30

no keepalive

no fair-queue

frame-relay traffic-shaping

frame-relay ip rtp header-compression

ip rsvp bandwidth

!

interface Serial0/1/0.1 point-to-point

ip address 10.0.0.2 255.255.255.192

ip ospf network point-to-point

frame-relay interface-dlci 17

class to-zone1

frame-relay ip rtp header-compression

ip rsvp bandwidth

ip rsvp data-packet classification none

ip rsvp resource-provider none

!

router ospf 113

log-adjacency-changes

network 10.0.0.0 0.0.0.63 area 1

network 192.168.1.0 0.0.0.255 area 1

!

ip classless

!

!

ip http server

no ip http secure-server

!

!

map-class frame-relay to-zone1

frame-relay cir 512000

frame-relay bc 51200

frame-relay be 0

frame-relay mincir 512000

frame-relay adaptive-shaping becn

service-policy output qos

!

map-class frame-relay to-site1

access-list 101 permit udp any any eq 1200

!

!

!

control-plane

!

!

!

!

!

!

!

!

line con 0

password <removed>

login

line aux 0

line vty 0 4

absolute-timeout 1000

login local

!

end

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
b.hsu Mon, 02/19/2007 - 06:49

RSVP Reservation Types

These are the two types of multicast flows:

Distinct reservation. This constitutes a flow that originates from exactly one sender.

Shared reservation. This constitutes a flow that originates from one or more senders.

RSVP describes these reservations as having certain algorithmic attributes.

Distinct Reservation

An example of a distinct reservation is a video application in which each sender emits a distinct data stream that requires admission and management in a queue. Such a flow, therefore, requires a separate reservation per sender on each transmission facility it crosses (such as Ethernet, a High-Level Data Link Control (HDLC) line, a Frame Relay data-link connection identifier (DLCI), or an ATM virtual channel). RSVP refers to this distinct reservation as explicit and installs it using a Fixed Filter style of reservation.

Use of RSVP for unicast applications is generally a degenerate case of a distinct flow.

Shared Reservation

An example of a shared reservation also is an audio application in which each sender emits a distinct data stream that requires admission and management in a queue. However, because of the nature of the application, a limited number of senders are sending data at any given time. Such a flow, therefore, does not require a separate reservation per sender. Instead, it uses a single reservation that can be applied to any sender within a set as needed.

RSVP installs a shared reservation using a Wild Card or Shared Explicit style of reservation, with the difference between the two determined by the scope of application (which is either wild or explicit):

The Wild Card Filter reserves bandwidth and delay characteristics for any sender and is limited by the list of source addresses carried in the reservation message.

The Shared Explicit style of reservation identifies the flows for specific network resources.

Planning for RSVP Configuration

You must plan carefully to successfully configure and use RSVP on your network. At a minimum, RSVP must reflect your assessment of bandwidth needs on router interfaces. Consider the following questions as you plan for RSVP configuration:

How much bandwidth should RSVP allow per end-user application flow? You must understand the "feeds and speeds" of your applications. By default, the amount reservable by a single flow can be the entire reservable bandwidth. You can, however, limit individual reservations to smaller amounts using the single flow bandwidth parameter. The reserved bandwidth value may not exceed the interface reservable amount, and no one flow may reserve more than the amount specified.

How much bandwidth is available for RSVP? By default, 75 percent of the bandwidth available on an interface is reservable. If you are using a tunnel interface, RSVP can make a reservation for the tunnel whose bandwidth is the sum of the bandwidths reserved within the tunnel.

How much bandwidth must be excluded from RSVP so that it can fairly provide the timely service required by low-volume data conversations? End-to-end controls for data traffic assume that all sessions will behave so as to avoid congestion dynamically. Real-time demands do not follow this behavior. Determine the bandwidth to set aside so bursty data traffic will not be deprived as a side effect of the RSVP QoS configuration.

Try:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800b75bb.html

Actions

This Discussion