[es] - Cisco ruter - propusni opseg

markom
Marko Milivojević
Network Engineer
Google
Mountain View

Član broj: 18427
Poruke: 4227
*.singidunum.net.

Sajt: https://markom.rs

+16 Profil

Re: Cisco ruter - propusni opseg

^{17.11.2004. u 16:50 - pre 236 meseci}

Za početak, pošto si nov na forumu, nisi ranije pisao, itd. ne znam kakvo je tvoje poznavanje materije. Ne zameri ako odgovor na pitanje bude imao previše suvišnih (osnovnih, jednostavnih, i sl.) informacija. Kako ovo čitaju i drugi korisnici na forumu, nekad nije zgoreg biti detaljan.

Ja sam arhitekturu mreže i problem razumeo kao na slici i u sledećem paragrafu teksta. Samim tim, rešenje problema se zasniva na tim parametrima. Ako sam negde pogrešio, korigovaćemo rešenje.

U LAN-u B se nalazi nekoliko klijent računara koji preko 128K FR veze pristupaju serveru u LAN-u A ili preko iste te veze Internetu, koji je "nekako" (nebitno za ovu priču) vezan sa FR ruterom na lokaciji A. Zbog velikog Internet saobraćaja, neka interaktivna aplikacija između klijenata u B i servera u A ima problema sa radom.

Ovaj problem može da bude jednostavan, ali može i da bude komplikovan. Ukoliko je pristupna brzina na obe strane 128Kb/s i ukoliko imaš isti toliki CIR, problem je jednostavan. Ukoliko se CIR razlikuje od pristupne brzine (CAR) ili u igri postoji i PIR, stvar može da bude komplikovana. Zarad jednostavnosti, a i pošto nisi naveo detalje, ja ću da podrazumevam da je na obe strane CAR=CIR=128Kb/s.

U čemu se sastoji rešenje problema:

- Potrebno je identifikovati saobraćaj koji treba prioritizovati
- Potrebno je odrediti garancije i eventualne limite za taj saobraćaj
- Sve ostalo tretirati kao saobraćaj nižeg prioriteta (best-effort)

Ovo iznad može da se uradi na mnogo različitih načina i uz korišćenje različitih alata u IOS-u (u prošloj poruci sam naveo Priority Queueing, Custom Queueing, Class Based Weighted Fair Queueing i Low Latency Queueing), ali spisak ne prestaje tu, pošto se identifikacija i klasifikacija saobraćaja takođe može obaviti različitim alatima (Commited Access Rate alat, Class Based Classification and Marking, Network Based Application Recognition, itd.). Sve u svemu, izbor rešenja je raznovrsan, ali ne treba previše komplikovati. Moje rešenje se zasniva na korišćenju class-based alata (dakle, class based marking i CBWFQ) i modularnog QoS CLI-a (MQC). Ovde bih iskoristio da uspešno rešenje ovog problema podrazumeva konfiguraciju oba FR rutera -- jedan će prioritizovati saobraćaj od servera ka klijentima, a drugi obrnuto.

Identifikacija saobraćaja
Pošto ne znamo tačno kakva je aplikacija u pitanju, samo znamo da je zasnovana na telnetu, možemo identifikaciju da obavimo na sledeći način: sav saobraćaj koji ide ka serveru po TCP portu 23, pripada toj aplikaciji. Takođe, sav saobraćaj od servera sa TCP porta 23 ka klijentima je ista ta aplikacija. Ovo nije bilo komplikovano.

Prioritizacija saobraćaja
Ovo je već malo kompleksnije. Pošto ne znamo tačno kakve su potrebe aplikacije u vidu 4 osnovna QoS parametra (bandwidth, delay, jitter i loss), pretpostavićemo da je u pitanju interaktivna aplikacija, relativno otporna na jitter (razlike u kašnjenju, npr: 150 ms, 200 ms, 110 ms, itd.). Ukoliko je neotporna na ovo, stvar se komplikuje i treba primeniti Frame Relay fragmentaciju, a ako ćemo pravo, to me izrazito mrzi sad da objašnjavam. Takođe, aplikacija toleriše povećano kašnjenje (ako ne toleriše, potrebno je primeniti low latency queueing, ali to nije podržano na svim ruterima). Takođe, pošto su nam bandwidth parametri nepoznati, pretpostavićemo da će aplikacija biti srećna i zadovoljna da dobije 50% bandwidtha na raspolaganju.

Dosta teoretisanja, evo konfiguracije:

Ruter A

Code:

access-list 128 remark *** Saobracaj ka klijentima
access-list 128 permit tcp IP.ADRESA.SERVERA eq 23 any

class-map APLIKACIJA
match access-group 128
!
policy-map PRIORITET
class APLIKACIJA
  bandwidth percent 50
class class-default
  fair-queue
  random-detect dscp-based
!
interface Serial0.1
service-policy output PRIORITET
!

Ruter B:

Code:

access-list 128 remark *** Saobracaj ka serveru
access-list 128 permit tcp any IP.ADRESA.SERVERA eq 23

class-map APLIKACIJA
match access-group 128
!
policy-map PRIORITET
class APLIKACIJA
  bandwidth percent 50
class class-default
  fair-queue
  random-detect dscp-based
!
interface Serial0.1
service-policy output PRIORITET
!

Marko.

OV SM
LA PK

Prikačeni fajlovi

mreza.PNG - 11.25k

Odgovor na temu