Relazione elegante

Progetto Garr-b PoReR - Università di Trieste
Giorgio Giorgetti
!
!
Si è inoltre considerata l’eventualità di settare la priorità di trasmissione assegnata alle
code che servono i diversi PVC. Attualmente sono configurati 26 PVC; Il valore totale
aggregato di banda in uscita dall’interfaccia ATM non supera i 10 Mbps di picco: con un
access-rate di 155 Mbps si è considerato trascurabile settare la priorità tra i pvc.
Infine per abilitare l’IP to ATM CoS si è reso necessario configurare il Cisco Express
Forwarding (ip cef).
Configurazione router Frame Relay
Anche su Frame Relay è stato possibile definire una policy (policy-map videoconf) da
applicare in uscita al PVC Frame Relay verso la sede di Trieste grazie alla nuova feature
(LLQ for Frame Relay) implementata nella versione 12.1(2)T. A differenza dell’ATM, la
policy è applicata al VC inserita nella map-class che definisce i parametri per lo shaping,
la frammentazione dei frames e la gestione della congestione:
!
interface Serial0.1 point -to-point
description frame-relay verso via Valerio tramite dlci 20
bandwidth 768
ip address 140.105.XXX.50 255.255.255.252
ip access-group 106 in
ip access-group 106 out
ip accounting output -packets
ip mtu 1496
no cdp enable
frame-relay interface-dlci 20 IETF
class h323class
!
map-class frame-relay h323class
frame-relay cir 768000
frame-relay bc 7680
frame-relay be 0
frame-relay mincir 768000
no frame-relay adaptive-shaping
service-policy output videoconf
frame-relay fragment 1600
!
Ugualmente a
l policy-map comprende due classi: la classe H.323 a stretta priorità
(class h323) a cui viene riservata una banda di 300 Kbps e la classe di default (class
class-default) su cui confluisce il resto del traffico:
policy-map videoconf
class h323
priority 300
class class-default
10
Progetto Garr-b PoReR - Università di Trieste
Giorgio Giorgetti
fair-queue
!
!
L’access-list 104 seleziona il traffico prioritario:
class-map match-all h323
match access-group 104
!
access-list 104 permit udp host 140.105.CCC.DDD host 140.105.AAA.BBB range 3230 3237 precedence
critical
Oltre ai parametri del traffic shaping, nella map-class viene disabilitata la gestione
della segnalazione di congestione tramite il flag BECN non supportato da Telecom, e
comunque inefficiente in caso di traffico inelastico, e viene definita la dimensione minima
del frame da frammentare. Analoghi test di saturazione della linea hanno permesso di
valutare sufficiente una banda riservata di 300 Kbps, come prevedibile secondo il calcolo
effettuato sommando ai flussi audio e video precedentemente calcolati a livello 3 (70 Kbps
+ 230 Kbps), il ridottissimo overhead di livello 2. Il TX-ring size (assegnato all’interfaccia
main) di default ha una profondità di 64 pacchetti. Visto il valore abbastanza elevato del
CIR, rispetto all’accesso, e visto che il PVC configurato è unico, si è lasciato il valore di
default.
Per le esigenze di QoS (in particolare riduzione del jitter) si è configurata la
frammentazione secondo lo standard FRF.12 che permette di attivare il processo di LFI
(Link Fragmentation ad Interleaving) per i frames in uscita dall’interfaccia main. Sebbene
con un access-rate di 1984 Kbps non fosse tecnicamente raccomandato frammentare
(1500 bytes in coda davanti ad un pacchetto RTP, aggiungono un delay di serializzazione
trascurabile di 6 ms), si è reso comunque necessario al fine di abilitare il sistema di
accodamento dual-fifo sull’interfaccia seriale, necessario alla gestione della coda fifo “alta”
(LLQ) per voce/video e la fifo normale per i dati (in effetti se non viene preventivamente
abilitata la frammentazione, il router non applica la service policy alla map-class frame
relay e restituisce un messaggio d’errore).
Serial0 is up, line protocol is up
Hardware is QUICC Serial
MTU 1500 bytes, BW 768 Kbit, DLY 20000 usec,
reliability 255/255, txload 40/255, rxload 33/255
Encapsulation FRAME-RELAY IETF, loopback not set
Keepalive set (10 sec)
LMI enq sent 189, LMI stat recvd 189, LMI upd recvd 0, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
FR SVC disabled, LAPF state down
11
Progetto Garr-b PoReR - Università di Trieste
Giorgio Giorgetti
Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:31:30
Queueing strategy: dual fifo
Output queue: high size/max/dropped 0/256/0
Output queue 0/128, 55196 drops; input queue 1/75, 0 drops
5 minute input rate 101000 bits/sec, 9 packets/sec
5 minute output rate 121000 bits/sec, 9 packets/sec
81631 packets input, 50651147 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
125638 packets output, 108610167 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
map-class frame-relay h323class
frame-relay cir 768000
frame-relay bc 7680
frame-relay be 0
frame-relay mincir 768000
no frame-relay adaptive-shaping
service-policy output videoconf
frame-relay fragment 1600
!
Impostando la dimensione del frame oltre la quale frammentare a 1600 (il massimo
consentito), ci si aspettava che non venisse frammentato alc un frame in uscita. Così non
è stato. Si è notato che la frammentazione causava la perdita di tutti i pacchetti di MTU
massima. I frames venivano scartati all’interoperabilità ATM/Frame Relay: pur conforme
allo standard FRF.8, non vi è la traduzione dei frame frammentati lato ATM mancando il
corrispettivo. L’uscita su WAN di frame frammentati è dovuta al fatto che, essendo l’MTU
dell’interfaccia seriale di 1500 Bytes (header di livello 2 escluso), il router ignora
l’impostazione frame-relay fragment 1600 e considera 1500 il limite dei frame da
frammentare. Dunque ad una trama in uscita di dimensione max 1514 bytes, tolto l’header
Ethernet, verrebbe aggiunto l’header Frame Relay a formare un frame di 1504 bytes,
maggiore di 1500 e dunque frammentato e scarta to in arrivo sullo switch di Telecom. Si è
provato a ridurre la default MTU a livello 2 sull’interfaccia seriale, ma tale impostazione
non viene considerata, o perlomeno il processo di frammentazione avviene prima.
Dunque si è fissata la MTU a livello 3 (ip mtu 1496) con l’inevitabile lieve aumento di
overhead: un compromesso valutato comunque come accettabile (il valore specificato a
livello IP è comprensivo di header, la perdita di carico totale è infine di 4 bytes per frame):
interface Serial0
bandwidt h 768
no ip address
ip accounting output -packets
12
Progetto Garr-b PoReR - Università di Trieste
Giorgio Giorgetti
ip mtu 1496
encapsulation frame-relay IETF
no ip mroute-cache
frame-relay traffic-shaping
frame-relay lmi-type cisco
!
interface Serial0.1 point -to-point
description frame-relay verso via Valerio tramite dlci 20
bandwidth 768
ip address 140.105.XXX.50 255.255.255.252
ip access-group 106 in
ip access-group 106 out
ip accounting output -packets
ip mtu 1496
no cdp enable
frame-relay interface-dlci 20 IETF
class h323class
!
1496+4=1500 bytes massimi per frame di livello 2 (header inclusi): non viene
frammentato alcun frame, e si osserva come il processo di interleaving è attivo, dando
precedenza immediata alla coda prioritaria:
pordenone#show frame-relay pvc 20
PVC Statistics for interface Serial0 (Frame Relay DTE)
DLCI = 20, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1
input pkts 231077
output pkts 56763
in bytes 63544599
out bytes 20121944
dropped pkts 0
in FECN pkts 0
in BECN pkts 0
out FECN pkts 0
out BECN pkts 0
in DE pkts 0
out DE pkts 0
out bcast pkts 0
out bcast bytes 0
pvc create time 2w1d, last time pvc status changed 1w2d
service policy miapol
Service-policy output: miapol (1131)
Class-map: videoconf (match-all) (1133/2)
26462 packets, 16790901 bytes
5 minute offered rate 162000 bps, drop rate 0 bps
Match: access-group 104 (1137)
Weighted Fair Queueing
Strict Priority
Output Queue: Conversation 72
Bandwidth 300 (kbps) Burst 7500 (Bytes)
(pkts matched/bytes matched) 26643/16888159
(total drops/bytes drops) 0/0
Class-map: class-default (match-any) (1141/0)
29882 packets, 3269824 bytes
5 minute offered rate 26000 bps, drop rate 0 bps
Match: any (1145)
Weighted Fair Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 64
(total queued/total drops/no-buffer drops)
13
Progetto Garr-b PoReR - Università di Trieste
Giorgio Giorgetti
0/0/0
Output queue size 0/max total 600/drops 0
fragment type end-t o-end
fragment size 1600
cir 768000 bc 7680
be 0
limit 960 interval 10
mincir 768000 byte increment 960 BECN response no
frags 56787
bytes 20129557 frags delayed 30134
bytes delayed 3236758
shaping active
traffic shaping drops 0
pordenone#
pur non essendoci in uscita alcun frame frammentato:
pordenone#show frame-relay fragment
interface
dlci frag-type frag-size in-frag
Serial0.1
20 end-to-end 1600
0
pordenone#
out-frag dropped-frag
0
0
Non si è implementato il cRTP per la compressione degli header di livello 3 e 4 in
quanto non supportato su ATM.
Non si è implementata alcuna politica di QoS su LAN: ne a Trieste, né a Pordenone.
Struttura del test e risultati
Per valutare il comportamento dei routers in caso di congestione si è utilizzato il
Multicast generator come generatore di traffico per porre sotto stress il collegamento WAN
prima in un senso e poi nell’altro (Test 1 e Test 2). Il generatore (MGEN ver 3.2a1) genera
un flusso RTP su UDP specificabile in termini di indirizzo IP target, pps, packet-size, porti
utilizzati e durata, verso il client ricevitore (DREC ver 3.2a1) che tiene traccia dei pacchetti
giunti a destinazione e fornisce un sommario finale. Oltre a ciò, alcuni flussi ICMP (ping) di
test tra tre distinti host sorgenti su LAN a Trieste verso tre distinti host destinatari su LAN
a Pordenone, hanno creato altro “disturbo” sul link, permettendo ulteriori valutazioni.
Non essendo possibile interrogare i router via SNMP per l’assenza di MIB compilati
con il supporto delle query alle variabili di interesse, si sono raccolti i dati attraverso
l’esecuzione sul router, via CLI da shell remota, di quegli show commands che
mostrassero i parametri da tracciare. A tal fine si è utilizzato un file di script schedulato sul
crontab di un server UNIX.
Si è inoltre utilizzato L’IP Accounting configurato sui due router a Trieste ed a
Pordenone per conteggiare il traffico IP tra gli host coinvolti durante il test. Tenendo conto
degli eventuali pacchetti scartati dai router, è possibile monitorare anche un eventuale
drop effe ttuato da Telecom sui propri WAN-switch.
14