1 / 38

Workshop sulle problematiche del Calcolo e Reti INFN

Workshop sulle problematiche del Calcolo e Reti INFN. Traffic Shaping, due soluzioni diverse: BSD, CISCO. Cos’è il traffic shaping.

chloe
Télécharger la présentation

Workshop sulle problematiche del Calcolo e Reti INFN

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Workshop sulle problematiche del Calcolo e Reti INFN Traffic Shaping, due soluzioni diverse: BSD, CISCO Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  2. Cos’è il traffic shaping Consiste nel forzare il traffico di rete ad essere conforme ad un determinato comportamento o seguire forzatamente un certo numero di policies create per modellarne le caratteristiche. Questo concetto può essere implementato con diverse tecnologie esistenti: class basedqueueing, priority queueing, traffic policing, leaky bucket, committed access rate, etc.. Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  3. Utilità del traffic shaping per l’INFN • Consente di dividere il traffico in diverse tipologie di classi e dare maggiore priorità a determinati servizi senza congestionare il link di accesso al GARR (ad es. trasferimento dati esperimenti) • Consente di limitare e/o abbattere drasticamente il traffico P2P • Consente di gestire la banda a disposizione in modo razionale evitando sprechi Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  4. Piattaforme testate Catalyst 3750G-24TS Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  5. OpenBSD: ALTQ (alternate queueing) Il sistema operativo decide in quale coda inserire i pacchetti e successivamente attraverso uno scheduler, quali code processare e in quale ordine rispetto alle altre. Le politiche disponibili per la gestione della coda sono: • FIFO (scheduler di default) • Class Based Queueing (CBQ) • Priority Queueing (PRIQ) Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  6. OpenBSD: ALTQ-CBQ La banda disponibile è divisa tra diverse code, caratterizzate da indirizzo sorgente, destinazione, numero di porta, protocollo… La configurazione ed il numero delle code è molto flessibile: ogni coda può essere rigida (deve stare entro il limite prefissato) oppure prendere in prestito banda, se ve n’è lasciata libera da altre code. Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  7. OpenBSD: esempi di CBQ • Root Queue (2Mbps) • UserA (1Mbps) • ssh (100Kbps) • ftp (900Kbps, borrow) • UserB (1Mbps) • audio (250Kbps) • bulk (750Kbps) • http (100Kbps) • other (650Kbps) • Root Queue (2Mbps) • QueueA (0.5Mbps) • http • QueueB (1.5Mbps) • other Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  8. OpenBSD: CBQ e priority Si può assegnare ad ogni coda CBQ un valore di priorità. Code con la stessa priorità all’interno della medesima gerarchia sono servite in modalità round-robin, code con priorità più alta sono servite preferenzialmente. ESEMPIO • Root Queue (2Mbps) • UserA (1Mbps, priority 1) • ssh (100Kbps, priority 5) • ftp (900Kbps, priority 3) • UserB (1Mbps, priority 1) Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  9. ALTQ-Priority Queuing (PRIQ) Ad ogni interfaccia di rete si possono assegnare più code, che si differenziano per il valore univoco di priorità. La coda con priorità più alta ha sempre la precedenza sulle altre, fino al proprio totale esaurimento. La struttura di tali code è piatta, senza “sottocode”. • ESEMPIO • Root Queue (2Mbps) • Queue A (priority 1) • Queue B (priority 2) • Queue C (priority 3) Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  10. OpenBSD: RED e ECN Random Early Detection è un algoritmo che serve per evitare la congestione del traffico. Viene controllato che una coda non diventi mai piena e si confronta lo stato della coda con due soglie (minima e massima). Il traffico viene tagliato mano a mano che ci si avvicina alla soglia massima. In questo caso più connessioni TCP concorrenti vengono opportunamente modellate in modo che la connessione che occupa più banda viene tagliata più delle altre evitando problemi di congestione globale. Explicit Congestion Notification viene utilizzato assieme a RED per notificare agli host situazioni di congestione della rete marcando i pacchetti in modo opportuno. Gli host che supportano ECN possono quindi auto-limitarsi riducendo la congestione della rete. (RFC 3168). Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  11. OpenBSD: schema piattaforma di provatest in laboratorio Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  12. OpenBSD: configurazione rete+bridging #/etc/hostname.fxp0 INTERFACCIA ESTERNA inet 172.16.0.254 255.255.255.0 172.16.0.255 media 100BaseTX mediaopt fdx #/etc/hostname.fxp1 INTERFACCIA INTERNA up media 100BaseTX mediaopt fdx #/etc/bridgename.bridge0 INTERFACCE CHE FANNO PARTE DEL BRIDGE add fxp0 add fxp1 up #/etc/sysctl.conf IP FORWARDING ENABLED net.inet.ip.forwarding=1 Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  13. OpenBSD: configurazione delle code (CBQ) #/etc/pf.conf CONFIGURAZIONE PF – ALTQ altq on fxp1 cbq bandwidth 100Mb queue { ftp, other } queue ftp bandwidth 30Mb queue other cbq(default) pass out on fxp1 inet proto {tcp} from any to any port 21 queue ftp Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  14. OpenBSD: generazione del traffico con iperf LATO SERVER (LAN): $ ./iperf.exe -s -p 21 LATO CLIENT (WAN): $ ./iperf.exe -c 172.16.0.1 -p 21 -t 500 ---------------------------------------------------- Client connecting to 172.16.0.1, TCP port 21 TCP window size: 8.00 KByte (default) ---------------------------------------------------- [1944] local 172.16.0.3 port 1141 connected with 172.16.0.1 port 21 [ ID] Interval Transfer Bandwidth [1944] 0.0-500.0 sec 5.47 GBytes 93.9 Mbits/sec Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  15. OpenBSD: test 1 - no firewall 93.9 Mbits/sec Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  16. OpenBSD: test 2 - bridged firewall passthrough 93.6 Mbits/sec Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  17. OpenBSD: test 3 - bridged firewall con CBQ queue ftp bandwidth 30Mb queue ftp bandwidth 60Mb Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  18. OpenBSD: schema piattaforma di produzione link INFN Firenze Il traffic shaping in uscita viene implementato su fxp0 e in entrata su fxp1 manrou.fi.infn.it LAN rc-infnfi1.fi.garr.net fxp0 fxp1 shaper - OpenBSD 3.4 Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  19. Configurazione traffic shaper OpenBSD in produzione # coda in entrata altq on fxp1 cbq bandwidth 100Mb queue { intstdin, stdin, p2pin } queue stdin bandwidth 8Mb cbq(default) queue p2pin bandwidth 256Kb cbq queue intstdin cbq(borrow) # coda in uscita altq on fxp0 cbq bandwidth 100Mb queue { intstdout, stdout, p2pout } queue stdout bandwidth 8Mb cbq(default) queue p2pout bandwidth 50Kb cbq queue intstdout cbq(borrow) # regole a cui applicare il traffic shaping pass out on fxp1 inet proto {tcp,udp,icmp} from any to any queue stdin pass out on fxp0 inet proto {tcp,udp,icmp} from any to any queue stdout # taglia i P2P pass out on fxp0 inet proto {tcp,udp} from any to any port > 1024 queue p2pout Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  20. OpenBSD: traffic shaping in entrata e in uscita Il grafico fra le due frecce mostra come la banda sia limitata a 8Mbit/s in un intervallo di tempo di circa 30 minuti. Il traffico generato e’ quasi totalmente TCP, il grafico blu mostra la banda utilizzata dai pacchetti in entrata sul link INFN di Firenze. Il grafico si riferisce alle statistiche di rete sull’interfaccia ATM del router di Firenze visti dalla parte GARR. Il traffic shaping funziona in modo ottimale in entrata ed in uscita. Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  21. OpenBSD: conclusioni • Traffic shaping affidabile e molto preciso • Possibilità di modificare qualsiasi tipo di regola per il traffic shaping on the fly • Software di packet filtering integrato con il policer del traffic shaping tutto kernel embedded per default • Possibilità di scrivere regole molto complesse facilitata da una sintassi molto intuitiva e relativamente semplice • Gestione del logging basata su tcpdump un po’ macchinosa e non del tutto immediata Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  22. Traffic Shaping secondo CISCO Viene utilizzata la QoS • Committed Access Rate (CAR) • Class Based Weighted Fair Queueing • Traffic Policing (policies applied to QoS) Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  23. Traffic Policingpolicies applied to QoS Questo metodo è supportato dagli switch che abbiamo testato, catalyst 3550 e catalyst 3750 • Vengono definite delle Classi per marcare i pacchetti come in CBWFQ • Si associa una o più ACL alla classe definita • Si crea la policy-map che agisce su una o più classi • La policy-map opera limitazioni sulla banda e “burst size”. • La policy-map viene associata ad un’interfaccia di rete Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  24. Piattaforma di test a 100Mbit/s Catalyst 3750 (WS-C3750G-24TS) sw:12.1(19)EA1, 12.2(18)SE1 GigabitEthernet1/0/11 192.168.0.1 172.20.20.1 GigabitEthernet1/0/12 192.168.0.2 SONY Vaio 172.20.20.2 SGI Octane Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  25. Packet rate e burst size Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  26. Configurazione Catalyst 3750 ip routing mls qos ! class-map match-all tftest match access-group 101 ! policy-map test class tftest police 1000000 1000000 exceed-action drop ! interface GigabitEthernet1/0/11 no switchport ip address 172.20.20.1 255.255.255.0 service-policy input test no mdix auto ! interface GigabitEthernet1/0/12 no switchport ip address 192.168.0.1 255.255.255.0 no mdix auto ! access-list 101 permit tcp host 172.20.20.2 any eq 20000 Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  27. Test con iperf (1) Client connecting to 192.168.0.2, TCP port 20001 TCP window size: 62.5 KByte 93.9 Mbits/sec Senza traffic shaping $ ./iperf -w 64000 -c 192.168.0.2 -p 20001 -t 120 Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  28. Test con iperf (2) Traffic shaping a 1Mbit, 5Mbit, 10Mbit Burst = 1MB 1.08 Mbits/sec 4.85 Mbits/sec 9.49 Mbits/sec Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  29. Test con iperf (burst size) (1) police 1000000 125000 exceed-action drop 947 Kbits/sec Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  30. Test con iperf (burst size) (2) • police 1000000 50000 exceed-action drop • police 1000000 10000 exceed-action drop 437 Kbits/sec Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  31. Test con iperf (burst size) (3) • police 15000000 1000000 exceed-action drop • police 20000000 1000000 exceed-action drop Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  32. Test con iperf (burst size) (4) police 30000000 1000000 exceed-action drop 22.1 Mbits/sec Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  33. Test con iperf (burst size) (5) (1) police 50000000 1000000 exceed-action drop (2) police 70000000 1000000 exceed-action drop (3) police 90000000 1000000 exceed-action drop (4) police 30000000 1000000 exceed-action drop (5) police 40000000 1000000 exceed-action drop (6) police 50000000 1000000 exceed-action drop (7) police 60000000 1000000 exceed-action drop (8) police 70000000 1000000 exceed-action drop (3) (2) (8) (7) (1) (6) (5) (4) Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  34. Test con iperf (UDP) Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  35. Cisco Catalyst: considerazioni police [bits per second] [normal burst bytes] exceed-action drop • Il parametro burst bytes è molto importante se impostato ad un valore troppo basso il traffic shaping non funziona in modo adeguato • In generale il parametro burst bytes con una stima molto grossolananon deve essere inferiore a 1/8 della banda impostata in bit per secondo (comp.dcom.sys.cisco). • Il comportamento a dente di sega nei grafici è dovuto al protocollo TCP stesso che agisce sulla window size quando è attenuato dal traffic policing Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  36. Cisco Catalyst: considerazioni (2) È opportuno fare test di questo tipo generando traffico con protocolli a livello 4 che non siano connection oriented come il TCP. Regola generale per calcolare un burst bytes adeguato alla banda che si vuole utilizzare: burst =2*RTT [sec] *bandwidth/8 [bytes/sec] Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  37. Considerazioni sul C3750 • Burst limitato a 1MB/s • Il traffic policing funziona solo se applicato ad acl TCP, non funziona con UDP con IOS 12.1(19)EA1 • Il traffic shaping è un po’ irregolare fatta eccezione per bande impostate a 30,40,50Mbit/s con un burst di 1MB/s; secondo alcuni questo è dovuto a come sono implementati gli algoritmi token bucket (comp.dcom.sys.cisco) Riccardo veraldi - INFN Firenze - Workshop CCR 2004

  38. Cisco Catalyst: Conclusioni • Complessivamente il traffic shaping funziona abbastanza bene • l’utilizzo della CPU è sempre stato praticamente nullo (monitoraggio tramite MIB) perchè lo switch lavora in ASIC a wire speed. • Configurazione del traffic policing molto macchinosa e poco intuitiva anche dopo avere letto i manuali CISCO (necessario consultare comp.dcom.sys.cisco) Riccardo veraldi - INFN Firenze - Workshop CCR 2004

More Related