DESCUBRIMIENTO AUTOMATICO DE ESTACIONES EN

ZABBIX

Nota:
El siguiente instructivo aplica para estaciones Ubiquiti AC.

Descripcion:
Se realiza Discovery para las subredes correspondientes a X nodo. Para que se pueda crear el host con
su nombre se utiliza el check al sysName, un check a ubntRadioMode que indicara el modo del radio
(AP=4 o ST=1), y un ckeck para verificar si es AC (con ifNumber=7 sabemos si es AC y si es
ifNumber=6 es M). El action debe aplicar para estar regla del discovery y la condicion debe cumplir
que sea ST (si el radio no es Ubiquiti no respondera el chek a ese OID) y que sea AC. En caso
afirmativo se ordena crear el host.

1- CREACION DEL DISCOVERY

Desde Configuration / Discovery se crea la regla en “Create discovery rule”

Indicar nombre del discovery, rango de ip a escanear, intervalo del escaneo, y las comprobaciones. Los
checks a agregar son:
Tipo Descripcion
ICMP PING Consulta ping
SNMPv1 agent ".1.3.6.1.2.1.1.5.0" sysName
SNMPv1 agent ".1.3.6.1.4.1.41112.1.4.1.1.2.1" ubntRadioMode
SNMPv1 agent ".1.3.6.1.2.1.2.1.0" ifNumber

2- CREACION DEL ACTION

Desde Configuration / Actions > Discovery Actions se crea la regla en “Create action”
En condiciones del Action debe cumplir:
Tipo Descripcion
Discovery status=Discovered Que este descubierto por el discovery
Received value=7 Que virtualmente tenga 7 interfaces para confiar
que es AC, si tiene 6 sera M
Received value=1 Que sea ST, de lo contrario sera 4 que es AP
En Operations realizaremos:
Tipo de Operacion Descripcion
Add host Crear host (estacion)
Add to host group: Ubiquiti Radios Vincular el host al grupo
Link to template: Template Ubiquiti AirOS 8 Colocar plantilla al host
Enable host Habilitar
Set host inventory mode: Automatic Inventario automatico del host

3- Verificar los Equipos Descubiertos

Desde Monitoring / Discovery se pueden ver los equipos que han sido descubiertos, la salida es similar
a: So If I can separate UPD and TCP traffic the best way is keeping a dedicated queue with an
allocated bandwidth. And should WRED be applied to this UPD dedicated queue?

If in your environment (app/infrastructure requirements) you can separate both, you'll avoid TCP
starvation by UDP dominance, because UDP will be contained to the maximum BW allocated to their
queue unless congestion is not experienced in your network.
 I suppose that applying WRED over this UDP dedicated queue can be more effective to avoid TCP
starvation not only when the UDP and TCP traffic can’t be separated.

About WRED: WRED is used to avoid full TCP synchronisation. If you find that TCP sessions are
frequently experimenting that event, then dropping some traffic is better than applying Tail Drop and
resynchronise all the flows. You don't need to use WRED in the UDP dedicated queue.

Los equipos que se muestran en Monitored host son los que ya estan siendo monitoreados por Zabbix;
es decir que ya creo ese host.

4- Verificar los Host creados

Desde Monitoring / Host se puede ver los equipos que han sido creados por el action del discovery.
En la imagen se ve que se crearon ST01 y ST03 aunque estan habilitados los host, aun no se les han
realizados comprobaciones a items por snmp por ello no muestra SNMP activo (el template que se le
asigno tiene un discovery que se encarga de crear los items)
Una vez el host tiene consultas activas a los items por SNMP se puede apreciar que se esta
monitoreando por SNMP y se ve la plantillada que se configuiro en el action.

Nota: si la regla discovery interna que traen los host con la plantilla se tarda en ejecutar, se puede
ingresar al host y ejecutar el discovery manualmente. Luego se puede descativar el discovery