Práctica de Laboratorio 2

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