En abstracto, un servidor DHCP puede atender una única subred, porque usa tráfico de broadcast que solo "funciona" en una subred. Por otro lado, a menos que tengas excelentes razones para ello no suele tener sentido tener múltiples servidores DHCP en una subred. Así que "un servidor dhcp por subred" suele ser una respuesta razonable. (nota, dependiendo de como fue programado puede ser un único demonio que permite que se le configuren varias subredes, p.ej. indicando en que interfaz servir qué rango de direcciones, etc., pero ese es otro tema).
En la segunda parte se intenta que el tráfico entre hosts que están físicamente en el mismo sitio no abandone el sitio, o sea que se enrute localmente. Para esto hace falta dos cosas:
1. Que en cada sitio haya disponible un enrutador capaz de forwardear tráfico entre las subredes, y
2. Que los hosts de una subred en un sitio tengan como gateway al router que está instalado en ese sitio. Esto se puede lograr configurando manualmente los hosts, o con una configuración cuidadosa de DHCP que identifique a los hosts de cada sitio y les entregue información de gateway "personalizada" para ese sitio (en el ejercicio no pide esta configuración, alcanza con darse cuenta que es un problema que hay que resolver).
En la segunda parte se intenta que el tráfico entre hosts que están físicamente en el mismo sitio no abandone el sitio, o sea que se enrute localmente. Para esto hace falta dos cosas:
1. Que en cada sitio haya disponible un enrutador capaz de forwardear tráfico entre las subredes, y
2. Que los hosts de una subred en un sitio tengan como gateway al router que está instalado en ese sitio. Esto se puede lograr configurando manualmente los hosts, o con una configuración cuidadosa de DHCP que identifique a los hosts de cada sitio y les entregue información de gateway "personalizada" para ese sitio (en el ejercicio no pide esta configuración, alcanza con darse cuenta que es un problema que hay que resolver).