RO132010A2 - Metode, sisteme şi suport citibil de calculator pentru diagnosticarea reţelei - Google Patents

Metode, sisteme şi suport citibil de calculator pentru diagnosticarea reţelei Download PDF

Info

Publication number
RO132010A2
RO132010A2 ROA201501028A RO201501028A RO132010A2 RO 132010 A2 RO132010 A2 RO 132010A2 RO A201501028 A ROA201501028 A RO A201501028A RO 201501028 A RO201501028 A RO 201501028A RO 132010 A2 RO132010 A2 RO 132010A2
Authority
RO
Romania
Prior art keywords
node
sut
diagnostic
network
information
Prior art date
Application number
ROA201501028A
Other languages
English (en)
Inventor
Marius Pavel Nistur
Silviu Ionuţ Niculescu
Alexandru-Bogdan Ştefan
Original Assignee
Ixia, A California Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ixia, A California Corporation filed Critical Ixia, A California Corporation
Priority to ROA201501028A priority Critical patent/RO132010A2/ro
Priority to US14/984,459 priority patent/US10425320B2/en
Publication of RO132010A2 publication Critical patent/RO132010A2/ro

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/12—Network monitoring probes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/535—Tracking the activity of the user
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1042—Peer-to-peer [P2P] networks using topology management mechanisms

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Environmental & Geological Engineering (AREA)

Abstract

Invenţia se referă la o metodă, un sistem şi un suport citibil de către calculator, destinate diagnosticării unei reţele de calculatoare. Metoda de diagnosticare a reţelei, conform invenţiei, constă în configurarea unei multitudini de noduri de diagnosticare (108, 110, 112) pentru a observa comportamentul traficului de date asociat cu un sistem de testat (SUT), observarea comportamentului traficului de date asociat cu sistemul de testat (SUT) şi detectarea problemei acestuia, identificarea, folosind informaţii despre topologia sistemului de testat (SUT), a unui nod de reţea asociat cu problema sistemului de testat, declanşarea unuia dintre nodurile de diagnosticare (108, 110, 112) pentru a obţine informaţii referitoare la nod, de la nodul de reţea, în care nodul de diagnosticare foloseşte cel puţin un protocol de comunicaţie pentru a interoga nodul de reţea cu privire la informaţiile legate de acesta, şi diagnosticarea problemei sistemului de testat (SUT) folosind datele referitoare la nod. Sistemul de diagnosticare a reţelei, conform invenţiei, cuprinde cel puţin un procesor şi un controler de diagnosticare (102) implementat utilizând cel puţin un procesor, în care controlerul dediagnosticare (102) este configurat să execute metoda conform invenţiei. Suportul citibil de către calculator, conform invenţiei, are stocate instrucţiuni executabile de calculator care, atunci când sunt executate de un procesor, comandă calculatorul să efectueze etapele metodei conform invenţiei.

Description

