Proyectos

ASN 32 bit y Router Cisco

publicado a la‎(s)‎ 15 jul. 2014 9:20 por Dario Fernandez

Un Sistema Autónomo (en inglés, Autonomous System: AS) se define como “un grupo de redes IP que poseen una política de rutas propia e independiente”. Esta definición hace referencia a la característica fundamental de un Sistema Autónomo: realiza su propia gestión del tráfico que fluye entre él y los restantes Sistemas Autónomos que forman Internet. Un número de AS o ASN se asigna a cada AS, el que lo identifica de manera única a sus redes dentro de Internet.

Actualmente se utilizan ASN de 32 bit (2^32=4294967296), pero antes se utilizaban hasta 16 bit (2^16=65536)
Para hacer BGP en un router cisco tenemos que poner los siguientes comandos:

router bgp [NuestroASN]
 bgp router-id [NuestraIP]
 bgp log-neinghbor-changes
 neighbor [IP1] remote-as [ASN1]
 neighbor [IP1] description [NombreDelPeer]
...
...

Por ejemplo para peer de hasta 16 bit

router bgp 52404
 bgp router-id 200.100.100.254
 bgp log-neinghbor-changes
 neighbor 200.100.100.1 remote-as 65535
 neighbor 200.100.100.1 description RESEARCH-PEER-01

...
...

Pero en el caso de tener un ASN superior a 65536 tenemos que dividirlo en 2 de 16 bit (X.Y)
Supongamos un ASN = 409600
Dividimos por 65536 y sacamos la parte entera:
409600/65536=6,25
Separamos la parte entera y los decimales (6) y (0,25)
Estos serían X e Y, pero Y hay que volver a multiplicarlo por 65536
X.Y => 6.(0,25x65536) => 6.16384
Quedando de esta manera

router bgp 52404
 bgp router-id
200.100.100.254
 bgp log-neinghbor-changes
 neighbor
200.100.100.1 remote-as 65535
 neighbor 200.100.100.1 description RESEARCH-PEER-01
 neighbor 200.100.100.2 remote-as 6.16384
 neighbor 200.100.100.2 description RESEARCH-PEER-02

...
...

Configuracion de Red OSPF / MPLS / VPLS

publicado a la‎(s)‎ 17 dic. 2013 5:41 por Dario Fernandez   [ actualizado el 17 dic. 2013 6:31 ]

Enrutamiento OSPF para proyecto de fibra óptica urbana Research SRL.


Router de 5 puertos gigabit

ether1 -> anillo hacia cliente anterior

ether2 -> anillo hacia cliente posterior

ether3 -> red lan del cliente

ether4 -> vacante

ether5 -> vacante


Ejemplo de configuración de 2 clientes anillados, vínculo a levantar entre (cliente 1 -> ether2) y (cliente 2 -> ether1)

Configurar cliente 1:

Creamos un brige loopback, le asignamos una ip de gestión y lo convertimos en default para ospf


/interface bridge add name=loopback

/ip address add interface=loopback address=10.255.255.1/32


Asignamos ip a los puertos del anillo y lan del cliente

red 1.1.1.0, mascara 255.255.255.252, broadcast 1.1.1.3, quedando libre para el otro punto 1.1.1.2

red 1.1.1.4, mascara 255.255.255.252, broadcast 1.1.1.7, quedando libre para el otro punto 1.1.1.6


/ip address

add interface=ether1 address=1.1.1.1/30

add interface=ether2 address=1.1.1.5/30


Creamos la instancia OSPF, le asignamos las interfaces y las networks


/routing ospf instance

set [ find default=yes ] distribute-default=if-installed-as-type-1 \

   redistribute-connected=as-type-1 router-id=10.255.255.1


/routing ospf interface

add interface=ether1 network-type=point-to-point

add interface=ether2 network-type=point-to-point


/routing ospf network

add area=backbone network=1.1.1.0/30

add area=backbone network=1.1.1.5/30


Configuración de MPLS siglas de (Multiprotocol Label Switching) / (Conmutación Multi-Protocolo mediante Etiquetas)

Configuramos ldp (protocolo para distribución de etiquetas) por ejemplo en el core, asignamos el mismo ID que el loopback y la dirección de transporte, también las interfaces del anillo


/mpls ldp

