Instituto Tecnológico y de Estudios Superiores de Monterrey Práctica de Laboratorio 2 Implementación de un Bridge Marco teórico: Un bridge es un dispositivo de red que opera a nivel 2 del modelo de capas OSI. Esto quiere decir que un bridge NO es capaz de rutear paquetes, y es por esta misma razón que ni siquiera se entera de que protocolo de red está encapsulando el frame (un bridge solo ve frames). A diferencia de un hub, el cual crea un solo dominio de colisiones, el bridge es capaz de separar una red en dos dominios de colisiones diferentes; y esta es la principal su principal ventaja. A C HUB B D Un hub es simplemente una conexión compartida, un alambrado común. A,B,C y D están luchando por el mismo medio y es por está razón que las colisiones son mucho mas probables a ocurrir. A C BRIDGE B D Un bridge separa a las computadoras C y D del dominio de colisiones que comparten A y B, de esta forma A solo lucha con B por el medio, mientras que C y D solo luchan por el medio entre ellos. Si C le manda un frame a D, tanto A como B deben de pasar inadvertidos de lo sucedido. Con todo esto debe de ser claro que el bridge ha separado la red en dos dominios de colisiones. Un bridge más sofisticado podría además convertir de un protocolo de enlace de datos como lo es Ethernet a otro protocolo diferente (no aplica en está practica). Objetivo: El objetivo de esta práctica consiste en implementar en software un “Puente de Red” (Bridge) entre dos interfaces de red (NIC), dentro de una misma computadora convencional. Escenario: Se tienen 3 computadoras: una de ellas tiene dos NIC instaladas y es la que servirá como Bridge; las otras dos sólo necesitan una NIC cada una y servirán solamente como terminales de prueba. A 192.168.1.1 B NO TCP/IP C 192.168.1.2 En el diagrama, las computadoras A y C son las terminales, mientras que la computadora B es la que tiene las dos interfaces y funcionará como Bridge. La computadora B no tiene implementado el protocolo TCP/IP en ninguna de sus interfaces. La computadora A y C tienen implementado el protocolo TCP/IP, y tienen configurada una IP estática 192.168.1.1/24 y 192.168.1.2/24, respectivamente. Se espera que la computadora A pueda hacer un ping exitoso a la computadora C. Descripción: La elección del lenguaje de programación a usar, así como las bibliotecas para interactuar con la NIC que se necesitan para realizar esta práctica está abierta a los alumnos; sin embargo, la explicación que se da en este apartado es referente a un lenguaje y a una biblioteca en particular: C++ y WinPCap. Se recomienda usar Visual C++ 6.0 para la realización de la práctica, aunque cualquier otro IDE estará bien. La biblioteca de desarrollo de WinPCap así como la documentación y ejemplos de uso de la misma se pueden encontrar en http://www.winpcap.org . El API de WinPCap está desarrollado en C puro, por lo que en realidad no es necesario un archivo de C++ para realizar la práctica; sin embargo, quizás sea conveniente renombrar el archivo fuente .c como .cpp para poder hacer uso de estructuras de datos ya desarrolladas para C++. En esta práctica, se espera que se implemente una tabla de hash como parte modular en el algoritmo del bridge: la tabla debe de tener la capacidad de guardar las direcciones MAC destino que se van leyendo en los paquetes, y posteriormente poder buscar a que segmento de red pertenece una dirección dada. Para la realización de la práctica también es necesario el uso de threads para poder estar escuchando por las dos interfaces a la vez; el uso de la técnica de polling(escuchar por una y luego por la otra consecutivamente) es insuficiente debido a que las funciones de recepción de paquetes son bloqueantes y una NIC no se podría dar el lujo de esperar a que la otra reciba un paquete para seguir operando. Se recomienda además el uso de un Sniffer como Ethereal (http://www.ethereal.com) para poder debugear el funcionamiento del programa en la red. El set de funciones definidas en el API de WinPCap que se pueden ocupar en esta práctica y que se recomiendan usar para evitar complicaciones de compilación, son las siguientes: int pcap_findalldevs (pcap_if_t **alldevsp, char *errbuf) Construct a list of network devices that can be opened with pcap_open_live(). pcap_t * pcap_open_live (const char *device, int snaplen, int promisc, int to_ms, char *ebuf) Open a live capture from the network. int pcap_loop (pcap_t *p, int cnt, pcap_handler callback, u_char *user) Collect a group of packets. typedef void(* pcap_handler)(u_char *user, const struct pcap_pkthdr *pkt_header, const u_char *pkt_data) Prototype of the callback function that receives the packets. int pcap_sendpacket (pcap_t *p, u_char *buf, int size) Send a raw packet. void pcap_freealldevs (pcap_if_t *alldevsp) Free an interface list returned by pcap_findalldevs(). Nota: para mas información sobre esta funciones se puede referir a la documentación de WinPCap, bajo el apartado de Exported functions.. Para el uso de threads se recomienda usar la función CreateThread que se encuentra en la biblioeca <Windows.h> que tiene la siguiente definición de parámetros: HANDLE CreateThread( LPSECURITY_ATTRIBUTES lpThreadAttributes, // dirección de los atributos de seguridad del hilo DWORD dwStackSize, // tamaño inicial de la pila del hilo en bytes LPTHREAD_START_ROUTINE lpStartAddress, // dirección de la función del hilo LPVOID lpParameter, // argumento para nuevo hilo DWORD dwCreationFlags, // flags de creación LPDWORD lpThreadId // dirección del identificador del hilo creado ); Nota: investigar como se debe de definir la función del thread. El algoritmo que le da funcionalidad al bridge se encuentra en el libro de texto. A esta funcionalidad posiblemente sea necesario agregarle una validación para evitar un problema que surge: este problema consiste en que cuando una NIC recibe un paquete y lo manda por la otra NIC, esta ultima NIC al momento de mandar el paquete también lo recibe en su thread correspondiente y lo vuelve a enviar a la otra NIC; esto concluye en que los paquetes se queden ciclados produciendo un bajo desempeño de la red y posteriormente una saturación de la misma con sus correspondientes implicaciones (TIP: hay que validar también la dirección fuente para evitar este problema). Ing. Jorge A. Bustamante Horta Ing. Octaviano Flores González