Purple WiFi सह Cisco Meraki एकत्रीकरण

This guide provides a definitive technical reference for deploying Purple WiFi on Cisco Meraki infrastructure, covering the dual-layer integration architecture — Dashboard API provisioning and Captive Portal API authentication — alongside step-by-step RADIUS and splash page configuration. It is designed for network engineers and IT managers who need to move from a functional guest WiFi deployment to a strategic guest intelligence platform, with measurable ROI outcomes drawn from live enterprise deployments including McDonald's Belgium, Harrods, and AGS Airports.

📖 10 मिनिटे वाचन📝 2,309 शब्द🔧 2 उदाहरणे❓ 3 प्रश्न📚 10 महत्त्वाच्या संज्ञा

🎧 हे मार्गदर्शक ऐका

ट्रान्सक्रिप्ट पहा

Cisco Meraki Integration with Purple WiFi — A Senior Consultant Briefing
Running time: approximately 10 minutes

INTRODUCTION AND CONTEXT (approximately 1 minute)

Welcome. If you are responsible for a Cisco Meraki deployment and you are trying to decide whether Purple WiFi is the right guest intelligence layer to sit on top of it, this briefing is for you. I am going to take you through exactly how the integration works, what you need to configure, where the common pitfalls are, and what kind of return you should realistically expect.

Let me set the scene. Cisco Meraki is, by a significant margin, the most widely deployed cloud-managed wireless infrastructure in the enterprise hospitality, retail, and public-sector space. It is reliable, scalable, and its cloud dashboard is genuinely excellent. But here is the thing — Meraki's native guest WiFi capabilities are functional, not strategic. You can get a guest online, but you cannot capture meaningful first-party data, you cannot build a marketing funnel from it, and you certainly cannot demonstrate ROI to your board. That is precisely the gap that Purple fills.

TECHNICAL DEEP-DIVE (approximately 5 minutes)

Let us talk architecture. The Purple and Meraki integration operates across two distinct technical layers, and understanding both is essential before you touch a single configuration setting.

The first layer is the Meraki Dashboard API — this is the provisioning layer. Purple uses Meraki's REST API to import your entire access point estate into the Purple Portal in a single batch operation. You authenticate with your Meraki API key, which you generate from the Organisation section of the Meraki dashboard under API and Webhooks. Once Purple has that key, it can pull every access point, every network, every SSID configuration directly from your Meraki cloud. For an estate of, say, three hundred access points across a hotel group, this reduces what would be a multi-day manual configuration exercise to something you can complete in under an hour. That is not a trivial operational saving.

The second layer is the authentication and captive portal layer — this is where the guest experience actually lives. Purple operates as an external splash page provider, using Meraki's Captive Portal API. When a guest connects to your guest SSID, Meraki intercepts their HTTP traffic and redirects them to Purple's hosted splash page — your branded captive portal. The guest authenticates through whatever method you have configured: social login, email form, SMS verification, or a combination. Purple then communicates back to Meraki via RADIUS — Remote Authentication Dial-In User Service — operating on port 1812 for authentication and port 1813 for accounting. Once RADIUS confirms the authentication, Meraki grants the guest full network access.

Now, let me walk you through the specific Meraki dashboard configuration, because the details matter here.

In the Meraki dashboard, navigate to Wireless, then Access Control. Select your guest SSID from the dropdown. Set the security to Open — yes, open, because the authentication is handled by the RADIUS and captive portal layer, not at the 802.11 association level. Set the splash page type to Sign-on with my RADIUS server. This is the critical selection — it tells Meraki to use an external RADIUS server for authentication rather than its own built-in options.

Under Advanced Splash Settings, set the captive portal strength to Block all access until sign-on is complete. Enable the walled garden — this is the list of domains that guests can reach before they have authenticated, which must include Purple's platform domains so the splash page itself can load. Purple provides a maintained whitelist of these domains in their support documentation.

For the RADIUS server configuration, you will need to add two servers — Purple provides primary and secondary endpoints for redundancy. The authentication port is 1812, and you will use the RADIUS secret provided in your Purple Portal. Add corresponding entries for RADIUS accounting on port 1813. Set the accounting interim interval to four minutes — this is important for accurate session tracking and analytics. Set the server timeout to five seconds with a retry count of three.

Under Advanced RADIUS Settings, configure the Called-Station-ID and NAS-ID to use the AP MAC address. This is critical for Purple's location analytics — without it, Purple cannot accurately attribute sessions to specific access points and therefore cannot generate meaningful floor-level analytics.

Then navigate to Wireless, Splash Page. Enter the custom splash URL provided by your Purple Portal — this is the URL of your branded captive portal. Configure the post-authentication redirect URL — typically your venue's website or a specific landing page.

Now, there is a second component worth discussing in detail: PurpleConnex, which is Purple's SecurePass solution. This creates a second SSID — typically named PurpleConnex — configured as a WPA2 Enterprise network using Purple's RadSec RADIUS servers. RadSec is RADIUS over TLS, which provides encrypted transport for authentication traffic. This SSID, combined with Hotspot 2.0 configuration — also known as Passpoint, the IEEE 802.11u standard — allows returning guests to reconnect automatically without seeing the captive portal again. Their device recognises the Passpoint profile and connects seamlessly. This is particularly valuable in environments where you want to eliminate the friction of repeat authentication, such as a hotel where a guest is staying for three nights, or a retail loyalty member who visits weekly.

The Hotspot 2.0 configuration in Meraki requires you to set the operator name to PURPLE colon GB, configure the domain list to securewifi.purple.ai, and add the Roaming Consortium OIs that Purple specifies. The NAI Realm is configured with EAP-TTLS and PAP authentication method. This is all documented in Purple's support portal, and it is straightforward once you understand what each field is doing.

IMPLEMENTATION RECOMMENDATIONS AND PITFALLS (approximately 2 minutes)

Let me give you the three most common failure modes I see in Meraki and Purple deployments, and how to avoid them.

First: walled garden misconfiguration. If your walled garden list is incomplete, guests will see a broken splash page — the CSS will not load, images will not render, and authentication will fail silently. Purple maintains a current whitelist of required domains. Treat this list as a living document and review it whenever Purple releases a platform update. I recommend testing the captive portal experience from a guest device on a separate network segment before go-live.

Second: RADIUS timeout settings. The default Meraki RADIUS timeout is often set too low for cloud-hosted RADIUS servers. Five seconds with three retries is the correct configuration. If you leave it at the default two seconds, you will see intermittent authentication failures during peak load — exactly the worst time for your guest experience to degrade.

Third: NAS-ID and Called-Station-ID misconfiguration. This is the one that catches engineers out most often. If you configure these fields incorrectly — or leave them as defaults — Purple's analytics engine cannot map sessions to specific access points. You will get aggregate data but no floor-level intelligence. The value must be set to AP MAC address, not SSID name or any other option.

On the compliance side: Purple's data capture is GDPR and CCPA compliant by design. The captive portal presents a consent mechanism that meets the requirements of both regulations. If you are operating in a PCI DSS scope environment — a hotel with a payment terminal on the same network segment, for example — ensure your guest SSID is on a separate VLAN with appropriate firewall rules. Meraki's NAT mode for client IP assignment, which is the recommended setting, provides a degree of isolation, but your network segmentation architecture needs to be reviewed by your security team independently.

