[c-nsp] Meraki...information

Thu Oct 10 22:28:14 EDT 2013

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 <eric at atlantech.net> 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:cisco-nsp-bounces at puck.nether.net] On Behalf Of
>> quinn snyder
>> Sent: Thursday, October 10, 2013 9:06 PM
>> To: cisco-nsp at puck.nether.net
>> 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:ikiris at gmail.com]
>>> 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
>>> <eric at atlantech.net<mailto:eric at atlantech.net>> 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  cisco-nsp at puck.nether.net<mailto:cisco-
>> nsp at puck.nether.net>
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>> 
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>> 
>> --
>> quinn snyder
>> snyderq at gmail.com
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/