MERKEZ de ki mevcut konfigurasyon aşagıdakı gibidir
interface Serial0/0
description MERKEZ FRAME-RELAY HUB
bandwidth 2048
no ip address
encapsulation frame-relay IETF
frame-relay traffic-shaping
frame-relay lmi-type ansi
ip rsvp bandwidth 1536 1536
interface Serial0/0.25 point-to-point
description connected to p
bandwidth 128
ip unnumbered Loopback0
no ip mroute-cache
frame-relay interface-dlci 36 CISCO
class voice128
frame-relay ip rtp header-compression
ip rsvp bandwidth 96 96
map-class frame-relay voice128
frame-relay fragment 80
frame-relay cir 128000
frame-relay bc 1280
frame-relay mincir 128000
frame-relay fair-queue
dial-peer voice 1025 voip
destination-pattern 325.
session target ipv4:172.10.25.1
ip qos dscp cs5 media
!
Sanırım Benım Merkez de yapmam gereken Serial 0/0 ın altında
"ip rsvp bandwidth 1536 1536" kaldırmak ve policy tanımlamak ama F/R
yanısıra merkeze G.SHDSL baglantıları da geldiği için policy yi mapclass
larla sub interface lerin altına degıl de Serial 0/0 ın altına
tanımlamam geregiyor kanımca aşagıdakı gibi bir örnek conf yapsam
sestekı kesılmeler çözülür mu acaba
class-map voice
match ip dscp ef
class-map signal
match access-group 111
policy-map policy128
class voice
priority 35
class signal
bandwidth 8
class class-defult
fair-queue
access-list permit 111 tcp any any eq 5060
access-list permit 111 tcp udp any eq 5060
access-list permit 111 tcp any eq 5060 any
access-list permit 111 udp any eq 5060 any
access-list permit 111 tcp any any eq 1720
access-list permit 111 tcp any eq 1720 any
interface Serial0/0
description MERKEZ FRAME-RELAY HUB
bandwidth 2048
no ip address
encapsulation frame-relay IETF
frame-relay traffic-shaping
frame-relay lmi-type ansi
service-policy outout policy128
Yukarıdakı gibi bir yapıda acaba yıne ses te kesılmeler yasarmıyım
daha oncekı denemelerımde aynı policy yi sub interface altında dlci
no nun altına gırdım ve Serial altındakı
"ip rsvp bandwidth 1536 1536" komutunu kaldırmadan deneme yaptım ve
data transferi oldugu zaman merkez den bana gelen ses te hıc
bır kesılme olmamasına ragmen merkez e gıden benım sesımde
kesılmeler oldu.
> Ustad ben aslinda yazma ozurluyum diyebilirim. Benim gorusum
priority
> ile atama yapmak belli bir bandwith ayirmaktan daha iyi. Ses
> kullanilmadigi zaman ayrilan kisim data kismi icin kullanilabilir
> olmasi bakimindan.
>
> Traffic shapping dalgali olan trafigi size ayrilan bandwith
sinirlari
> icerisinde birakarak, dalgalanmayi onleyerek trafigin daha duzgun
bir
> sekilde aksamasini saglamaktir.
>
> Asagidaki confla problem yasamamaniz lazim ama eger hala
yasiyorsaniz.
>
> show controllers Serial 1/0 | include tx_limited
>
> Ciktida tx_limits (64) olarak gozukuyorsa
>
> interface altinda
> tx-ring-limit 3
> komutunu calistirabilirsiniz. Gerci bu cpu intensiv bir uygulamadir
> ama sorun devam ediyorsa deneyinbunu.
>
> Selamlar,
> Ahmet
>
> On 4/2/07, cumhuraltan <cumhuraltan@...> wrote:
> > --->
> > > SIP altında hangi codec kullanıyorsun ?
> > > frame relay interfaceler altında RTP compression aktif edersen
ve
> > > birde en son olarak LLQ aktif edersen problemini
halledebilirsin.
> > > Sesde kalite sağlamak için en son jitter bufferını biraz artır.
> > > görüşme ilk başladığı zaman çok az bir geçikme ile başlar ama
daha
> > > sonra kaliteli devam eder.
> > >
> > > rtp için aşağıdaki linkten faydalanabilirsin.
> > >
> > >
> >
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgc
> > r/qos_c/qcpart6/qcrtphc.htm
> > >
> >
> > Selam Ahmet Bey ben aslında LLq uygulamaya calımıstım ama ilk
> > voşce deneyımım oldugu ıcın baygaı bı karıstırdım sanıyorum
> > ama yaptıgım arastırmalar sonucu bandwidth yerıne priority
> > kullansam daha saglıklı olacagı kanısına vardım sip uzerınde
> > g729 codec ını kullanmaktayız ve analog gatewayler
> > kullanıldıgı ıcın ben router ın ses paketlerını yakalayamamıs
> > gıbı bır durum olabılecegı kanısına vardım aslında tek
basıma
> > vardım daha tecrubelı tanıdıklarıma da danıstım ve su
> > işlemlerı yapmak geldı aklıma oncelıklı olarak access-list
> > degılde voice ile ilgili class ta "match ip dscp ef" olarak
> > işaretlemeyı deneyecegım veya
> > "access-list aclnumber permit ip 192.168.25.4 any any "
> > (192.168.25.4 analog gateway in ip adresı)
> > ve acaba asagıda kı gıbı bır conf yaparsam sorunum cozülür
mu
> > pazartesı uygulayacagım
> >
> >
> > Aşagıdakı Conf da "frame-relay traffic-shaping" olması gerekıyor
> > mu cunku traffic-shaping ile ilgili bir şey yapmıyorum eger
> > olursa mevcut QoS in çalışmamasına sebep olabilir mi şu esneda
> > kafama takılan tek soru bu aslında "frame-relay traffic-
shaping"
> > ile ilgili net bilgiye henuz vakıf degilim malesef konuyla
> > ilgili cok kısa da olsa benı bilgilendırecek arkadaşlara
> > şimdiden Teşekkür ederim.
> >
> >
> >
> >
> > class-map voice
> > match ip dscp ef
> > class-map signal
> > match access-group 111
> >
> >
> > policy-map voice128
> > class voice
> > priority 35
> > class signal
> > bandwidth 8
> > class class-defult
> > fair-queue
> >
> > map-class frame-relay V128
> > frame-relay cir 128000
> > frame-relay bc 1280
> > frame-relay be 0
> > frame-relay mincir 128000
> > frame-relay fragment 160
> > service-policy output voice128
> > access-list 111 permit udp any any eq 5060
> > access-list 111 permit tcp any any eq 5060
> >
> > interface Serial0/0
> > description FRAME-RELAY HUB
> > bandwidth 128
> > no ip address
> > encapsulation frame-relay
> > invert txclock
> > frame-relay traffic-shaping
> > frame-relay lmi-type ansi
> >
> > interface Serial0/0.1 point-to-point
> > description connected to MERKEZ
> > bandwidth 128
> > ip unnumbered Loopback0
> > frame-relay interface-dlci 16 CISCO
> > class V128
> > frame-relay ip rtp header-compression
> >
> >
> >
> >
> > --
> > Cisco Teknik Tartisma Listesi (Cisco-ttl)
> >
> > Bu listede onerilen degisikliklerin uygulanmasindaki tum
sorumluluk
> > kullaniciya aittir. Liste yoneticileri, oneride bulunan liste
uyeleri ya da
> > bu uyelerin calistigi kuruluslar herhangi bir sekilde sorumlu
tutulamazlar.
> > Yahoo! Groups Links
> >
> >
> >
> >
>
Received on Thu Apr 5 14:37:07 2007