Bienvenido, Gustavo! Interesante tu experiencia! ... View more

Lo más fácil y ahorrador de tiempo, pudiera ser, para asegurarse que funciona bien el ap:   1.- Resetea (dejar el botón de reset presionado por 30 segundos, mientras esté energizado) 2.- Conectar directamente a un módem de internet que te de DHCP. 3.- Dejarlo por 10-15 minutos, a ver si contacta a la nube y jala de nuevo su configuración. (LED en verde o azul) 4.- Dejarlo así por 1 hora.   Y luego ya ponerlo de regreso en el segmento / puerto donde debe de ir.   Si lo anterior no funciona, tal vez necesites hablar a soporte y aplicar para un RMA. Ese modelo aún está bajo soporte hasta marzo 31 2024. ... View more

Si hablas de que no sale tal info en la página de los puertos de switch en el dashboard, igual sí abre un caso de soporte para que lo revisen. ... View more

Corregiré:   Requieres que el MX sea el default gateway para que éste aplique de forma diferenciada y correcta las group policies de las distintas VLANs en el acceso.   Lo anterior, dado que el MX requiere visibilidad de las direcciones MAC de los dispositivos finales, que el MX no vería si se dejara la función de default gateway a un switch capa 3 situado entre el MX y los dispositivos finales. ... View more

AH, it was kind of the back of my mind, but completely forgot. Thanks for the reminder, PhilipDAth! The power of the community! I stand corrected. ... View more

Lo que es una realidad es que, para que sea lo más rápido y conveniente el "plug and play" de switches meraki, idealmente se conectarían a una red que otorgue una IP por DHCP y salida a internet. Y ya desde la nube uno puede ir haciendo cambios respecto a la VLAN de gestión.   Yo no soy de la idea de evitar la VLAN 1 a toda costa. Creo que bien puede tener su uso para aspectos de levantar los equipos inicialmente. Por otro lado, me parece buena idea no usar la VLAN 1 para datos productivos.   Pero cuidado porque a veces VLAN1 juega un rol para pasar BPDU's (plano de control) que es con lo que se arma el spanning tree interoperando con otros sabores de STP distintos al estándar RSTP. Ver cuidadosamente esta guías de interoperabilidad, en particular las que tienen que ver con lo que por default corren los switches catalyst. Quitar, entonces, la VLAN 1 de troncales entre switches meraki y switches catalyst corriendo sus default RPVST o PVST+ no es recomendado.   Los MS390 y los nuevos switches Catalyst Meraki, corren el estándar MSTP por default. Los catalyst también soportan ese modo. Lo ideal a largo plazo es que todo use MSTP, en 1 instancia.. Es lo más transparente y menos complicado. No veo temas ahí haciendo prune de la VLAN 1 en troncales, incluso.   Aquí una lista interesante de recomendaciones de STP con switches meraki. Mencionamos dejar la VLAN 1 para propósitos de STP (no para datos).   Vean todo esto para propósitos de NO TENER TEMAS COMPLEJOS de troubleshooting de STP en ambientes híbridos. No por usar la VLAN 1 para estos aspectos de planos de control, significa que la organización está vulnerable a un ataque o algo así. STP es bastante plug and play, hasta que cosas extrañas suceden, si es que no se tomaron decisiones planeadas y deliberadas....y el troubleshooting entonces es muy complejo cuando hay problemas.   Alternativo a todo esto de la VLAN 1 permitida en as troncales y nativa, tal vez todo esté ok desde el punto de vista de topología STP usar una VLAN nativa distinta a la 1.....PERO HOMOLOGADA EN TODA LA RED LAN. De nuevo, no quieres meterte con problemas de topología STP inestable. ... View more

