1 / 9

Prove di rate limiting su router Cisco

Prove di rate limiting su router Cisco. P. Lo Re, INFN Napoli Workshop sulle Problematiche di Calcolo e Reti nell’INFN Cagliari, maggio 2004. Il rate limiting in IOS - I. Il rate limiting consiste nella possibilita’ di definire policy di traffico “per porta ben nota”

Télécharger la présentation

Prove di rate limiting su router Cisco

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. Prove di rate limiting su router Cisco P. Lo Re, INFN Napoli Workshop sulle Problematiche di Calcolo e Reti nell’INFN Cagliari, maggio 2004 Paolo Lo Re, maggio 2004

  2. Il rate limiting in IOS - I • Il rate limiting consiste nella possibilita’ di definire policy di traffico “per porta ben nota” • IOS supporta questa feature a partire dalla versione 12.2 (Mainstream) Paolo Lo Re, maggio 2004

  3. Il rate limiting in IOS - II • Il rate limiting e’ implementato in IOS introducendo un limite al traffico che un’interfaccia trasmette in caso di match dei pacchetti interessati con le entry di una ACL • Nella ACL vengono elencate le porte che si desidera limitare Paolo Lo Re, maggio 2004

  4. Il rate limiting in IOS - III • Il comando, da applicare a una interfaccia, e’ rate-limit {input|output} access-group n1 n2 n3 n4 conform-action {transmit|drop} exceed-action {transmit|drop} In cui: n1 e’ la access list che elenca le porte da limitare n2 e’ il limite di bps da imporre per singolo burst n3 e’ la tipica dimensione del burst di dati n4 e’ la massima dimensione del burst di dati Paolo Lo Re, maggio 2004

  5. Prove fatte a Napoli - I • Per valutare quantitativamente il traffico P2P, le porte tipiche del P2P sono state del tutto chiuse per circa un’ora: il traffico input e’ passato da 27 a 8 Mbps • La versione di IOS, dopo vari tentativi, e’ stata portata a 12.3(5) che supporta il rate limiting ed e’ stabile Paolo Lo Re, maggio 2004

  6. Prove fatte a Napoli - II • Si e’ constatato che abilitare il cef interagisce in modo forte con il rate limiting, e costringe a configurarlo in modo opportuno con tuning fine, riducendo di molto il limite di bps permesso e portando il valore di burst al limite minimo consentito • Comunque e’ una operazione molto pesante per la cpu: con un 7206 il carico e’ passato in media dal 12% al 41% Paolo Lo Re, maggio 2004

  7. Prove fatte a Napoli - III • La policy impostata (dopo varie prove) e’ rate-limit input access-group 120 48000 4470 8940 conform-action transmit exceed-action drop rate-limit output access-group 120 48000 4470 8940 conform-action transmit exceed-action drop Paolo Lo Re, maggio 2004

  8. Prove fatte a Napoli - IV • La access-list 120 elenca le seguenti porte: access-list 120 permit tcp any any eq 1080 (ecc.) … Le porte sono: 1214 – 4661 – 4662 – 4663 – 4664 – 4665 – 6345 6346 – 6347 – 6348 – 6349 – 6688 – 6699 – 7719 7729 – 7730 – 7731 – 7732 – 7733 – 7734 - 8875 4444 – 5555 – 6666 – 7777 - 8888 Paolo Lo Re, maggio 2004

  9. Risultati ottenuti • La policy e’ stata introdotta in produzione sul router di accesso al GARR della Sezione di Napoli il 16/12/03 alle 16.10 • Il 17/12/03 alle 10.00 il traffico era: Paolo Lo Re, maggio 2004

More Related