Ne znam za rtp priority, ali čini mi se da bi trebalo da staviš traffic rate 64000 128000, a mogao bi i da promeniš ime map klase.

Najiskrenije ... nisam te razumeo!
Zasto da odradim te dve stvari?

Probaj ovako:

class-map voice
match ip rtp 16384 16383

class-map ostali_saobracaj
match ostali_saobracaj

policy-map priority
class voice
priority bandwidth_u_procentima_ili_kbps
class ostali_saobracaj
bandwidth bandwidth_u_procentima_ili_kbps

map-class frame-relay cir128
service-policy output priority

pozdrav,

Sasa

Zato što ti je port u NS 128/64, pa treba da pustiš PVC da radi između ove dve vrednosti. Do sada si bombardovao Novi Sad malo više nego što može da podnese. A ime promeni čisto da odgovara stvarnoj situaciji.

Sad cu to da postavim pa da probam.



Zbunj! A kako si ti iz ovoga sto sam ja postovao ovde zakljucio koliki je port u NS ?
Ti radis u Telekomu?

Veliki Brat vas posmatra...

JUPAK ?
Dane i Mihajlo? :)

Ja sam napravio jednu klasu posto imam samo jedan prioritet na linku - glas. Ostalo prolazi samo kad ima slobodnog linka. Da li je to OK ili moram napraviti i klasu za ostali saobracaj?



class-map match-all voice
match ip rtp 16384 16383
!
!
policy-map priority
class voice
priority percent 95
!
map-class frame-relay cir128
service-policy output priority
snmp-server community private RW
snmp-server community public RO
snmp-server ifindex persist
!

Ne moras...mozes koristiti class_default - ova ti hvata sav ostali saobrcaj! Ona ce ti se svakako pitati nakon priority klase pa nije lose da joj eventualno explicitno definises i bandwidth, polising, shaping...sta ti volja



S

_{[Ovu poruku je menjao positive0 dana 14.02.2006. u 14:49 GMT+1]}

Hvala!
Sve sam postavio kao sto sam i napisao ranije u poruci. Uradio sam mali test. Dok sam razgovarao sa koleginicom iz Novog Sada pustio sam i kopiranje nekog fajla od 1GB sa svog na njen racunar. Par puta je doslo do manjeg seckanja. Ovo je EXTREMNA situacija i nije realno da se tako nesto dogodi (kopiranje fajla od 1GB preko FR) u svakodnevnom koriscenju FR-a. Cekam reakcije korisnika iz ostalih filijala.

Hvala na pomoci.

Do sjeckanja ne bi smjelo da dolazi...s obzirom da LLQ osigurava bandwidth/delay za tu klasu....mozda bi trebalo da pogledas jos jednom kako si primjenio map_class-u!

Da li ti je prioritet definisan i sa druge strane?

Sasa

Evo setovanja u BG-u i NS-u pa prosudi sam. Kako ti izgleda?

Beograd#sh run
!
class-map match-all voice
match ip rtp 16384 16383
!
policy-map priority
class voice
priority percent 90
!
interface Serial0/0/0.2 point-to-point
description Frame Relay veza ka Novom Sadu
ip address 10.10.100.1 255.255.255.252
frame-relay class cir128
frame-relay interface-dlci 101 CISCO
frame-relay ip rtp header-compression
!
map-class frame-relay cir128
service-policy output priority
snmp-server community private RW
snmp-server community public RO
snmp-server ifindex persist

Novi_Sad#sh run
!
interface Serial0/1/0
bandwidth 128
no ip address
encapsulation frame-relay IETF
ip route-cache flow
no fair-queue
frame-relay traffic-shaping
frame-relay lmi-type ansi
!
interface Serial0/1/0.1 point-to-point
ip address 10.10.100.2 255.255.255.252
frame-relay class cir128
frame-relay interface-dlci 100 CISCO
frame-relay ip rtp header-compression
!
class-map match-all voice
match ip rtp 16384 16383
!
policy-map priority
class voice
priority percent 95
!
map-class frame-relay cir128
service-policy output priority
snmp-server community private RW
snmp-server community public RO
snmp-server ifindex persist
!