RAPID-FIRE Q AND A (approximately 1 minute)

Question: Can Purple integrate with Meraki MX security appliances as well as wireless APs?

Answer: Yes. The configuration process is essentially identical — the MX supports the same splash page and RADIUS configuration as the wireless APs. The support article covers AP, MX, and Z1 teleworker gateway configurations.

Question: How long does a full deployment take for a 50-site hotel group?

Answer: With the automated provisioning via the Meraki API, the access point import is a single operation per organisation. The SSID and RADIUS configuration can be templated across networks. A 50-site deployment with a competent network engineer should be achievable in two to three days of configuration work, plus testing time.

Question: Does Purple support Meraki's newer Wi-Fi 6 and Wi-Fi 6E access points?

Answer: Yes. The integration operates at the application layer — RADIUS and HTTP redirect — so it is hardware-generation agnostic. Purple works with any Meraki AP that supports the splash page and RADIUS configuration described.

SUMMARY AND NEXT STEPS (approximately 1 minute)

To summarise: the Cisco Meraki and Purple WiFi integration is a mature, well-documented deployment that combines Meraki's excellent cloud-managed infrastructure with Purple's guest intelligence and data capture capabilities. The integration uses two primary mechanisms — the Meraki Dashboard API for automated provisioning, and the Captive Portal API with RADIUS authentication for the guest experience layer.

The three things to get right are: your walled garden configuration, your RADIUS timeout and retry settings, and your NAS-ID configuration for accurate location analytics.

The business case is compelling. McDonald's Belgium, Walmart Canada, and Harrods are all live Purple and Cisco deployments. AGS Airports achieved an 842 percent return on investment. Harrods turned 600,000 WiFi logins into a 57 times return on investment.

If you are ready to move forward, the next step is to generate your Meraki API key, log into the Purple Portal, and use the Hardware Import Wizard to pull in your access point estate. From there, your Purple account team can walk you through the SSID and RADIUS configuration in a single session.

Thank you for your time.

कार्यकारी सारांश

Cisco Meraki हे हजारो एंटरप्राइझ ठिकाणांसाठी (हॉटेल्स, रिटेल चेन्स, स्टेडियम्स आणि सार्वजनिक क्षेत्रातील सुविधा) पसंतीचे इन्फ्रास्ट्रक्चर बॅकबोन आहे. त्याचे क्लाउड-मॅनेज्ड आर्किटेक्चर मोठ्या प्रमाणावर ऑपरेशनल साधेपणा प्रदान करते, परंतु त्याच्या मूळ अतिथी WiFi क्षमता आधुनिक ठिकाण ऑपरेटरच्या आवश्यकतांपेक्षा खूपच कमी पडतात: फर्स्ट-पार्टी डेटा कॅप्चर, GDPR-सुसंगत संमती व्यवस्थापन, रिअल-टाइम फूटफॉल ॲनालिटिक्स आणि मार्केटिंग ऑटोमेशन एकत्रीकरण. Purple WiFi ही तफावत निर्णायकपणे दूर करते.

Purple आणि Meraki एकत्रीकरण दोन तांत्रिक स्तरांवर कार्य करते. Meraki Dashboard API स्वयंचलित बल्क प्रोव्हिजनिंग सक्षम करते — एकाच ऑपरेशनमध्ये Meraki संस्थेकडून शेकडो ॲक्सेस पॉइंट्स Purple पोर्टलमध्ये आयात करते. Meraki Captive Portal API, RADIUS ऑथेंटिकेशनसह एकत्रित होऊन, अतिथींना उत्तम अनुभव प्रदान करते: एक पूर्णपणे ब्रँडेड स्प्लॅश पेज, लवचिक ऑथेंटिकेशन पर्याय आणि सेशन अकाउंटिंग जे Purple च्या ॲनालिटिक्स इंजिनला डेटा पुरवते. परत येणाऱ्या अतिथींसाठी, PurpleConnex (SecurePass) SSID अखंड ऑटो-रिकनेक्शनसाठी Hotspot 2.0 (Passpoint, IEEE 802.11u) चा वापर करते, ज्यामुळे वारंवार ऑथेंटिकेशनचा त्रास दूर होतो.

या एकत्रीकरणाचे डिप्लॉयमेंट्स मोठ्या प्रमाणावर लाईव्ह आहेत: McDonald's Belgium, Walmart Canada, Harrods (600,000 लॉगिन्सवर 57× ROI), आणि AGS Airports (842% ROI). Meraki इस्टेटचे व्यवस्थापन करणाऱ्या आणि अतिथी WiFi मधून मोजता येण्याजोगे व्यावसायिक मूल्य प्रदर्शित करू पाहणाऱ्या कोणत्याही IT टीमसाठी, हे एकत्रीकरण त्या परिणामापर्यंत पोहोचण्याचा सर्वात ऑपरेशनलदृष्ट्या कार्यक्षम मार्ग आहे.

तांत्रिक सखोल माहिती

एकत्रीकरण आर्किटेक्चर

Purple आणि Meraki एकत्रीकरण नेटवर्क स्टॅकच्या वेगवेगळ्या स्तरांवर कार्य करणारे दोन समांतर API संबंध म्हणून उत्तम प्रकारे समजले जाऊ शकते. पहिले Meraki Dashboard REST API द्वारे मॅनेजमेंट-प्लेन एकत्रीकरण आहे, जे केवळ प्रोव्हिजनिंग आणि कॉन्फिगरेशनसाठी वापरले जाते. दुसरे Meraki Captive Portal API आणि RADIUS प्रोटोकॉलद्वारे डेटा-प्लेन एकत्रीकरण आहे, जे लाईव्ह अतिथी ऑथेंटिकेशन फ्लो नियंत्रित करते.

मॅनेजमेंट-प्लेन: डॅशबोर्ड API प्रोव्हिजनिंग

Meraki api.meraki.com/api/v1 वर एक व्यापक REST API एक्सपोज करते. Purple चे हार्डवेअर इम्पोर्ट विझार्ड ऑर्गनायझेशन-स्कोप असलेल्या API की चा वापर करून या API विरुद्ध ऑथेंटिकेट करते, आणि नंतर Meraki संस्थेतील सर्व नेटवर्क्स, SSIDs आणि ॲक्सेस पॉइंट्सची गणना करते. यामुळे नेटवर्क इंजिनिअरला 50 साइट्सवरील 300+ ॲक्सेस पॉइंट्सची इस्टेट एकाच बॅच ऑपरेशनमध्ये आयात करण्याची अनुमती मिळते — अशी प्रक्रिया ज्यासाठी अन्यथा प्रत्येक डिव्हाइससाठी मॅन्युअल एंट्री आवश्यक असते. Purple ची टू-वे इंटिग्रेशन क्षमता प्लॅटफॉर्मला Captive Portal, वॉल्ड गार्डन आणि RADIUS कॉन्फिगरेशन परत Meraki कडे पुश करण्याची अनुमती देते, ज्यामुळे मॅन्युअल कॉन्फिगरेशनचा भार आणखी कमी होतो.