set enable=yes lsr-id=10.255.255.1 transport-address=10.255.255.1

/mpls ldp interface

add interface=ether1

add interface=ether2


Configuración de enlaces de Lan privada virtual (VPLS) montados en MPLS

Siguiendo el esquema, cada punto del anillo tiene su loopback configurada 10.255.255.X/32 y es única, el MPLS distribuye y transporta esa misma ID.

Ahora para realizar los vínculos punto a punto tenemos que crear una interface virtual que apunte al otro extremo.

CLIENTE 1 (loopback=10.255.255.2) / Sucursal 1 (loopback=10.255.255.4) / CORE (loopback=10.255.255.1)


en Cliente 1:

/interface vpls

add name=toSuc1 remote-peer=10.255.255.4 mac-address=0:0:0:0:0:1 vpls-id=10:0

add name=toCore remote-peer=10.255.255.1 mac-address=0:0:0:0:0:2 vpls-id=11:0


en Sucursal 1

/interface vpls add name=toClie1 remote-peer=10.255.255.2 mac-address=0:0:0:0:0:3 vpls-id=10:0


en Core

/interface vpls add name=toClie1 remote-peer=10.255.255.2 mac-address=0:0:0:0:0:4 vpls-id=11:0


Luego tenemos que crear los bridges y asignarles las interfaces

en Cliente 1:

/interface bridge

add name=internet

add name=redlan


/interface bridge port

add bridge=internet interface=toCore

add bridge=internet interface=ether3

add bridge=redlan interface=toSuc1

add bridge=redlan interface=ether4

Limitar velocidad a un puerto vpls: Supongamos que queremos limitar el puerto de salida hacia el core del cliente 1, primero tenemos que marcar los paquetes que salen por la interfaz física, en este caso ether3


/interface bridge filter

add action=mark-packet chain=forward in-interface=ether3 new-packet-mark=mark-to-core


Despues creamos una queue tree que dependa del tunel vpls toCore


/queue tree

add limit-at=256k max-limit=256k name=queue-to-Core paquet-mark=mart-to-core parent=toCore



Rotor de antena

publicado a la‎(s)‎ 3 ago. 2010 11:43 por Dario Fernandez   [ actualizado el 3 ago. 2010 12:07 ]

Este es el cógigo en CCS para programar un PIC16F883 para manejar un rotor de antena.

#include "rotor_v01.h"
#include <stdio.h>
#include <string.h>
#define LEDON output_high(PIN_C4)     //enciende un led en el pin_c4                   
#define LEDOFF output_low(PIN_C4)     //apaga el led
#define MOTOROFF output_low(PIN_C0)   //salida para el relay que alimenta el motor pin_c0
#define MOTORON output_high(PIN_C0)   //este es un relay simple
#define MOTORHO output_low(PIN_C1)    //salida para el relay invierte el sentido de giro pin_c1
#define MOTORAHO output_high(PIN_C1)  //este es un relay doble inversor
#define BT_IZ PIN_C2                  //botón de sentido de giro izquierda
#define BT_DR PIN_C3                  //botón de sentido de giro derecha  

int valor=0x00;

/*
 como el consumo del motor es variable, se toma un promedio de
 10 mediciones para establilizar el valor del mismo
*/
void toma_adc(void){
int i; //0-255
int16 xxx=0; // 0-255<int16
valor=0;
// Lectura del canal 0
set_adc_channel(0);
for(i=0;i<10;i++) {
delay_ms(1);
xxx=xxx+read_adc();
delay_ms(1); //para que se estabilice
}
valor=xxx/10;
}