Ispade ti koristis 90% linka za voice???

Btw, koji kodek koristis? ova kompresija rtp headera moze praviti problem, u zavisnosti od kodeka koji koristis.

Ja bih ovako:

class-map match-all voice
match ip rtp 16384 16383
!
policy-map priority
class voice
priority percent 20
class class-default
bandwidth percent 80
random-detect
random-detect ecn
!
interface Serial0/0/0.2 point-to-point
description Frame Relay veza ka Novom Sadu
ip address 10.10.100.1 255.255.255.252
frame-relay class cir128
frame-relay interface-dlci 101 CISCO

!
map-class frame-relay cir128
adaptive-shaping becn
service-policy output priority



Novi_Sad#sh run
!
interface Serial0/1/0
bandwidth 128
no ip address
encapsulation frame-relay IETF
ip route-cache flow
no fair-queue
frame-relay traffic-shaping
frame-relay lmi-type ansi
!
interface Serial0/1/0.1 point-to-point
ip address 10.10.100.2 255.255.255.252
frame-relay class cir128
frame-relay interface-dlci 100 CISCO

!
class-map match-all voice
match ip rtp 16384 16383
!
policy-map priority
class voice
priority percent 20
class class-default
bandwidth percent 80
random-detect
random-detect ecn
!
map-class frame-relay cir128
adaptive-shaping becn
service-policy output priority


P.S. Ja sam stavio 20% za voice....ti ces vec vidjeti koliko ti treba - prosudi prema broju poziva i kodeku koji koristis!
E, da- mozda mozes umjesto adaptive-shapinga d ukljucis konkretne definicije za cir-ove...ja nisam znao kako su ti brzine distribuirane po dlci-ima, pa sam stavio adaptive-shaping becn!

Pozdrav,

Sasa


---

<sub>[Ovu poruku je menjao positive0 dana 14.02.2006. u 16:28 GMT+1]

[Ovu poruku je menjao positive0 dana 14.02.2006. u 16:47 GMT+1]</sub>

BTW,

Mozda ne bilo lose da napravis posebnu klasu i samo za signaling saobracaj...sip, h323, mgcp...sta vec koristis...


--

Pazi ovako ... dok sam imao FR 256/128 nisam imao nikakav problem. Sve je funkcionisalo perfektno. Onda sam oborio FR na 128/64 i poceli su problemcici. Nije ovo seckanje bas izrazeno ... dogodi se ponekad.
Zasto sam smanjio kapacitet FR-a? Pa razlika izmedju 256 i 128 je preko 20000 dinara mesecno pa to sve puta broj lokacija (koji ce biti poprilican) vidite koja se usteda ostvari mesecno! Codec za komunikaciju izmedju filijale i centrale je g729r8.
Svaka filijala ima od 6 do 10 IP telefona i isto toliko racunara.
Od aplikacija koje koriste FR na racunarima rade samo Outlook i IE. Nista vise.

Ideja je da voice ima puni prioritet a sve ostalo da koristi preostali deo bandwidth-a.

Mislis da treba da ukljucim adaptive-shaping ?

Voice-u ces dati puni prioritet vec samom cinjenicom da ga ukljucujes u LLQ queue...e sad da li za njega treba rezervisati bas 90% linka izracunaj sam:
ti si bas uzeo najfensi codec G729 - 8kbps po pozivu ako se dobro sjecam....vec si tu unio odredjeni processing i serialization delay (iako si smanjio end-to-end delay)...u svakom slucaju, 8kbps*8 telefona u prosjeku=64kbps u situaciji u kojoj ti svih 8 telefona prica istovremeno.

Kao bilo...ja bih prije isao na neki slabiji codec - meni licno najvise odgovara 711, ali to je vjerovatno zato sto imam bandwitha koliko hocu

