Creo que lo más divertido (y estresante) de trabajar en Sistemas es encontrar soluciones a los retos que surgen todos los días.
Este mes ya evitamos que el usuario navegue por lugares que no debe, frenamos el modo de compartir internet desde los equipos personales, mejoramos la red de WiFi y creamos una de visitas(para más adelante el lab) y ahora nos enfrentamos a un nuevo desafío: Proveer una conexión a Google Meet con la mejor calidad posible.
Esta es una de las guerras en las que no vamos a poder ganar todas las batallas, pero podemos dar nuestro mejor esfuerzo y lograr un funcionamiento aceptable dentro de la red.
Factores que destruyen Google Meet
Para este laboratorio me basé en este documento oficial de Google Meet: https://support.google.com/a/answer/1279090?hl=es
Lo detallo para Mikrotik RouterOS y al final para implementar en Cisco ASA.(Lo testee en un ASA5515x y configuré desde ASDM)
De este documento obtengo los siguientes factores que pueden afectar la conexión en video calls:
1- Ancho de banda: Si bien google se puede adaptar a cualquier ancho de banda, si la red está muy saturada vamos a experimentar cortes, pérdidas de imagen y hasta el cartelito de: Problemas con su conexión. Este es el mecanismo al que apunto con el lab de hoy.
2- Consumo de Memoria Ram o CPU: Este factor va a depender del equipo del cliente. En el documento antes mencionado Google nos solicta que al empezar una conexión con Google Meet cerremos pestañas y aplicaciones que no usemos. Este factor solo lo puede atacar el usuario.
3- Calidad de imagen y transferencia de datos: Google nos recomienda modificar la calidad desde nuestra consola de Workspace configurando la «calidad de video» en configurar automaticamente. Eso debemos hacerlo desde el panel por el administrador de Google Workspace.
Garantizando el servicio
Google recomienda NO aplicar QoS (calidad de servicio) a las conexiones, para no limitar el ancho de banda disponible para Google Meet, pero de tener una red muy grande y que esto sea inevitable te da algunos consejos.
Basado en este dato defino una Queue que establezca, en este caso, 50Mbps de subida e igual de bajada para cualquier tráfico que tenga como destino las ips de google antes anunciadas.
/queue simple
add dst=74.125.250.0/24 max-limit=50M/50M name="Google Meet" target=""
add dst=142.250.82.0/24 max-limit=50M/50M name="Google Meet 2" target=""
Este ejemplo de Simple Queue funcionó a la perfección. Hay que colocarlo arriba de todas las demás Queues
De esta manera todo el tráfico que vaya a los servidores de Google Meet tendrá prioridad sobre el resto, garantizando el ancho de banda necesario para que todos puedan participar de la call sin problema.
La cantidad de Mbps que destines dependerá mucho del ancho de banda total que tengas. Les dejo parte de la documentación.
Casos fallidos
Solo para documentar incluyo un primer caso en el que traté de ser más específico y el ejemplo NO FUNCIONÓ como esperaba.
En este caso hice un marcado de paquetes según los datos de conexión que me daba la documentación oficial:
/ip firewall address-list
add address=142.250.0.0/15 list=google-meet
add address=172.217.0.0/16 list=google-meet
add address=172.253.0.0/16 list=google-meet
add address=74.125.0.0/16 list=google-meet
/ip firewall mangle
# Marcar conexiones basadas en IPs de Google Meet
add chain=prerouting protocol=tcp dst-address-list=google-meet action=mark-connection new-connection-mark=google-meet-conn passthrough=yes
add chain=prerouting protocol=udp dst-address-list=google-meet action=mark-connection new-connection-mark=google-meet-conn passthrough=yes
# Marcar conexiones basadas en puertos específicos de Google Meet
add chain=prerouting protocol=tcp dst-port=443 action=mark-connection new-connection-mark=google-meet-conn passthrough=yes
add chain=prerouting protocol=udp dst-port=19302-19309 action=mark-connection new-connection-mark=google-meet-conn passthrough=yes
add chain=prerouting protocol=udp dst-port=3478 action=mark-connection new-connection-mark=google-meet-conn passthrough=yes
# Marcar paquetes basados en las conexiones marcadas anteriormente
add chain=prerouting connection-mark=google-meet-conn action=mark-packet new-packet-mark=google-meet-pkt passthrough=no
/queue simple
add name=QoS-google-meet target=0.0.0.0/0 max-limit=50M/50M packet-marks=google-meet-pktEste ejemplo se basó en los datos que pasa Google para los Filtros de puertos a implementar:
Como veras, es la misma regla que antes pero con rangos de ips más grandes y detalles de los puertos y protocolos específicos que declara la documentación oficial.
Ahora en Cisco ASA (el ejemplo funcional)
Para Cisco ASA las reglas son exactamente las mismas que nuestro ejemplo que SI funcionó:
Cómo chequeamos que funcione?.
show service-policyVamos a ver las estadísticas de consumo de la ACL.
Conclusiones
Después de varias pruebas dentro de la red puedo ver, en el gráfico de la Simple Queue, que al establecer una conexión en un reunión virtual de Google Meet, el tráfico empieza a marcar sus característicos Picos mostrándome que la regla funciona.
De todas formas, cabe destacar que el ancho de banda garantizado no es suficiente para que Google Meet funcione correctamente. Me he topado con problemas de render cuando el usuario blurrea el fondo o pone algún filtro sobre la imagen, cuando tiene una aplicación corriendo en segundo plano que utiliza excesiva memoria ram o solo discos rígidos lo suficientemente lentos como para cargar toda la interfaz.
La solución en este caso es un summun de varias capas del modelo OSI.
