Proactive PCAP

[New2Meraki]

Hi all -

I recently started at a company that uses Meraki so I'm on a learning curve.  One of the cool things I noticed is that Meraki wireless can now automatically capture packets if a client has issues joining wifi (or roaming, believe).  But there's a part that doesn't pass the sniff test and I'm not clear what's going on. 

1) It's not enabled by default.

2) Once you enable it, you choose how broadly to turn it on (just this AP, this entire network, etc).

I can't think of even a single scenario where you wouldn't want this working on every single AP, by default.  There's obviously a reason Meraki doesn't turn this on by default and perhaps the same reason it isn't applied to all AP's by default.

What's the downside to turning this on everywhere?  Why would you ever choose to turn it on only in some places, but intentionally remain in the dark for wireless issues in other parts?  What's the tradeoff that's not mentioned in the documentation?

[New2Meraki]

Interesting, thanks for your thoughts! I'd be very interested in an actual response from PM as the guesses still don't provide a reasonable answer (IMO).  I hope this comes across as intended, which is genuinely just trying to understand. 

There's a feature that, if it works as advertised, any customer outside a true mom-and-pop would want turned on everywhere, by default.  But it's not, and Meraki went to a lot of trouble to build a workflow that requires you to specify if it should be on at all and, if so, where exactly you want it on.  You provided 3 reasons, which I'll restate below to see if I'm understanding correctly.

- First reason is because it's new, quite probably buggy, and could cause real production impact.  Hence many customers shouldn't turn it on outside a lab.  If true, this should be spelled out more clearly in the documentation.  Like a VERY clear warning that turning this on could cause serious production impact.

- Second, it will require an advanced license eventually and not many people have that.  But this would only make sense if Meraki will auto-charge those who don't have a license once it becomes required.  I can't imagine that would be true but, if so, it's ridiculous that it isn't spelled out clearly.

- Third reason is that some customers don't care if wireless is working well or not, so not turning it on saves Meraki on storage.  This seems like a major reach (no offense intended whatsoever)...

For the 3rd reason to be true, Meraki would have to genuinely believe that a significant number of their customers are so far down on the SMB spectrum that they literally just do not care if wifi is working or not.  And if it isn't working, they simply do not want to have the evidence to troubleshoot and remediate - even if they gain absolutely nothing by not having it enabled.  I don't mean this as disrespectful but this would seem like an awful assumption to actually believe your customers are buying your product, deploying it, and then just stop caring if it works or not.

Again, I really hope this comes across ok.  It's just fishy that this amazing new feature is released that, if it works as advertised, any reasonable customer would want turned on everywhere - by default.  But it's not and there must be an extremely compelling reason that Meraki made this decision.  There's something we're not being told in the documentation and I'm not sure why 😕

[cmr]

I tested it on a small network and it captured a few hundred sessions in a couple of days.  It will only let you store a certain amount and in any reasonable size network you would end up with many thousands of captures in a day.  This is why I think you are only meant to enable it for particular troubleshooting.

[cmr]

I've also noticed that it now needs the advantage/advanced license, which I don't remember being the case when it was first available? 

If you have that then you can store up to 4GB of captures in the cloud with proactive capturing.

As PDL allows you to apply an advantage license to individual APs, with the rest left at Enterprise, you could just enable it on those.

[Ryan_Miles]

https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Packet_Capture_Overvi...

Same as MS130 adaptive policy in that during early access phase license enforcement is not enabled.

[TyShawn]

Let's make this phase a long as possible 🙂 we are in noooooooo rush ;).

[TyShawn]

Yeah they changed it at some point I recall seeing the advance warning when I noticed the feature. 

[New2Meraki]

Right, but using this method significantly weakens the effectiveness.  If this feature actually works then you end up with a network you can troubleshoot with proactive notification in some places but not in others.  That sucks. 

[New2Meraki]

WHOA.  If accurate, this makes the feature MUCH less compelling.  The entire point of Proactive Pcap is to capture issues the first time they happen, and provide a dynamic pcap for the evidence.  If you only turn it on to troubleshoot once there's an issue then you've already lost the entire "proactive" part. 

[Packetmike]

I suspect the reason Meraki gives you the option to enable proactive capture may be driven by regulatory requirements for data storage. 

Government type customers in particular generally have requirements around cloud storage to be limited to certain jurisdictions (it might be ok for configuration to be stored off shore, but not pcaps).

And that also could be the reason why you would want to enable this on only some networks or devices with in that network.  

[MinseK]

Thank you for all of insightful discussions. Your contributions have been invaluable in shaping perspectives on what Cisco should prioritize next. Proactive Capture has been meticulously developed over the past few years from the Cisco Meraki innovation labs. Our goal was to design a groundbreaking solution that sets a new benchmark in the market. We aimed to not only exceed expectations but to redefine the standard of innovation and deliver unparalleled outcomes that elevate the user experience to an entirely new level.

Having said that,  I’d like to take this opportunity to outline the reasoning behind the explicit enablement approach for Proactive Packet Capture (PCAP).