आवश्यक API की जनरेट करण्यासाठी, Meraki डॅशबोर्डमधील Organisation > API & Webhooks > API Keys वर जा आणि Generate API Key निवडा. ही की एक विशेषाधिकार प्राप्त क्रेडेंशियल मानली जावी — ती सिक्रेट्स मॅनेजमेंट सिस्टीममध्ये स्टोअर करा आणि तुमच्या संस्थेच्या स्टँडर्ड क्रेडेंशियल लाईफसायकलवर रोटेट करा.

डेटा-प्लेन: Captive Portal API आणि RADIUS

अतिथी ऑथेंटिकेशन फ्लो साइन-ऑन मोडमध्ये Meraki चे Captive Portal API वापरतो. जेव्हा एखादा अतिथी अतिथी SSID शी जोडला जातो, तेव्हा Meraki चे ॲक्सेस कंट्रोल इंजिन पहिल्या HTTP विनंतीला इंटरसेप्ट करते आणि Purple-होस्ट केलेल्या स्प्लॅश पेज URL वर 302 रिडायरेक्ट जारी करते. स्प्लॅश पेज Purple च्या CDN इन्फ्रास्ट्रक्चरवरून सर्व्ह केले जाते; वॉल्ड गार्डन कॉन्फिगरेशन हे सुनिश्चित करते की ऑथेंटिकेशन पूर्ण होण्यापूर्वी Purple चे डोमेन्स पोहोचण्यायोग्य आहेत.

अतिथीने स्प्लॅश पेजवर ऑथेंटिकेशन पूर्ण केल्यावर, Purple चे प्लॅटफॉर्म पोर्ट 1812 वर Meraki AP ला RADIUS ॲक्सेस-ॲक्सेप्ट मेसेज जारी करते. त्यानंतर Meraki डिव्हाइसला पूर्ण नेटवर्क ॲक्सेस देते. पोर्ट 1813 वरील RADIUS अकाउंटिंग मेसेजेस Purple च्या ॲनालिटिक्स इंजिनला सेशन स्टार्ट, इंटेरिम अपडेट (दर 4 मिनिटांनी), आणि सेशन स्टॉप इव्हेंट्स प्रदान करतात, ज्यामुळे अचूक ड्वेल टाइम, सेशन कालावधी आणि रिपीट व्हिजिट कॅल्क्युलेशन्स सक्षम होतात.

ऑथेंटिकेशन पद्धती

Purple चे Captive Portal एकाधिक ऑथेंटिकेशन यंत्रणांना सपोर्ट करते, ज्या प्रत्येकाचे डेटा कॅप्चरचे परिणाम भिन्न असतात:

पद्धत (Method)	कॅप्चर केलेला डेटा (Data Captured)	GDPR संमती (GDPR Consent)	शिफारस केलेला युज केस (Recommended Use Case)
सोशल लॉगिन (Facebook, Google)	नाव, ईमेल, प्रोफाइल डेटा	इनलाइन संमती टिक-बॉक्स	हॉस्पिटॅलिटी, रिटेल लॉयल्टी
ईमेल फॉर्म	ईमेल, कस्टम फील्ड्स	इनलाइन संमती टिक-बॉक्स	कोणतेही ठिकाण, जास्तीत जास्त डेटा नियंत्रण
SMS पडताळणी	मोबाईल नंबर	इनलाइन संमती टिक-बॉक्स	उच्च-सुरक्षा किंवा वयोमर्यादा असलेली ठिकाणे
क्लिक-थ्रू (केवळ ToS)	डिव्हाइस MAC, सेशन डेटा	अटींची स्वीकृती	लो-फ्रिक्शन पब्लिक ॲक्सेस

PurpleConnex: SecurePass आणि Hotspot 2.0

PurpleConnex हा प्राथमिक अतिथी SSID सोबत डिप्लॉय केलेला दुसरा SSID आहे. हे WPA2 एंटरप्राइझ नेटवर्क म्हणून कॉन्फिगर केले आहे, ज्यामध्ये TLS ट्रान्सपोर्टसह पोर्ट 2083 वर Purple चे RadSec RADIUS सर्व्हर्स (rad1-secure.purple.ai आणि rad2-secure.purple.ai) आहेत. या SSID वर Hotspot 2.0 (Passpoint) सक्षम केलेले आहे, जे securewifi.purple.ai डोमेन आणि Purple रोमिंग कन्सोर्टियम OIs ची जाहिरात करते. जेव्हा परत येणाऱ्या अतिथीच्या डिव्हाइसने यापूर्वी Purple Passpoint प्रोफाइल डाउनलोड केले असेल, तेव्हा ते आपोआप PurpleConnex शी जोडले जाईल आणि सायलेंटली ऑथेंटिकेट करेल — कोणतेही स्प्लॅश पेज नाही, मॅन्युअल लॉगिन नाही. हॉटेलच्या वातावरणात हे विशेषतः प्रभावी आहे, जिथे अनेक रात्रींच्या मुक्कामासाठी चेक इन करणाऱ्या अतिथीला प्रत्येक डिव्हाइस रिकनेक्शनवर पुन्हा ऑथेंटिकेट करण्याची आवश्यकता नसावी.

Hotspot 2.0 कॉन्फिगरेशन iOS 14 आणि Android 10+ द्वारे सादर केलेल्या MAC ॲड्रेस रँडमायझेशन आव्हानाचे देखील निराकरण करते. कारण PurpleConnex ऑथेंटिकेशन MAC-आधारित ऐवजी क्रेडेंशियल-आधारित आहे, प्रत्येक कनेक्शन प्रयत्नावर डिव्हाइसने वेगळा रँडमाइज्ड MAC ॲड्रेस सादर केला तरीही Purple एक सुसंगत अतिथी ओळख रेकॉर्ड राखू शकते.

अंमलबजावणी मार्गदर्शक

प्री-डिप्लॉयमेंट चेकलिस्ट

कॉन्फिगरेशन सुरू करण्यापूर्वी, खालील पूर्वअटी पूर्ण झाल्याची खात्री करा. तुमच्या Meraki संस्थेमध्ये API ॲक्सेस सक्षम असणे आवश्यक आहे — हे Organisation > Settings > Dashboard API Access अंतर्गत एक संस्था-स्तरीय सेटिंग आहे. तुम्हाला तुमचे ठिकाण(णे) तयार केलेले आणि तुमचे SSID(s) कॉन्फिगर केलेले Purple पोर्टल खाते आवश्यक असेल. Meraki डॅशबोर्डला स्पर्श करण्यापूर्वी Purple पोर्टलवरून खालील मूल्ये मिळवा: RADIUS सर्व्हर होस्टनेम्स आणि शेअर्ड सिक्रेट, कस्टम स्प्लॅश URL, पोस्ट-ऑथेंटिकेशन रिडायरेक्ट URL, आणि वर्तमान वॉल्ड गार्डन डोमेन व्हाईटलिस्ट.

पायरी 1: Meraki API की जनरेट करा आणि ॲक्सेस पॉइंट्स आयात करा

