[c-nsp] Meraki...information

[Eric Van Tol]

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/