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:[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/