Meraki डॅशबोर्डमध्ये, Organisation > API & Webhooks > API Keys वर जा आणि नवीन API की जनरेट करा. ही की त्वरित कॉपी करा — ती फक्त एकदाच प्रदर्शित केली जाते. Purple पोर्टलमध्ये, Venue Management > Import Hardware > Third Party API वर जा, Cisco Meraki निवडा आणि तुमची API की पेस्ट करा. Purple तुमच्या संपूर्ण ॲक्सेस पॉइंट इस्टेटची गणना करेल. तुम्हाला प्रत्येक Purple ठिकाणाशी जोडायचे असलेले ॲक्सेस पॉइंट्स निवडा आणि आयातीची पुष्टी करा.

पायरी 2: अतिथी SSID कॉन्फिगर करा — ॲक्सेस कंट्रोल

Meraki डॅशबोर्डमध्ये, Wireless > Access Control वर जा. ड्रॉपडाउनमधून तुमचा अतिथी SSID निवडा आणि खालील सेटिंग्ज लागू करा:

पॅरामीटर (Parameter)	मूल्य (Value)
SSID Status	Enabled
Security	Open
Splash Page	Sign-on with my RADIUS server
Captive Portal Strength	Block all access until sign-on is complete
Walled Garden	Enabled (सर्व Purple डोमेन एंट्रीज जोडा)
Simultaneous Logins	Allow
Controller Disconnection Behaviour	Default
Client IP and VLAN	Meraki DHCP (NAT mode)
Data-Carrier Detect	Disabled

RADIUS Servers अंतर्गत, तुमच्या Purple पोर्टलवरील शेअर्ड सिक्रेटसह पोर्ट 1812 वर दोन ऑथेंटिकेशन सर्व्हर्स (प्राथमिक आणि दुय्यम) जोडा. पोर्ट 1813 वर संबंधित अकाउंटिंग सर्व्हर्स जोडा. अकाउंटिंग इंटेरिम इंटरव्हल 4 minutes, सर्व्हर टाइमआउट 5 seconds, आणि रिट्राय काउंट 3 वर सेट करा.

Advanced RADIUS Settings अंतर्गत, Called-Station-ID आणि NAS-ID दोन्ही AP MAC address वर सेट करा. या फील्ड्समधून इतर कोणतीही मूल्ये काढून टाका.

पायरी 3: स्प्लॅश पेज कॉन्फिगर करा

Wireless > Splash Page वर जा. तुमच्या Purple पोर्टलवरून Custom Splash URL प्रविष्ट करा. पोस्ट-स्प्लॅश रिडायरेक्ट डेस्टिनेशन तुमच्या पसंतीच्या URL वर सेट करा — सामान्यतः तुमच्या ठिकाणाची वेबसाइट किंवा विशिष्ट प्रमोशनल लँडिंग पेज. बदल सेव्ह करा.

पायरी 4: PurpleConnex (SecurePass SSID) कॉन्फिगर करा

PurpleConnex नावाचा नवीन SSID तयार करा. सिक्युरिटी WPA2 Enterprise वर सेट करा. Wi-Fi Personal Network (WPN) अक्षम करा. RADIUS सर्व्हर्स अंतर्गत, RadSec (RADIUS over TLS) सक्षम करून आणि शेअर्ड सिक्रेट radsec सह पोर्ट 2083 वर rad1-secure.purple.ai आणि rad2-secure.purple.ai जोडा. RADSec TLS आयडल टाइमआउट 15 मिनिटांवर सेट करा. RADIUS CoA सपोर्ट अक्षम करा. RADIUS प्रॉक्सी सक्षम करा.

Wireless > Hotspot 2.0 वर जा. PurpleConnex SSID निवडा आणि खालीलप्रमाणे कॉन्फिगर करा:

पॅरामीटर (Parameter)	मूल्य (Value)
Hotspot 2.0	Enabled
Operator Name	PURPLE:GB
Network Type	Free public network
Domain List	securewifi.purple.ai
Roaming Consortium OIs	5A03BA0000, 004096
NAI Realm	securewifi.purple.ai (EAP-TTLS / PAP)

पायरी 5: पडताळणी आणि चाचणी करा

डिप्लॉयमेंट पूर्ण झाल्याचे घोषित करण्यापूर्वी, वेगळ्या नेटवर्क सेगमेंटवरील कंझ्युमर डिव्हाइसवरून संपूर्ण अतिथी प्रवासाची चाचणी करा. स्प्लॅश पेज योग्यरित्या लोड होत असल्याची, सर्व ऑथेंटिकेशन पद्धती कार्य करत असल्याची, पोस्ट-ऑथेंटिकेशन नेटवर्क ॲक्सेस 3-5 सेकंदात दिला जात असल्याची आणि सेशन डेटा 5 मिनिटांच्या आत Purple ॲनालिटिक्स डॅशबोर्डमध्ये दिसत असल्याची पडताळणी करा. Passpoint प्रोफाइल डाउनलोड करून आणि दुसऱ्या भेटीवर अखंड रिकनेक्शनची पुष्टी करून PurpleConnex ऑटो-रिकनेक्ट फ्लोची चाचणी करा.

सर्वोत्तम पद्धती

नेटवर्क सेगमेंटेशन आणि PCI DSS कंप्लायन्स. अतिथी WiFi ट्रॅफिक एका समर्पित VLAN वर आयसोलेट केले पाहिजे, ज्यामध्ये फायरवॉल नियम कॉर्पोरेट नेटवर्क सेगमेंट्समधील लॅटरल मूव्हमेंटला प्रतिबंधित करतात. जर तुमचे ठिकाण समान भौतिक नेटवर्क इन्फ्रास्ट्रक्चरवर पेमेंट कार्ड डेटावर प्रक्रिया करत असेल, तर औपचारिक PCI DSS स्कोपिंग एक्सरसाइज आवश्यक आहे. Meraki चा NAT मोड AP स्तरावर क्लायंट आयसोलेशन प्रदान करतो, परंतु स्विचिंग लेयरवरील VLAN सेगमेंटेशन हे PCI स्कोप व्यवस्थापनासाठी योग्य नियंत्रण आहे.

GDPR आणि CCPA डेटा गव्हर्नन्स. Purple चे Captive Portal ऑथेंटिकेशनच्या वेळी एक संमती यंत्रणा सादर करते, जे मार्केटिंग कम्युनिकेशन्ससाठी स्पष्ट ऑप्ट-इन कॅप्चर करते. तुमच्या Purple पोर्टल डेटा रिटेन्शन सेटिंग्ज तुमच्या संस्थेच्या डेटा गव्हर्नन्स धोरणाशी सुसंगत असल्याची खात्री करा. Purple चे प्लॅटफॉर्म डेटा सब्जेक्ट ॲक्सेस विनंत्या आणि राईट-टू-इरेजर वर्कफ्लोजना नेटिव्हली सपोर्ट करते, जे कस्टम Captive Portal सोल्यूशन्सच्या तुलनेत एक महत्त्वपूर्ण कंप्लायन्स फायदा आहे.

वॉल्ड गार्डन देखभाल. वॉल्ड गार्डन डोमेन लिस्ट हा एक जिवंत कॉन्फिगरेशन आयटम आहे. Purple चे CDN आणि प्लॅटफॉर्म इन्फ्रास्ट्रक्चर कालांतराने बदलू शकते आणि जुन्या वॉल्ड गार्डनमुळे स्प्लॅश पेजचा अनुभव खराब होईल. Purple च्या रिलीज नोट्स सबस्क्राईब करा आणि तुमच्या स्टँडर्ड चेंज मॅनेजमेंट प्रक्रियेचा भाग म्हणून वॉल्ड गार्डन लिस्टचे पुनरावलोकन करा.

