Bandwidth Usage Measurement: पद्धती, KPIs आणि सेटअप
Published
तुम्ही हॉटेल, कॅम्पस किंवा व्हेन्यूची साखळी चालवता. मासिक अहवाल सांगतो की Uplink चा वापर केवळ अंशतः झाला आहे. नंतर संध्याकाळ होते, गेस्ट नेटवर्क मंद होते, आणि तक्रारींची तिकिटे येऊ लागतात. जेव्हा कमजोर bandwidth usage measurement मासिक एकूण प्रमाणावर थांबते, तेव्हा असा फरक दिसून येतो.
सरासरी व्हॉल्यूम ही एक उपयुक्त बेसलाइन आहे. ते गर्दीच्या वेळा, ट्रॅफिकची दिशा किंवा रात्री 9 वाजता कोणता ग्रुप ऑन द एअर होता याचे वर्णन करत नाही. एनक्रिप्शन जुन्या शॉर्टकटला अधिक वाईट बनवते, कारण पोर्ट नंबर्स आणि पेलोड तपासणी आता कोणत्याही आत्मविश्वासाने ॲप्लिकेशनचे नाव सांगू शकत नाहीत.
अजूनही जे कार्य करते ते अधिक मर्यादित आहे. एका निश्चित बिंदूवर दोन्ही दिशांमधील बाईट्स मोजा, मागणीचे स्वरूप पाहण्यासाठी पुरेशा वेळा सॅम्पल घ्या, आणि वापराचे श्रेय सेशन, VLAN, किंवा की ला द्या. यापेक्षा अधिक सूक्ष्म असलेल्या कोणत्याही गोष्टीला अनुमान समजा. खालील सेटअपमध्ये कोणता स्त्रोत कोणत्या प्रश्नाचे उत्तर देतो, कोणते KPI अलर्टसाठी योग्य आहेत, आणि सर्वत्र प्रकाशित करण्यापूर्वी एका ठिकाणावर आकडे कसे सिद्ध करायचे हे समाविष्ट आहे.
अनुक्रमणिका
- तुमच्या प्रश्नाशी जुळणारी पद्धत निवडा
- फक्त व्हॉल्यूम नाही तर मागणी दाखवणारे KPIs
- आठ टप्प्यांत मोजमाप कसे सेट करायचे
- सॅम्पलिंग विरुद्ध पूर्ण कॅप्चर आणि प्रत्येकाचा खर्च
- बहुतेक ट्रॅफिक एनक्रिप्टेड असताना वापर ट्रॅक करणे
- तुमच्या आकडेवारीत तफावत का आहे आणि ती कशी सुधारायची
- कंपनी-व्यापी रिपोर्टिंग करण्यापूर्वी एका साइटवर पडताळणी करा
तुमच्या प्रश्नाशी जुळणारी पद्धत निवडा
एखादा हॉटेल समूह दिवसभरात Uplink क्षमता सुमारे 35% वापरत असला, तरीही दररोज संध्याकाळी त्यांना पाहुण्यांच्या तक्रारींना सामोरे जावे लागू शकते. सरासरीने क्षमतेच्या प्रश्नाचे उत्तर दिले. पाहुणे मात्र गर्दीच्या वेळेचा (busy-hour) प्रश्न विचारत होते. Bandwidth usage measurement फक्त तेव्हाच उपयुक्त ठरते जेव्हा स्त्रोत आणि प्रश्न एकमेकांशी जुळतात, म्हणूनच कोणीही तक्ता तयार करण्यापूर्वी बहुतांश ठिकाणी दोन फीडची आवश्यकता असते. एक फीड एकूण प्रमाण आणि ट्रेंडसाठी असते. तर दुसरी फीड Attribution साठी असते.
तुम्हाला नवीन हार्डवेअरची क्वचितच गरज भासते. ॲक्सेस पॉइंट्स, कंट्रोलर, राऊटर आणि ऑथेंटिकेशन सर्व्हिसवर आधीपासूनच सहा स्रोत उपलब्ध आहेत.
| स्त्रोत | हे काय रिपोर्ट करते | ग्रॅन्युलॅरिटी | यासाठी सर्वोत्तम | ओव्हरहेड |
|---|---|---|---|---|
| SNMP इंटरफेस काउंटर्स (ifHCInOctets, ifHCOutOctets) | प्रति पोर्ट किंवा रेडिओ इन आणि आऊट बाइट्स | प्रति इंटरफेस, प्रत्येक 1-5 मिनिटांनी पोल केलेले | अपलिंक ट्रेंड आणि क्षमता नियोजन | कमी |
| NetFlow v9 किंवा IPFIX | स्त्रोत, गंतव्यस्थान, पोर्ट्स, बाइट्स आणि पॅकेट्ससह फ्लो रेकॉर्ड्स | प्रति फ्लो, सहसा दर 1-5 मिनिटांनी एक्सपोर्ट केले जाते | टॉप टॉकर्स आणि कोण कोणाशी बोलत आहे हे पाहण्यासाठी | मध्यम, एक्सपोर्ट आणि CPU लोडवरून |
| sFlow | सॅम्पल केलेले पॅकेट हेडर्स अधिक इंटरफेस काउंटर्स | N पॅकेट्समध्ये 1, अंदाजांनुसार स्केलिंग केलेले | जलद लिंक्स (10G आणि त्याहून अधिक) आणि जवळजवळ रिअल-टाइम मधील टॉप टॉकर्स | कमी, हार्डवेअरमध्ये सॅम्पलिंग चालते |
| प्रति-SSID आणि प्रति-VLAN काउंटर्स | प्रति वायरलेस नेटवर्क किंवा VLAN बाइट्स आणि क्लायंट काउंट्स | प्रति SSID, VLAN आणि ॲक्सेस पॉइंट | गेस्ट विरुद्ध कर्मचाऱ्यांचा लोड आणि प्रत्येक SSID ची एअरटाइम कॉस्ट | कमी |
| RADIUS अकाउंटिंग (Acct-Input-Octets, Acct-Output-Octets) | प्रति ऑथेंटिकेटेड सेशन बाइट्स | प्रति सेशन, दर 5-15 मिनिटांनी अंतरिम अपडेट्स | वापरकर्त्यास, डिव्हाइसला किंवा की ला वापराचे श्रेय देणे | कमी |
| DNS आणि संरक्षक DNS लॉग्स | पॉलिसी किंवा श्रेणीनुसार डोमेन क्विरीज | प्रति क्वेरी | पेलोड तपासणीशिवाय श्रेणी-स्तरीय इनसाइट | कमी ते मध्यम |
प्रश्नाशी काउंटर जुळवा
SNMP counters हे एकूण मूल्यांचे स्त्रोत आहेत. 64-बिट ऑब्जेक्ट्स, ifHCInOctets आणि ifHCOutOctets पोल करा. 1 Gbps पोर्टवरील 32-बिट ऑक्टेट काउंटर पूर्ण वेगाने सुमारे 34 सेकंदात रॅप होतो, म्हणून जुन्या ऑब्जेक्टवरील पाच-मिनिटांचा पोल चुकीचे किंवा निरर्थक डेल्टा तयार करतो. Per-SSID counters हे क्लायंट लोड आणि प्रत्येक वायरलेस नेटवर्कचा एअरटाइम खर्च दाखवतात. जेव्हा पेलोड एनक्रिप्ट केलेले असतात, तेव्हा RADIUS accounting बाइट्सना युजर, डिव्हाइस किंवा की शी जोडते, जे अॅट्रिब्यूशन फीड म्हणून काम करते.
मोबाईलची मागणी इतकी मोठी आहे की तिला फिक्स्ड-साइटच्या एकूण ट्रॅफिकमध्ये मिसळल्याने महत्त्वाची बंधने लपून राहतात. ITU Facts and Figures 2024 नुसार, 2023 मध्ये जागतिक इंटरनेट ट्रॅफिक 1 zettabyte मोबाईल ब्रॉडबँड एंड-युझर ट्रॅफिकपर्यंत पोहोचले आहे. व्हेन्यू अपलिंक आणि सेल्युलर ऑफलोड पाथ ही वेगळी मोजमापे आहेत.
तुम्ही काहीही कॉन्फिगर करण्यापूर्वी प्रत्येक साईटसाठी एक प्रायमरी टोटल्स सोर्स आणि एक एट्रिब्यूशन सोर्स निवडा. नंतर तिसरी फीड जोडणे सोपे आहे. एका महिन्यानंतर दोन अनलेबल केलेल्या फीड्सचे गुंते सोडवणे सोपे नाही.
केवळ व्हॉल्यूमच नाही तर मागणी दर्शवणारे KPIs
एक वापरण्यायोग्य बेसलाइन एका सुसंगत कालावधीत, सहसा एका कॅलेंडर महिन्यात, अंतिम वापरकर्त्याच्या ॲक्सेस पॉइंटवर एकूण वॉल्यूम, डाउनलोड्स आणि अपलोड्स एकत्र जोडून मोजते. ITU पद्धतीवरून घेतलेला European Commissionचा डेटा, फिक्स्ड-ब्रॉडबँड ट्रॅफिकची व्याख्या तशीच करतो आणि तो होलसेल आणि वॉल्ड-गार्डन ट्रॅफिक वगळून मोबाइल-ब्रॉडबँड ट्रॅफिक वेगळा ठेवतो. ती सीमा व्हेन्यू नेटवर्कवर देखील महत्त्वाची असते. ग्राहकाचा वापर म्हणजे बॅकबोन क्षमता किंवा ऑपरेटर सोडत नसलेला ट्रॅफिक एकच गोष्ट नाही.
प्रत्येक रिपोर्टमध्ये मोजमाप बिंदूचे नाव नमूद करा. मॅनेजमेंट आणि कंट्रोल फ्रेम वगळल्या आहेत की नाही ते सांगा. त्या नियंत्रणांशिवाय, एकाच युजर्स असलेल्या दोन साइट्सची तुलना करता येणार नाही.
व्यावहारिक नियम: जर एखाद्या KPI मध्ये पॉईंट, दिशा, सॅम्पल इंटरव्हल आणि कालावधी नमूद केला नसेल, तर तो अलर्ट देण्यासाठी तयार नाही.
तुम्ही स्वतः तपासू शकता अशी सूत्रे
सरासरी थ्रुपुट (Average throughput) म्हणजे एकूण बाइट्सला 8 ने गुणून, नंतर त्या कालावधीतील सेकंदांनी भागणे होय. पीक थ्रुपुट (Peak throughput) हे सर्वाधिक 1 मिनिट किंवा 5 मिनिटांचे सॅम्पल असते, मासिक सरासरी नाही. 95वी पर्सेंटाईल (95th percentile) प्रत्येक सॅम्पलची वर्गवारी करते आणि 95% वर मूल्य घेते, त्यामुळे एका फाइल कॉपीमुळे बिझी लेव्हल ठरत नाही. बिझी-अवर व्हॉल्यूम (Busy-hour volume) हे एकाच सर्वाधिक तासातील बाइट्स असतात आणि त्या तासानुसारच तुम्ही साईझ ठरवता. कॉन्करंट ॲक्टिव्ह क्लायंट्स (Concurrent active clients) एकाच विंडोमध्ये डेटा ट्रान्सफर करणाऱ्या उपकरणांची गणना करतात. ॲअरटाइम युटिलायझेशन (Airtime utilisation) हा चॅनेल व्यस्त असलेल्या वेळेचा भाग आहे, जो ॲक्सेस पॉइंट रेडिओ काउंटरवरून घेतला जातो आणि अपलिंक व्यवस्थित दिसत असतानाही हीच अनेकदा वायरलेसची मर्यादा असते. अपस्ट्रीम शेअर (Upstream share) म्हणजे अपस्ट्रीम बाइट्सला एकूण बाइट्सने भागणे.
| KPI | गणना कशी करावी | हे तुम्हाला काय सांगते | सोडवलेले उदाहरण |
|---|---|---|---|
| एकूण व्हॉल्यूम | कालावधीतील इन आणि आऊट बाइट्सची बेरीज | कॅपॅसिटी बेसलाइन आणि मासिक ट्रेंड | 30 दिवसांत दररोज 40 GB म्हणजे दरमहा 1.2 TB |
| सरासरी थ्रूपूट | बाइट्स x 8 भागिले सेकंद | सरासरी लोड | दररोज 40 GB म्हणजे सरासरी सुमारे 3.7 Mbps |
| पीक थ्रूपूट | सर्वात जास्त 1-मिनिट किंवा 5-मिनिटांचा नमुना | बर्स्ट मागणी | त्या अपलिंकवरील सर्वात व्यस्त 5-मिनिटांचा नमुना |
| 95th पर्सेंटाइल थ्रूपूट | सॅम्पल्स क्रमवारी लावा आणि 95% वर मूल्य घ्या | दुर्मिळ स्पाइक्सशिवाय टिकून राहिलेली व्यस्त पातळी | 5-मिनिटांच्या पोलिंगच्या एका महिन्यात 95% ची खूण |
| व्यस्त-वेळेचा व्हॉल्यूम | सर्वात जास्त ट्रॅफिक असलेल्या तासातील बाइट्स | सर्वात वाईट तासासाठी आकारमान ठरवणे | रात्री 9 च्या तासात 9 GB |
| एकाच वेळी सक्रिय क्लायंट्स | त्याच सॅम्पल विंडोमध्ये डेटा ट्रान्सफर करणारे क्लायंट्स | स्पर्धा आणि एअरटाइमचा दबाव | एका 5-मिनिटांच्या विंडोमध्ये डेटा ट्रान्सफर करणारे 45 क्लायंट्स |
| एअरटाइम वापर | AP रेडिओ काउंटरवरून चॅनेलचा व्यस्त वेळ | वायरलेस गर्दी (कंजेशन) | चॅनेल व्यस्त राहण्याचा वेळेचा भाग |
| अपस्ट्रीम शेअर | अपस्ट्रीम बाइट्स भागिले एकूण बाइट्स | व्हिडिओ कॉल, क्लाउड बॅकअप, अपलोड्स | एकूण 10 GB पैकी 2 GB अपस्ट्रीम म्हणजे 20% |
अंकगणिताने काढलेले हे आकडे केवळ तपासणीसाठी आहेत, ते तुमच्या साइट्ससाठीचे लक्ष्य नाहीत. सरासरी 3.7 Mbps वर असलेली साइट देखील एका तासासाठी सॅच्युरेटेड असू शकते.
डॅशबोर्डच्या आधीच्या सूचना
पहिला रिपोर्ट जाण्यापूर्वी थ्रेशोल्ड सेट करा. कोणतीही साइट ज्याची 95वी पर्सेंटाईल पूर्ण बिझी अवरसाठी अपलिंक क्षमतेच्या 80% पेक्षा जास्त राहते तिला फ्लॅग करणे आणि ज्या चॅनेलचा ॲअरटाइम सलग संध्याकाळी जास्त राहतो त्याची चौकशी करणे ही एक योग्य सुरुवात आहे. बेसलाइनच्या एका महिन्यानंतर दोन्ही समायोजित करा. साइट, SSID आणि VLAN नुसार रिपोर्ट तयार करा. संपूर्ण इस्टेटची एकच सरासरी अपयशी ठरणाऱ्या प्रॉपर्टीला लपवेल, म्हणूनच दर-स्थान वापर दृश्य (per-location usage view) रॉ काउंटरच्या शेजारी असावे.
संख्या प्रकाशित करण्यापूर्वी, तुम्ही त्याचा मोजमाप बिंदू, दिशा, सॅम्पल अंतर आणि कालावधी एका वाक्यात सांगण्यास सक्षम असले पाहिजे.
आठ पायऱ्यांमध्ये मोजमाप कसे सेट करावे
डिव्हाइसला स्पर्श करण्यापूर्वी संकलन डिझाइन लिहा. खालील आठ पायऱ्या या किमान अशा आहेत ज्या कर्मचाऱ्यांमधील बदल आणि फर्मवेअर अपग्रेडच्या एका वर्षानंतरही टिकून राहतात.
ते लिहून घ्या, नंतर संकलित करा
प्रश्न आणि त्याची मर्यादा एका वाक्यात लिहा. उदाहरण: प्रति अतिथी SSID, प्रति साइट, प्रति महिना, दोन्ही दिशांचे बाईट्स. वाक्य दोन प्रश्न विचारत असल्यास, आपण दोन अर्धे-अपुरे रिपोर्ट तयार कराल. आपण स्पष्ट करू इच्छित असलेल्या तिकीटाऐवजी डॅशबोर्ड टेम्पलेटवरून सुरुवात करणे ही एक सामान्य चूक आहे.
मापनाचा बिंदू निवडा. अपलिंक किंवा वायरलेस कंट्रोलर एकूण संख्या दर्शवतो. कोर राउटर प्रवाह दर्शवतो. एज फायरवॉल केवळ बाह्य ट्रॅफिक दर्शवते, आणि त्यामुळे LAN-to-LAN ट्रान्सफर चुकतील. या तिन्हींची एकत्र बेरीज करू नका. त्यांना एकाच नंबरची प्रत मानणे ही चूक ठरेल.
64-bit काउंटर पोलिंग सक्षम करा. व्यस्त अपलिंक्सवर 1-मिनिटांचे अंतर आणि दीर्घकालीन ट्रेंडसाठी 5-मिनिटांचे अंतर वापरा. एक-मिनिटाचा डेटा तो बस्ट दाखवतो जो पाच-मिनिटांची सरासरी सपाट करते. 32-bit ऑब्जेक्ट पोल करणे ही एक चूक आहे जी सर्वात व्यस्त पोर्ट्सना आधी खराब करते.
कलेक्टरमध्ये फ्लो एक्सपोर्ट करा. सक्रिय टाइमआउट 1-5 मिनिटांवर सेट करा जेणेकरून दीर्घ सत्र संपण्यापूर्वी दिसेल. त्या टाइमआउटशिवाय, अतिथी डिसकनेक्ट करेपर्यंत व्हिडिओ कॉलने काहीही वापरले नाही असे दिसते. राउटरवरील CPU आणि एक्सपोर्ट ड्रॉप्सवर लक्ष ठेवा. मागे पडणारा कलेक्टर नकळत कमी मोजणी करतो.
प्रत्येक सिरीज टॅग करा. साइट, SSID, VLAN, आणि ॲक्सेस पॉइंट नाव रेकॉर्ड स्टोअर करताना त्यावर असणे आवश्यक आहे. अनटॅग केलेला डेटा नंतर विभक्त केला जाऊ शकत नाही, आणि पुढील तिमाहीत SSID चे नाव बदलल्याने इतिहास दुरुस्त होणार नाही. उपकरणाचे होस्टनेम ही एक स्थिर साइट की आहे असे गृहीत धरणे ही चूक आहे.
अंतरिम अपडेट्ससह RADIUS अकाउंटिंग सुरू करा. पंधरा मिनिटे हा एक व्यावहारिक कालावधी आहे. अंतरिम रेकॉर्ड्स दीर्घ सत्र दृश्यमान ठेवतात, आणि ते कधीही स्पष्ट स्टॉप न पाठवणाऱ्या क्लायंटमध्येही टिकून राहतात. तुम्ही डिसकनेक्ट होण्याची वाट पाहिल्यास, स्टॉप गमावल्यास रात्रीची सत्रे दैनिक अहवालातून गायब होतात.
रिटेंशन आणि ज्ञात ट्रान्सफर
हेतूने रिटेंशन सेट करा. 5 मिनिटांच्या एकूण विश्लेषणाचा 13 महिन्यांचा डेटा जतन करा जेणेकरून तुम्ही पुढील वर्षी त्याच आठवड्याची तुलना करू शकाल. 7 ते 14 दिवसांचे रॉ फ्लो (raw flows) जतन करा. प्रत्येक साइटचा पूर्ण फ्लो इतिहास तो शिकवण्यापेक्षा जास्त महाग पडतो. कोणीही डिलीट जॉब सेट न केल्यामुळे रॉ फ्लो नेहमीसाठी ठेवणे ही चूक ठरते.
माहित असलेल्या ट्रान्सफरसह व्हॅलिडेट करा. एका उपकरणावर 10 GB फाईल डाउनलोड करा आणि तुम्ही प्रायमरी म्हणून निवडलेल्या काउंटरवर, काही टक्क्यांच्या आत तीच एकूण संख्या बदलते का याची खात्री करा. कोणीही चार्टवर विश्वास ठेवण्यापूर्वी हे करा. व्हॅलिडेशन वगळल्यास रॅप केलेले काउंटर किंवा वन-वे फ्लो एक्सपोर्ट क्षमता प्लॅन म्हणून पाठवले जाते.
स्टेप 8 अयशस्वी झाल्यास, थांबवा. काउंटर, टाइमआउट किंवा गहाळ पाथ दुरुस्त करा. हेच कॉन्फिगरेशन पुढील साइटवर रोल आउट करू नका.
सॅम्पलिंग विरुद्ध फुल कॅप्चर आणि प्रत्येकाचा खर्च
एकूण आकडे काउंटरवरून येतात, टॉप टॉकर अनसॅम्पल्ड फ्लोमधून येतात, जलद लिंक्स सॅम्पल केल्या जातात आणि पूर्ण कॅप्चर हे अल्प कालावधीच्या फॉरेन्सिक विंडोसाठी असते. अचूकता, स्टोरेज आणि गोपनीयता परस्परविरुद्ध दिशेने जातात, त्यामुळे प्रत्येक प्रश्नासाठी एकच पद्धत वापरल्यास ती एकतर चुकीची माहिती देईल किंवा डिस्क भरेल.
| दृष्टिकोन | तंतोतंतपणा | स्टोरेज आणि ओव्हरहेड | गोपनीयता जोखीम | यासाठी सर्वोत्तम |
|---|---|---|---|---|
| दर 5 मिनिटांनी पोल केलेले इंटरफेस काउंटर्स | अचूक एकूण बाईट्स | खूप कमी | काहीही नाही | एकूण, ट्रेंड आणि बिलिंग तपासणी |
| नमुने न घेतलेले फ्लो रेकॉर्ड्स (NetFlow किंवा IPFIX) | प्रति प्रवाह अचूक, एक्सपोर्टचे नुकसान वजा करून | मध्यम, प्रवाहाच्या संख्येनुसार वाढते | कमी, केवळ हेडर | टॉप टॉकर्स आणि पोर्ट-स्तरीय ॲप्लिकेशन सूचना |
| 1,000 पैकी 1 ते 4,000 पॅकेट्सपैकी 1 मधील sFlow | अंदाज, लहान प्रवाहासाठी कमी प्रभावी | कमी | कमी, हेडर आणि ट्रंकेट केलेले पेलोड | 10G आणि त्याहून अधिकचे जलद लिंक्स |
| पूर्ण पॅकेट कॅप्चर | अचूक, प्रत्येक पॅकेट | खूप जास्त, व्यस्त 10G लिंकवर दररोज अनेक TB | जास्त, वैयक्तिक डेटा असू शकतो | घटनांदरम्यानचे लहान फॉरेन्सिक विंडो |
प्रत्येक पद्धत कुठे अपयशी ठरते
इंटरफेस काउंटर बाईट्ससाठी तंतोतंत असतात आणि ते कोणी पाठवले याबद्दल मौन बाळगतात. जेव्हा बिल किंवा कॅपॅसिटीचा युक्तिवाद समर्थनीय असावा लागतो तेव्हा त्यांचा वापर करा. ते टॉकरचे नाव सांगणार नाहीत.
Unsampled NetFlow किंवा IPFIX प्रत्येक प्रवाहाची नोंद ठेवते, जे टॉप टॉकर्ससाठी आवश्यक असते. एक्सपोर्ट लॉस आणि ओव्हरलोड झालेला कलेक्टर्स व्यस्त राउटरवर नोंदी वगळू शकतात, त्यामुळे जुळणीमध्ये कोणतीही चूक नसतानाही फ्लो सम इंटरफेस काउंटरपेक्षा कमी असू शकतो. या फरकाकडे आरोग्य सिग्नल म्हणून पाहा, न वापरलेली क्षमता म्हणून नाही.
sFlow हार्डवेअरमध्ये सॅम्पल घेते, सहसा access आणि core लिंक्सवर 1,000 ते 4,000 मधील 1 पॅकेट, आणि नंतर त्या सॅम्पल्सचे वॉल्यूम अंदाजात रूपांतर करते. 10G आणि जलद लिंक्सवर हे फायदेशीर ठरते. छोटे प्रवाह अदृश्य होऊ शकतात. मेसेजिंग, DNS, आणि लहान HTTPS सेशन्सची गर्दी हीच अशी ठिकाणे आहेत जिथे हा अंदाज सर्वात कमकुवत असतो, त्यामुळे sFlow वरून बिलिंग करू नका आणि एका उपकरणाचा वापर सिद्ध करण्यासाठी त्याचा वापर करू नका.
फुल पॅकेट कॅप्चर तंतोतंत असते, आणि लाईन रेटवर व्यस्त 10G लिंकवर ते दररोज अनेक टेराबाइट्स तयार करू शकते. पेलोडमध्ये असा वैयक्तिक डेटा असू शकतो जो ठेवण्याची तुमची पॉलिसी परवानगी देत नाही.
एखाद्या वादासाठी उत्तर तंतोतंत असणे आवश्यक असल्यास, काउंटर वापरा. जर त्याने ॲप्लिकेशन्सचा अंदाज देणे आवश्यक असेल, तर केवळ हेडरसह फ्लो रेकॉर्ड वापरा. जर ही एक वेळची घटना असेल, तर एका तासापेक्षा कमी वेळेसाठी कॅप्चर करा आणि विंडो बंद झाल्यावर कॅप्चर थांबवा.
बहुतेक ट्रॅफिक एनक्रिप्टेड असताना वापराचे ॲट्रिब्यूशन करणे
ऍप्लिकेशन्सची नावे निश्चित करण्यासाठी पेलोड तपासणी हा एक कमकुवत आधार आहे. अलिकडील मोजमापांनुसार 2025 च्या अखेरीस 95% पेक्षा जास्त निरीक्षण केलेले रिक्वेस्ट HTTPS चे होते, जसे की Help Net Security च्या Cloudflare 2025 मधील इंटरनेट ट्रेंड्सच्या अहवालात नोंदवले गेले आहे. QUIC, एनक्रिप्टेड DNS, शेअर केलेले CDNs, VPNs आणि गोपनीयतेची वैशिष्ट्ये पोर्ट-आधारित लेबल्सना अधिक अविश्वसनीय बनवतात.
एनक्रिप्टेड ट्रॅफिकमुळे bandwidth usage measurement अशक्य होत नाही. ते पुराव्याचे स्वरूप बदलते. तुम्ही अजूनही बाईट्स, पॅकेट्स, टायमिंग, दिशा, कनेक्शन संख्या, रीट्रांसमिशन आणि लेटन्सी मोजू शकता. जिथे धोरण अनुमती देते, तिथे तुम्ही डेस्टिनेशन कॅटेगरी किंवा ऑथेंटिकेटेड आयडेंटिटी जोडू शकता. पेलोडने तुम्हाला ॲप्लिकेशन सांगितले असा दावा तुम्ही करू शकत नाही.
एक स्टॅक जो त्याचा विश्वासार्हता स्तर सांगतो
तुम्ही सिद्ध करू शकाल अशा नोंदींवरून ॲट्रिब्यूशन तयार करा.
- RADIUS सेशन बाइट्स (उच्च विश्वासार्हता): Acct-Input-Octets आणि Acct-Output-Octets वॉल्यूम ऑथेंटिकेटेड सेशन, डिव्हाइस किंवा xPSK की सोबत जोडतात. Accounting पाथ पूर्ण असल्यास "या डिव्हाइसने 8 GB वापरले" ही उच्च विश्वासार्ह माहिती असू शकते.
- प्रति-VLAN काउंटर्स (गटासाठी उच्च विश्वासार्हता): गेस्ट, कर्मचारी, टिल्स आणि IoT प्रत्येकाचा VLAN वेगळा असतो, त्यामुळे ग्रुप लोड कशाचेही डिक्रिप्ट करण्यावर अवलंबून नसतो.
- DNS पॉलिसी श्रेणी (मध्यम, आणि लेबल केलेले): श्रेणी एकूण ॲप्लिकेशनसारखी इनसाइट देतात. "व्हिडिओने 5 GB वापरले" हा एक अंदाज आहे. अहवालावर तसे स्पष्ट सांगा.
- ॲग्रीगेट फ्लो रेकॉर्ड्स (ॲप नावासाठी कमी): हेडर्स अजूनही दर्शवतात की कोणी कोणत्या ॲड्रेसशी संवाद साधला आणि किती बाइट्स ट्रान्सफर झाले. शेअर केलेला CDN ॲड्रेस हे ॲप्लिकेशन नाही.
रँडम केलेले MAC ॲड्रेस डिव्हाइसच्या संख्येची अचूकता बिघडवतात. एक फोन दिवसभरात दोन डिव्हाइसेससारखा दिसू शकतो, ज्यामुळे क्लायंटची एकूण संख्या फुगते आणि त्याचे बाइट्स विभाजित होतात. जेव्हा पॉलिसी तुम्हाला ती ओळख देते तेव्हा प्रति व्यक्ती किंवा प्रति की सेशन्सची गणना करा. रिटेल फ्लोअरसाठी, हीच कल्पना एका शेअर केलेल्या रेडिओवर शॉपर्सच्या ट्रॅफिकला कर्मचाऱ्यांच्या ट्रॅफिकपासून कशी वेगळी करायची यात दिसते, जी चांगल्या retail WiFi design चा भाग आहे.
सोप्या शब्दांतील हे ट्रेड-ऑफ या संक्षिप्त वॉकथ्रूमध्ये आहे.
ओळखीशी जोडलेले रेकॉर्ड फक्त ट्रबलशूटिंग, कॅपेसिटी प्लॅनिंग आणि अनुपालनासाठीच ठेवा. ते ठरलेल्या वेळेनुसार डिलीट करा. प्रत्येक आकड्यावर कॉन्फिडन्स लेबल लावण्यासाठी काहीही खर्च येत नाही आणि त्यामुळे श्रेणीच्या अंदाजाला बिल मानणे थांबते.
तुमचे आकडे जुळत का नाहीत आणि त्यांचा मेळ कसा घालावा
वापरकर्ते दररोज संध्याकाळी तक्रार करत असताना देखील मासिक सरासरी उत्तम दिसू शकते. या दोन्ही गोष्टी बऱ्याचदा खर्या असतात. एकत्रित फिक्स्ड आणि मोबाईल ट्रॅफिक हे देखील एक बदलणारे उद्दिष्ट आहे. ITU च्या 2023 च्या ट्रॅफिक आकडेवारीनुसार 2019 ते 2023 दरम्यान सरासरी वार्षिक वाढ सुमारे 30% झाली आहे, ज्यामध्ये 2020 मध्ये साथीच्या रोगाच्या सुरुवातीला सर्वात मोठी वाढ झाली आहे. केवळ वाढ हे वाईट संध्याकाळचे कारण असू शकत नाही. संपूर्ण दिवसाची स्थिती याचे स्पष्टीकरण देते.
OpenVault चा Q1 2025 ब्रॉडबँड रिपोर्ट दर्शवतो की एकच सरासरी मूल्य कॅपॅसिटीच्या कामात कशी दिशाभूल करू शकते. U.S. सबस्क्रायबरचा सरासरी वापर दरमहा 663.2 GB वर पोहोचला आहे, ज्यामध्ये वर्षागणिक 9.5% वाढ झाली आहे, तर व्यवसायांचा पीक-अवर डाउनस्ट्रीम वापर 21.2% आणि अपस्ट्रीम वापर 23.6% ने वाढला आहे. व्यवसायांची डाउनस्ट्रीम मागणी दुपारी 1 वाजता सर्वोच्च पातळीवर होती. निवासी क्षेत्राची अपस्ट्रीम आणि डाउनस्ट्रीम मागणी रात्री 9 च्या सुमारास सर्वोच्च पातळीवर होती. एखादे हॉटेल किंवा निवासी मालमत्ता मासिक चार्टवर साधारण दिसू शकते आणि तरीही एखाद्या अंदाज लावण्यायोग्य तासात अपयशी ठरू शकते. मासिक गिगाबाइट्स कमी केल्याने ती तक्रार सुटत नाही. पीक वेळेतील लोड हलवणे, किंवा एअरटाइम आणि स्पर्धा सुधारणे, यामुळे बर्‍याचदा मोठ्या एकूण पाईपपेक्षा पाहुण्यांना जास्त मदत होते.
बँडविड्थ खरेदी करण्यापूर्वी विसंगती वाचा
| लक्षण (Symptom) | संभाव्य कारण | तपासा |
|---|---|---|
| काउंटर्स क्षमतेच्या 30% दाखवतात, तरीही अतिथी तक्रार करतात | सरासरी आकडे संध्याकाळचे पीक अव्हर्स किंवा एअरटाइम कॉन्टेंशन लपवतात | बिझी-अवर 95th पर्सेंटाइल आणि चॅनेल युटिलायझेशनची तुलना करा |
| फ्लो टोटल इंटरफेस काउंटर्सपेक्षा 15% कमी आहे | सॅम्पलिंग एरर, असिमेट्रिक राउटिंग किंवा एका पाथवरून एक्सपोर्टर गहाळ असणे | अनसॅम्पल्ड लिंकवर तुलना करा आणि प्रत्येक पाथ फ्लो एक्सपोर्ट करतो याची खात्री करा |
| प्रति-SSID टोटल AP टोटलशी जुळत नाही | मॅनेजमेंट ट्रॅफिक वगळले गेले आहे, किंवा क्लायंट सॅम्पलच्या मध्यभागी रोमिंग करत आहेत | टाइमस्टॅम्प्स अलाइन करा आणि प्रत्येक काउंटरमध्ये कोणत्या फ्रेम्स समाविष्ट आहेत ते कन्फर्म करा |
| RADIUS चे टोटल डिव्हाइस काउंटपेक्षा जास्त आहे | रीकनेक्टनंतर डुप्लिकेट सेशन्स किंवा रीऑथेंटिकेशनवर काउंटर्स रिसेट होतात | सेशन ID द्वारे ग्रुप करा आणि रिसेट हँडलिंग तपासा |
| एक साइट समान दुसऱ्या साइटपेक्षा दुप्पट वापर करते | वेगळा युझर मिक्स, कॅश केलेले अपडेट्स किंवा VLAN टॅगिंग त्रुटी | VLAN आणि टॉप डेस्टिनेशन कॅटेगरीजनुसार विभाजन करा |
| रोलआउटच्या दुसऱ्या दिवशी वापर अचानक वाढतो | क्लाउड अपडेट्स किंवा नेटवर्कमध्ये नवीन डिव्हाइस क्लास समाविष्ट झाला आहे | DNS कॅटेगरीज आणि रोलआउटची अचूक वेळ तपासा |
आधी टाइम अलाइनमेंट दुरुस्त करा, नंतर सॅम्पलिंग आणि त्यानंतर ॲट्रिब्यूशन. नंतरच्या त्रुटी आधीच्या त्रुटींमध्ये भर घालतात.
समान साईट्समधील दोन पट फरक हा सहसा VLAN टॅग किंवा उपकरणांचे वेगळे मिश्रण असते, कोणतेही रहस्यमय ॲप्लिकेशन नाही. तुम्ही कॅपॅसिटी प्लॅन पुन्हा लिहिण्यापूर्वी क्लॉक, एक्सपोर्टर आणि सेशन की यांची पुष्टी करा. संपूर्ण संस्था-व्यापी सरासरी हे प्रत्येक ठिकाणाचे मॉडेल असू शकत नाही.
कंपनी-व्यापी रिपोर्टिंग करण्यापूर्वी एका साइटवर व्हॅलिडेट करा
पहिल्याच दिवशी प्रत्येक प्रॉपर्टीवर नवीन मेजरमेंट डिझाइन लागू करू नका. दोन ते चार आठवड्यांसाठी एका प्रातिनिधिक साईटवर पायलट चालवा. या विंडोमध्ये किमान एक गर्दीची संध्याकाळ आणि एक शांत कामकाजाचा दिवस समाविष्ट असणे आवश्यक आहे, अन्यथा तुम्ही फक्त त्याच सरासरीला सिद्ध कराल ज्यावर तुमचा आधीच अविश्वास आहे.
नवीन कलेक्शन तुम्ही आज चालवत असलेल्या नेटवर्कच्या शेजारी ठेवा. नवीन मालिका एकूण बाईट्सवर सुमारे 5% च्या मर्यादेत जुळत नाही तोपर्यंत सध्याचे काउंटर्स बदलू नका. रॅप केलेला काउंटर, हरवलेला एक्सपोर्टर, किंवा कधीही टॅग न केलेला VLAN शोधण्यासाठी समांतर रन उपयुक्त ठरते.
डॅशबोर्ड किती पूर्ण दिसतो यावर नाही, तर दोन चाचण्यांवर पायलटचे मूल्यमापन करा.
- तिकिटे: गर्दीच्या वेळेची आकडेवारी तुमच्याकडे आधीपासून असलेल्या तक्रारींशी जुळते का? जर सर्वात वाईट संध्याकाळी चार्ट शांत दिसत असेल, तर सॅम्पल इंटरव्हल किंवा मोजमापाचा बिंदू चुकला आहे.
- ऑडिट: दिलेल्या दिवशी उपकरणाने कोणता VLAN वापरला, अशा वास्तविक प्रश्नाचे उत्तर कोणी देऊ शकते का? जर ट्रेल याचे उत्तर देऊ शकत नसेल, तर Attribution चे काम पूर्ण झालेले नाही.
आम्ही आधी एका साइटवर, त्या साइटवर आधीपासून असलेल्या ॲक्सेस पॉइंट्सवर, लाईव्ह नेटवर्कच्या जवळ डिझाइन सिद्ध करतो आणि व्यापक रोलआउटपूर्वी तिकिटे आणि ऑडिट पुराव्यांवरून त्याचे मूल्यांकन करतो. एका अभियंत्यासाठी त्या हार्डवेअरवरील आजचे SSIDs ओपन, सुरक्षित आणि xPSK वर मॅप करण्यासाठी 45 मिनिटांचे डिझाइन सत्र पुरेशी असते आणि योजना तुमच्याकडेच राहते. नेटवर्क हेल्थ मॉनिटरिंग नंतर इस्टेटवरून लोकेशन आणि हार्डवेअरच्या तुकड्यापर्यंत स्पीड टेस्ट, ऑथेंटिकेशन रेट्स आणि डाउनलोड व वर्तणुकीसंबंधी डेटासह सखोल तपासणी करते, ज्यामुळे गैरवापर अंदाज लावण्याऐवजी स्पष्टपणे दिसतो. रेडिओ प्लॅन अजूनही योग्य असावा लागतो. मेजरमेंट अशा चॅनेल प्लॅनचे पुनरुज्जीवन करणार नाही जो कधी डिझाइनच केला गेला नव्हता, म्हणूनच WiFi नेटवर्क डिझाइन हे एक वेगळे काम राहते.
दुसऱ्या साइटच्या आधी रिपोर्टिंगचे नियम सेट करा. सर्वत्र तोच कालावधी आणि तोच सॅम्पल इंटरव्हल वापरा. कॉन्फिडन्स लेबल करा. साइट, SSID आणि VLAN नुसार रिपोर्ट करा आणि प्रत्येक डॅशबोर्डला एक नियुक्त मालक द्या. जेव्हा पायलट काउंटर्सशी जुळेल आणि टीम डेटावरून तिच्या पहिल्या तीन प्रश्नांची उत्तरे देऊ शकेल तेव्हाच रोल आउट करा. जर तसे नसेल, तर विसंगती तपासांकडे परत जा. तुटलेली बेसलाइन वाढवल्याने त्रुटी अधिक वेगाने पसरते.
Purple Access तुम्ही आधीपासून वापरत असलेल्या ॲक्सेस पॉइंट्सवर ओपन, सुरक्षित आणि iPSK लावते, ज्यामध्ये क्लाउड RADIUS अकाउंटिंग असते जे तुम्ही वापरकर्ता, डिव्हाइस किंवा की शी जोडू शकता, तसेच हेल्थ व्ह्यूज जे एका शांत मासिक सरासरीला वाईट व्यस्त तासापासून वेगळे करतात. तुमच्या उर्वरित इस्टेटमध्ये बदल करण्यापूर्वी तुमच्या तिकिटांवर आणि ऑडिट ट्रेलवर एका साइटवर ते सिद्ध करा. तुमच्या ठिकाणांसाठी ते कसे योग्य ठरते ते Purple Access वर पहा.
