Hola

Había olvidado dejaros visibles las lecturas de la proxima clase de problemas (ahora ya estan). De todas formas los problemas serán en su mayor parte sobre la clase pasada que vimos.

Un saludo

Daniel

Hola

Aquí está la figura que no se veía en las transparencias de hoy

Feliz año a todos

He colocado consultas en todas las semanas que me faltaban preguntando por las horas que habeis dedicado a la asignatura. Lamento no haberlas puesto antes, entre gripes y navidades varias se me había pasado. Confio en que vuestras jovenes neuronas funcionen mejor que las mías, no hayan sufrido mucho con los brindis y recordeis qué días habeis estudiado la asignatura y me podais dar realimentación para que me haga una idea del esfuerzo que os está requiriendo, algo que yo correlaré con los resultados que vais obteniendo.

Pues nada, que nos vemos el lunes que viene. Espero que ya no quede nadie con gripe o indigestiones de tanto turrón (yo aún tengo que arreglarme la garganta para poder dar 2h de chapa)

Feliz 2009 de nuevo

Un saludo

Daniel

Hola

Teneis una nueva encuesta sobre el tiempo dedicado a la asignatura la semana pasada

Daniel

Hola

Respondiendo a una pregunta de clase del día pasado: qué sucede cuando un host ve un ARP Request que no pregunta por su dirección IP sino por la de otro, en el sentido de: aprende la pareja (IP, MAC) de quien envía el ARP Request?
Es una buena pregunta. Como el ARP Request va dirigido a la MAC de broadcast va a ser recibido por todas las máquinas de la LAN. En la misma pregunta del ARP Request viene ya informacion interesante que es la pareja (IP, MAC) de quien hace la pregunta, y puede ser util aprender ya ese mapeo.

Para responder a esta pregunta nos podemos ir a la RFC 826 en la cual está especificado ARP. Os pongo a continuación lo que dice que debe hacer el modulo de ARP al recibir un mensaje (uno cualquiera):

<---- START From RFC 826 ---->

?Do I have the hardware type in ar$hrd?
Yes: (almost definitely)
[optionally check the hardware length ar$hln]
?Do I speak the protocol in ar$pro?
Yes:
[optionally check the protocol length ar$pln]
Merge_flag := false
If the pair <protocol type, sender protocol address> is
already in my translation table, update the sender
hardware address field of the entry with the new
information in the packet and set Merge_flag to true.
?Am I the target protocol address?
Yes:
If Merge_flag is false, add the triplet <protocol type,
sender protocol address, sender hardware address> to
the translation table.
?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!)
Yes:
Swap hardware and protocol fields, putting the local
hardware and protocol addresses in the sender fields.
Set the ar$op field to ares_op$REPLY
Send the packet to the (new) target hardware address on
the same hardware on which the request was received.

<---- END From RFC 826 ---->

Si alguna variable no os queda clara podeis leer el resto de la RFC. Si Seguís el 'IF', independientemente de que la pregunta del ARP sea para este host, si ya tenemos en la tabla de mapeos una entrada para la dirección IP del que pregunta actualizaremos la entrada con la MAC de este mensaje. Es decir, no aprendemos mas que si ya tenemos una entrada para esa (IP,MACquesea). Y esto sirve para algo? Por lo menos sirve para que si el interfaz con esa IP ha cambiado de MAC nos enteremos.
Siguiendo el IF entramos en la parte solo para el host para el que es la pregunta del ARP request, el cual sí que apunta todo el mapeo (IP,MAC) si no lo tenia ya.

Cuestiones?

Daniel