रिडंडन्सी आणि फेलओव्हर. Purple अतिथी SSID आणि PurpleConnex या दोन्हींसाठी दोन RADIUS सर्व्हर एंडपॉइंट्स प्रदान करते. दोन्ही नेहमी कॉन्फिगर केले पाहिजेत. Purple प्लॅटफॉर्म आउटेजच्या स्थितीत, Meraki चे कंट्रोलर डिस्कनेक्शन बिहेवियर Default वर कॉन्फिगर करा — हे पूर्वी ऑथेंटिकेट केलेल्या सेशन्सना सुरू ठेवण्याची अनुमती देते तर नवीन ऑथेंटिकेशन्स रिट्रायसाठी रांगेत असतात.

Wi-Fi 6 आणि थ्रूपुट ऑप्टिमायझेशन. स्टेडियम्स आणि कॉन्फरन्स सेंटर्स सारख्या उच्च-घनतेच्या ठिकाणांसाठी, Meraki चे Wi-Fi 6 (802.11ax) ॲक्सेस पॉइंट्स समवर्ती अतिथी सेशन्ससाठी आवश्यक थ्रूपुट हेडरूम प्रदान करतात. Purple चे एकत्रीकरण हार्डवेअर-जनरेशन ॲग्नोस्टिक आहे — RADIUS आणि Captive Portal कॉन्फिगरेशन Meraki च्या AP उत्पादन पिढ्यांमध्ये एकसारखेच आहे.

ट्रबलशूटिंग आणि जोखीम निवारण

खालील तक्ता Meraki आणि Purple डिप्लॉयमेंट्समध्ये आढळणाऱ्या सर्वात सामान्य फेल्युअर मोड्स, त्यांची मूळ कारणे आणि शिफारस केलेले उपाय यांचा सारांश देतो.

लक्षण (Symptom)	मूळ कारण (Root Cause)	उपाय (Remediation)
स्प्लॅश पेज लोड होण्यात अपयशी (कोरे किंवा तुटलेले)	अपूर्ण वॉल्ड गार्डन	वॉल्ड गार्डन व्हाईटलिस्टमध्ये सर्व Purple डोमेन एंट्रीज जोडा
ऑथेंटिकेशन यशस्वी होते परंतु नेटवर्क ॲक्सेस दिला जात नाही	RADIUS टाइमआउट खूप कमी आहे	सर्व्हर टाइमआउट 5s वर सेट करा, रिट्राय काउंट 3 वर सेट करा
ॲनालिटिक्स प्रति-AP डेटा दाखवत नाही	NAS-ID / Called-Station-ID चुकीचे कॉन्फिगर केले आहे	Advanced RADIUS Settings मध्ये दोन्ही फील्ड्स AP MAC address वर सेट करा
पीक लोडच्या वेळी अधूनमधून ऑथेंटिकेशन फेल्युअर्स	सिंगल RADIUS सर्व्हर कॉन्फिगर केला आहे	प्राथमिक आणि दुय्यम दोन्ही Purple RADIUS एंडपॉइंट्स जोडा
PurpleConnex ऑटो-कनेक्ट होत नाही	Hotspot 2.0 चुकीचे कॉन्फिगर केले आहे	Roaming Consortium OIs आणि NAI Realm सेटिंग्जची पडताळणी करा
परत येणाऱ्या अतिथींना पुन्हा ऑथेंटिकेट करण्यास सांगितले जाते	PurpleConnex SSID डिप्लॉय केलेला नाही	Passpoint कॉन्फिगरेशनसह PurpleConnex SSID डिप्लॉय करा
GDPR संमती कॅप्चर केली नाही	स्प्लॅश पेज संमती फील्ड्स अक्षम आहेत	Purple पोर्टल स्प्लॅश एडिटरमध्ये मार्केटिंग ऑप्ट-इन फील्ड्स सक्षम करा

MAC ॲड्रेस रँडमायझेशन. आधुनिक iOS आणि Android डिव्हाइसेस डीफॉल्टनुसार रँडमाइज्ड MAC ॲड्रेसेस सादर करतात. याचा परिणाम अतिथी SSID वर परत येणाऱ्या अभ्यागतांना ओळखण्याच्या Purple च्या क्षमतेवर होतो. PurpleConnex / SecurePass सोल्यूशन MAC-आधारित ओळखीऐवजी क्रेडेंशियल-आधारित ऑथेंटिकेशन वापरून याचे निराकरण करते. ज्या ठिकाणांसाठी PurpleConnex डिप्लॉय करणे शक्य नाही, तिथे Purple चे प्लॅटफॉर्म प्रभाव अंशतः कमी करण्यासाठी सेशन मेटाडेटा वापरून प्रोबॅबिलिस्टिक मॅचिंग लागू करते.

Meraki फर्मवेअर सुसंगतता. तुमचे Meraki APs PurpleConnex साठी आवश्यक असलेल्या Hotspot 2.0 आणि RadSec वैशिष्ट्यांना सपोर्ट करणारी फर्मवेअर आवृत्ती चालवत असल्याची खात्री करा. प्रॉडक्शन डिप्लॉयमेंट्ससाठी Meraki च्या स्टेबल फर्मवेअर चॅनेलची शिफारस केली जाते; लाईव्ह अतिथी WiFi वातावरणात बीटा फर्मवेअर वापरले जाऊ नये.

ROI आणि व्यावसायिक प्रभाव

Meraki इस्टेटवर Purple डिप्लॉय करण्यासाठीचा बिझनेस केस एकाधिक व्हर्टिकल्समधील लाईव्ह डिप्लॉयमेंट्सद्वारे चांगल्या प्रकारे सिद्ध झाला आहे. खालील परिणाम प्रकाशित Purple केस स्टडीजमधून घेतले आहेत.

संस्था (Organisation)	क्षेत्र (Sector)	परिणाम (Outcome)
Harrods	लक्झरी रिटेल	600,000 WiFi लॉगिन्सवर 57× ROI
AGS Airports	ट्रॅव्हल आणि ट्रान्सपोर्ट	टियर्ड बँडविड्थ महसुलाद्वारे 842% ROI
McDonald's Belgium	क्विक सर्व्हिस रेस्टॉरंट	लाईव्ह Purple + Cisco Meraki + Socialspot डिप्लॉयमेंट
Walmart Canada	बिग बॉक्स रिटेल	Purple आणि Cisco सह एंटरप्राइझ-स्केल अतिथी WiFi
Miami HEAT (Kaseya Center)	स्पोर्ट्स आणि एंटरटेनमेंट	290,000 कनेक्शन्स, दरमहा सरासरी 28,000
c2c Rail	ट्रान्सपोर्ट	81,601 WiFi युजर्स → 151% ROI