Tendrás un diagrama? Tengo dificultad para entender la situación y tu duda. Y tal vez pantallazo del dashboard con flechas descriptivas.   Es común que entre switches (cisco, o meraki, o de cualquier otra marca) la interconexión se haga con "troncales", 802.1q. Por default, los puertos de los switches meraki están todos configurados en troncales, pasando todas las vlans (no hay que crearlas, ya están), y vlan nativa 1. Las troncales idealmente tienen que tener la misma configuración en los dos switches, en los puertos usados para esa interconexión. Ambos puertos como troncales, admitiendo las mismas vlan y misma vlan nativa. Los dispositivos como teléfonos se conectan a un puerto de switch configurado como "acceso", y en esa configuración se define en qué vlan va. Aquí hay un par de módulos de cursos con detalle de cómo hacer configuraciones de puertos y uplinks/troncales.   No sé si ese switch que hablas tenga dos puertos potenciales de uplink (49, y 38). Los uplinks para los switches meraki, no tienen que ser los de fibra. Un uplink es el camino que el switch toma para establecer su comunicación de gestión con la nube. Tal vez se hizo un cambio en el switch cisco (remotamente via ssh) que hizo que en el meraki, que está debajo de ese swicth cisco, se cambiara el uplink. ... View more

Thinking you may be speaking of this topology, and if you set the client tracking by IP in that MX-only network, it should be possible for you to manually assign group policies by client IP.    Alternative that is more automated could be MX Active Directory integration. ... View more

Describes que tu implementación es parecido a esto. Si ese SW capa 3 no es uno meraki, pudieras en el MX hacer que el rastreo de clientes sea por IP. Track by IP. Una vez que el MX identifique los dispositivos por IP, ya puedes aplicar group policies de forma manual, si tu pregunta es el cómo aplicar políticas diferenciadas de las VLAN's que no terminan en el MX.   Otra alternativa puede ser integrar el MX con Active Directory.   Si esto te ayuda, darle en aceptar solución! ... View more

Hola Gsintes!   Lo que ves es como históricamente se ha dado, y probablemente así siga a futuro. La prioridad de Cisco es tener un producto que consideremos esté realmente listo para ser adoptado, y aprovechado, por las empresas que tengan decenas, cientos o miles de de AP's. Los fabricantes que mencionas apuntan a otro mercado y no cuentan con el tipo de clientes, exigencias y nivel de madurez tecnológica operativa que vemos.   Para conocer la posición de Cisco, directamente del la unidad de negocio de WiFi, puedes ver nuestra presentación en el Mobility Field Day. Minuto 40 aproximadamente.     ... View more

Hola! Las "Private subnets" que se especifican en el third party site to site VPN, corresponden a las subredes que están "detrás" del dispositivo remoto.   Y aquí, para una guía troubleshooting que puede ayudarte. ... View more

Adicional al tip de @alemabrahao te recomendaría los siguientes pasos:   1.- Ver el MX85 administrable desde la nube (lo más fácil es que conectes su puerto WAN a, digamos, un módem de internet que le dará una dirección IP por DHCP, y la salida necesaria a internet) 2.- Los MX por default están en modo ruteado y tienen una vlan con DHCP prendido. Solo revisar eso, y que los puertos del MX85 estén como troncales, dejando pasar todas las vlan, hasta la nativa (por default la 1) 3.- Conectar el switch ms225-24p, que recibiría una IP del MX85, y a través de él, se conectaría a la nube. 4.- Todos los puertos del switch, por default, están en troncal, vlan nativa 1. Esto significa que, si conectas una computadora, te daría una IP por DHCP proveniente del MX85, y te dejará salir y navegar a internet. 5.- Usar ese puerto para conectar uno de los MR36, que, como tu computadora, tomaría una IP por DHCP del MX85, y saldría a internet y se registraría con la nube. 6.- Repetir el paso 4 y 5 para el otro AP.   Recurso ... View more

Estando en automático el puerto WAN del MX68, y el del Módem, debiera no tener problemas. Yo los dejaría en auto. Por otro lado, si se pone el LED en naranja-rojo, como la foto, significa que desde la perspectiva del MX68, se perdió acceso a internet. Curioso el comportamiento que describes de los puertos LAN del MX68. Te sugiero marcarle a soporte para que recibas el soporte que la licencia ampara, y revisen a más detalle:   Encuentras todos los números telefónicos, yendo a la esquina superior derecha, bajo: "?" > Get help > Still need help? > Call the Meraki Support team > View regional phone numbers, ... View more