1. Cloud-Based Packet Capture Storage
   The Meraki cloud has traditionally served as a management and configuration plane, without storing or transporting end-user data packet or payload—except in specific scenarios, such as SD-WAN with Umbrella Secure Internet Gateway. With the introduction of Intelligent Capture, which stores PCAP files in the cloud, containing payload data, we made a conscious decision to require explicit customer action to enable this feature. This ensures alignment with customer expectations and maintains transparency in how data is handled.
   
   

2. Uplink Traffic Consumption
   Proactive PCAP leverages secure tunneling to transfer PCAP files between MR/CW access points and the Meraki cloud. This process can increase uplink traffic consumption beyond the 1 Kbps baseline previously communicated and published, particularly in large-scale networks. To prevent unintended uplink bandwidth increase, the feature is designed to be activated at the customer’s discretion, ensuring network traffic remains within manageable thresholds.
   
   

3. Preserving Customer Configuration Integrity
   At Cisco, we recognize that customers place immense value on maintaining full control over their network configurations. We respect this autonomy and adhere to a strict policy of not altering configurations without explicit enduser consent or approval. Since enabling Proactive PCAP modifies access point behavior and cloud interaction, we’ve ensured that activation requires deliberate customer action, safeguarding network integrity. This deliberate approach reflects Cisco’s commitment to customer-centric design and operational transparency. I hope this clarifies any concerns regarding the enablement process.
   

lastly, let me address few additional questions that brought in the discussion, 

Q1> Does Proactive PCAP require an ADV license? Wasn’t it part of the Enterprise license initially?
A1> No, Proactive PCAP as a part of Intelligent Capture feature—has always required an ADV license. This was explicitly stated in the Early Access dashboard and documentation, though the license requirement banner was not displayed during the Early Access period. The banner was added when Intelligent Capture transitioned to General Availability in January this year. However, not all Intelligent Capture features require an ADV license. Customers with an Enterprise license can still access On-Demand PCAP and will soon have access to Scheduled PCAP.

Q2> Are there scalability concerns if Proactive PCAP is enabled across all APs?
A2> There are no scalability concerns or issues with enabling Proactive PCAP on all APs. The option to enable it per AP or per Tag was introduced solely to address uplink traffic consumption, as explained earlier. In fact, I recommend enabling it across all APs where feasible. While Proactive PCAP may generate thousands of files, they are automatically purged after seven days, ensuring no long-term storage impact.

Lastly, thank you for leveraging the Proactive PCAP feature. As a Cisco employee, nothing brings me greater joy than seeing customers uses the services and solutions that our team has tirelessly worked on countless hours to deliver exceptional value and an outstanding experience. we truly believe Meraki magic and love to make it expended and transpired to Cisco magic!

[GIdenJoe]

Hey, it would be great to have the option to choose between proactive on select AP's you have now or have a deliberate configuration where you select a few clients to track and ALWAYS capture their probes, auth, assoc, disassoc, reassoc, dot11v, dot11k,4way handshake, and action frames pertaining key exchanges.  This feature would provide a ways to monitor certain clients for a while if issues arise.

The problem with the current implementation is that most proactive captures happen when a client decides to roam but has a EAPoL timeout due to it roaming again.  These captures are mostly quite useless since they usually don't show a problem.

[MinseK]

Thank you @GldenJoe for the feeedback!  let us think about what you have proposed. and indeed we have exact PCAP option which you described in Catalyst Center version of Intelligent capture. (Manual Onboard Packet capture with specified client MAC address) while we took different approach this time. proactive PCAP designed to happen everytime client failed to connect or failed to roam. and when it failed to roam, it designed to capture from two APs and combine it then stored in in single file for later analysis or download.

[GIdenJoe]

While I do like the function, the current way of doing it will result an many pcaps littering the storage while being of little use since many of them will just be client roaming decisions.

- Some of these are also mismarked: Like the no DNS response just contains an ARP request ARP reply conversation where these are repeated several times.

I would also like to add a few other smaller remarks:
- In wireshark you have the ethers file where you can add mac addresses for your access points so you can instantly see in your wireshark capture what AP is involved.  This is a bonus feature but would be awesome.

- Also I have noticed that in case some frames are heard by two AP's on the same channel all these frames are put into the same pcap file without filtering identical frames out.  The issue here is that the pcap will contain multiple duplicate frames.  The only way to know that the source is a different capturing AP is when looking inside the radio tap header that the RSSI is different.

So my opinion is having the same way Catalyst Center does it or at least as an option would be better, adding consistency to Cisco products, and in this case you could more easily draw the timeline and have the more enriched version of the roaming analytics.  Because when tracking one client and then filtering the pcaps to only have the frames between the client and the current AP it is communicating to is more clear and then you can also see the behavior of the client why it is moving to this AP and perhaps stopping and then connecting to yet another AP while seeing that in one big capture aiding in understanding why a client does a certain move.  You could then project that up to the roaming analytics where each AP in question shows it's current channel + load and some given 802.11v suggestions to the client.

[MinseK]

Thank you for the feedbacks and this is certainly worth investing further and looking into.