ROI यंत्रणा सरळ आहे. Purple अतिथी WiFi ऑथेंटिकेशन इव्हेंट्सना फर्स्ट-पार्टी डेटा प्रोफाइल्समध्ये रूपांतरित करते — ईमेल ॲड्रेसेस, डेमोग्राफिक माहिती, भेटीची वारंवारता, ड्वेल टाइम आणि वर्तणुकीचे नमुने. हा डेटा Purple च्या API कनेक्टर्सद्वारे थेट CRM आणि मार्केटिंग ऑटोमेशन प्लॅटफॉर्म्समध्ये फीड केला जातो, ज्यामुळे टार्गेटेड मोहिमा सक्षम होतात ज्या रूपांतरण दर (conversion rate) आणि प्रति संपादन खर्च (cost per acquisition) या दोन्ही बाबतीत थर्ड-पार्टी ऑडियन्स डेटापेक्षा स्पष्टपणे चांगली कामगिरी करतात.

70% ऑक्युपन्सीवर चालणाऱ्या आणि प्रति रूम सरासरी 1.8 अतिथी असलेल्या 200-खोल्यांच्या हॉटेलसाठी, Meraki इस्टेटवरील Purple डिप्लॉयमेंट सामान्यतः दररोज 250-300 नवीन फर्स्ट-पार्टी प्रोफाइल्स कॅप्चर करेल. 3-5% च्या इंडस्ट्री-स्टँडर्ड ईमेल मार्केटिंग कन्व्हर्जन रेटवर, आणि £150 च्या सरासरी इन्क्रिमेंटल बुकिंग मूल्यावर, केवळ ईमेल री-एंगेजमेंटमधून मिळणारा वार्षिक महसूल सामान्यतः पहिल्या ऑपरेशनल वर्षातच Purple प्लॅटफॉर्म लायसन्सच्या एकूण खर्चापेक्षा जास्त असतो.

स्वयंचलित Meraki प्रोव्हिजनिंगमधून मिळणारे ऑपरेशनल कार्यक्षमतेचे फायदे हा एक दुय्यम परंतु अर्थपूर्ण फायदा आहे. 50 लोकेशन्सचे व्यवस्थापन करणाऱ्या मल्टी-साइट ऑपरेटरसाठी, मॅन्युअल कॉन्फिगरेशन वेळेतील कपात — प्रति साइट अंदाजे 3-4 तासांवरून 30 मिनिटांपेक्षा कमी — इंजिनिअरिंग रिसोर्स खर्चात लक्षणीय बचत दर्शवते.

महत्त्वाच्या संज्ञा आणि व्याख्या

Captive Portal

A web-based authentication gateway that intercepts a guest device's initial HTTP request and redirects it to a login or terms-acceptance page before granting network access. In the Meraki-Purple integration, the captive portal is hosted by Purple and delivered via a custom splash URL configured in the Meraki dashboard.

IT teams encounter this when configuring the Splash Page settings in the Meraki dashboard. The choice between Click-through (terms acceptance only) and Sign-on (RADIUS authentication) determines the level of data capture and security the deployment provides.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol (RFC 2865) that provides centralised authentication, authorisation, and accounting (AAA) for network access. In the Meraki-Purple integration, Purple operates RADIUS servers that receive authentication requests from Meraki APs on port 1812 and return Access-Accept or Access-Reject responses. Accounting data is sent to port 1813.

RADIUS is the backbone of the guest authentication flow. Network engineers need to configure the RADIUS server IP addresses, shared secret, and port numbers in the Meraki Access Control settings. Incorrect RADIUS configuration is the most common cause of guest authentication failure.

Walled Garden

A list of network destinations (IP addresses, domain names, or CIDR blocks) that a guest device is permitted to reach before completing captive portal authentication. In the Meraki-Purple integration, the walled garden must include all domains required by Purple's splash page — CDN assets, authentication provider endpoints, and the Purple platform itself.

IT teams must maintain this list as a living configuration item. An incomplete walled garden results in a broken splash page experience for guests. Purple publishes and maintains a current whitelist of required domains in their support documentation.

RadSec (RADIUS over TLS)

An extension to the RADIUS protocol (RFC 6614) that transports RADIUS messages over a TLS-encrypted TCP connection, providing confidentiality and integrity for authentication traffic. Purple's PurpleConnex SSID uses RadSec on port 2083, replacing the standard UDP transport used by the guest SSID RADIUS configuration.

RadSec is required for the PurpleConnex SecurePass SSID. Network engineers must enable the RadSec toggle in Meraki's RADIUS server configuration and use port 2083 rather than the standard 1812/1813. Failure to enable RadSec will prevent PurpleConnex authentication from functioning.

Hotspot 2.0 / Passpoint (IEEE 802.11u)

A Wi-Fi Alliance certification programme based on the IEEE 802.11u standard that enables automatic, secure network discovery and association. A device with a Passpoint profile will automatically connect to a compatible network without user intervention, using EAP-based authentication rather than a captive portal.

In the Meraki-Purple integration, Hotspot 2.0 is configured on the PurpleConnex SSID to enable seamless auto-reconnection for returning guests. This is particularly valuable in hospitality and retail environments where repeat authentication friction reduces guest satisfaction.

NAS-ID (Network Access Server Identifier)

A RADIUS attribute (Attribute 32) that identifies the network access server — in this context, the Meraki access point — that is sending the authentication request. Purple uses the NAS-ID to attribute guest sessions to specific physical access points, enabling floor-level location analytics.

This is one of the most commonly misconfigured parameters in Meraki-Purple deployments. It must be set to AP MAC address in the Meraki Advanced RADIUS Settings. Any other value (such as SSID name or a static string) will prevent Purple from generating per-AP analytics.

Meraki Dashboard API

A RESTful API provided by Cisco Meraki that allows programmatic access to the Meraki cloud management platform. It supports read and write operations across organisations, networks, devices, and configuration objects. Purple uses this API to import access point data and push SSID/RADIUS configuration during the provisioning phase.

IT teams need to generate an API key from the Meraki dashboard (Organisation > API & Webhooks) and provide it to the Purple Portal's Hardware Import Wizard. This key should be treated as a privileged credential and stored securely.

GDPR (General Data Protection Regulation)

EU Regulation 2016/679, which governs the collection, processing, and storage of personal data of EU residents. In the context of guest WiFi, GDPR requires that venues obtain explicit, informed consent before collecting personal data (such as email addresses) through a captive portal, and provide mechanisms for data subjects to access, correct, or delete their data.

Purple was among the first WiFi providers to achieve GDPR compliance. The Purple captive portal presents a consent mechanism at the point of authentication, and the platform supports data subject access requests and right-to-erasure workflows natively. IT teams should ensure that the Purple Portal's data retention settings align with their organisation's data governance policy.

PurpleConnex (SecurePass)

Purple's seamless reconnection solution, implemented as a second SSID configured with WPA2 Enterprise security, RadSec RADIUS transport, and Hotspot 2.0 (Passpoint) advertisement. Returning guests whose devices have downloaded a Purple Passpoint profile will automatically associate with PurpleConnex without seeing a captive portal.

PurpleConnex is deployed alongside the primary guest SSID and is invisible to first-time visitors. It resolves two key challenges: repeat authentication friction for returning guests, and MAC address randomisation (iOS 14+, Android 10+) which breaks MAC-based guest identification on the primary SSID.

Called-Station-ID (RADIUS Attribute 30)

A RADIUS attribute that identifies the access point or network access server that the client connected to, typically expressed as the AP's MAC address. Purple uses this attribute in conjunction with NAS-ID to map guest sessions to specific physical access points for location analytics.