void main() {
int sentido;
int flag_motor;
setup_oscillator(OSC_4MHZ|OSC_INTRC);
setup_adc_ports(sAN0|VSS_VDD); //configuramos el pin A0 como analogico
setup_adc(ADC_CLOCK_INTERNAL); //configura el converso
setup_spi(FALSE);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
setup_comparator(NC_NC_NC_NC);
enable_interrupts(INT_RDA);
enable_interrupts(INT_TIMER2);
enable_interrupts(GLOBAL);
set_tris_a(0b11111111); // 0 Salida - 1 Entrada
set_tris_c(0b10000000); //
delay_ms(10);
printf("inicializando \n\r");
sentido=0;
MOTORHO;
do {
toma_adc();
if (valor>=50) {
MOTOROFF;
delay_ms(200);
flag_motor=0;
printf("Motor off, Valor= %u \n\r",valor);
if (sentido==0) {
sentido=1;
MOTORAHO;
delay_ms(50);
MOTORON;
delay_ms(1000);
MOTOROFF;
delay_ms(50);
} else {
sentido=0;
MOTORHO;
delay_ms(50);
MOTORON;
delay_ms(1000);
MOTOROFF;
delay_ms(50);
}
printf("sentido = %u \n\r",sentido);
delay_ms(2000);
if (input(BT_IZ)==0) {
if (flag_motor==1) {
flag_motor=0;
MOTOROFF;
delay_ms(1000);
} else {
MOTORAHO;
sentido=1;
MOTORON;
flag_motor=1;
delay_ms(100);
}
}
if (input(BT_DR)==0) {
if (flag_motor==1) {
flag_motor=0;
MOTOROFF;
delay_ms(1000);
} else {
MOTORHO;
sentido=0;
MOTORON;
delay_ms(100);
flag_motor=1;
}
}
LEDON;
delay_ms(100);
LEDOFF;
delay_ms(100);
}while(true);
}

y para la configuración del rotor_v01.h

#include <16F887.h>
#device adc=8

#FUSES NOWDT                    //No Watch Dog Timer
#FUSES INTRC_IO                 //Internal RC Osc, no CLKOUT
#FUSES NOPUT                    //No Power Up Timer           
#FUSES MCLR                     //Master Clear pin enabled
#FUSES NOPROTECT                //Code not protected from reading
#FUSES NOCPD                    //No EE protection
#FUSES NOBROWNOUT                 //Reset when brownout detected
#FUSES NOIESO                     //Internal External Switch Over mode enabled
#FUSES NOFCMEN                    //Fail-safe clock monitor enabled
#FUSES NOLVP                    //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NODEBUG                  //No Debug mode for ICD
#FUSES NOWRT                    //Program memory not write protected
#FUSES BORV40                   //Brownout reset at 4.0V

#use delay(clock=8000000)
#use rs232(baud=9600,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8,stream=COM1)

Reloj de control de personal (1)

publicado a la‎(s)‎ 15 ene. 2010 9:36 por Dario Fernandez

Viendo la problemática actual para el control el acceso en general y realizando un estudio de los elementos disponibles en el mercado, se inicia este proyecto.

Problemática actual:
  • Recolección de datos
  • Programación desde un teclado de 4x4
  • Fuera de red
  • Demora entre lectura de tarjetas
  • Con escasas funcionalidades de ampliación
  • Necesidad de software adicional para la operación
Mediante la utilización de un sistema embebido como es un Rabbit se intenta utilizarlo como control de personal.

Requisitos mínimos:
  • Lector de tarjetas RFID
  • Display LCD
  • Rabbit 2200
Para el lector de tarjetas RFID, se utiliza uno marca HID, modelo proxipoint plus.

Este lector se encuentra conectado a una compuerta NAND para optimizar la salida de DATA0 y DATA1 dado que es relativamente rápido los cambios de estado.

Utiliza el protocolo WIEGAND 37, del cual desconociamos su funcionamiento, asi que se envió esta información a un pic para posibilitar su lectura.

Las tarjetas RFID normalmente tienen la codificación y 2 numeros Facility code y Nro ID, pero se puede visualizar impreso en ellas algo como "INTELECTRON 37 BITS # 26426418 41007412-3"

El dato que nos sirve es "26426418" que es FAC=264 ID=26418.

Los datos del lector HID son en binario y los ceros son 5 V en DATA0 y los 1 5 V en DATA1.

Como se utilizó un PIC16F873A que tiene una sola interrupción, se utilizan 3 compuertas NAND para la adquisición de estos datos.

Una vez que el PIC interpreta la lectura lo codifica y envia los datos via USART o RS232 o RS485 al rabbit, y adicionando su propio ID de modulo.

El rabbit recibe el dato del lector y genera un registro con [FAC], [ID], [RealTime], [IDLector], [Entrada/Salida]

Protocolo de comunicación:
Como posee 4 puertos series (el minimo en cualquiera de estos modulos), se pueden conectar 4 lectores simultaneos directamente a cada puerto USART del rabbit, o armar un protocolo RS485 propio para conectar XX lectores.

En la fase inicial se denomina "Modulo Lector" al conjunto PIC, HID, MAX[232/485], NAND.
Se puede establecer un lazo con varios módulos colgados de este por medio de MAX485 y unas cuantas sentencias mas.
Se prepara todos los módulos para trabajo sobre estas condiciones.

Al tener una limitación en cuanto a la DATAMemory del Rabbit 2200, se implementa un limite máximo de registros o lecturas guardadas a 1000.
Se establece comunicación mediante protocolo FTP y SMTP para generar un Archivo y/o un Mail con la información de los registros acumulados y se borra la DATAMemory al recibir el OK de envio de información.

Actualizado!!! 15 enero 2010

Se implementa la configuración en un Rabbit 3700, que posee el doble de memoria, lo que posibilita llevar el limite de registros de 1000 a 10000, solucionando la limitación de memoria previa.
También al implementar el RCM3700 como posee una separación estandar de pines facilita el diseño de circuitos y PCB.

Se implementa un protocolo de comunicación RS485 y 6 puertos de comunicación en el RCM3700, como el RCM3700 posee 6 puertos seriales de comunicación, posibilita tener 6 canales de lectura simultaneos, esto fué probado en una obra con 500 empleados, que a la hora del almuerzo anteriormente se necesitaban 6 relojes de control de personal, ahora con 1 solo y 6 módulos RFID se logra un resultado mucho mejor.

La base de tiempo de lectura de un reloj convencional no se corresponde a la del lector RFID, el lector se probó que puede realizar 1 lectura por segundo correcta, mientras que los relojes convencionales no lo soportaban.
Con nuestra implementación se logró realizar un máximo de 6 lecturas por segundo, y en condiciones de funcionamiento fué probado con 500 personas haciendo fila cada uno con su tarjeta en 6 lectores simultáneos se logró un tiempo promedio de 6 minutos.
Algo que anteriormente llevaba 15 minutos para marcar la entrada y 15 minutos para marcar la salida (media hora de personal marcando tarjeta) contra 12 minutos en total.

Sistema de acceso Inteligente

publicado a la‎(s)‎ 15 ene. 2010 8:47 por Dario Fernandez   [ actualizado el 15 ene. 2010 9:39 ]

A solicitud de uno de nuestros clientes, hemos desarrollado un sistema de acceso Inteligente.

Dado un edificio y la necesidad de instalación de un sistema de porteros, al cliente le proyectamos soluciones alternativas a las falencias de los porteros convencionales.
  • No poseen comunicación entre departamentos
  • En caso de no encontrarse nadie, no se puede dejar un mensaje de visita
  • No se tiene un control de acceso al edificio
  • No se sabe quien ni cuando se abrió la puerta
  • Si se necesitan múltiples accesos los tendidos de cables son muy propensos a fallas, etc.

Planteó particular del cliente es el siguiente
:
  • El edificio cuenta con 3 accesos (Principal, Cochera y SubSuelo), por lo que son necesarios 3 frentes de portero.
  • También se necesita conocer quien y cuando accedió.
  • Se necesita un sistema que sea robusto, que no se deteriore con el paso del tiempo.
  • Que opere las 24 horas los 365 días del año.
  • En el acceso de vehículos, al ser en una pendiente se necesita que el portero se encuentre alejado del portón (subsuelo)
Solución elegida por el cliente:
Sistema de control de acceso:
  • Control de acceso por medio de tarjetas RFID y/o código ingresado por teclado en todos los frentes de portero.
  • Toda la información queda registrada en la base de datos del sistema.
  • Se puede dar de alta y baja tanto códigos como tarjetas RFID.
  • Se puede modificar que puerta es abierta en el caso que se envié el comando de apertura (desde el portero de acceso a la cochera se acciona otro modulo de la red)

Sistema de comunicación:
  • Se instala una central telefónica en lugar de un sistema de portero convencional
  • Se puede establecer una comunicación entre departamentos, para consulta.
  • Transferir una llamada, realizar una transferencia por un período de tiempo (en el caso de vacaciones por ejemplo)
  • Se puede recibir una comunicación desde un teléfono convencional (linea fija o celular)

Sistema de Seguridad:
  • Se instalan cámaras en los accesos y se realiza un cableado a cada departamento
  • Las cámaras son ingresadas a un modulador de RF y se reciben en cada departamento en los canales preseleccionados (del 40 al 99 CATV)
  • Se selecciona cámaras Samsung analógicas de ultima generación con lentes Auto Iris lo que posibilita una buena visión en las condiciones mas adversas.

Sistema de alimentación:
  • Se instala toda una red de 24 Vcc, respaldado por baterías para alimentar tanto los frentes como las cámaras para un funcionamiento H24

Funcionalidades adicionales desarrolladas:
  • Todo el sistema no necesita PC ni sistema operativo lo que evita cualquier tipo de cuelgues externos a las necesidades del propio sistema.
  • Se utilizaron microcontroladores PIC para comandar los frentes de acceso.
  • Se utiliza un módulo Rabbit como concentrador maestro y sistema de gestión de acceso Inteligente, con manejo de base de datos propia y generación de reportes de accesos.
  • Se utilizó una comunicación de lazo RS485 para vincular los frentes al módulo maestro.
  • Se desarrolló una placa de audio con señalización DTMF, para el sistema de apertura y comunicación, lo que posibilita que el sistema de apertura desde los departamentos opere de manera independiente en caso de falla del modulo maestro.
  • En el sistema queda registrado tal cual se cargaron los datos de usuario (Nombre + RFID + COD) por lo que en los registros se visualiza Fecha, Hora, Puerta, Nombre y Codigo de acceso utilizado.
  • También se registra todos los errores de acceso, esto posibilita visualizar en un servidor de grabación de video la persona que quiso ingresar con un código y/o tarjeta erronea.

Central de Incendio

publicado a la‎(s)‎ 15 ene. 2010 8:25 por Dario Fernandez

Mediante la implementación de sistemas embebidos Rabbit, se está desarrollando un sistema de control de incendio para realizar control de sensores, sirenas, accionadores manuales.

Esto mejora las prestaciones básicas de una central convencional, ya que brinda acceso a la misma mediante una interfaz Ethernet y posibilita establecer un vínculo mediante una red ip a cualquier parte del mundo.

Como los sistemas Rabbit disponen de toda la tecnología para realizar comunicaciones TCP/IP y/o UDP, como así también poseen la suficiente capacidad de procesamiento para tener en su diminuto tamaño todo un servidor web, smtp, ftp, telnet, etc. Es el motivo por el cual lo elegimos para realizar nuestros desarrollos.

Modulos de zona:
La central de Incendio cuenta con Modulos de zona, conformado por un Pic, un puerto RS485, 2 lazos de entrada de sensores (2 zonas), 2 salidas programables por zona, que pueden ser comandadas directamente por el módulo o por el maestro, pero tiene la posibilidad de trabajar completamente Stand Alone sin inconvenientes.

Los módulos de zona son productos que pueden operar de manera independiente. Solo se necesita Alimentación de 24 VCC y este puede manejar 2 zonas con 10 sensores / actuadores por zona. Y 2 salidas para manejo de Sirenas, comandar sistemas de aspersión por medio de contactores y hasta comandar los sistemas automatizados de apertura de puertas para casos de emergencia habilitar todas las salidas.

El Rabbit o Módulo Maestro:
Cerebro de la red RS485 y Ethernet. Este módulo es donde serán configurados los comandos que realizará cada una de las zonas instaladas. En la programación se puede seleccionar que cuando se accione una alarma en una determinada zona, se accione una salida en otra. Un ejemplo básico de este procedimiento es el caso de un edificio de varios pisos, en el caso de que se detecte un incendio en un piso inferior se debe dar aviso a todos los pisos superiores.
Dado que todos los módulos de zona reportan su estado mediante una interfaz de lazo RS485, poseen comunicación entre ellos y entre el Maestro, por lo que en el caso de fallar cualquiera de los vínculos pasaran a operar como Stand Alone, mejorando la funcionalidad de cualquier central de incendio del mercado actual.

Al poseer el stack del protocolo TCP/IP, el módulo maestro se convierte en el comunicador hacia el exterior con un sin fin de posibilidades, desde aviso por SMS, envio de Mail, hasta activación y desactivación remota de la central.


1-6 of 6