Bienvenido Héctor! Si hablamos de un MX68 nuevo, si conectas uno de sus puertos WAN a un puerto LAN de un modem ADSL, va a amarrar su velocidad en automático. La WAN del MX68 va agarrar una IP por dhcp y va a salir a internet, registrándose a la nube de gestión. Y si te conectaras a la LAN de ese MX68, debiera dejarte salir, sin restricción alguna. No me queda muy clara tu dificultad. Tal vez en el MX68 hay algunas reglas de firewall activas, en la salida hacia internet.   Has podido revisar la documentación? Te recomiendo: Security & SD-WAN (MX) Introduction course y Esta liga. ... View more

Si es hotel, comúnmente el SSID no tiene password (está abierto), y se invoca un portal cautivo externo ("splash page"). Para interactuar adecuadamente con ese portal cautivo externo, y ver ejemplos de configuración del SSID, puedes revisar la siguiente documentación: https://developer.cisco.com/meraki/captive-portal-api/overview/   A veces hay que poner algunos dominios en el "walled garden". Puedes revisar también esta documentación.   No me parece que haga sentido poner un preshared key, que haría la experiencia de conectarse a la red más compleja (tener q meter un password + tener que lidiar con el tema del splash page, que probablemente pida credenciales que el hotel está dando) ... View more

Hola Yordy! No es convención de industria especificar eso en hojas de datos de AP's wifi, porque hay muchas variables para responder. Es una pregunta común, que desafortunadamente no tiene una respuesta sencilla.   Lo que es un hecho es que los AP's tienen que cumplir regulaciones de la cantidad total de energía que emiten (potencia del AP mismo+ganancia de la antena), y uno se fija principalmente en el tipo de patrón de radiación de la antena (mostrado en datahseet), que es la que indica en dónde concentrará su energía. Y en base a lo anterior, luego uno usa herramientas como Ekahau Site survey para poder cargar mapas y hacer ejercicios predictivos, con simulación de obstáculos, y obtener una representación visual de lo que uno pudiera esperar respecto a la calidad de señal a determinada distancia.   ... View more

Mi experiencia es que sí puedes establecer meraki client VPN (o, alternativamente, con el anyconnect) sin contar con una IP dedicada en tu modem de internet.   El "truco" está en especificar unas reglas de port forward en tu modem (de puertos UDP 500, 4500 para client vpn, y usé tcp/udp 443 para anyconnnect). O sea, las regla dice que tráfico de entrada que llegue al modem, de esos puertos, se avance a los mismos puertos a la IP WAN del Meraki MX que está detrás del modem. Y en el client vpn o any connect, se usa el hostname del meraki MX que ves en appliance status (no especificas una IP). De esa forma, si cambia la IP de tu modem, a los 5 minutos aprox ese hostname meraki lo va a actualizar con el valor de esa nueva dirección pública.   Yo tengo también dos internets sin IP fijas, y eso lo hago en los dos modems para que funcione. ... View more

1.- Si quieres renovar 12, solo renueva eso. Quita 3 equipos que ya no usan de la "network" donde se encuentran, y así no cuentan versus el límite de licencias requeridas.   2.- Quitar de la "network" el equipo dañado, y metes a la "network" el equipo que ahora quieres usar.   Tener dispositivos en el inventario no te pide licencias. Solo cuando están en un "network" es cuando cuentan. ... View more

Meraki SD-WAN relies on an underlay network (whatever technology) that has ultimate reach to the internet-meraki cloud. The mechanism that builds the overlay, and its automated routing domain, is auto VPN. It is publicly documented in order to facilitate understanding of the mechanics and troubleshooting. https://meraki.cisco.com/product-collateral/auto-vpn-whitepaper/?file ... View more

Yes. One option is have the MX in the DC as a one arm concentrator. https://documentation.meraki.com/MX/Site-to-site_VPN/Configuring_Site-to-site_VPN_over_MPLS. And the management traffic of that MPLS remote link IP would have to go through a central DC firewall that is not the MX. Other option would be to have the remote MPLS link cloud mgmt traffic traverse the MPLS cloud, into the DC or central location, and then cross a meraki MX in routed/firewall mode that is there, from its LAN through its WAN. In that case, a tunnel would be established from remote WAN MPLS link, to central MX LAN side. Could not find documentation on that. ... View more

Puedes revisar esto   O con nuestros socios de ecosistema, "Splash Access", tienen esa capacidad desarrollada ... View more