Must be set to AP MAC address in Meraki's Advanced RADIUS Settings. This attribute works in tandem with NAS-ID — both must be correctly configured for Purple's floor-level analytics to function accurately.

केस स्टडीज

A 250-room four-star hotel group with 12 properties across the UK has a fully deployed Cisco Meraki estate (MR46 and MR57 APs, MX68 security appliances). They currently offer open guest WiFi with no captive portal. The IT Director wants to implement Purple WiFi to capture guest email addresses for the hotel's CRM, comply with GDPR, and generate analytics on peak-hour network usage. The deployment must be completed with minimal disruption to existing guests and must not require on-site engineer visits to any of the 12 properties. How should this deployment be structured?

The deployment should proceed in three phases, leveraging the Meraki Dashboard API for remote, zero-touch provisioning across all 12 properties.

Phase 1: Provisioning (Day 1, remote) Generate a Meraki API key scoped to the hotel group's Meraki organisation. In the Purple Portal, use the Hardware Import Wizard with the Third Party API option to import all access points across all 12 networks in a single batch. Assign each network to the corresponding Purple venue. This operation typically completes in under 20 minutes for an estate of this size.

Phase 2: SSID and RADIUS Configuration (Days 1–2, remote via Meraki dashboard) For each of the 12 Meraki networks, configure the existing guest SSID with the Sign-on with my RADIUS server splash page type. Add Purple's primary and secondary RADIUS servers on ports 1812 and 1813 with the shared secret from the Purple Portal. Set captive portal strength to Block all access, enable the walled garden with Purple's domain whitelist, and configure the custom splash URL. Set NAS-ID and Called-Station-ID to AP MAC address. Because Meraki's dashboard supports configuration templates, a single template can be applied across all 12 networks simultaneously, reducing per-site configuration time to near zero.

Phase 3: PurpleConnex Deployment (Days 2–3, remote) Create the PurpleConnex SSID on each network with WPA2 Enterprise and RadSec RADIUS configuration. Enable Hotspot 2.0 with the Purple operator name and domain settings. This SSID is invisible to guests who have not previously authenticated — it will auto-connect returning guests silently on subsequent visits.

Validation: Test the full guest journey remotely using a 4G-connected mobile device at one property before rolling the configuration live across all 12. Monitor the Purple analytics dashboard for session data ingestion within the first 24 hours of go-live.

The entire deployment is achievable in 2–3 days of engineering time with zero on-site visits, leveraging Meraki's cloud management and Purple's API provisioning.

अंमलबजावणीच्या नोंदी: This approach is optimal because it exploits the core operational advantage of the Meraki and Purple integration: the ability to provision and configure an entire multi-site estate remotely via API. The use of Meraki configuration templates is the key efficiency multiplier — without templates, a 12-site deployment would require 12 separate manual configuration sessions. The phased approach (provisioning, then guest SSID, then PurpleConnex) is correct because it allows the team to validate the primary guest journey before adding the complexity of the Passpoint/SecurePass layer. An alternative approach — deploying both SSIDs simultaneously — is technically feasible but increases the blast radius of any misconfiguration. The zero-on-site-visit constraint is fully achievable with this architecture, which is a significant operational and cost advantage over competing solutions that require local controller access.

A 60,000-capacity football stadium uses Cisco Meraki MR45 access points throughout the concourse, seating bowl, and hospitality suites. They want to deploy Purple WiFi to capture fan data, run in-venue surveys during matches, and integrate with their existing Salesforce CRM. The primary concern is scale: on match days, up to 35,000 concurrent WiFi sessions are expected. The stadium's IT team is concerned about RADIUS authentication performance under peak load. How should the RADIUS configuration be optimised for high-concurrency environments?

For a high-concurrency stadium deployment, the RADIUS configuration requires specific attention to redundancy, timeout parameters, and session management.

RADIUS Server Configuration for Scale: Configure both Purple RADIUS endpoints (primary and secondary) on every Meraki AP and MX in the estate. This is non-negotiable for a stadium deployment — a single RADIUS server configuration will create a single point of failure that will manifest as authentication failures precisely at kick-off, when concurrent connection attempts peak.

Set the RADIUS server timeout to 5 seconds and retry count to 3. This gives each authentication attempt up to 15 seconds before failing over to the secondary server, which is sufficient for a cloud-hosted RADIUS service under normal conditions. Do not reduce the timeout below 5 seconds in a stadium environment — the additional latency from concurrent load means that aggressive timeout values will cause false failures.

Set the accounting interim interval to 4 minutes. This generates a RADIUS Accounting-Interim-Update message every 4 minutes per active session, which Purple uses to calculate dwell time. In a stadium with 35,000 concurrent sessions, this generates approximately 145 accounting messages per second — well within Purple's platform capacity.

SSID and Network Segmentation: Deploy the guest SSID on a dedicated VLAN with a sufficiently large DHCP scope. A /16 subnet (65,534 addresses) is recommended for a 60,000-capacity venue. Ensure the DHCP lease time is set to match the expected session duration — for a 2-hour match, a 3-hour lease is appropriate. Short lease times will cause unnecessary DHCP churn and add load to the authentication infrastructure.

Salesforce CRM Integration: Purple's platform supports native Salesforce connector integration. Configure the CRM connector in the Purple Portal to push new guest profiles and session events to Salesforce in real time. Map Purple's data fields (email, visit count, dwell time, authentication method) to the corresponding Salesforce Contact and Campaign Member objects. This enables the stadium's marketing team to trigger automated post-match email campaigns within minutes of the final whistle.

In-Venue Surveys: Purple's MicroSurvey feature can be triggered post-authentication, presenting a 1–3 question survey on the splash page redirect. For a stadium deployment, configure the survey to trigger for a random 20% sample of authenticated guests to avoid survey fatigue while maintaining statistical significance.

अंमलबजावणीच्या नोंदी: The stadium scenario tests understanding of RADIUS at scale, which is the most technically demanding aspect of the Purple-Meraki integration. The critical insight is that RADIUS authentication is a synchronous, per-session operation — at 35,000 concurrent sessions, even a small percentage of authentication failures or timeouts creates a visible guest experience degradation. The dual-server configuration and correct timeout settings are the primary risk mitigations. The DHCP scope sizing and lease time recommendation demonstrates network architecture depth that goes beyond the Purple-specific configuration — this is the kind of holistic thinking that distinguishes a senior network architect from a configuration technician. The Salesforce integration and survey sampling recommendations address the business requirements (CRM integration, fan data capture) with practical implementation detail.

परिस्थिती विश्लेषण

Q1. A retail chain with 80 stores has deployed Cisco Meraki MR33 access points throughout their estate. They want to implement Purple WiFi but their security team has raised concerns about deploying an Open SSID for guest access. The security team argues that all SSIDs should use WPA2 encryption at minimum. How do you address this concern, and what is the correct security architecture for the guest WiFi deployment?

💡 संकेत:Consider the difference between link-layer encryption (WPA2) and application-layer authentication (captive portal + RADIUS). Also consider what the PurpleConnex SSID provides.

शिफारस केलेला दृष्टिकोन दाखवा

