[c-nsp] Meraki...information

[quinn snyder]

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