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/
