iirc the 'wireshark' is a 30s .pcap file that is dumped into your web browser for download.
i am trying to recall if you can span off the switch. its been a month (and many beverages) since my meraki training. q. -= sent via iphone. please excuse spelling, grammar, and brevity =- > On Oct 10, 2013, at 18:47, Eric Van Tol <[email protected]> wrote: > > Thanks, Quinn, for not being a condescending prick - your answer was actually > helpful and to the point. The customer is not entirely knowledgable about > these switches, doesn't like them one bit, and had mentioned that they had a > problem before where the switches changed the MTUs dynamically on the ports. > It sounded far-fetched to me, but who knows what "the cloud" is doing these > days. Do these switches support ERSPAN or just local SPAN/RSPAN? > > We are trying to set up a remote device for RDP/Webex access so we can > actually troubleshoot from the customer side, as well as see if we can get > some Wireshark traces. > > The Meraki may well be a red herring, but I wanted to explore all "obvious" > (albeit strange) avenues, especially after being told about some weird > MTU-changing-switch jackassery. I really am at a loss as to why the customer > would even have trouble browsing his own locally-hosted website because of a > simple circuit migration we've made on our side, of which we've been through > over two dozen times this year alone. Obviously, more troubleshooting info > from the customer is needed. > > Thanks again, > evt > > >> -----Original Message----- >> From: cisco-nsp [mailto:[email protected]] On Behalf Of >> quinn snyder >> Sent: Thursday, October 10, 2013 9:06 PM >> To: [email protected] >> Subject: Re: [c-nsp] Meraki...information >> >> meraki switches create "pseduo-out-of-band" management tunnels to (2) >> geographically remote datacenters. this is how the changes are pushed >> from the cloud "dashboard" to the devices themselves. >> if the connectivity is lost, the devices should continue to push bits as >> previously configured. limited local management is possible, but not >> anywhere near the level provided by the dashboard. >> >> from a "packet" perspective -- no packets are pushed from the switch to >> the cloud. only management frames do this. >> >> it is possible perform a span session on the switch. i'd suggest >> looking at a wireshark capture to see if there is a fundamental change >> somewhere along the line. it may also be helpful to have the customer >> walk you through the configuration via webex or so. the level of config >> isn't much different from the "catalyst express" switches of yesteryear. >> >> q. >> >>> On 10/10/2013 05:31 PM, Eric Van Tol wrote: >>> Blake, >>> I'm well aware of how switching and buffering works, but I appreciate the >> derisive suggestion - it was a big help. >>> >>> However, for clarity: no errors (including input/output drops) on the >> transport circuit (or the customer's directly-attached circuit). >>> >>> Let me ask a more pointed question: >>> >>> Besides simple management, do the Meraki switches perform any other >> functions "in the cloud", or more specifically, rely on non-local upstream >> connectivity? >>> >>> I'm well aware that it makes absolutely zero sense that a change in our >> transport network would cause a local issue within the customer's network. >> However, the customer mentioned that they have had "odd" problems with these >> Meraki switches before when changes occurred outside our network. Thus, I >> felt it necessary to try and ask the list if anyone has ever heard of >> anything remotely like this before. >>> >>> -evt >>> >>> >>> From: Blake Dunlap [mailto:[email protected]] >>> Sent: Thursday, October 10, 2013 1:31 PM >>> To: Eric Van Tol >>> Subject: Re: [c-nsp] Meraki...information >>> >>> Not enough relevant information to assist. Due to what you have and >> haven't stated in this report I suspect you don't understand the >> fundamentals of how this change affects switching and buffering, and suggest >> reading about it and learning how the technology works at that fundamental >> level before proceeding. >>> Specifically, you never mention if there are asic or input drops, or even >> an indication that you looked for them or understand what these symptoms >> lean twords or what troubleshooting steps should be taken. >>> >>> -Blake >>> >>>> On Thu, Oct 10, 2013 at 12:04 PM, Eric Van Tol >>> <[email protected]<mailto:[email protected]>> wrote: >>> Hi all, >>> We ran into a very strange problem last night with a customer who utilizes >> Meraki switches. I'd like to ask anyone on the list who is familiar with >> this model of switch whether there is *any* possibility that an upstream >> modification would cause issues with traffic traversing these switches. >>> >>> A little background: we attempted to perform a migration of a transport >> circuit in our network from 1G to 10G last night, but the single customer >> attached to the ME3600 where the transport circuit was changed, started to >> have issues. There are no errors being reported on either end of the >> circuit, light levels are good, and we get consistent 1500-byte df-bit pings >> to their firewall from both inside and outside our borders. The transport >> circuit is not even a circuit that "touches" the customer's network. >> However, they report slow browsing from within their LAN (but not from their >> DMZ on the same ASA). When switching the transport circuit back to 1G, >> everything works fine. There is absolutely no difference in the routing, >> path, or IP addresses on this transport circuit - the only difference is >> link speed. >>> >>> Customer now believes the problem is with their Meraki switches, but we >> are both confused about how a change two physical hops upstream from their >> LAN would cause such issues. The "slow browsing" issue is definitely >> contained within their network, as they are not even able to browse their >> own website which is located entirely on their infrastructure and doesn't >> pass through the 10G link, or even through the CPE we provide. >>> >>> I know nothing about the Meraki product, besides the fact that it's a >> cloud managed solution. Has anyone ever heard of a problem like this before >> with this model of switch? >>> >>> Thanks, >>> evt >>> >>> >>> _______________________________________________ >>> cisco-nsp mailing list [email protected]<mailto:cisco- >> [email protected]> >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >>> >>> _______________________________________________ >>> cisco-nsp mailing list [email protected] >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> >> -- >> quinn snyder >> [email protected] >> _______________________________________________ >> cisco-nsp mailing list [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
