[cisco-ttl] Re: MERKEZ CONFIGURASYONU

From: cumhuraltan <cumhuraltan_at_....>
Date: Thu Apr 05 2007 - 13:14:19 CEST


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

This archive was generated by hypermail 2.1.8 : Thu Apr 05 2007 - 14:37:09 CEST