Vous êtes sur la page 1sur 2

SUGERENCIAS GENERALES de configuracion AIRMAX

MCS / DataRate
Lo ideal es que todos trabajen con el mismo MCS ( o en maximo posible y automatico)
o al menos que todos trabajen con el mismo MCS, asi el AP no tiene que ir cambiando de velocidad
porque si tengo muchos clientes con MCS bajo, el AP consume mas tiempo de aire para atender a
todos, degradando la calidad.
Seria optimo probar en cada instalacion con el MCS maximo y automatico, y chequear el test local de ancho
de banda. Luego ir bajando el MCS , hasta encontrar el valor de mcs que de un test con mejores resultados.
Sin embargo, si el cliente no tiene señal muy buena, un MCS alto producira jitter o cortes ,
volviendo inestable el link debido a que intentara renegociar siempre la velocidad mas alta.
En ese caso, seria conveniente usar un MCS mas bajo, 9, 10 , 11 o 12… (no queda otra que
probar...)

FIRMWARE:
Quizas sea una obviedad , pero en lo posible que todos tengan el ultimo firmware.
Tarea que se hace mas sencilla mediante el AirControl

AIRMAX PRIORITY (AMP)


LOW = clientes residenciales
MEDIUM = clientes corporativos
HIGH = conexiones de backbone
NONE = reservar para clientes con señal mala (-70 o peor )
Cuidado con usar en muchos clientes AMP = HIGH ya que agota los timeslots del AP

DISTANCIA (automatica, o auto-ack)


El AP deberia quedar SIN auto distancia, poniendo la distancia al punto del cliente mas lejano sumando un
15%
Esta recomendacion es porque cuando el AP tiene muchas estaciones conectadas, consume muchos recursos
auto calcular la distancia de cada CPE, y comienza a funcionar mal.

Ademas el auto ajuste de distancia lo unico que hace es estimar la distancia del CPE mas lejano y luego
setearse en ese valor.
Las estaciones, van con Auto-Ack a menos que esten muy lejos en cuyo caso se recomienda no usar auto ack
25km para 20mhz, 17km en 40mhz.

En algunos casos, cuando el freznel o despeje no es del todo bueno, es posible que las estaciones no
calculen correctamente la distancia con AutoACK causando un mal funcionamiento de la misma en
determinados momentos. En ese caso se recomienda dejar fija la distancia, desactivando la funcion AutoACK.
Para detectar estos casos, se puede utilizar el AirControl, o entrando al status de cada estacion, (nos damos
cuenta porque la auto-deteccion de ack establece distancias muy distinas a las reales, ejemplo 100km)

CLIENTES CON SEÑAL DEBIL


Siempre hay que enfocarse en el cliente que peor señal tiene ya que el AP siempre se adapta el peor cliente.
Por lo tanto los peores DEGRARAN el nodo completo.
Si un cliente tiene valores muy distino en sus chains 0 y 1 se debe a interferencias o freznel
(puede ser tambien mala alineacion). Lo ideal seria poder lograr una diferencia de hasta 3db en los chains
Una ayuda seria poner el AP (en advanced) el parametro "ADVANCED Sensitivity Threshold" en -68 para
que rechace clientes con señal debil.
Ademas, una buena señal se logra con minimo SNR = 20 (es decir 20 es la diferencia entre la
signal y el noise floor)

CLIENTES CON SEÑAL MUY FUERTE


Se debe evitar señales superiores a -55 (leidas desde el AP).
Para ello se debera bajar el output power en las estaciones.
SEPARACION DE ANTENAS
Segun los usuarios mas "antiguos" de la comunidad, cada antena debe estar separada una
de otra a mas de 3 metros. Segun los usuarios mas "jovenes", con 1,5 metros es suficiente,
y tambien separando por varios MHZ unas de otras.
Tambien , si la poblacion de antenas es muy importante en la torre, en la comunidad ubiquiti
recomiendan de manera recurrente utilizar blindajes del estilo RF Armor http://www.rfarmor.com
En el siguiente Link, podremos observar la diferencia del uso de blindajes RF Armor, comparando
el antes y el despues. Aqui la comparacion.
Aparentemente la mejora de los niveles de señal y las reducciones de piso de ruido alcancan hasta
un 50%, segun los fabricantes.

DOBLE POLARIZACION
FALSO: Un equipo 1x1 (ej bullet, nanostations legacy viejos, o airgrid) obliga a todo el AP a trabajar en 1x1
Los CPE 1x1 NO AFECTAN a los CPE 2x2 conectados al mismo nodo.
Simplemente el punto seria que el AP demora mas tiempo en atender al CPE en 1x1 que al resto ya que
este solo puede asociarse a MCS7 en el mejor de los casos, degradando la performance del resto del nodo.
Fuente: http://community.ubnt.com/t5/Installation-Troubleshooting/1x1-airgrid-reduces-sector-capacity/m-
p/54...
gracias a (bydaro y a UBNT-Mike.Ford)

CALIDAD MINIMA
politica de calidad: solo permitir clientes hasta -70
señal recomendada por ubiquiti -60
Idealmente, no hay que conectar jamas clientes con peores niveles de señal ya que afectaran al resto de las
estaciones conectadas al mismo nodo.

Uso de canales de 10 MHZ, en PTMP


Por el momento parece ser que hay problemas en setups PTMP (punto - multi punto), con mas de
30 estaciones asociadas y utilizando canales de 10 MHZ.
Los problemas experimentados son latencia, jitter, continuos cambios en el TX DataRate (de las estaciones),
causando innumerables problemas. El VOIP se vuelve inusable en este caso.
Se soluciona totalmente el problema pasandose a canales de 20mhz. Si no hay posibilidad de moverse de los
10mhz, recomiendan en segundo lugar bajar el fw a 5.3.5 (solo en el AP), o bien, desactivar AirMax.
Ubiquiti esta al tanto de este inconveniente y esta intentando solucionarlo, segun lo reportado en el post:
http://community.ubnt.com/t5/airOS-Beta/5-5-2-High-jitter-on-10mhz-APs-with-gt-30-clients-Anyone-els...

WDS
usar WDS siempre. Ya que para administrar un nodo mediante PPPoE, HotSpot, o DHCP, podremos
aprovechar el parametro de la MacAddress para asociar al cliente o estacion.

TRAFFIC SHAPPING:
Conviene establecer en un valor alto: ejemplo 6 mbps en todos los casos, con el fin de aprovechar rafagas y
no saturar el nodo, siempre y cuando tengamos un sistema de administracion centralizado de queues.

SKYNET
Como verificar si tiene skynet virus un ubiquiti
Ingresando con algun cliente SSH al equipo (ejemplo putty)
ls -la /etc/persistent/
y verificar si aparece un archivo llamado ".skynet".
En caso afirmativo aplicar los siguientes aplicar los sigueintes comandos:
rm /etc/persistent/rc.poststart; rm -rf .skynet; save; reboot
Pueden contraer skynet los equipos con firmware anterior a 5.3.5.
Sin embargo si un equipo esta contagiado, la mera actualizacion de firmware no remueve el virus.

Vous aimerez peut-être aussi