frame-relay shaping obavezno stavi...njime kontrolises layer2 burst na samom FRF-u...kao sto sam ti rekao, posto ja ne znam koliko jos lokacija imas i kako ti ide taj burst na FRF-u, stavio sam adaptive-shaping....za tebe bi najbolje bilo da definises konkretne vrijednosti za cir i bc: shaping average itd....ima tu par komandi...

pozdrav,

Sasa

Mislim da 711 koristi preko 45 kbps a 729 negde oko 25 kbps. Mogu to da tvrdim sa 85% sigurnosti ... mislim da sam to negde citao.
Po ovoj kalulaciji ja sam i stavio da bude 90%.

Da li ja treba obavezno da definisem vrednosti za CIR na ruteru?
Od cega on racuna tih 90% ... od tih definicija ili?

Mogu ja i da povecam CIR-ove na FR-ovim ali ne volim da placam ono sto ne moram. Zato se sad malo igram da vidim koliko mogu dobro da iskoristim i ovih 128/64 ! :)

A evo i jednog korisnog linka o tome koliko koji codec uzima bandwidth-a ...

http://www.cisco.com/warp/publ...ce-general/bwidth_consume.html

Kako si izracunao da si bas 85% siguran?
Nego...da...u pravu si...8kbps je bit rate!


Znaci jos jednom:


map-class cir128
no frame-relay adaptive-shaping
frame-relay cir 128000
frame-relay bc 640 (- ovde forsiras Tc=10 ms)
frame-relay mincir 64000 (- ne moras ovo stavljati jer ti je vec disablovan adaptive shaping, ali nije lose)
service-policy output priority


Sto se tvog pitanja o izracunavanju procenta tice, :
http://www.cisco.com/en/US/pro...9186a0080443156.html#wp1024688 ... u sustini, svodi se na to da se procenat izracunava na osnovu cir/2

A ako te i dalje brine na osnovu cega se izracunava procenat, predlazem ti dvije alternative:

1. koristi konkretne vrijednosti kbps unutar policy mape umjesto procenata!

2. shape-uj sav saobracaj na interfejsu drugom policy mapom:

policy-map shape
class-class-default
shape average 128
service-policy priority

a onda hvataj cir128 map-classom ovu shape klasu umjesto priority!




Ok?


Pozdrav

Hvala, probacu u petak posto danas i sutra ne radim.
A sto se tice procenta ... do cifre od 90-95% za voice sam dosao sopstvenom logikom. :)
Kazem ti, ideja je da kroz taj link APSOLUTNI prioritet ima voice a sve ostalo koristi samo ono sto preostane od linka. Znaci ako se pojavi ogroman saobracaj na linku, da 95% bandwidth-a prepusti voice-u a ostatak ostalom saobracaju (ovih 5% cisto da nesto postoji). Trenutno ne postoje neke aplikacije, u filijalama, koje koriste taj link (samo IE i Outlook).

Nadam sa da razumes moju logiku? :)
Slazes se samnom ili? :)

I samo da remiziram (da bih znao u buduce sam), fora je da se definise kapacitet linka i onda odrede grupe (klase) kojima se dodeljuju prioriteti na linku?

Opet ja sa istom pricom ... situacija je sada sledeca ... veza izmedju centrale i tacke A je 256/128 a izmedju centrale i tacke B je 128/64
Codec je g729r8.

Povreveno dolazi do zagusenja linka (data saobracaj) pa pocne da mi stuca voice u tom trenutku (nije moguca komunikacija jer uzasno "secka" glas).
Zar ne bi voice trebao da ima PUN prioritet bez obzira ma zagusenje?

