In molte località, abbiamo solo un Cisco ASA 5505 ciascuno e uno o più AP WiFi, oltre al router del provider. Nessun server o PC, solo servizio WiFi per visitatori occasionali. Voglio verificare in remoto se il provider ci fornisce la larghezza di banda contratta. Ho potuto vedere la larghezza di banda utilizzata sul monitoraggio ASA e testare una direzione inviando traffico all'ASA utilizzando Iperf dalla mia parte.
Esiste un modo per consentire all'ASA di generare traffico notevole?
Risposte:
(Ho appena notato il tuo commento su Raspberrys e voglio dare seguito)
Abbiamo una grande rete MPLS in cui dobbiamo misurare la larghezza di banda e il jitter tra i siti per assicurarci che le nostre applicazioni più sensibili non danneggino.
Un ottimo modo per farlo è, come hai già detto, distribuire Raspberrys. Sono abbastanza piccoli, quindi puoi installarli quasi ovunque. Un ottimo toolf per testare bandwith / jitter è iperf , che puoi quindi impostare per funzionare come demone (filtrato!) Su ogni PI. Quindi avviare i test da una stazione di gestione centrale.
A valle potresti essere in grado di scaricare qualcosa su null: sull'ASA ma a monte potresti essere limitato a quanto può trasferire il disco flash che di solito non è molto.
La tua scommessa migliore sarebbe quella di collegare un PC ed eseguire i test, ma ciò richiede ovviamente che qualcuno si trovi sul posto.
Forse il monitoraggio passivo è un approccio migliore. Esistono molti sistemi che monitorano lo stato / errori / scarti / larghezza di banda dell'interfaccia. Un grafico della larghezza di banda soddisfa le tue esigenze?
Avevo un requisito simile molte lune fa con un router remoto con IOS. Finì per usare il servizio chargen di tcp-small-server sul router - gira su tcp / 19. Genererà un flusso di caratteri casuali ecc. E può essere ridimensionato utilizzando più sessioni Telnet dal router remoto ad altri router che eseguono chargen. In nessun posto vicino al ricco controllo / funzionalità dei test iperf basati su host. Inoltre, come sappiamo, ASA non supporta telnet a livello locale, quindi non funzionerà qui ...
ASA ha quell'utilità di tracciamento dei pacchetti dal 7.0 per generare traffico interessante per le configurazioni del tunnel ma non consente l'ottimizzazione della velocità. Tale funzionalità sarebbe anche un vettore di attacco interessante se sfruttata in remoto e su larga scala ... Qualsiasi funzionalità nativa su ASA probabilmente peg il piano di controllo e qualsiasi varietà di attività di polizia del piano di controllo intrinseco dovrebbe limitare la velocità di traffico generata.
Sono d'accordo con sopra che Raspberry Pi è una buona soluzione qui. Ne abbiamo appena inseriti alcuni per guidare gli schermi in stile NOC. Sono fantastici.
In realtà sono stato bloccato con una richiesta simile la scorsa settimana (ovviamente il sito remoto era dall'altra parte del paese). Quello che ho finito per fare è stato usare mgen per inviare udp unidirezionale e solo verificare i contatori sul dispositivo laterale remoto. Se non ti senti a tuo agio con mgen , potresti fare lo stesso con nping o uno degli strumenti nmap .
Come hai sottolineato, il problema con iperf , IxChariot e così tanti altri strumenti è che richiedono un risponditore remoto. mgen , nping e pochi altri no.
Se si dispone di Solar Winds Engineering Tool Kit, è possibile utilizzare "WAN Killer" tra le due posizioni. Assicurati che i tuoi ACL consentano a entrambe le estremità di dialogare in questo modo e inondare con il livello appropriato di eco o di scarto dal punto A al punto B e viceversa.
Usiamo questo per testare la capacità delle reti di gestire il traffico attraverso le connessioni VPN e MPLS, sia che si tratti della velocità effettiva grezza da A a B che del PPS da A a B.