METODE, SISTEME Șl SUPORT CITIBIL DE CALCULATOR PENTRU
DIAGNOSTICAREA REȚELEI
Domeniul tehnic de aplicare
Prezenta invenție se referă la testarea rețelelor de calculatoare. Mai precis, prezenta invenție se referă la metode, sisteme și suport citibil de calculator pentru diagnosticarea rețelei.
Stadiul anterior al tehnicii în general, operatorii de rețea testează nodurile de rețea înainte de implementarea acestora în rețelele reale. De exemplu, un operator de rețea mobilă poate testa o nouă generație de echipamente de comunicații folosind o rețea de testare și/sau mai multe platforme de testare înainte de implementarea echipamentului de comunicații într-o rețea reală (cum ar fi, non-testată). Cu toate acestea, chiar și cu testare prealabilă, uneori rețelele reale pot prezenta diverse aspecte care trebuie să fie depanate sau diagnosticate și rezolvate rapid. Pentru a diagnostica și rezolva astfel de probleme poate fi costisitor, se consumă timp și resurse. Mai mult decât atât, aceste probleme pot afecta eficiența utilizatorului final și/sau pot cauza întreruperi de rețea, în consecință, există o nevoie de metode, sisteme și suport citibil de calculator îmbunătățite pentru diagnosticarea rețelei.
Expunerea pe scurt a invenției
Sunt dezvăluite metode, sisteme și suport citibil de calculator pentru diagnosticarea rețelei. Conform unei metode, aceasta este realizată la un controler de diagnosticare implementat, folosind cel puțin un procesor. Metoda include configurarea unei multitudini de noduri de diagnosticare pentru a observa comportamentul traficului de date asociat cu un sistem de testat (SUT). Metoda include, de asemenea, observarea, folosind nodurile de diagnosticare, a comportamentul traficului de date asociat cu SUT. Metoda include suplimentar detectarea, folosind comportamentul traficului de date, a problemei SUT. Metoda include, de asemenea identificarea, folosind informații despre topologia SUT, a unui nod de rețea în SUT asociat cu problema SUT. Metoda include suplimentar declanșarea unuia dintre nodurile de diagnosticare astfel încât să se a 2015 01028
22/12/2015 obțină informații referitoare la nod de la nodul de rețea, în care nodul de diagnosticare folosește cel puțin un protocol de comunicație pentru a interoga nodul de rețea despre informațiile legate de acesta. Metoda include, de asemenea, diagnosticarea, folosind datele referitoare la nod, problemei SUT.
Conform unui sistem, acesta conține un controler de diagnosticare implementat care folosește cel puțin un procesor. Controlerul de diagnosticare este configurat pentru a configura o multitudine de noduri de diagnosticare pentru a observa comportamentul traficului de date asociate cu un SUT, pentru a observa, folosind nodurile de diagnosticare, comportamentul traficului asociat cu SUT, pentru a detecta, folosind comportamentul de trafic, o problemă SUT, pentru a identifica, folosind informații despre topologia SUT, un nod de rețea în SUT asociat cu problema SUT, pentru a declanșa unul dintre nodurile de diagnosticare ca să se obțină informațiile referitoare nod de la nodul de rețea, în care nodul de diagnosticare folosește cel puțin un protocol de comunicații pentru a interoga nodul rețelei despre informațiile referitoare la nod și pentru a diagnostica, folosind informațiile referitoare nod, problema SUT.
Obiectele prezentei invenții pot fi puse în aplicare de software-ul în combinație cu hardware și/sau firmware. De exemplu, obiectele descrise aici pot fi implementate de software-ul executat de un procesor. Conform unui exemplu de realizare, obiectele prezentei invenții pot fi implementate folosind un suport non tranzitoriu citibil de calculator care are stocate instrucțiuni executabile de calculator, astfel că atunci când sunt executate de procesor, comandă calculatorul să efectueze etapele. în mod exemplar, suportul citibil de calculator adecvat pentru punerea în aplicare a obiectelor prezentei invenții, include dispozitive non-tranzitorii, cum ar fi dispozitive cu memorie disc, dispozitive cu memorie cip, dispozitive logice programabile și circuite integrate specifice. în plus, un suport care poate fi citit de calculator care implementează prezenta invenție poate fi dispus pe un singur dispozitiv sau platformă informatică sau poate fi distribuit pe mai multe dispozitive sau platforme de calcul.
Așa cum este utilizat aici, termenul nod se referă la o platformă informatică fizică care include cel puțin un procesor, o interfață de rețea și memorie.
Așa cum sunt utilizați aici, fiecare din termenii funcție, motor” și modul se referă la hardware care de asemenea poate include software și/sau firmware pentru implementarea problemei(lor) descrise aici.
a 2015 01028
22/12/2015
Prezentarea pe scurt a desenelor explicative
Se dă în continuare mai multe exemple de realizare a invenției, în legătură cu Figurile 1 - 5 care reprezintă:
- Figura 1 este o diagramă care prezintă un mediu pentru diagnosticare de rețea, în conformitate cu un exemplu de realizare a prezentei Invenții;
- Figurile 2A-2B sunt diagrame care prezintă un algoritm de diagnosticare, în conformitate cu un exemplu de realizare a prezentei invenții;
- Figura 3 este o diagramă care prezintă comunicații asociate cu diagnosticarea de rețea, în conformitate cu un exemplu de realizare a prezentei invenții;
- Figura 4 este o diagramă care prezintă comunicații asociate cu diagnosticarea de rețea, conform unui alt exemplu de realizare a prezentei invenții; și
- Figura 5 este o diagramă care prezintă un metodă de diagnosticare de rețea, în conformitate cu un exemplu de realizare a prezentei invenții.
Descrierea detaliată
Sunt dezvăluite metode, sisteme și suport citibil de calculator pentru diagnosticare rețelei. Diagnosticarea rețelei necesită de obicei un operator de rețea care să execute manual numeroase teste și încercări pentru a diagnostica caracteristicile sau problemele pe baza rezultatelor testelor și informațiilor de configurare cunoscute. Cu toate acestea, deoarece astfel de diagnosticări sunt realizate manual și pentru că unele probleme nu sunt evidente din rezultatele testelor specifice, de obicei, aceste diagnosticări de rețea necesită un volum semnificativ de lucru și pot fi mari consumatoare de timp, ineficiente și predispuse la erori.
în conformitate cu unele aspecte ale prezentei invenții, sunt descrise tehnici, metode sau mecanisme pentru automatizarea diagnosticării problemelor de rețea și pentru a preveni astfel de probleme prin simularea de trafic real și prin utilizarea rezultatelor pentru depanarea unui sistem de testat (SUT) (de exemplu, unul sau mai multe dispozitive de rețea). De exemplu, un instrument de diagnosticare sau un algoritm corespunzător poate identifica cu precizie o cauza inițială a uneia sau mai multor probleme, printr-o abordare non-intruzivă în monitorizarea unei rețele reale, cum ar fi aceea care utilizează script-uri (scenarii) pentru a obține informații de stare și/sau alte
a 2015 01028
22/12/2015 informații referitoare la dispozitiv din dispozitivele de rețea care utilizează unul sau mai multe protocoale de comunicații suportate de dispozitivele de rețea, în mod avantajos, în conformitate cu unele aspecte ale prezentei invenții, depanarea și/sau rezolvarea problemelor rețelelor pot fi îmbunătățite prin utilizarea de noduri de diagnosticare care execută unul sau mai multe script-uri (scenarii de rețea) pentru obținerea fermă și în mod automat a informațiilor de stare și/sau a altor informații legate de dispozitiv de la unul mai multe dispozitive (de exemplu, noduri de și/sau funcții de rețea). Prin utilizarea script-urilor și/sau a unui sau mai mulți algoritmi de diagnosticare, o rețea mare care conține un număr semnificativ de dispozitive poate fi diagnosticată rapid cu puțină sau deloc intervenție umană, reducând astfel costurile și timpii morți în rețea.
Figura 1 este o diagramă care prezintă un mediu 100 informatic pentru diagnosticare de rețea, în conformitate cu un exemplu de realizare a obiectului prezentei invenții. Referitor la Figura 1, mediul 100 informatic poate include un controler 102 de diagnosticare, un dispozitiv 104 de stocare a datelor, nodurile 108-112 de diagnosticare (DN-uri) și un sistem 106 de testat (SUT) care include nodurile și/sau funcțiile de rețea (noduri/funcții) 114-116.
Controlerul 102 de diagnosticare poate reprezenta orice entitate adecvată (de exemplu, una sau mai multe platforme informatice sau un instrument de testare implementate folosind cel puțin un procesor) pentru efectuarea diverselor aspecte legate de diagnosticarea sau rezolvarea problemelor asociate cu SUT 106. Conform unor exemple de realizare concrete, controlerul 102 de diagnosticare poate, de asemenea, efectua testarea SUT 106 sau poate să fie implicat în testarea SUT 106. în unele exemple de realizare, controlerul 102 diagnosticare poate configura unul sau mai multe noduri DN 108-112 pentru a genera și transmite trafic de testare la SUT 106 și/sau pentru a observa traficul în rețea, pentru a genera metrici de legate de trafic și pentru a efectua diagnosticarea pe una sau mai multe porțiuni ale SUT 106. De exemplu, controlerul 102 de diagnosticare și/sau DN-urile 108-112 pot include funcționalități pentru utilizarea script-urilor de testare pentru configurarea uneia sau mai multor testări ale SUT 106 și pot utiliza, de asemenea, script-uri de diagnosticare (de exemplu, într-o interfață de linie de comandă (CLI) legată de limbajul de criptare) ca să se obțină de date de la nodurile sau funcțiile de rețea în SUT 106. în acest 5 a 2015 01028 Μ
22/12/2015 exemplu, flecare script de diagnosticare poate utiliza diferite sintaxe, comenzi și/sau limbaj de programare, pe baza unui tip de nod care va fi diagnosticat și/sau pe baza protocolului sau interfeței de comunicații utilizate.
Dispozitivul 104 de stocare a datelor poate reprezenta orice entitate adaptată (de exemplu, un suport non-tranzitoriu care poate fi citit de calculator, memoria încorporată sau un dispozitiv de memorie) pentru stocarea datelor asociate cu testarea și/sau diagnosticarea. De exemplu, dispozitivul 104 de stocare a datelor poate stoca diverse script-uri de diagnosticare, script-uri de testare, caracteristici de funcționare SUT (de exemplu, informații de configurare, informații despre capacitatea de performanță, informații de resurse interne etc.), informații de conectivitate SUT (de exemplu, informații despre starea legăturii de comunicație, informații despre port, etc), informații de interfață de comunicație legate de SUT (de exemplu, informații sub protocolul de interfață de comunicații referitor la managementul rețelei SUT, informații sub protocolul de management rețea simplă (SNMP), informații sub protocolul de rețea criptografic (SSH), informații sub protocolul de rețea care se folosește în Internet precum și în rețele de calculatoare tip LAN la comunicația textuală, bidirecțională și interactivă,
Telnet, informații sub protocolul de transfer hypertext (HTTP), informații sub protocolul de arhitectură software a rețelei (REST) informații despre interfața pentru programarea de aplicații (API), informații despre proprietatea interfeței pentru programarea de aplicații API, etc.). în unele exemple de realizare, dispozitivul 104 de stocare a datelor poate fi accesat de către controlerul de diagnosticare și/sau de alte entități. în unele exemple, dispozitivul 104 de stocare a datelor poate fi amplasat pe o singură platformă sau dispozitiv informatic sau poate fi distribuit pe mai multe dispozitive sau platforme informatice.
în unele exemple de realizare, controlerul 102 de diagnosticare poate configura un SUT 106 și poate să valideze apoi SUT 106 sau o porțiune a acestuia, cum ar fi elementele individuale de rețea sau de noduri/funcții. în astfel de realizări, această configurație poate, opțional, să fie realizată utilizând un controler SDN sau un controler de proprietate care are una sau mai multe interfețe de programare de aplicații (API) expuse și care este susținută de controlerul 102 de diagnosticare.
în unele exemple de realizare de realizare, controlerul 102 de diagnosticare poate primi informații despre o configurare preexistentă a SUT (de exemplu, de la un v\P a 2015 01028
22/12/2015 controler de rețea sau de la o bază de date aferentă) și poate configura DN-rile 108112 pentru validarea configurației SUT. în unele exemple de realizare, controlerul 102 de diagnosticare poate modifica anumite aspecte ale unei configurații pentru diverse scopuri de testare și măsurare. în astfel de exemple de realizare, controlerul 102 de diagnosticare poate schimba configurația modificată înapoi la configurația sa inițială. SUT 106 poate include nodurile/funcțiile 114-116 și/sau alte entități pentru realizarea uneia sau mai multor funcțiuni sau servicii. De exemplu, SUT 106 poate include nodurile/funcțiile 114-116 pentru conversia pachetelor de date de tip VolP de la un format la alt format, în cazul în care fiecare nod/funcție în SUT 106 îndeplinește una sau mai multe funcții asociate cu transformarea pachetelor de tip VolP. într-un alt exemplu, SUT 106 poate include nodurile/funcțiile 114-116 pentru furnizarea de comunicații media între două rețele. în acest exemplu, nodul/funcția 116 poate îndeplini o funcție firewall și nodul/funcția 114 poate îndeplini o funcție de server media. Fiecare dintre nodurile/funcțiile 114-116 poate reprezenta orice entitate adecvată (de exemplu, software-ul stocat într-o memorie și/sau care este executat folosind cel puțin un procesor) pentru efectuarea uneia sau mai multor funcții de rețea. Fiecare dintre nodurile/funcțiile 114-116 poate fi o construcție logică implementată folosind hardware sau resursele fizice de la una sau mai multe locații, dispozitive și/sau platforme. De exemplu, folosind cel puțin un procesor de pe o primă platformă informatică sau de pe un computer dedicat să fie utilizat ca și server și desemnat să fie instalat într-un cadru de lucru (server rack) și de pe memoria de la o a doua platformă informatică sau server rack, nodul/funcția 116 poate îndeplini funcții de server web, de exemplu, care recepționează cererile prin protocolul de transfer hypertext (HTTP) și care furnizează răspunsuri HTTP. într-un alt exemplu, folosind procesoarele și memoria de la o aceeași platformă informatică sau server rack, nodul/funcția 114 și nodul/funcția 116 pot îndeplini funcții de criptare și respectiv, de decriptare.
Fiecare dintre DN 108-112 poate reprezenta orice entitate adecvată (de exemplu, software-ul stocat într-o memorie și/sau executat folosind cel puțin un procesor) pentru efectuarea diverselor aspecte legate de testarea SUT 106 și/sau de diagnosticare ale diferitelor comunicații sau rețele potențiale, asociate cu SUT 106. De exemplu, DN 108 poate acționa ca un punct final (de exemplu, o aplicație pentru calculator care imită funcționarea unei unități optice CD/DVD (daemon) sau un serviciu care se execută de
a 2015 01028
22/12/2015 cel puțin un procesor) care primește de la controlerul de diagnosticare informații de configurare testare sau un controler de testare și generează trafic în funcție de informațiile de configurare testare recepționate.
în unele exemple de realizare, fiecare dintre DN 108-112 poate fi implementat folosind hardware sau resurse fizice de la una sau mai multe locații, dispozitive, și/sau platforme. De exemplu, DN 110 poate fi implementat pe o platformă informatică aceeași ca și DN 112 și nodul/funcția 116. într-un alt exemplu, DN 110 poate fi implementat pe platforme informatice diferite de DN 112 și de nodul/funcția 116. în unele exemple de realizare, DN-urile 108-112 pot testa diverse noduri/funcții, de exemplu, un nod/funcție de echilibrarea încărcării, un nod/funcție de detectare a intruziunilor, un nod/funcție de protecție Ia intruziune, un nod /funcție antivirus, un nod/funcție firewall, un nod/funcție antispam, un nod de comutație sau un nod/funcție de rutare. în unele exemple de realizare, DNS 108-112 poate acționa sau apărea altor entități, cum ar fi DN-urile, nodurile, funcțiile, rețele sau calculatoarele principale. în unele exemple de realizare, testarea DN 108-112 poate 11 transparentă sau necunoscută de alte entități (de exemplu, nodurile/funcțiile 114-116), în SUT 106. în unele exemple de realizare, DN-urile 108-112 pot fi configurate pentru a genera și/sau transmite trafic de testare pentru testarea SUT 106 sau a unui sau mai multor dintre nodurile/funcțiile 114-116. în unele exemple de realizare, informațiile de generare trafic pot fi determinate pe baza cerințelor de testare, a funcționalității unui nod/funcție și/sau a altor factori. De exemplu, DN 108 poate fi configurat să acționeze ca un generator de trafic pentru testarea nodului/funcției 114 care îndeplinește o funcție firewall. în acest exemplu, controlerul 102 de diagnosticare poate configura DN 108 pentru a genera trafic care pare să provină de la diferite rețele, inclusiv rețelele locale și de la distanță. Continuând cu acest exemplu, DN 108 poate transmite traficul generat de nodul/funcția 114, caz în care un DN 110 ulterior poate analiza ieșirea de la nodul/funcția 114.
în unele exemple de realizare, DN-urile 108-112 pot fi configurate pentru validarea de la un capăt la altul a funcționalității SUT 106. De exemplu, DN 108 poate fi situat la un început de SUT 106 și DN 112 poate fi situat la un capăt final al SUT 106. în acest exemplu, DN 108 poate transmite trafic de testare printr-un port de ieșire la nodul/funcția 114 și apoi, după prelucrare, nodul/funcția 114 poate transmite trafic la a 2015 01028
22/12/2015 nodul/funcția 116 prin DN 110 înainte de a fi trimis de la nodul/funcția 116 la DN 112. Continuând cu acest exemplu, DN 112 poate analiza ieșirea pentru erori sau alte probleme potențiale, pe baza rezultatelor de ieșire așteptate pentru traficul de testare, în unele exemple de realizare, DN-urile 108-112 pot fi configurate să acționeze un dispozitiv hardware care oferă o modalitate de a accesa datele care trec printr-o rețea de calculatoare pentru monitorizarea traficului și/sau observarea comportamentului rețelei. De exemplu, controlerul 102 de diagnosticare poate configura DN 110 pentru a acționa ca un dispozitiv hardware care oferă o modalitate de a accesa datele care trec printr-o rețea în SUT 106, pentru analiza de trafic, copierea traficului, generarea metricilor legate de trafic și/sau altor funcții legate de dispozitivul hardware de rețea, în unele exemple de realizare, DN 108-112 pot fi configurate pentru a efectua funcții de diagnosticare. De exemplu, fiecare dintre DN 108-112 poate fi configurat cu un motor sau un algoritm de diagnosticare capabile de diagnosticarea problemelor asociate cu SUT 106 care comunică cu unul sau mai multe noduri/funcții 114-116 folosind unul sau mai multe protocoale de management sau de comunicații, programe sau interfețe de comunicații. în acest exemplu, algoritmul de diagnosticare poate încerca să comunice utilizând o multitudine de protocoale de comunicații (de exemplu, un protocol de management SNMP sau HTTP) sau mecanisme și poate învăța sau se poate adapta singur în funcție de setările preconfigurate, datele istorice și/sau preferințele utilizatorilor.
în unele exemple de realizare, un motor de diagnosticare sau un algoritm corespunzător poate accesa și interpreta scripturi de diagnosticare capabile să comunice și/sau să facă diagnosticarea problemelor asociate cu diferite tipuri de noduri/funcții. De exemplu, un algoritm de diagnosticare care se execută la DN 108 poate accesa și utiliza diverse scripturi de diagnosticare pentru a comunica (sau pentru a încerca să comunice) cu diferite noduri folosind diferite protocoale de comunicație, în acest exemplu, un prim script de diagnosticare poate fi declanșat de către algoritmul de diagnosticare atunci când se încearcă să se comunice cu ajutorul unui protocol SNMP, un al doilea script de diagnosticare poate fi declanșat de către algoritmul de diagnosticare atunci când se încearcă să se comunice cu ajutorul unui protocol SSH, și tot un al doilea script de diagnosticare poate fi declanșat de către algoritmul de diagnosticare atunci când se încearcă să se comunice cu ajutorul unui protocol HTTP, \ΰ^ a 2015 01028
22/12/2015 un protocol Cmd (protocolul de comenzi IP folosind linia de comandă) sau un protocol criptografic de rețea Bash.
în unele exemple de realizare, un script de diagnosticare poate fi dispozitivul specific. De exemplu, un prim script de diagnosticare ar putea fi pentru comunicație și pentru diagnosticarea problemelor asociate cu nodul/funcția 114 (de exemplu, un nod/funcție firewall sau un dispozitiv de comutație) și un al doilea script de diagnosticare poate fi pentru comunicație și pentru diagnosticarea problemelor asociate cu nodul/funcția 116 (de exemplu, un server web). în acest exemplu, fiecare script de diagnosticare poate solicita diferite tipuri de informații, în funcție de funcționalitatea sau capacitățile nodului/funcției ce va fii diagnosticat.
în unele exemple de realizare, DN-urile 108-112 potfi configurate pentru conectivitatea dinamică (de exemplu, inserarea, activarea sau dezactivarea). De exemplu, DN 108 poate reprezenta o imagine virtuală (de exemplu, un client virtual), care poate fi introdusă în mod dinamic în jurul sau în SUT 106 pe baza diverșilor factori, cum ar fi cerințele de testare, problemele detectate de trafic, condițiile de rețea sau momentul zilei.
în unele exemple de realizare, după ce DN 108-112 sunt instalate în mediul 100 informatic, fiecare dintre DN 108-112 se poate înregistra cu controlerul 102 de diagnosticare sau cu un sistem corespunzător. în unele exemple de realizare, fie în mod automat, fie pe baza datelor introduse de utilizator, controlerul 102 de diagnosticare poate crea o topologie a SUT 106 și poate iniția testarea lui folosind diferite scripturi de trafic la un anumit interval de timp. De exemplu, fiecare script de trafic poate implica diferite tipuri de performanță a traficului tranzitat, de exemplu, care include trafic de voce, video și amestecuri de aplicații.
în unele exemple de realizare, după o fază de simulare a traficului, controlerul 102 de diagnosticare poate fi capabil să determine cu precizie care segment de rețea are probleme de rețea. De exemplu, DC poate primi metrici referitoare la trafic și/sau alte informații de la DN-urile 108-112 și poate analiza aceste informații pentru a determina dacă anumite rute, noduri, funcții și/sau tipuri de trafic nu au acționat cum era de așteptat sau anticipat, de exemplu, pe baza topologiei cunoscute, a informațiilor istorice, a cerințelor sau pragurilor de testare, etc.
a 2015 01028
22/12/2015 în unele exemple de realizare, după detectarea unei sau mai multor probleme, informațiile relevante (de exemplu, informațiile referitoare la testare) pot fi trimise la DN-uri (de exemplu, DN 108-112) care sunt la margini sau într-un anumit traseu sau segment de rețea problematice. Utilizând informațiile recepționate de la controlerul 102 de diagnosticare și/sau alte informații relevante, fiecare dintre DN-uri poate utiliza un motor sau un algoritm de diagnosticare pentru efectuarea de diagnosticări în încercarea de a identifica cauza problemelor detectate și de a oferi soluții potențiale. Detalii suplimentare cu privire la un exemplu de algoritm de diagnosticare este discutat mai jos în legătură cu Figura 2.
Se va aprecia că Figura 1 este pentru scopuri ilustrative și că diferite entități descrise, locațiile și/sau funcțiile lor descrise mai sus în legătură cu Figura 1 pot fi modificate, alterate, adăugate sau eliminate. De exemplu, un dispozitiv (de exemplu, un calculator care include cel puțin un procesor cuplat la o memorie) poate include funcționalitatea nodului/funcției 114 și DN 108.
Figurile 2A-2B reprezintă o diagramă care prezintă un algoritm de diagnosticare în conformitate cu un exemplu de realizare a obiectului descris aici. în unele exemple de realizare, un algoritm de diagnosticare, menționat ca și un algoritm de depanare, poate include logica de program pentru depanarea problemelor asociate cu SUT106 sau cu nodurile/funcțiile acestuia. De exemplu, un algoritm de diagnosticare poate utiliza unul sau mai multe protocoale de comunicații și/sau script-uri automate pentru comunicația cu unul sau mai multe noduri/funcții (de exemplu, nodurile/funcțiile 114-116).
Conform Figurii 2A, în etapa 201, datele de intrare de la testare, de exemplu, metricile legate de trafic, informațiile de stare și/sau alte informații asociate cu SUT 106, pot fi utilizate pentru a deduce, deriva sau determina diverse caracteristici de intrare pentru efectuarea de diagnosticări referitoare la SUT. De exemplu, intrările se pot baza pe rezultatele testelor și/sau pe alte informații și pot include informații prin Internet Protocol (IP) sau prin protocoalele de trafic utilizate (de exemplu, protocolul de control al transmisiei (TCP) și/sau prin protocolul datagramelor de utilizator (UDP)), precum și informații despre problemele potențiale (probleme de conectivitate, probleme de randament, de întârziere de rețea sau de depășire a unui prag acceptabil de bruiaj (jitter) din exterior, întreruperi de conexiuni, semnale proaste Wi-Fi, etc).
(
1° a 2015 01028
22/12/2015 în etapa 202, se poate determina dacă a avut loc o problemă de conectivitate, probabil în timpul testării. De exemplu, atunci când un transfer de date măsurat între punctele finale este mai mic decât o valoare prezisă, pot fi efectuate etape suplimentare pentru a verifica SUT sau o conexiune a unui dispozitiv corespunzător.
în unele exemple de realizare, dacă o problemă de conectivitate a avut loc probabil în timpul testării, se poate efectua etapa 203. în unele exemple de realizare, dacă o problemă de conectivitate a nu a avut loc în timpul testării, se poate realiza etapa 227. în etapa 227, poate fi analizată și/sau verificată disponibilitatea traficului. De exemplu, algoritmul 200 de diagnosticare care se execută la DN 108 poate iniția o comandă traceroute (urmărire traseu) de la punctul final local și poate analiza răspunsul, în etapa 228, poate fi detectat și raportat un dispozitiv care cauzează problema. De exemplu, algoritmul 200 de diagnosticare care se execută la DN 108 poate utiliza un răspuns la o comandă traceroute pentru a detecta un dispozitiv care cauzează probleme de rețea, cum ar fi un dispozitiv ce acționează ca un obstacol de trafic.
La etapa 203, poate fi analizată și/sau verificată conectivitatea (sau lipsa acesteia) la un dispozitiv local (de exemplu, nodul/funcția 114).
în etapa 204, se poate determina dacă există o problemă de conectivitate care implică dispozitivul local. De exemplu, o comandă ping” poate fi realizată utilizând o adresă IP asociată cu dispozitivul local. în acest exemplu, în cazul în care comanda ping” are succes, se poate stabili că nu există probleme de conectivitate, dar în cazul în care comanda ping” eșuează, atunci se poate stabili că există o problemă de conectivitate, în unele exemple de realizare, dacă există o problemă de conectivitate care implică dispozitivul local, poate apărea etapa 205. în unele exemple de realizare, dacă nu există o problemă de conectivitate care implică dispozitivul local, poate să apară etapa 206.
în etapa 205, poate fl raportată o cauză sau un diagnostic, de exemplu, la un utilizator, la un raport de sistem sau la o altă entitate.
în etapa 206, poate fi analizată și/sau verificată conectivitatea la o pereche de noduri (de exemplu, controlerul 102 de diagnosticare, DN 108, DN 110, DN 112, etc.).
La etapa 207, în cazul în care conectivitatea la o pereche de noduri nu poate fi verificată, poate fi detectat și poate fi raportat un dispozitiv de blocare (de exemplu, un dispozitiv intermediar sau firewall).
a 2015 01028
22/12/2015 în etapa 208, se poate determina dacă dispozitivul local este accesibil folosind un protocol SNMP.
La etapa 209, dacă dispozitivul local este accesibil folosind un protocol SNMP, poate fi stabilită o conexiune SNMP.
La etapa 210, se pot determinat posibilele cauze ale unei sau mai multor probleme detectate folosind intrările de la testare și/sau alte informații.
Conform Figurii 2B, în etapa 211, se poate determina dacă informațiile referitoare la dispozitive(de exemplu, nodul) obținute folosind un protocol SNMP sunt utile pentru diagnosticarea unei sau mai multor probleme detectate. De exemplu, informațiile legate de testare și problemele detectate pot fi analizate pentru a determina dacă informațiile se pot obține folosind un protocol SNMP și sunt, probabil, pentru a diagnostica o problemă detectată.
în unele exemple de realizare, dacă informațiile referitoare la dispozitiv obținute folosind un protocol SNMP sunt determinate ca fiind relevante pentru una sau mai multe probleme detectate, poate apărea etapa 212. în unele exemple de realizare, dacă informațiile referitoare la dispozitiv obținute folosind un protocol SNMP sunt determinate ca nefiind relevante pentru una sau mai multe probleme detectate, poate să apară etapa 213.
La etapa 212, pot fi obținute informațiile legate de dispozitiv și poate fi raportată o cauză sau un diagnostic, de exemplu, la un utilizator, la un sistem de raportare sau la o altă entitate. De exemplu, algoritmul 200 de diagnosticare care se execută la DN 108 poate transmite un mesaj de cerere SNMP la nodul/funcția 114 pentru solicitarea de informații de configurare, de informații legate de identificatorul de obiect (OID) și/sau alte informații legate de nodul/funcția 114 și poate fi transmis de la nodul/funcția 114 până la DN 108 un mesaj de răspuns SNMP care conține informațiile solicitate.
La etapa 213, pot fi obținute informațiile referitoare la dispozitiv. De exemplu, algoritmul 200 de diagnosticare care se execută la DN 108 poate stoca informațiile referitoare la dispozitiv obținute folosind SNMP șî poate, de asemenea, încerca să recupereze informațiile suplimentare folosind interfețe de comunicații și/sau alte protocoale de comunicații.
în etapa 214, se poate determina dacă dispozitivul local este accesibil cu ajutorul SSH.
în unele exemple de realizare, dacă informațiile referitoare la dispozitiv obținute
VP a 2015 01028
22/12/2015 folosind SSH sunt determinate ca fiind relevante pentru una sau mai multe probleme detectate, poate apărea etapa 215. în unele exemple de realizare, în cazul în care informațiile referitoare la dispozitiv obținute folosind SSH sunt determinate ca fiind nerelevante pentru una sau mai multe probleme detectate, poate apărea etapa 220.
în etapa 215, poate fi stabilită o sesiune SSH.
în etapa 216, pot fi executate unul sau mai multe script-uri specifice în timpul sesiunii SSH. De exemplu, algoritmul 200 de diagnosticare care se executa la DN 108 poate executa un script care utilizează SSH sau un program relevant sau interfață pentru obținerea de informații la dispozitiv și/sau la dispozitivul bazat pe metrici, în etapa 217, se poate determina dacă informațiile referitoare la dispozitiv obținute folosind SSH sunt relevante pentru una sau mai multe probleme detectate. De exemplu, informațiile referitoare la dispozitiv pot indica probleme de configurare, probleme de hardware și/sau alte probleme care pot afecta capacitatea SUT-ului 106. în unele exemple de realizare, dacă informațiile referitoare la dispozitiv obținute folosind SSH sunt determinate ca fiind relevante pentru una sau mai multe probleme detectate, poate apărea etapa 218. în alte exemple de realizare, în cazul în care informațiile referitoare la dispozitiv obținute folosind SSH sunt determinate ca fiind nerelevante pentru una sau mai multe probleme detectate, poate apărea etapa 219. în etapa 218, poate fi raportată o cauză sau un diagnostic, de exemplu, la un utilizator, la un sistem de raportare sau la o altă entitate.
în etapa 219, o eroare sau un mesaj corespunzător indică faptul că poate fi raportat că nu este găsită o cauză care să detecteze o problemă. în unele exemple de realizare, înainte de raportarea unei erori, pot fi efectuate etape suplimentare de diagnosticare care includ obținerea de informații de la un dispozitiv local folosind interfețe de comunicație și/sau protocoale de comunicații, suplimentare.
în etapa 220, se poate determina dacă dispozitivul local este accesibil folosind o interfață API prin HTTP. în unele exemple de realizare, dacă un dispozitiv local este accesibil folosind o interfață API prin HTTP, poate să apară etapa 221. în unele exemple de realizare, dacă un dispozitiv local nu este accesibil folosind o interfață API prin HTTP, poate să apară etapa 226.
în etapa 221, poate fi stabilită o conexiune HTTP.
a 2015 01028
22/12/2015 în etapa 222, pot fi executate, în timpul conexiunii HTTP, unul sau mai multe script-uri specifice dispozitivului. De exemplu, algoritmul 200 de diagnosticare care se execută la DN 108 poate executa un script care utilizează o interfață API prin HTTP sau un program sau o interfață relevante pentru obținerea de informații la dispozitiv și/sau la dispozitivul bazat pe metrici.
în etapa 223, se poate determina dacă informațiile referitoare la dispozitiv obținute folosind o interfață API prin HTTP sunt relevante pentru una sau mai multe probleme detectate. De exemplu, informațiile referitoare la dispozitiv pot indica probleme de configurare, probleme de hardware și/sau alte probleme care pot afecta capacitatea SUT-ului 106.
în unele exemple de realizare, dacă informațiile referitoare la dispozitiv obținute folosind o interfață API prin HTTP sunt determinate ca fiind relevante pentru una sau mai multe probleme detectate, poate apărea etapa 224. în unele exemple de realizare, în cazul în care informațiile referitoare la dispozitiv obținute folosind o interfață API prin HTTP sunt determinate ca fiind nerelevante pentru una sau mai multe probleme detectate, poate apărea etapa 225.
în etapa 224, poate fi raportată o cauză sau un diagnostic, de exemplu, la un utilizator, la un sistem de raportare sau la o altă entitate.
în etapa 225, o eroare sau un mesaj corespunzător indică faptul că poate fi raportat că nu este găsită o cauză pentru a detecta o problemă. în unele exemple de realizare, înainte de raportarea unei erori, pot fi efectuate etape suplimentare de diagnosticare care includ obținerea de informații de la un dispozitiv local folosind interfețe de comunicație și/sau protocoale de comunicații, suplimentare.
Se va aprecia că Figura 2 este pentru scopuri ilustrative și că acțiuni diferite și/sau suplimentare, altele decât cele descrise în Figura 2, pot fi utilizate pentru diagnosticarea referitoare la SUT. Se va aprecia, de asemenea, că diferite acțiuni descrise aici pot să apară simultan sau într-o ordine sau secvență diferită. De exemplu, algoritmul 200 de diagnosticare poate include aspecte de învățare automată care pot evita utilizarea anumitor protocoale de comunicații, interfețe sau programe bazate pe ratele de succes istorice și/sau bazate pe rezultate care implică tipuri similare de dispozitive pentru a fi diagnosticate. într-un alt exemplu, algoritmul 200 de
a 2015 01028
22/12/2015 diagnosticare poate modifica o comandă prin care mecanismele de comunicație sunt utilizate pentru diferite dispozitive de diagnosticat.
Figura 3 este o diagramă care prezintă comunicațiile asociate cu diagnosticarea de rețea, în conformitate cu un exemplu de realizare a obiectului descris aici. în unele exemple de realizare, controlerul 102 de diagnosticare poate interacționa cu mediul 100 informatic pentru configurarea, previzionarea sau gestionarea DN-urilor 108-112 și/sau testării SUT 106. De exemplu, controlerul 102 de diagnosticare poate utiliza informații de rețea în momentul transmiterii informațiilor de configurare la DN 108-112 pentru testarea SUT 106 și/sau diagnosticarea problemelor asociate cu SUT 106. în unele exemple de realizare, controlerul 102 de diagnosticare poate configura DN 108 și 112 pentru testarea SUT 106 într-o rețea reală. De exemplu, SUT 106 poate fi configurat pentru a procesa și/sau ruta traficul de date (de exemplu, de tip voce, video, și/sau trafic de aplicații) a unui număr de utilizatori într-o rețea reală. în acest exemplu, controlerul 102 de diagnosticare poate configura DN 108 pentru a simula trafic în rețeaua reală. Continuând cu acest exemplu, DN-urile 108 și 112 pot fi configurate pentru a observa traficul simulat și/sau traficul non-simulat și pentru a genera metrici de trafic despre traficul observat.
în unele exemple de realizare, controlerul 102 de diagnosticare poate analiza metricile referitoare la trafic și/sau alte informații de la DNS 108 și 112 pentru a determina dacă există probleme la SUT. Dacă există o problemă la SUT, controlerul 102 de diagnosticare poate oferi instrucțiuni și/sau alte informații DN-urilor 108 și 112 pentru obținerea de informații suplimentare de la elemente individuale (de exemplu, nodurile/funcțiile 114-116) în SUT 106. De exemplu, fiecare DN 108 și 112 poate efectua interogarea nodurilor/funcțiilor 114-116 folosind un algoritm de diagnosticare sau script-uri de diagnosticare conexe.
Conform Figurii 3, în etapa 3001, pot fi trimise de la controlerul 102 de diagnosticare la DN 108, informații de configurare testare (de exemplu, informații de configurare), în etapa 3002, informațiile de configurare testare pot fi transmise de la DN 108 la DN 112 și/sau la alte DN-uri, în mediul 100 informatic la SUT 106.
în etapa 3003, traficul de testare sau simulat poate fi trimis de la DN 108 la DN 112 prin SUT 106. De exemplu, DN 108 poate acționa ca un trafic generat și poate \C$ a 2015 01028
22/12/2015 transmite numeroase tipuri de pachete de date care simulează una sau mai multe sesiuni de comunicație.
I în etapa 3004, după testare, rezultatele testelor pot fi trimise de la DN 108 la controlerul 102 de diagnosticare. De exemplu, DN 108 poate colecta metricile de trafic de la DN 112 și/sau poate genera rezultatele testelor pe baza acestor metrici de trafic și/sau a altor date de la diverse surse.
în etapa 3005, controlerul 102 de diagnosticare poate analiza rezultatele testelor și/sau alte informații pentru a determina dacă există una sau mai multe probleme asociate cu SUT 106. De exemplu, controlerul 102 de diagnosticare poate utiliza rezultatele testelor și poate consulta dispozitivul 104 de stocare a datelor despre informații de topologie de rețea relevante și/sau despre informațiile de configurare SUT. în unele exemple de realizare de realizare, controlerul 102 de diagnosticare poate determina că există o problemă potențială asociată cu SUT 106 și poate încerca să declanșeze diagnosticarea. De exemplu, controlerul 102 de diagnosticare poate transmite un mesaj legat de diagnosticare sau informații corespunzătoare la DN 108 si/sau la DN 112 pentru obținerea informațiilor de stare si/sau a altor date de la SUT 106 sau de la nodul/functia 114.
I în etapa 3006, informațiile legate de diagnosticare pot fi trimise de la controlerul 102 de diagnosticare la DN 108 pentru obținerea informațiilor de stare de la nodul/funcția
114.
în etapa 3007, informațiile legate de diagnosticare pot fi transmise de la DN 108 la DN 112 si/sau la alt DN-uri în mediul 100 informatic sau la SUT 106.
I
La etapa 3008, DN 112 poate executa un algoritm de diagnosticare pentru obținerea de informații de stare si/sau a altor informații de la nodul/functia 114. în unele exemple de realizare, un algoritm de diagnosticare poate include numeroase scripturi și/sau logica de program pentru a încerca să comunice cu mai multe noduri de rețea, cu mai multe funcții de rețea sau cu entități asociate. De exemplu, un algoritm de diagnosticare poate încerca să solicite informații de stare și/sau alte date de la nodul/funcția 114 folosind o serie sau un set de protocoale de comunicații, în etapa 3009, poate să nu fie stabilită o legătură între DN 112 și nodul/funcția 114. De exemplu, comunicațiile efectuate de DN 112 la nodul/funcția 114 pot fi blocate sau eliminate de către un firewall care intervine, situat între DN 112 si nodul/functia 114.
a 2015 01028
22/12/2015 în etapa 3010, DN 108 poate executa un algoritm de diagnosticare pentru obținerea de informații de stare și/sau a altor informații de la nodul/funcția 114. în etapa 3011, poate fi stabilită o conexiune legată de SNMP între DN 108 și nodul/funcția 114.
în etapa 3012, poate fi trimis un mesaj de solicitare SNMP de la DN 108 la nodul/funcția 114. De exemplu, un mesaj de solicitare SNMP poate cere informații de stare și/sau alte informații de la o baza de date referitoare la managementul rețelei.
în etapa 3013, poate fi trimis un mesaj de răspuns SNMP de la nodul/funcția 114 la DN 108. De exemplu, un mesaj de răspuns SNMP poate furniza informații de stare și/sau alte informații despre nodul/funcția 114.
în etapa 3014, DN 108 poate stabili dacă sunt necesare informații suplimentare de la nodul/funcția 114. Dacă este așa, DN 108 sau un algoritmul de diagnosticare asociat poate determina să se utilizeze un alt protocol de comunicații și/sau un alt script specific dispozitivului, pentru a obține informații suplimentare.
în etapa 3015, poate fi stabilită o conexiune legată de SSH între DN 108 și nodul/funcția 114.
în etapa 3016, una sau mai multe comenzi SSH pot fi trimise de la DN 108 la nodul/funcția 114 pentru obținerea de informații diverse despre nodul/funcția 114. De exemplu, în timpul unei sesiuni SSH, o comandă SSH poate solicita diverse metrice de procesare asociate cu traficul de testare.
în etapa 3017, informațiile pot fi trimise de la nodul/funcția 114 la DN 108 pentru a indica posibile cauze ale unei sau mai multor probleme referitoare la SUT 106. De exemplu, ca răspuns la o comandă SSH pentru informațiile de stare, un router poate indica o problemă cauzată de faptul că un tabel de rutare este complet, fiind în imposibilitatea de a curății intrările.
în etapa 3018, poate Fi transmis la controlerul 102 de diagnosticare, un raport de diagnosticare sau informații asociate. De exemplu, controlerul 102 de diagnosticare poate primi rapoarte multiple de diagnosticare de la unul sau mai multe DN-uri 108112 și poate utiliza aceste rapoarte la generarea unui raport de diagnosticare SUT. în acest exemplu, raportul de diagnosticare SUT poate indica faptul că SUT 106 a prezentat o problemă de trafic cauzată de greșelile de configurare a ale portului de rețea la nodul/funcția 114 și poate indica o posibilă soluție în cazul în care un anumit a 2015 01028
22/12/2015 trafic de aplicație este transmis la numerele de port 3453 sau 6785 în loc de numărul de port 8080, port care primește de asemenea traficul HTTP criptat. într-un alt exemplu, raportul de diagnosticare SUT poate indica faptul că SUT 106 a prezentat o problemă de lățime de bandă sau congestionare cauzată de eșecuri ale legăturii de comunicație într-un grup de agregare asociat cu nodul/funcția 116 și poate indica o posibilă soluție în cazul în care legăturile de comunicație sunt inspectate sau înlocuite. Se va aprecia că acțiunile și/sau comunicațiile reprezentate în Figura 3 sunt pentru scop ilustrativ și că diferite acțiuni și/sau comunicații altele decât cele descrise în Figura 3 pot fi utilizate suplimentar pentru testarea SUT 106 și/sau pentru diagnosticarea problemelor asociate cu SUT 106. Se va aprecia de asemenea că diversele comunicații și/sau a acțiuni descrise aici pot să apară simultan sau într-o ordine sau secvență diferită. De exemplu, etapa 3008 se poate produce concomitent cu etapa 3010.
Figura 4 este o diagramă care prezintă comunicațiile asociate cu diagnosticarea de rețea, conform unui alt exemplu de realizare a obiectului descris aici. în unele exemple de realizare, controlerul 102 de diagnosticare poate interacționa cu mediul 100 informatic pentru configurarea, previzionarea sau gestionarea DN 108-112 și/sau testarea SUT 106. De exemplu, controlerul 102 de diagnosticare poate utiliza informațiile de rețea la transmiterea de informații de configurare la DN 108-112 pentru testarea SUT 106 și/sau pentru diagnosticarea problemelor referitoare la SUT 106. în unele exemple de realizare, controlerul 102 de diagnosticare poate configura DN 108-112 pentru testarea SUT 106 într-o rețea reală. De exemplu, SUT 106 poate fi configurat pentru a procesa și/sau ruta traficul de date (de exemplu, de tip voce, video, și/sau trafic de aplicații) a unui număr de utilizatori într-o rețea reală. în acest exemplu, controlerul 102 de diagnosticare poate configura DN 108 pentru a simula traficul în rețeaua reală. Continuând cu acest exemplu, DN-urile 108-112 pot fi configurate pentru a observa traficul simulat și/sau traficul non-simulat și pentru a genera metrici asociate cu traficul care afectează aproximativ traficul observat.
în unele exemple de realizare de realizare, controlerul 102 de diagnosticare poate primi metrici legate de trafic și/sau alte informații de la DN-urile 108-112 pentru a analiza și determina dacă există probleme SUT. Dacă există o problemă la SUT, controlerul 102 de diagnosticare poate oferi instrucțiuni și/sau alte informații la unul
a 2015 01028
22/12/2015 sau mai multe DN-uri 108-112 pentru obținerea de informații suplimentare de la elemente individuale (de exemplu, noduri/funcții 114-116) în SUT 106. De exemplu, fiecare dintre DN-urile 108-112 poate efectua interogarea de noduri/funcții 114-116 folosind un algoritm de diagnosticare sau script-uri de diagnosticare conexe.
Conform Figurii 4, în etapa 4001, controlerul 102 de diagnosticare poate configura DN 108 ca și un client virtual. De exemplu, un client virtual (de exemplu, software-ul rulat de un procesor) poate acționa ca și un generator de trafic pentru generarea și transmiterea traficului de testare la SUT 106.
în etapa 4002, controlerul 102 de diagnosticare poate configura DN 110 ca un dispozitiv hardware virtual. De exemplu, dispozitiv hardware virtual (cum ar fi softwareul rulat de un un procesor) poate acționa ca dispozitiv hardware de rețea și poate monitoriza traficul care traversează DN 110.
în etapa 4003, controlerul 102 de diagnosticare poate declanșa ca DN 108 să înceapă transmiterea traficului de testare. De exemplu, controlerul 102 de diagnosticare poate transmite informații de configurare care indică pachetele de testare de transmis la SUT 106 sau la porțiuni ale acestuia.
în unele exemple de realizare, după ce a primit o comandă de declanșare de la controlerul 102 de diagnosticare începe testarea, pachetele de testare potfi generate și transmise de la DN 108 la nodul/funcția 114 și procesate. După procesare, pachetele de testare pot fi transmise de la nodul/funcția 114 la nodul/funcția 116 prin DN 110. Continuând cu acest exemplu, pachetele de răspuns pot fi generate și transmise de la nodul/funcția 116 la nodul/funcția 114 prin DN 110 și apoi de la nodul/funcția 114 la DN 108.
în unele exemple de realizare, DN-urile 108-110 sau logica de program a acestora pot monitoriza datele de trafic transmise și/sau genera metrici referitoare la trafic pentru diagnosticarea potențialelor probleme asociate cu SUT 106.
în etapa 4004, legătura de comunicație observată și/sau metricile de trafic pot fi transmise de la DN 110 la controlerul 102 de diagnosticare. De exemplu, după ce testarea este completă sau la intervale periodice, informațiile legate de testare (de exemplu, latență, bruiaj (jitter), etc.) potfi calculate de DN 110 și raportate la controlerul 102 de diagnosticare.
a 2015 01028
22/12/2015 în etapa 4005, legătura de comunicație observată și/sau metricile de trafic pot fi transmise de la DN 108 la la controlerul 102 de diagnosticare. De exemplu, după ce testarea este completă sau la intervale periodice, informațiile legate de testare (de exemplu, latență, bruiaj (jitter), etc.) pot fi calculate de DN 108 și raportate la controlerul 102 de diagnosticare.
în etapa 4006, controlerul 102 de diagnosticare poate analiza link-ul recepționat și/sau metricile de trafic pentru a identifica comportamentul anormal (de exemplu, una sau mai multe probleme). De exemplu, controlerul 102 de diagnosticare poate determina care jitter asociat cu nodul/funcția 114 a fost semnificativ mai mare decât se aștepta sau care nod/funcție 116 nu pare să genereze pachete de răspuns adecvate.
La etapa 4007, în cazul în care este detectat un comportament anormal, controlerul 102 de diagnosticare poate determina care nod/funcție să aleagă sau să interogheze pentru informații suplimentare. De exemplu, controlerul 102 de diagnosticare poate utiliza logica de program, informații despre SUT și/sau informații de rețea (de exemplu, informații de topologie de rețea) pentru a face propriile determinări.
în etapa 4008, controlerul 102 de diagnosticare poate interoga (de exemplu, cerere și/sau sondaj) nodul/funcția 114 pentru informațiile de stare, metricile de trafic și/sau pentru alte informații care pot fi utile in diagnosticarea comportamentului anormal. De exemplu, controlerul 102 de diagnosticare poate utiliza un script și/sau un algoritm de diagnosticare care încearcă să obțină informații de stare de la nodul/funcția 114 folosind mai multe protocoale și/sau mecanisme (de exemplu, SNMP, o interfață REST HTTP API, comenzi SHH, etc.) în etapa 4009, controlerul 102 de diagnosticare poate interoga (de exemplu, cerere și/sau sondaj) nodul/funcția 116 pentru informațiile de stare, metricile de trafic și/sau pentru alte informații care pot 11 utile in diagnosticarea comportamentului anormal. De exemplu, controlerul 102 de diagnosticare poate utiliza un script și/sau un algoritm de diagnosticare care încearcă să obțină informații de stare de la nodul/funcția 116 folosind mai multe protocoale și/sau mecanisme (de exemplu, SNMP, o interfață REST HTTP API, comenzi SHH, etc.) în etapa 4010, controlerul 102 de diagnosticare poate utiliza informațiile obținute (de exemplu, Informații de stare și informații de monitorizare comportament de rețea) a 2015 01028
22/12/2015 pentru a genera un raport de diagnosticare SUTcare include sugerarea soluțiilor la problemele identificate.
Se va aprecia că acțiunile și/sau comunicațiile reprezentate în Figura 4 sunt pentru scop ilustrativ și că diferite alte comunicații și/sau acțiuni, altele decât cele descrise în Figura 4, pot fi utilizate suplimentar pentru testarea SUT 106 și/sau pentru diagnosticarea problemelor asociate cu SUT 106. Se va aprecia de asemenea că diversele comunicații și/sau a acțiuni descrise aici pot să apară simultan sau într-o ordine sau secvență diferită.
Figura 5 este o diagramă care prezintă o metodă 500 pentru diagnosticarea rețelei, în conformitate cu un exemplu de realizare a obiectului descris aici. în unele exemple de realizare, metoda 500 sau porțiuni ale acesteia poate fi efectuată de către sau la controlerul 102 de diagnosticare și/sau de către sau la un alt nod sau modul (de exemplu, un controler de diagnosticare). în unele exemple de realizare, metoda 500 poate include etapele 502, 504 și/sau 506.
Conform metodei 500, în etapa 502, pot fi configurate o multitudine de noduri de diagnosticare pentru a observa comportamentul traficului asociat cu un SUT. De exemplu, controlerul 102 de diagnosticare poate transmite informații de configurare la DN 108 și DN 112 pentru testarea și diagnosticarea la SUT 106 a oricăror probleme detectate asociate SUT 106.
în unele exemple de realizare, configurarea unei multitudini de noduri de diagnosticare poate include utilizarea informațiilor de configurare a rețelei sau a informațiilor despre topologia SUT.
în unele exemple de realizare, configurarea unei multitudini de noduri de diagnosticare include configurarea unui dispozitiv hardware de rețea pentru monitorizarea traficului de rețea în SUT.
în unele exemple de realizare, configurarea unei multitudini de noduri de diagnosticare poate include configurarea unui nod dintre nodurile de diagnosticare pentru a transmite trafic de testare și configurarea la cel puțin unul dintre nodurile de diagnosticare pentru a genera metrici de trafic asociate cu traficul de testare.
La etapa 504, comportamentul traficului asociat cu SUT poate fi observat cu ajutorul nodurilor de diagnosticare. De exemplu, nodul 108 de diagnosticare poate observa
a 2015 01028
22/12/2015 mesajele de răspuns de la nodul/funcția 116 la traficul inițial prin el și nodul 112 de diagnosticare poate observa mesajele de solicitare de la nodul/funcția 114. în etapa 506, o problemă SUT poate fi detectată cu ajutorul comportamentului traficului. De exemplu, folosind metricile de trafic obținute de la DN 108 și DN 112, controlerul 102 de diagnosticare poate stabili că 30% din traficul transmis de DN 108 nu răspunde.
în etapa 508, poate fi identificat un nod de rețea în SUT asociat cu problema SUT, cu ajutorul informațiilor despre topologia SUT. De exemplu, după stabilirea că răspunsurile nu sunt recepționate pentru traficul transmis de DN 108, controlerul 102 de diagnosticare poate determina care nod/funcție 114 și nod/funcție 116 pot fi asociate cu această problemă SUT.
în unele exemple de realizare, un nod de rețea poate include un nod de echilibrare a încărcării, un nod de detectare a intruziunilor, un nod de prevenirea intruziunilor, un nod antivirus, un nod antispam, un nod firewall, un nod de comutație sau un nod de rutare.
în etapa 510, unul dintre nodurile de diagnosticare poate fi declanșat pentru a obține informații referitoare la nod de la nodul de rețea. Nodul de diagnosticare poate folosi cel puțin un protocol de management sau de comunicație pentru a alege nodul de rețea pentru informațiile referitoare la nod. Câteva exemple de informații legate de nod (de exemplu, informații legate de dispozitiv) pot include informațiile de configurare, informațiile de topologie, informații de securitate, protocoalele de comunicații suportate, tipuri de memorie, utilizarea memoriei, disponibilitatea de memorie, informații de producător, date de construcție, tip procesor, utilizare procesor, disponibilitate procesor, versiunea sistemului de operare, versiunea de firmware, metrici legate de nod, metrici de randament, metrici de performanță, metrici de eroare, informații de stare, statutul actual al lungimii, capacitatea de stocare, utilizarea spațiului de stocare, informații de conectivitate (de exemplu, informații de port, informații de legătură de comunicație, etc.), informații de rutare sau informații de memorie tampon, în unele exemple de realizare, cel puțin un management sau protocol de comunicații poate include SNMP, SSH, Telnet, un protocol CLI, HTTP, și/sau REST. în unele exemple de realizare, interogarea unui nod de rețea pentru informații asociate nodului poate include determinarea dacă un prim protocol de comunicații este utilizabil
a 2015 01028
22/12/2015 pentru comunicația cu nodul de rețea în SUT și ca răspuns la determinarea faptului că primul protocol de comunicații este utilizabil pentru comunicația cu nodul de rețea în SUT, solicitarea, de la nodul de rețea, a informațiilor referitoare la nodul care folosește primul protocol de comunicații.
în unele exemple de realizare, interogarea unui nod de rețea pentru informații referitoare la nod poate include, de asemenea, determinarea dacă un al doilea protocol de comunicații este utilizabil pentru comunicația cu nodul de rețea în SUT și ca răspuns la determinarea faptului că al doilea protocolul de comunicație este utilizabil pentru comunicația cu nodul de rețea în SUT, solicitarea, de la nodul de rețea, a informațiilor referitoare la nodul care folosește al doilea protocol de comunicație.
în etapa 512, problema SUT poate fi diagnosticată folosind informațiile referitoare la nod. De exemplu, folosind SSH sau o interfață API prin HTTP, controlerul 102 de diagnosticare poate prelua metricile de performanță asociate cu nodul/funcția 114, de exemplu, un nod de rutare. în acest exemplu, metricile de performanță pot indica o scădere semnificativă a performanței până la de două ori în timpul testării. în acest exemplu, controlerul 102 de diagnosticare poate utiliza aceste informații împreună cu informațiile despre ce tip de trafic a fost transmis în acest timp, pentru a determina că acel nod/funcție 114 a fost configurat greșit și, ca atare, nu a reușit să ruteze în mod corespunzător traficul prin protocolul de inițiere a sesiunii (SIP).
în unele exemple de realizare, diagnosticarea unei probleme SUT poate include generarea unui raport de diagnosticare care indică problema SUT și cel puțin o potențială soluție. De exemplu, ca răspuns la determinarea că acel nod/funcție 114 a fost configurat greșit și nu a reușit să ruteze în mod corespunzător traficul prin protocolul de inițiere a sesiunii (SIP), controlerul de diagnosticare poate indica, într-un raport de diagnosticare, că o soluție potențială pentru greșelile de configurare este aceea de a adăuga intrări de rutare la nodul/funcția 114 pentru rutarea traficului SIP. Se va aprecia că metoda 500 este pentru scopuri ilustrative și că pot fi utilizate acțiuni diferite și/sau suplimentare. Se va aprecia de asemenea că diferite acțiuni descrise aici pot să apară într-o ordine sau secvență diferită.
Trebuie remarcat faptul că menționatul controler 102 de diagnosticare și/sau funcționalitatea descrisă aici poate constitui un dispozitiv informatic cu scop special.
Mai mult, controlerul 102 de diagnosticare și/sau funcționalitatea descrisă aici pot ^1/
2015 01028
22/12/2015 îmbunătăți domeniul tehnologic de diagnosticare de rețea prin furnizarea de mecanisme de testare automate a SUT 106 și diagnosticarea problemelor referitoare la SUT 106. Mai mult, controlerul 102 de diagnosticare și/sau funcționalitatea descrisă aici poate îmbunătăți domeniul tehnologic de diagnosticare de rețea prin furnizarea de mecanisme pentru obținerea informațiilor de stare și/sau a altor informații de la nodurile/funcțiile 114-116 în SUT 106, folosind un algoritm de diagnosticare care încearcă să comunice cu ajutorul unui sau mai multor protocoale de comunicație.
Se va înțelege că diferite detalii ale obiectului prezentei invenții pot fi modificate fără a ne îndepărta de la scopul invenției. în plus, descrierea de maî sus este pentru a prezenta scopul și nu în scopul limitării, astfel că invenția revendicată este definită prin revendicările enunțate mai jos.

Claims (20)

  1. REVENDICĂRI
    1. Metodă de diagnosticare rețea, care, la un controler de diagnosticare implementat care folosește cel puțin un procesor, constă în::
    - configurarea unei multitudini de noduri de diagnosticare pentru a observa comportamentul traficului de date asociat cu un sistem de testat (SUT);
    - observarea, folosind nodurile de diagnosticare, a comportamentul traficului de date asociat cu SUT;
    - detectarea, folosind comportamentul traficului de date, a problemei SUT;
    - identificarea, folosind informații despre topologia SUT, a unui nod de rețea în SUT asociat cu problema SUT;
    - declanșarea ca un nod dintre nodurile de diagnosticare să obțină informații referitoare la nod de la nodul de rețea, în care nodul de diagnosticare folosește cel puțin un protocol de comunicație pentru a interoga nodul de rețea despre informațiile legate de acesta;
    - diagnosticarea, folosind datele referitoare la nod, a problemei SUT.
  2. 2. Metodă, conform revendicării 1, caracterizată prin aceea că menționata configurare a multitudinii de noduri de diagnosticare include configurarea unui nod dintre nodurile de diagnosticare pentru a transmite trafic de testare și configurarea a cel puțin un nod dintre nodurile de diagnosticare pentru a genera metrici de trafic asociate cu traficul de testare.
  3. 3. Metodă, conform revendicării 1, caracterizată prin aceea că protocolul de comunicație include cel puțin un protocol de management simplu de rețea (SNMP), un protocol criptografic de rețea (SSH), un protocolul Teinet, un protocol de interfață de linie de comandă (CLI), un protocol de transfer hypertext (HTTP) sau un protocol de arhitectură software a rețelei (REST).
  4. 4. Metodă, conform revendicării 1, caracterizată prin aceea că interogarea nodului de rețea pentru informațiile referitoare la nod, constă în:
    - determinarea dacă un prim protocol de comunicații este utilizabil pentru comunicația cu nodul de rețea în SUT; și
    - ca răspuns la determinarea faptului că primul protocol de comunicații este utilizabil pentru comunicația cu nodul de rețea în SUT, solicitarea,
    Φ a 2015 01028
    22/12/2015 de la nodul de rețea, a informațiilor referitoare la nodul care folosește primul protocol de comunicații.
  5. 5. Metodă, conform revendicării 4, caracterizată prin aceea că mai constă ;
    - determinarea dacă un al doilea protocol de comunicații este utilizabil pentru comunicația cu nodul de rețea în SUT; și
    - ca răspuns la determinarea faptului că al doilea protocol de comunicații este utilizabil pentru comunicația cu nodul de rețea în SUT, solicitarea, de la nodul de rețea, a informațiilor referitoare nodul care folosește al doilea protocol de comunicații.
  6. 6. Metodă, conform revendicării 1, caracterizată prin aceea că menționata configurare a multitudinii de noduri de diagnosticare include folosirea informațiilor de configurare a rețelei sau a informațiilor despre topologia SUT.
  7. 7. Metodă, conform revendicării 1, caracterizată prin aceea că menționata configurare a multitudinii de noduri de diagnosticare include configurarea unui dispozitiv hardware de rețea care permite trafic de date pentru monitorizarea traficului de rețea în SUT.
  8. 8. Metodă, conform revendicării 1, caracterizată prin aceea că diagnosticarea problemei SUT include generarea unui raport de diagnosticare care indică problema SUT și cel puțin o soluție posibilă.
  9. 9. Metodă, conform revendicării 1, caracterizată prin aceea că nodul de rețea include un nod de echilibrare a încărcării, un nod de detectare a intruziunilor, un nod de prevenirea intruziunilor, un nod antivirus, un nod antispam, un nod firewall, un nod de comutație sau un nod de rutare.
  10. 10.Sistem de diagnosticare de rețea, care, la cel puțin un procesor, conține:
    - un controler de diagnosticare implementat care folosește cel puțin un procesor, în care controlerul de diagnosticare este configurat pentru a configura o multitudine de noduri de diagnosticare pentru a observa comportamentul traficului de date asociat cu un sistem de testat (SUT), pentru a observa, folosind nodurile de diagnosticare, comportamentul traficului asociat cu SUT, pentru a detecta, folosind comportamentul traficului, o problemă SUT, pentru a identifica, folosind informații despre topologia SUT, un nod de rețea în SUT asociat cu problema SUT, pentru 27 a 2015 01028
    22/12/2015 a declanșa ca unul dintre nodurile de diagnosticare să obțină informații referitoare la nod de la nodul de rețea, în care nodul de diagnosticare folosește cel puțin un protocol de comunicații pentru a interoga nodul rețelei despre informațiile legate de nod și pentru a diagnostica, folosind informațiile legate de nod, problema SUT.
  11. 11. Sistem, conform revendicării 10, caracterizat prin aceea că menționatul controler de diagnosticare este configurat pentru a configura unul dintre nodurile de diagnosticare pentru a transmite trafic de testare și pentru a configura cel puțin unul din multitudinea de noduri de diagnosticare să genereze metrici de trafic asociate cu traficul de testare.
  12. 12.Sistem, conform revendicării 10, caracterizat prin aceea că protocolul de comunicație include cel puțin un protocol de management simplu de rețea (SNMP), un protocol criptografic de rețea (SSH), un protocolul Telnet, un protocol de interfață de linie de comandă (CLI), un protocol de transfer hypertext (HTTP) sau un protocol de arhitectură software a rețelei (REST).
  13. 13.Sistem, conform revendicării 1 caracterizat prin aceea că, menționatul controler de diagnosticare este configurat pentru a determina dacă un prim protocol de comunicații este utilizabil pentru comunicația cu nodul de rețea în SUT și ca răspuns la determinarea faptului că primul protocol de comunicații este utilizabil pentru comunicația cu nodul de rețea în SUT, solicitarea, de la nodul de rețea, a informațiilor referitoare la nodul care folosește primul protocol de comunicații.
  14. 14. Sistem, conform revendicării 13, caracterizat prin aceea că menționatul controler de diagnosticare este configurat pentru a determina dacă un al doilea protocol de comunicații este utilizabil pentru comunicația cu nodul de rețea în SUT și ca răspuns la determinarea faptului că al doilea protocol de comunicații este utilizabil pentru comunicația cu nodul de rețea în SUT, solicitarea, de la nodul de rețea, a informațiilor referitoare la nodul care folosește al doilea protocol de comunicații.
  15. 15.Sistem, conform revendicării 10, caracterizat prin aceea că menționata configurare a multitudinii de noduri de diagnosticare include folosirea informațiilor de configurare a rețelei sau informațiile despre topologia SUT.
    a 2015 01028
    22/12/2015
  16. 16. Sistem, conform revendicării 10, caracterizat prin aceea că menționatul controler de diagnosticare este configurat pentru a configura un dispozitiv hardware de rețea care permite trafic de date pentru monitorizarea traficului de rețea în SUT.
  17. 17.Sistem, conform revendicării 10, caracterizat prin aceea că menționatul controler de diagnosticare este configurat pentru a genera un raport de diagnosticare care indică problema SUT și cel puțin o soluție posibilă.
  18. 18.Sistem, conform revendicării 10, caracterizat prin aceea că nodul de rețea include un nod de echilibrare a încărcării, un nod de detectare a intruziunilor, un nod de prevenirea intruziunilor, un nod antivirus, un nod antispam, un nod firewall, un nod de comutație sau un nod de rutare.
  19. 19.Suport non tranzitoriu citibil de calculator care are stocate instrucțiuni executabile de calculator, astfel că, atunci când sunt executate de procesor, comandă calculatorul să efectueze etapele care constau în:
    - configurarea unei multitudini de noduri de diagnosticare pentru a observa comportamentul traficului de date asociat cu un sistem de testat (SUT);
    - observarea, folosind nodurile de diagnosticare, a comportamentul traficului de date asociat cu SUT;
    - detectarea, folosind comportamentul traficului de date, a problemei SUT;
    - identificarea, folosind informații despre topologia SUT, a unui nod de rețea în SUT asociat cu problema SUT;
    - declanșarea ca un nod dintre nodurile de diagnosticare să obțină informații referitoare la nod de la nodul de rețea, în care nodul de diagnosticare folosește cel puțin un protocol de comunicație pentru a interoga nodul de rețea despre informațiile legate de acesta;
    - .diagnosticarea, folosind datele referitoare la nod, a problemei SUT.
  20. 20. Suport non tranzitoriu citibil de calculator, conform revendicării 19, caracterizat prin aceea că menționata configurare a multitudinii de noduri de diagnosticare include configurarea unui nod dintre nodurile de diagnosticare pentru a transmite trafic de testare și configurarea a cel puțin unui nod dintre nodurile de diagnosticare pentru a genera metrici de trafic asociate cu traficul de testare.
ROA201501028A 2015-12-22 2015-12-22 Metode, sisteme şi suport citibil de calculator pentru diagnosticarea reţelei RO132010A2 (ro)

Priority Applications (2)

Application Number Priority Date Filing Date Title
ROA201501028A RO132010A2 (ro) 2015-12-22 2015-12-22 Metode, sisteme şi suport citibil de calculator pentru diagnosticarea reţelei
US14/984,459 US10425320B2 (en) 2015-12-22 2015-12-30 Methods, systems, and computer readable media for network diagnostics

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ROA201501028A RO132010A2 (ro) 2015-12-22 2015-12-22 Metode, sisteme şi suport citibil de calculator pentru diagnosticarea reţelei

Publications (1)

Publication Number Publication Date
RO132010A2 true RO132010A2 (ro) 2017-06-30

Family

ID=59063912

Family Applications (1)

Application Number Title Priority Date Filing Date
ROA201501028A RO132010A2 (ro) 2015-12-22 2015-12-22 Metode, sisteme şi suport citibil de calculator pentru diagnosticarea reţelei

Country Status (2)

Country Link
US (1) US10425320B2 (ro)
RO (1) RO132010A2 (ro)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6097889B2 (ja) * 2014-07-28 2017-03-15 株式会社日立製作所 監視システム、監視装置、および検査装置
US10511516B2 (en) 2016-08-29 2019-12-17 Keysight Technologies Singapore (Sales) Pte. Ltd. Methods, systems and computer readable media for quiescence-informed network testing
US10594720B2 (en) * 2017-11-03 2020-03-17 International Business Machines Corporation Exercising security control point (SCP) capabilities on live systems based on internal validation processing
US20190319881A1 (en) * 2018-04-13 2019-10-17 Microsoft Technology Licensing, Llc Traffic management based on past traffic arrival patterns
US11552874B1 (en) 2019-01-18 2023-01-10 Keysight Technologies, Inc. Methods, systems and computer readable media for proactive network testing
US10353804B1 (en) * 2019-01-22 2019-07-16 Capital One Services, Llc Performance engineering platform and metric management
DE102019203352A1 (de) * 2019-03-12 2020-09-17 Robert Bosch Gmbh Verfahren und Vorrichtung zum Betreiben eines Kommunikationssystems
CN110071848B (zh) * 2019-03-27 2020-12-08 武汉思普崚技术有限公司 自动化测试命令行命令的方法、设备及存储介质
US11502932B2 (en) * 2019-05-17 2022-11-15 Keysight Technologies, Inc. Indirect testing using impairment rules
US11469942B2 (en) 2019-08-15 2022-10-11 At&T Intellectual Property I, L.P. System and method for SDN orchestration validation
CN110535725B (zh) * 2019-08-28 2021-10-29 网宿科技股份有限公司 一种企业网络测试方法及装置
US11621908B2 (en) 2020-07-13 2023-04-04 Keysight Technologies, Inc. Methods, systems and computer readable media for stateless service traffic generation
CN111736924B (zh) * 2020-08-18 2020-12-15 江苏神彩科技股份有限公司 基于Lua脚本接入数采仪的方法、装置、设备及介质
US11388081B1 (en) 2021-03-30 2022-07-12 Keysight Technologies, Inc. Methods, systems, and computer readable media for impairment testing using an impairment device
US20230262000A1 (en) * 2022-02-17 2023-08-17 Saudi Arabian Oil Company System and method for maintaining communication service quality in a network
US11876686B2 (en) * 2022-03-31 2024-01-16 Keysight Technologies, Inc. Methods, systems, and computer readable media for conducting a network traffic simulation using hypertext transfer protocol archive data
CN115396348B (zh) * 2022-08-25 2024-05-10 北京智芯微电子科技有限公司 无线传感器网络的测试***、方法及计算机可读存储介质

Family Cites Families (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5579234A (en) 1994-03-11 1996-11-26 Physio-Control Corporation System for automatically testing an electronic device during quiescent periods
US6549882B1 (en) * 1998-12-21 2003-04-15 Cisco Technology, Inc. Mechanisms for providing and using a scripting language for flexibly simulationg a plurality of different network protocols
US6651093B1 (en) * 1999-10-22 2003-11-18 Dell Usa L.P. Dynamic virtual local area network connection process
US6625750B1 (en) 1999-11-16 2003-09-23 Emc Corporation Hardware and software failover services for a file server
US6763380B1 (en) 2000-01-07 2004-07-13 Netiq Corporation Methods, systems and computer program products for tracking network device performance
US6625648B1 (en) 2000-01-07 2003-09-23 Netiq Corporation Methods, systems and computer program products for network performance testing through active endpoint pair based testing and passive application monitoring
US7254607B2 (en) * 2000-03-30 2007-08-07 United Devices, Inc. Dynamic coordination and control of network connected devices for large-scale network site testing and associated architectures
US7633942B2 (en) * 2001-10-15 2009-12-15 Avaya Inc. Network traffic generation and monitoring systems and methods for their use in testing frameworks for determining suitability of a network for target applications
US7159021B2 (en) * 2002-06-27 2007-01-02 Microsoft Corporation System and method for testing peer-to-peer network applications
US20040066748A1 (en) 2002-10-04 2004-04-08 Burnett Charles James Method and apparatus for testing a data network
US7278061B2 (en) * 2002-10-08 2007-10-02 Agilent Technologies, Inc. Building packets of data for testing a communication network
US7680920B2 (en) * 2003-03-24 2010-03-16 Netiq Corporation Methods, systems and computer program products for evaluating network performance using diagnostic rules identifying performance data to be collected
US7281167B2 (en) * 2003-08-26 2007-10-09 Finisar Corporation Multi-purpose network diagnostic modules
KR100689430B1 (ko) 2004-12-16 2007-03-08 삼성전자주식회사 디지털 홈 서비스에서 하이브리드 모니터링을 통한 동적서비스 품질 매핑 장치 및 방법
GB2431315A (en) 2005-10-11 2007-04-18 Agilent Technologies Inc Testing a telecommunications network
US20080010523A1 (en) 2006-05-12 2008-01-10 Samik Mukherjee Performance Testing Despite Non-Conformance
US7869354B2 (en) 2006-08-31 2011-01-11 International Business Machines Corporation Analyzing and generating network traffic using an improved Markov Modulated Poisson Process model with one bursty state and a plurality of idle states
US7730029B2 (en) 2006-09-15 2010-06-01 Alcatel Lucent System and method of fault tolerant reconciliation for control card redundancy
KR101145848B1 (ko) 2006-11-29 2012-05-17 삼성전자주식회사 콘텐츠 전송을 위한 접근 제어 방법 및 상기 접근 제어방법을 이용하는 네트워크의 노드
US8751619B2 (en) 2011-05-31 2014-06-10 Cisco Technology, Inc. Autonomous performance probing
US8867377B2 (en) 2007-10-11 2014-10-21 Cisco Technology, Inc. Dynamic selection between active and passive probing in computer network
US7936685B2 (en) 2009-01-15 2011-05-03 Vss Monitoring, Inc. Intelligent fast switch-over network tap system and methods
GB0919655D0 (en) 2009-11-10 2009-12-23 Ciqual Ltd Methods and apparatus for monitoring network link quality
CN103493437B (zh) * 2011-04-19 2016-04-20 三菱电机株式会社 网络解析支援装置、网络试验装置、网络解析支援方法以及网络试验方法
US8976697B2 (en) 2012-12-17 2015-03-10 Broadcom Corporation Network status mapping
US9680728B2 (en) * 2013-02-12 2017-06-13 Ixia Arrangements for monitoring network traffic on a cloud-computing environment and methods thereof
EP2809033B1 (en) 2013-05-30 2018-03-21 Solarflare Communications Inc Packet capture in a network
KR101401990B1 (ko) 2013-06-28 2014-06-05 주식회사 인터엠 네트워크 기반 오디오 송수신기에서의 데이터 버퍼링 제어 방법 및 그 장치
US9356855B2 (en) 2013-10-10 2016-05-31 Ixia Methods, systems, and computer readable media for providing for specification or autodiscovery of device under test (DUT) topology information
US9628356B2 (en) 2013-10-10 2017-04-18 Ixia Methods, systems, and computer readable media for providing user interfaces for specification of system under test (SUT) and network tap topology and for presenting topology specific test results
US9712376B2 (en) * 2014-01-02 2017-07-18 Red Hat Israel, Ltd. Connector configuration for external service provider
US9823988B2 (en) 2014-09-16 2017-11-21 Spirent Communications, Inc. System and method of test iteration via property chaining
US9935854B2 (en) * 2014-09-23 2018-04-03 Uila Networks, Inc. Infrastructure performance monitoring
US10205938B2 (en) 2014-11-10 2019-02-12 Keysight Technologies Singapore (Holdings) Pte. Ltd. Methods, systems, and computer readable media for monitoring and/or testing network communications
US9641419B2 (en) 2014-12-23 2017-05-02 Ixia Methods and systems for providing background pretesting of communications or storage network equipment
US10511505B2 (en) 2015-12-09 2019-12-17 Keysight Technologies Singapore (Sales) Pte. Ltd. Systems and methods to recreate real world application level test packets for network testing
US10511516B2 (en) 2016-08-29 2019-12-17 Keysight Technologies Singapore (Sales) Pte. Ltd. Methods, systems and computer readable media for quiescence-informed network testing

Also Published As

Publication number Publication date
US20170180233A1 (en) 2017-06-22
US10425320B2 (en) 2019-09-24

Similar Documents

Publication Publication Date Title
RO132010A2 (ro) Metode, sisteme şi suport citibil de calculator pentru diagnosticarea reţelei
US11038744B2 (en) Triggered in-band operations, administration, and maintenance in a network environment
EP3375144B1 (en) Methods, systems, and computer readable media for testing network function virtualization (nfv)
US10057136B2 (en) Method and apparatus for visualized network operation and maintenance
Agarwal et al. SDN traceroute: Tracing SDN forwarding without changing network behavior
CN104796298B (zh) 一种sdn网络故障分析的方法及装置
US10999132B1 (en) Detecting degraded network monitoring agents
US9467330B2 (en) Diagnosing connectivity in a network
WO2021128977A1 (zh) 一种故障诊断方法及装置
Wu et al. Virtual network diagnosis as a service
US20210184937A1 (en) Auto discovery of network proxies
Gheorghe et al. SDN-RADAR: Network troubleshooting combining user experience and SDN capabilities
US11121941B1 (en) Monitoring communications to identify performance degradation
US11012523B2 (en) Dynamic circuit breaker applications using a proxying agent
Tang et al. Intelligence enabled sdn fault localization via programmable in-band network telemetry
Iurman et al. Towards cross-layer telemetry
US20140325279A1 (en) Target failure based root cause analysis of network probe failures
US20240146599A1 (en) Methods, systems, and computer readable media for test system agent deployment in a smartswitch computing environment
Levin et al. Network Monitoring in Federated Cloud Environment
US10461992B1 (en) Detection of failures in network devices
Fang et al. Towards automatic root cause diagnosis of persistent packet loss in cloud overlay network
Aalibagi et al. Low-Overhead Packet Loss Diagnosis for Virtual Private Clouds using P4-Programmable NICs
Espinet et al. Framework, models and controlled experiments for network troubleshooting
Bergström et al. Detecting Network Partitioning in Cloud Native 5G Mobile Network Applications
Sillanpää Network performance monitoring in hybrid infrastructure