Konfiguracija je sledeca:
!
class-map match-all Voice-SIG
match access-group name Voice-SIG
!
ip access-list extended Voice-SIG
permit tcp host 10.1.1.10 any eq 1720
permit tcp host 10.1.1.10 eq 1720 any
permit udp host 10.1.1.10 any range 1718 1720
permit udp host 10.1.1.10 range 1718 1720 any
permit tcp host 10.1.1.10 any range 11000 65535
permit tcp host 10.1.1.10 range 11000 65535 any
permit tcp host 10.1.1.10 any eq 2000
permit tcp host 10.1.1.10 eq 2000 any
!
policy-map priority
class Voice-SIG
bandwidth percent 15
!
interface Serial0/0/0.8 point-to-point
description Frame Relay veza ka lokaciji A
ip address 10.10.100.53 255.255.255.252
frame-relay class cir128
frame-relay interface-dlci 108 CISCO
frame-relay ip rtp header-compression
!
interface Serial0/0/0.9 point-to-point
description Frame Relay veza ka lokaciji B
ip address 10.10.100.25 255.255.255.252
frame-relay class cir64
frame-relay interface-dlci 107 CISCO
frame-relay ip rtp header-compression
!
map-class frame-relay cir128
frame-relay cir 128000
frame-relay ip rtp priority 16384 16380 200
service-policy output priority
!
map-class frame-relay cir64
frame-relay cir 64000
frame-relay ip rtp priority 16384 16380 100
service-policy output priority
snmp-server community private RW
snmp-server community public RO
snmp-server ifindex persist
!

Hvala na pomoci.

Ti bas ne zelis da shvatis?

class-map match-all Voice-SIG
match access-group Voice-SIG
match dscp ef

policy-map V_mark
class Voice-SIG
set dscp ef

policy-map priority
class Voice-SIG
compress header ip rtp
priority percent 20 -ja bih ovde najprije definisao po broju kanala umjesto po procentu: 1 kanal sa kompresovanim rtp hederom=12k, pa prema tome, za dva kanala ce biti:
priority 24
class class-default
fair-queue
random-detect
random-detect ecn

map-class frame-relay p128c64
frame-relay cir 128000
frame-relay bc 1280
frame-relay be 0
frame-relay mincir 64000
frame-relay adaptive-shaping becn
service-policy output priority

Mada se meni vise svidja sljedece: (ovo zbog toga sto ne mozes garantovati da ti telekom nece ispustati pakete u cloudu...postoje istina neke napredne voice-adaptive-shaping tehnike na frame-u, ali da se drzimo jednostavnijih varijanti. Izaberi sam da li ces da zakucas cir na 64 ali da ti je voice 100%, ili da dopustis adaptive shaping ali uz rizik da ukoliko dodje do zagusenja i voice bude dropan od strane Telekoma)

map-class frame-relay c64
frame-relay cir 64000
frame-relay bc 640
frame-relay be 0
frame-relay mincir 64000
no frame-relay adaptive-shaping becn
service-policy output priority

Interface FastEthernet x/x
service-policy input V_mark

interface Serial0/0/0.9 point-to-point
description Frame Relay veza ka lokaciji B
ip address 10.10.100.25 255.255.255.252
frame-relay interface-dlci 107 CISCO
class c128 ili c64


OK?

I am out!!!











_{[Ovu poruku je menjao positive0 dana 09.08.2006. u 14:17 GMT+1]}

Jesi li siguran da će ovo da mu radi na FR? FR na Cisco ruterima ima malkice drugačiji pristup QoS-u od ostalih tipova veza... Sad me malkice mrzi da kopam po knjigama (FR se u mom delu sveta ne koristi), ali sam gotovo siguran da mora da definiše FR QoS, a ne samo MQC...

Marko.

Izvini ako sam te uznemirio ali pitanje sam i postavio zato sto nesto nisam razumeo. Jos uvek ucim pa pitam kad ne znam.
Zaista nemas nikakvu obavezu da mi odgovaras.

Hvala u svakom slucaju na pomoci.

Jel dovoljno ako kazem 100% siguran?

Obrati paznju da je MQC uhvacen FR mapom...

Poz,

Sasa

Jes' nisam video to. Iz nekog razloga sam zaključio da si primenio policy na interfejs, što na FR može i ne mora da radi.

Marko.

P.S. Koristite [ code ] tagove za te konfiguracije, mnogo lepše izgledaju i lakše se čitaju...

Hvala na pomoci!
Sada sve radi kako treba!

Pozdrav!

Wellcome!