The security team's concern is valid in principle but reflects a conflation of two different security objectives. WPA2 encryption protects the radio link between the client device and the access point — it prevents eavesdropping on the wireless medium. However, for a public guest network, WPA2 Personal (PSK) provides minimal practical security because the pre-shared key is, by definition, publicly known to all guests. Any guest who knows the PSK can decrypt other guests' traffic using a passive capture attack.

The correct architecture is: deploy the guest SSID as Open (no WPA2) with a captive portal for authentication. This is the industry-standard approach for public guest WiFi because it allows the captive portal to function without requiring guests to know a password before they can reach the splash page. The security model relies on application-layer controls (HTTPS on the splash page, RADIUS authentication, VLAN isolation) rather than link-layer encryption.

For guests who require encrypted transport, the PurpleConnex SSID provides WPA2 Enterprise security with RadSec RADIUS — this is genuinely secure because each client receives a unique encryption key derived from their EAP credentials. Returning guests who have the PurpleConnex Passpoint profile will automatically connect to this encrypted SSID.

The complete security architecture is therefore: Open SSID for first-time guest onboarding (captive portal + RADIUS authentication + VLAN isolation) + WPA2 Enterprise PurpleConnex SSID for returning guests (RadSec + Passpoint). This satisfies both the guest experience requirement and the security team's encryption requirement for repeat visitors.

Q2. A conference centre is deploying Purple WiFi on their Meraki estate for the first time. Three weeks after go-live, the marketing team reports that the Purple analytics dashboard shows total session counts but no per-room or per-zone data — all sessions appear to be attributed to a single location. The network engineer who performed the configuration has left the organisation. What is the most likely cause, and how do you diagnose and resolve it?

💡 संकेत:Think about which RADIUS attribute Purple uses to map sessions to physical locations, and what the default Meraki configuration for that attribute is.

शिफारस केलेला दृष्टिकोन दाखवा

The most likely cause is that the NAS-ID and/or Called-Station-ID RADIUS attributes are not configured to use AP MAC address. When these fields are set to a static string, SSID name, or left at default, every access point in the estate sends the same identifier in its RADIUS messages. Purple's analytics engine receives identical location identifiers from all APs and cannot distinguish between them, resulting in all sessions being attributed to a single (or unknown) location.

Diagnosis: In the Meraki dashboard, navigate to Wireless > Access Control for the guest SSID. Scroll to Advanced RADIUS Settings. Check the values for Called-Station-ID and NAS-ID. If either field shows anything other than AP MAC address — such as SSID name, a static string, or multiple values — this is the root cause.

Resolution: Set both Called-Station-ID and NAS-ID to AP MAC address only. Remove any other values from these fields. Save the configuration. Note that this change takes effect for new sessions — existing active sessions will not be retroactively re-attributed. Within 5–10 minutes of the configuration change, new session data in the Purple analytics dashboard should begin showing per-AP attribution.

If the issue persists after correcting the RADIUS attribute configuration, verify that the Purple Portal has the correct AP MAC addresses imported and associated with the correct floor plan zones. If APs were imported before floor plans were configured, the MAC-to-zone mapping may need to be updated in the Purple Portal's venue management settings.

Q3. A 500-bed NHS hospital trust wants to deploy Purple WiFi on their existing Cisco Meraki infrastructure to provide patient and visitor WiFi. Key requirements are: GDPR compliance for data collection, content filtering to block inappropriate content on the patient network, seamless connectivity for long-stay patients (multi-day admissions), and integration with their existing patient engagement platform via API. What Purple features and Meraki configuration elements address each requirement?

💡 संकेत:Consider Purple's compliance features, Purple Shield DNS filtering, PurpleConnex for long-stay patients, and Purple's API/connector capabilities for the patient engagement platform integration.

शिफारस केलेला दृष्टिकोन दाखवा

Each requirement maps to a specific combination of Purple features and Meraki configuration:

GDPR Compliance: Purple's captive portal presents a consent mechanism at authentication, capturing explicit opt-in for data processing. The Purple Portal's data governance settings allow configuration of data retention periods aligned with NHS data governance policies. Purple supports data subject access requests and right-to-erasure natively. The splash page should be configured to present clear, plain-language consent language — not buried in terms and conditions — to meet the GDPR requirement for informed, unambiguous consent.

Content Filtering: Purple Shield is Purple's cloud-native DNS filtering service. It operates at the infrastructure level, filtering DNS queries before they resolve, and can be configured with category-based blocking (adult content, gambling, malware, etc.) appropriate for a patient environment. This is configured within the Purple Portal and applies to all authenticated sessions on the guest SSID without requiring additional hardware.

Seamless Connectivity for Long-Stay Patients: Deploy PurpleConnex with Hotspot 2.0 (Passpoint) configuration. Once a patient has authenticated once and downloaded the Passpoint profile, their device will auto-connect on subsequent associations — including after the device wakes from sleep, moves between wards, or reconnects after a brief disconnection. This eliminates the daily re-authentication friction that is a common complaint in hospital WiFi deployments.

Patient Engagement Platform Integration: Purple's platform exposes a REST API and supports pre-built connectors for major CRM and engagement platforms. Configure the Purple Portal's API connector to push authenticated session events (patient ID if captured at login, session start/end, ward-level location data) to the patient engagement platform in real time. If the engagement platform is not in Purple's pre-built connector library, the REST API allows custom integration development.

महत्त्वाचे निष्कर्ष

✓The Purple and Meraki integration operates across two distinct layers: the Meraki Dashboard REST API for automated bulk provisioning of access points, and the Captive Portal API with RADIUS authentication (ports 1812/1813) for the live guest experience — understanding this separation is essential for both deployment planning and troubleshooting.
✓The three most critical configuration parameters are: NAS-ID and Called-Station-ID set to AP MAC address (required for per-zone analytics), RADIUS server timeout of 5 seconds with retry count of 3 (required for reliability under load), and a complete walled garden domain whitelist (required for the splash page to load correctly).
✓PurpleConnex (SecurePass) deploys a second WPA2 Enterprise SSID with RadSec RADIUS and Hotspot 2.0 (Passpoint/IEEE 802.11u), enabling returning guests to auto-reconnect without a captive portal — this also resolves the MAC address randomisation challenge introduced by iOS 14+ and Android 10+.
✓GDPR and CCPA compliance is built into Purple's captive portal by design, with explicit consent capture at authentication, data subject access request workflows, and configurable data retention — making Purple a materially lower compliance risk than bespoke captive portal solutions.
✓The business case is well-evidenced: Harrods achieved 57× ROI on 600,000 WiFi logins, AGS Airports achieved 842% ROI, and McDonald's Belgium, Walmart Canada, and the Miami HEAT are all live Cisco Meraki and Purple deployments at enterprise scale.
✓For multi-site deployments, the Meraki Dashboard API enables batch import of entire access point estates into the Purple Portal in a single operation, reducing a multi-day manual configuration exercise to under an hour — the operational efficiency gain is a significant secondary benefit beyond the guest intelligence value.
✓Network segmentation is a non-negotiable prerequisite: guest WiFi traffic must be isolated on a dedicated VLAN with firewall rules preventing lateral movement to corporate segments, and any PCI DSS scoping implications of shared physical infrastructure must be formally assessed before go-live.