¿Qúe es un DHCP?:

El protocolo de configuración dinámica de host (DHCP, Dynamic Host Configuration Protocol) es un estándar TCP/IP diseñado para simplificar la administración de la configuración IP de los equipos de nuestra red.
Si disponemos de un servidor DHCP, la configuración IP de los PCs puede hacerse de forma automática, evitando así la necesidad de tener que realizar manualmente uno por uno la configuración TCP/IP de cada equipo.

Un servidor DHCP es un servidor que recibe peticiones de clientes solicitando una configuración de red IP. El servidor responderá a dichas peticiones proporcionando los parámetros que permitan a los clientes autoconfigurarse. Para que un PC solicite la configuración a un servidor, en la configuración de red de los PCs hay que seleccionar la opción 'Obtener dirección IP automáticamente'.

El servidor proporcionará al cliente al menos los siguientes parámetros:

• Dirección IP
• Máscara de subred

Opcionalmente, el servidor DHCP podrá proporcionar otros parámetros de configuración tales como:

• Puerta de enlace
• Servidores DNS
• Muchos otros parámetros más

El servidor DHCP proporciona una configuración de red TCP/IP segura y evita conflictos de direcciones repetidas. Utiliza un modelo cliente-servidor en el que el servidor DHCP mantiene una administración centralizada de las direcciones IP utilizadas en la red. Los clientes podrán solicitar al servidor una dirección IP y así poder integrarse en la red.

Funcionamiento de una petición DHCP

El servidor solo asigna direcciones dentro de un rango prefijado. Si por error hemos configurado manualmente una IP estática perteneciente al rango gestionado por nuestro servidor DHCP, podría ocurrir que dicha dirección sea asignada dinámicamente a otro PC, provocándose un conflicto de IP. En ese caso el cliente solicitará y comprobará, otra dirección IP, hasta que obtenga una dirección IP que no esté asignada actualmente a ningún otro equipo de nuestra red.

La primera vez que seleccionamos en un PC que su configuración IP se determine por DHCP, éste pasará a convertirse en un cliente DHCP e intentará localizar un servidor DHCP para obtener una configuración desde el mismo. Si no encuentra ningún servidor DHCP, el cliente no podrá disponer de dirección IP y por lo tanto no podrá comunicarse con la red. Si el cliente encuentra un servidor DHCP, éste le proporcionará, para un periodo predeterminado, una configuración IP que le permitirá comunicarse con la red. Cuando haya transcurrido el 50% del periodo, el cliente solicitará una renovación del mismo.

Cuando arrancamos de nuevo un PC cuya configuración IP se determina por DHCP, pueden darse dos situaciones:

• Si la concesión de alquiler de licencia ha caducado, el cliente solicitará una nueva licencia al servidor DHCP (la asignación del servidor podría o no, coincidir con la anterior).
• Si la concesión de alquiler no ha caducado en el momento del inicio, el cliente intentará renovar su concesión en el servidor DHCP, es decir, que le sea asignada la misma dirección IP.

Antes de comenzar con los procesos de instalación y configuración de nuestro servidor DHCP, vamos a definir algunos términos que utilizaremos a lo largo de dicho proceso.
Ámbito servidor DHCP: Un ámbito es un agrupamiento administrativo de equipos o clientes de una subred que utilizan el servicio DHCP.

Rango servidor DHCP: Un rango de DHCP está definido por un grupo de direcciones IP en una subred determinada, como por ejemplo de 192.168.0.1 a 192.168.0.254, que el servidor DHCP puede conceder a los clientes.

Concesión o alquiler de direcciones: es un período de tiempo que los servidores DHCP especifican, durante el cual un equipo cliente puede utilizar una dirección IP asignada.

Reserva de direcciones IP: Consiste en reservar algunas direcciones IP para asignárselas siempre a los mismos PCs clientes de forma que cada uno siempre reciba la misma dirección IP. Se suele utilizar para asignar a servidores o PCs concretos la misma dirección siempre. Es similar a configurar una dirección IP estática pero de forma automática desde el servidor DHCP. En el servidor se asocian direcciones MAC a direcciones IP. Es una opción muy interesante para asignar a ciertos PCs (servidores, impresoras de red, PCs especiales...) siempre la misma IP.

[HostName] Como cambiar el nombre del equipo:

El hostname, es un nombre único que se le da a un dispositivo conectado a una determinada red. El nombre de equipo puede ser una palabra elegido por el administrador de la red.

Luego de instalar openSUSE puedes encontrar que el nombre de equipo asignado por el instalador no es el más adecuado o conveniente. Pero cambiar el nombre de equipo es algo simple, tanto si lo realizamos desde la consola o utilizando YaST, y bautizar tu equipo con un nombre más a tu gusto.
Desde la consola solo es necesario modificar un archivo como root.
su
cd /etc
vi HOSTNAME

Puedes utilizar cualquier editor de texto simple, como kate, leafpad, etc.

En mi caso el nombre era como “linux-algoxx.site”.  Solo modificas el nombre de tu equipo (lo que está antes del punto) y tendrás cambiado para siempre tu hostname. La palabra “site” es el dominio que le quieras poner a tu equipo (no es nada importante si no estás en una red con controlador de dominio).
Si no deseas utilizar la consola, puedes hacerlo desde YaST. Vamos al menú de openSUSE, luego clic en Máquina y por último clic en YaST.

Ventana de YaST

Clic en Dispositivos de red, luego clic en Ajustes de red.

Esta advertencia nos aparece si NetworkManager es el gestor de redes.

Si utilizamos NetworkManager como gestor de redes, continuamos presionando Aceptar. En la ventana de Configuración de Red, clic en la pestaña Nombre de Host/DNS, y modificamos el nombre host a nuestro gusto.

Finalizamos presionando Aceptar. Solo queda reiniciar el equipo para que se apliquen los cambios a nivel global.

Protocolo de Resolución de Direcciones (ARP):

El protocolo ARP es un protocolo estándar específico de red. Su status es electivo.
El protocolo de resolución de direcciones es responsible para convertir las direcciones de protocolo de alto nivel (direcciones IP) para direcciones de red física. Primero, consideremos algunos tópicos generales en Ethernet.

Ethernet vs IEEE 802.3

Se pueden usar dos formatos de trama en el cable coaxial de Ethernet:

1. El estándar que emitió en 1978 Xerox Corporation, Intel Corporation y Digital Equipment Corporation, habitualmente llamado Ethernet (o DIX Ethernet).
2. El estándar international IEEE 802.3, un estándar definido más reciente.

La diferencia entre los dos estándares está en el uso de uno de los campos cabecera, que contienen un número del tipo de protocolo para Ethernet y la longitud de los datos de la trama para IEEE 802.3.

• El campo tipo en Ethernet se usa para distinguir entre protocolos diferentes que se ejecutan en el cable coaxial, y permite su coexistencia en el mismo cable físico.
• La longitud máxima de una trama Ethernet es 1526 bytes. Esto significa una longitud del campo de datos por encima de 1500 bytes. La longitud del campo de datos de 802.3 también está limitada a 1500 bytes para redes de 10 Mbps, pero es distinta para otras velocidades de transmisión.
• En la trama MAC 802.3, la longitud del campo de datos se indica en la cabecera 802.3. El tipo de protocolo it carries están indicados en la cabecera 802.2 (protocolo de alto nivel), ver figura superior.
• En la práctica sin embargo, pueden coexistir ambos formatos de trama en el mismo coaxial físico. Esto se hace usando números de tipo de protocolo (campo tipo) más grandes que 1500 en la trama Ethernet. Sin embargo, se necesitan drivers de dispositivos diferentes para manejar cada uno de estos formatos.

Por tanto, para propósitos prácticos, la capa física Ethernet y la IEEE 802.3 son compatibles. Sin embargo, la capa de enlace de datos Ethernet y la IEEE 802.3/802.2 son incompatibles.

Capa de Control del Enlace de Datos (LLC)

Arriba, IEEE 802.3 usa un concepto conocido como Punto de Acceso al Servicio de Enlace (LSAP) que usa una cabecera de 3 bytes:
donde DSAP y SSAP simbolizan el Punto de Acceso al Servicio de Origen y Destino respectivamente. El comité del IEEE asigna los números para estos campos.
Debido al crecimiento del número de aplicaciones que usan IEEE 802 como protocolo de capa más baja, se realizó una extensión al protocolo IEEE 802.2 en la forma del Protocolo de Acceso a SubRedes (SNAP). Es una extensión de la cabecera LSAP, y su uso se indica con el valor 170 en los campos SSAP y DSAP de la trama LSAP anterior.
En la evolución de TCP/IP se han establecido tres estándares que describen el encapsulamiento de las tramas IP y ARP en estas redes:

1. 1984: RFC 894 - Estándar para la Transmisión de Datagramas IP sobre Redes Ethernet especifica sólo el uso de tipo de redes Ethernet. Los valores asignados al campo tipo son:
   • 2048 (hex 0800) para datagramas IP
   • 2054 (hex 0806) para datagramas ARP
2. 1985: RFC 948 - Dos Métodos para la Transmisión de Datagramas IP sobre Redes IEEE 802.3 especifica dos posibilidades:
   1. El método Ethernet compatible: las tramas se envían en una red IEEE 802.3 real de la misma manera que en una red Ethernet, es decir, usando el campo de longitud de datos IEEE 802.3 como el campo tipo Ethernet.
   2. Formato IEEE 802.2/802.3 LLC tipo 1: usando la cabecera LSAP 802.2 con IP utilizando el valor 6 para los campos SSAP y DSAP.
   El RFC indica claramente que el método IEEE 802.2/802.3 es el método preferido, es decir, que se supone que todas las implementaciones IP futuras de las redes IEEE 802.3 usan el segundo método.
   
3. 1987: RFC 1010 - Números Asignados (ahora obsoleto por el RFC 1700 de 1994) notes that as a result of IEEE 802.2 evolution y the need for more internet protocol numbers, a new approach was developed based on practical experiences exchanged during the August 1986 TCP Vendors Workshop. It states in an almost completely overlooked part of this RFC that from now on all IEEE 802.3, 802.4 y 802.5 implementations should use the Sub-Network Access Protocol (SNAP) form of the IEEE 802.2 LLC: DSAP y SSAP fields set to 170 (indicating the use of SNAP) y then SNAP assigned as follows:
   • 0 (cero) como código de organización.
   • Campo EtherType:
     • 2048 (hex 0800) para datagramas IP
     • 2054 (hex 0806) para datagramas ARP
     • 32821 (hex 8035) para datagramas RARP
     Estos son los mismos valores que los usados en el campo tipo Ethernet.
     
4. 1988: RFC 1042 - Estándar para la Transmisión de Datagramas IP sobre Redes IEEE 802.

Concepto detallado ARP

ARP is used on IEEE 802 networks as well as on the older DIX Ethernet networks to map IP addresses to physical hardware addresses. To do this, it is closely related to the device driver for that network. In fact, the ARP specifications in RFC 826 only describe its functionality, not its implementation. The implementation depends to a large extent on the device driver for a network type y they are usually coded together in the adapter microcode.

Generación de paquetes ARP

Si una aplicación desea enviar datos a cierta dirección de destino IP, el mecanismo de enrutamiento IP primero determina la dirección IP del "próximo salto" del paquete (puede ser el propio host de destino, o un router) y el dispositivo hardware al cual se debería enviar. Si se trata de una red IEEE 802.3/4/5, el módulo ARP se debe consultar para hacer corresponder el <tipo de protocolo, la dirección del protocolo de destino> con una dirección física.
El módulo ARP intenta encontrar la dirección en esta caché ARP. Si encuentra la pareja correspondiente, devuelve la correspondiente dirección física de 48 bits al que lo llamó (el driver del dispositivo) que entonces transmite el paquete. Si no encuentra la pareja en su tabla, descarta el paquete (assumption is that a higher-level protocol will retransmit) y generates a network broadcast of an ARP request.
donde:

espacio de direcciones hardware

Especifica el tipo de hardware; ejemplo de ello son Ethernet o Red de Radio por Paquetes.

espacio de direcciones del protocolo

Especifica el tipo de protocolo, igual que el campo EtherType en la cabecera IEEE 802 (IP o ARP).

longitud de direcciones hardware

Especifica la longitud (en bytes) de las direcciones hardware en este paquete. Para IEEE 802.3 y IEEE 802.5 será 6.

longitud de direcciones del protocolo

Especifica la longitud (en bytes) de las direcciones del protocolo en este paquete. Para IP será 4.

código de operación

Especifica si es una petición ARP (1) o una respuesta (2).

dirección hardware origen/destino

Contiene las direcciones hardware de red física. Para IEEE 802.3 son direcciones de 48 bits.

dirección del protocolo origen/destino

Contiene las direcciones del protocolo. Para TCP/IP son direcciones de IP de 32 bits.

Para el paquete de petición ARP, la dirección hardware de destino es el único campo no definido en el paquete.

Recepción de paquetes ARP

Cuando un host recibe un paquete ARP (una petición de broadcast o una respuesta punto a punto), el driver del dispositivo receptor pasa el paquete al módulo ARP que lo trata como se muestra en la figura.
El host solicitante recibirá esta respuesta ARP y seguirá el mismo algoritmo para tratarlo. Como resultado de esto, se añadirá la tripleta <tipo de protocolo, dirección de protocolo, dirección hardware> para el host deseado a su tabla de búsqueda (cahé ARP). La próxima vez que una protocolo de más alto nivel quiera enviar un paquete a ese host, el módulo ARP encontrará la dirección hardware de destino y se enviará el paquete a ese host.

Proxy-ARP o subnetting transparente

Proxy-ARP se describe en el RFC 1027 - Usar ARP para Implementar Pasarelas de Subred Transparente, que es de hecho un subconjunto del método propuesto en el RFC 925 - Resolución de Direcciones Multi-LAN. Es otro método para construir subredes locales, sin necesidad de modificar el algoritmo de enrutamiento IP, pero modificando los routers, que interconectan las subredes.

Concepto de Proxy-ARP

Consideremos una red IP, que está dividida en subredes, interconectada por routers. Usamos el algoritmo de enrutamiento IP "antiguo", que significa que ningún host conoce la existencia de múltiples redes físicas. Consideremos que los hosts A y B que están en diferentes redes físicas con la misma red IP y un router R entre las dos subredes como muestra la figura:
Cuando un host A quiere enviar un datagrama IP a un host B, primera tiene que determinar la dirección de red física del host B usando el protocolo ARP.
Como el host A no puede diferenciar entre las redes físicas, su algoritmo de enrutamiento IP piensa que el host B está en la red física local y envía una petición ARP de broadcast. El host B no recibe este broadcast, pero el router R sí. El router R entiende de subredes, esto es, ejecuta la versión "subnet" del algoritmo de enrutamiento IP y será capaz de ver que el destino de la petición ARP (del campo de dirección de protocolo destino) está en otra red física. Si las tablas de enrutamiento del router R especifican que el próximo salto a esa otra red se hace a través de un dispositivo físico diferente, responderá a ARP como si fuera el host B, diciendo que la dirección de red del host B es la del mismo router R.
El host A recibe esta respuesta ARP, la pone en su caché y enviará futuros paquetes IP para el host B hacia el router R. El router enviará tales paquetes a la subred correcta.
El resultado es subnetting transparente:

• Los hosts normales (tales como A y B) no saben subnetting, así que usan el algoritmo de enrutamiento IP "old".
• Los routers entre subredes tienen que:
  1. Usar el algoritmo IP "subnet".
  2. Usar un módulo ARP modificado, que puede responder en beneficio de otro hosts.

Administración del sistema, servicios IP:

Tablas y tipos de enrutamiento

Tanto los enrutadores como los hosts guardan una tabla de enrutamiento. El daemon de enrutamiento de cada sistema actualiza la tabla con todas las rutas conocidas. El núcleo del sistema lee la tabla de enrutamiento antes de reenviar paquetes a la red local. La tabla de enrutamiento enumera las direcciones IP de las redes que conoce el sistema, incluida la red local predeterminada del sistema. La tabla también enumera la dirección IP de un sistema de portal para cada red conocida. El portal es un sistema que puede recibir paquetes de salida y reenviarlos un salto más allá de la red local. A continuación se incluye una tabla de enrutamiento simple en una red sólo de IPv4:

Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- default 172.20.1.10 UG 1 532 ce0 224.0.0.0 10.0.5.100 U 1 0 bge0 10.0.0.0 10.0.5.100 U 1 0 bge0 127.0.0.1 127.0.0.1 UH 1 57 lo0

En un sistema Oracle Solaris puede configurar dos tipos de enrutamiento: estático y dinámico. Puede configurar uno o ambos tipos de enrutamiento en un único sistema. Un sistema que implementa enrutamiento dinámico se basa en los protocolos de enrutamiento, como RIP para redes IPv4 y RIPng para redes IPv6, con el fin de mantener sus tablas de enrutamiento. Un sistema que sólo ejecuta enrutamiento estático no se basa en ningún protocolo de enrutamiento para la información de enrutamiento ni para actualizar la tabla de enrutamiento. Es preciso guardar las rutas conocidas del sistema manualmente con el comando route. Para obtener más información al respecto.
Al configurar el enrutamiento para la red local o el sistema autónomo, considere el tipo de enrutamiento que desea para los hosts y enrutadores específicos.
La tabla siguiente muestra los diversos tipos de enrutamiento y las redes para las que es adecuado cada tipo.

Tipo de enrutamiento	Recomendado para
Estático	Hosts y redes de tamaño reducido que obtienen las rutas de un enrutador predeterminado, y enrutadores predeterminados que sólo necesitan conocer uno o dos enrutadores en los siguientes saltos.
Dinámico	Interredes de mayor tamaño, enrutadores en redes locales con múltiples hosts y hosts de sistemas autónomos de gran tamaño. El enrutamiento dinámico es la mejor opción para los sistemas en la mayoría de las redes.
Estático y dinámico combinados	Enrutadores que conectan una red con enrutamiento estático y una red con enrutamiento dinámico, y enrutadores de límite que conectan un sistema autónomo interior con redes externas. La combinación del enrutamiento estático y dinámico en un sistema es una práctica habitual.

El SA que se muestra en la combinación el enrutamiento estático y el dinámico.

Configuración de rutas

Para implementar el enrutamiento dinámico para una red IPv4, utilice el comando routeadm o svcadm para iniciar el daemon de enrutamiento in.routed. Para ver las instrucciones,  El enrutamiento dinámico es la estrategia preferida para la mayoría de las redes y sistemas autónomos. Sin embargo, la topología de red o un sistema específico de la red podrían requerir el enrutamiento estático. En tal caso, debe editar manualmente la tabla de enrutamiento del sistema para que refleje la ruta conocida al portal. El siguiente procedimiento muestra cómo agregar una ruta estática.

---

Nota – Dos rutas al mismo destino no hacen que el sistema ejecute automáticamente la función de equilibrio de carga o fallos. Si necesita estas funciones, utilice IPMP.

---

Cómo agregar una ruta estática a la tabla de enrutamiento

1. Visualice el estado actual de la tabla de enrutamiento.
   Utilice su cuenta de usuario habitual para ejecutar el siguiente comando netstat:
   

   % netstat -rn

   Obtendrá un resultado similar al siguiente:
   

   Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- 192.168.5.125 192.168.5.10 U 1 5879 ipge0 224.0.0.0 198.168.5.10 U 1 0 ipge0 default 192.168.5.10 UG 1 91908 127.0.0.1 127.0.0.1 UH 1 811302 lo0

2. Asuma el rol de administrador principal, o conviértase en superusuario.
   La función de administrador.
   
3. (Opcional) Vacíe las entradas existentes en la tabla de enrutamiento.
   

   # route flush

4. Agregue una ruta que persista tras el reinicio del sistema.
   

   # route -p add -net network-address -gateway gateway-address

   -p

   Crea una ruta que debe persistir tras el reinicio del sistema. Si desea que la ruta sea válida sólo para la sesión actual, no utilice la opción -p.
   

   add

   Indica que está a punto de agregar la siguiente ruta.
   

   -net dirección_red

   Especifica que la ruta se dirige a la red con la dirección de dirección_red.
   

   -gateway dirección_portal

   Indica que el sistema de portal para la ruta especificada tiene la dirección IP dirección_portal.
   

---

Ejemplo 5–5 Cómo agregar una ruta estática a la tabla de enrutamiento

El siguiente ejemplo muestra cómo agregar una ruta estática a un sistema. El sistema es el enrutador 2, el enrutador predeterminado para la red 172.20.1.0 que se muestra, el enrutador 2 está configurado para el enrutamiento dinámico. Para actuar como enrutador predeterminado para los hosts de la red 172.20.1.0, el enrutador 2 necesita además una ruta estática al enrutador de límite del SA, 10.0.5.150 .
Para ver la tabla de enrutamiento del enrutador 2, debe configurar lo siguiente:

# netstat -rn Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- default 172.20.1.10 UG 1 249 ce0 224.0.0.0 172.20.1.10 U 1 0 ce0 10.0.5.0 10.0.5.20 U 1 78 bge0 127.0.0.1 127.0.0.1 UH 1 57 lo0

La tabla de enrutamiento indica las dos rutas que conoce el enrutador 2. La ruta predeterminada utiliza la interfaz 172.20.1.10 del enrutador 2 como portal. La segunda ruta, 10.0.5.0, fue descubierta por el daemon in.routed que se ejecuta en el enrutador 2. El portal de esta ruta es el enrutador 1, con la dirección IP 10.0.5.20.
Para agregar una segunda ruta a la red 10.0.5.0, que tiene su portal como enrutador de límite, debe configurar lo siguiente:

# route -p add -net 10.0.5.0/24 -gateway 10.0.5.150/24 add net 10.0.5.0: gateway 10.0.5.150

Ahora la tabla de enrutamiento cuenta con una ruta para el enrutador de límite, que tiene la dirección IP 10.0.5.150/24.

# netstat -rn
Routing Table: IPv4
  Destination           Gateway           Flags  Ref   Use   Interface
-------------------- -------------------- ----- ----- ------ ---------
default              172.20.1.10          UG        1    249 ce0
224.0.0.0            172.20.1.10          U         1      0 ce0
10.0.5.0             10.0.5.20            U         1     78 bge0
10.0.5.0             10.0.5.150           U         1    375 bge0
127.0.0.1            127.0.0.1            UH        1     57 lo0

Pasos para crear o modificar subredes de una red:

Cada subred de red debe asociarse a un sitio de red para poder determinar la ubicación geográfica del host que pertenece a esta subred. Puede usar Panel de control de Lync Server para configurar subredes. Desde Panel de control de Lync Server, puede crear, modificar o eliminar una subred de red. Para obtener información detallada sobre la eliminación de subredes de red. En la mayoría de las implementaciones de Microsoft Lync Server 2013 que implementen el control de admisión de llamadas (CAC) habrá normalmente una gran cantidad de subredes. Por ese motivo, suele ser recomendable configurar subredes desde el Shell de administración de Lync Server. De ese modo podrá llamar a New-CsNetworkSubnet junto con el cmdlet Import-CSV de Windows PowerShell. Usando estos cmdlet juntos, puede leer la configuración de subred en un archivo de valores separados por comas (.csv) y crear varias subredes al mismo tiempo. Para consultar ejemplos sobre cómo crear subredes a partir de un archivo .csv.

Para crear una subred de red

1. Desde una cuenta de usuario que sea miembro del grupo RTCUniversalServerAdmins (o que tenga derechos de usuario equivalentes), o esté asignada al rol CsAdministrator, inicie sesión en cualquier equipo en la implementación interna.
   
2. Abra una ventana del explorador y después introduzca la dirección URL de administración para abrir el panel de control de Lync Server. Para más información sobre los diferentes métodos que puede usar para iniciar el panel de control de Lync Server.
   
3. En la barra de navegación izquierda, haga clic en Configuración de red y, a continuación, en Subred.
   
4. En la página Subred, haga clic en Nueva.
   
5. En Nueva subred, especifique un valor en el campo ID de subred. Debe ser una dirección IP (por ejemplo, 174.11.12.0) y debe estar ubicada en primer lugar en el intervalo de direcciones IP definido por la subred.
   
6. En el campo Máscara, especifique un valor numérico del 1 al 32.
   

   Nota:
   Este valor es la máscara de bits que se aplicará a la subred que se está creando.

7. En Id. del sitio de red, seleccione el sitio al que pertenece la subred.
   
8. (Opcional) Escriba un valor en el campo Descripción para proporcionar información sobre esta subred más allá de lo que se pueda deducir de su nombre.
   
9. Haga clic en Confirmar.
   

Para modificar una subred de red

1. Desde una cuenta de usuario que sea miembro del grupo RTCUniversalServerAdmins (o que tenga derechos de usuario equivalentes), o esté asignada al rol CsAdministrator, inicie sesión en cualquier equipo en la implementación interna.
   
2. Abra una ventana del explorador y después introduzca la dirección URL de administración para abrir el panel de control de Lync Server. Para más información sobre los diferentes métodos que puede usar para iniciar el panel de control de Lync Server.
   
3. En la barra de navegación izquierda, haga clic en Configuración de red y luego en Subred.
   
4. En la página Subred, haga clic en la subred que desea modificar.
   
5. En el menú Editar, haga clic en Mostrar detalles.
   
6. En la página Editar subred, puede modificar la máscara de bits, el sitio de red asociado o la descripción. Si modifica la máscara de bits, recuerde que el ID de subred debe seguir siendo la primera dirección del intervalo de dirección IP definido en la subred.
   
7. Haga clic en Confirmar.
   

Como configurar la Interfaz para una direción IP:

La interfaz de bucle local

La primera interfaz en ser activada es la interfaz de bucle local o loopback:

# ifconfig lo 127.0.0.1

Ocasionalmente, también vera que el nombre comodín localhost es usado en vez de la dirección de IP. ifconfig buscará el nombre en el fichero hosts que debe contener un registro declarando localhost como nombre válido para la dirección 127.0.0.1:

# Registro de ejemplo para localhost en /etc/hosts localhost 127.0.0.1

Para ver la configuración de una interfaz, use ifconfig, pasándole como argumento únicamente el nombre de la interfaz:

$ ifconfig lo lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 Collisions:0

Como podrá observar, la máscara asignada a la interfaz del bucle local es 255.0.0.0, debido a que 127.0.0.1 es una dirección de clase A.
Ahora, ya casi puede empezar a jugar con su "mini-red". Sólo queda añadir una entrada en la tabla de encaminamiento que comunique al IP que puede usar esa interfaz como ruta hacia 127.0.0.1. Para llevar esto a cabo, basta escribir:

# route add 127.0.0.1

También aquí puede usar localhost en lugar de la dirección IP, suponiendo que lo haya introducido en su /etc/hosts.
Lo siguiente es comprobar que todo funciona como es debido, por ejemplo usando ping. ping es el equivalente a un sonar en una red. Esta orden se usa para verificar que una dirección dada es accesible y para medir el retraso entre el envío de un datagrama y su recepción de vuelta. Este tiempo es conocido como tiempo de ida y vuelta.

# ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.4 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.4 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.4 ms ^C --- localhost ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.4/0.4/0.4 ms #

Cuando se ejecuta ping según se muestra aquí, la emisión de paquetes continúa a menos que sea interrumpida por el usuario. El ^C marca el momento en el que se apretó Ctrl-C.
Este ejemplo muestra que los paquetes dirigidos a la máquina 127.0.0.1 están siendo entregados correctamente y la respuesta a ping es recibida de forma casi instantánea. Esto significa que ha establecido con éxito su primera interfaz de red.
Si la salida de ping no se parece a la de más arriba, usted tiene problemas. Compruebe la posibilidad de que algún fichero no haya sido instalado correctamente. Compruebe que los ejecutables ifconfig y route son compatibles con la versión del núcleo que usa y sobre todo que éste ha sido compilado con la opción de red activada (esto se puede ver comprobando que existe el directorio /proc/net). Si el mensaje de error es “network unreachable”(red inaccesible), seguramente ejecutó la orden route incorrectamente. Asegúrese de que es la misma dirección que la que usó con ifconfig.
Los pasos descritos arriba son suficientes para poder ejecutar aplicaciones de red en una máquina aislada. Una vez esas líneas son añadidas al script de inicialización de red y después de asegurarse de que es ejecutado en tiempo de arranque, puede proceder a rearrancar su máquina y probar las diferentes aplicaciones de red. Por ejemplo telnet localhost debería establecer una conexión telnet con su máquina, pidiéndole el nombre de usuario y la contraseña.
Sin embargo, la interfaz de bucle local es útil, no sólo como ejemplo en libros de redes, o como método de pruebas durante el desarrollo: también la utilizan algunas aplicaciones como modo normal de operacion. Por ello, debe usted configurarla siempre, independientemente de que su máquina esté conectada a una red o no.

5.7.2. Interfaces Ethernet

La configuración de una interfaz Ethernet es más o menos igual que la de la interfaz de bucle local. Sólo requiere algunos parámetros más cuando está usando varias subredes.
En la Cervecera Virtual, hemos dividido la red IP, originalmente de clase B, en subredes de clase C. Para que la interfaz reconozca esto, usamos la orden ifconfig

# ifconfig eth0 vstout netmask 255.255.255.0

Esto asigna a la interfaz eth0 la dirección IP de la máquina vstout (191.72.1.2). Si hubiésemos omitido la máscara de red, ifconfig habría deducido la máscara de la clase de la red IP, tomando por tanto 255.255.0.0, que es incorrecto. Una comprobación rápida nos da:

# ifconfig eth0 eth0 Link encap 10Mps Ethernet HWaddr 00:00:C0:90:B3:42 inet addr 172.16.1.2 Bcast 172.16.1.255 Mask 255.255.255.0 UP BROADCAST RUNNING MTU 1500 Metric 1 RX packets 0 errors 0 dropped 0 overrun 0 TX packets 0 errors 0 dropped 0 overrun 0

Puede ver que ifconfig ha fijado la dirección de difusión automáticamente (el campo Bcast de arriba) a su valor usual, que es el de la red con todos los bits de la máquina activados. Además se fija la unidad de transferencia de mensajes (tamaño máximo que el núcleo va a generar para esa interfaz) a un máximo de 1500 bytes. Todos estos valores pueden ser especificados mediante opciones especiales que se explican en Sección 5.8”.
De forma semejante al caso de la interfaz de bucle local, debe también establecer ahora una entrada en la tabla de encaminamiento que informe al núcleo de que la red es accesible mediante eth0. Para la Cervecera Virtual, ejecutaría:

# route add -net 172.16.1.0

Inicialmente podría parecer algo mágico, pues no esta claro como route detecta cuál es la interfaz que debe usar. Sin embargo el truco es sencillo: el núcleo comprueba todas las interfaces que han sido configuradas hasta el momento y compara la dirección de destino (191.72.1.0 en este caso) con la parte de red de las direcciones de las interfaces (o, lo que es lo mismo, ejecuta un "and" lógico de la dirección de la interfaz y la máscara de red). La única interfaz que cumple esto es eth0.
Veamos, ¿qué significa la opción –net? Esta opción es necesaria porque el programa route es capaz de trabajar con rutas a redes o a máquinas concretas (como vimos arriba en el caso de localhost). Cuando la dirección es dada en notación de cuaterna, intenta adivinar si se trata de una red o una máquina fijándose en los bits de máquina de la dirección. Si esa parte es nula, route asume que se trata de una red, y de otro modo lo toma como dirección de una máquina. Por tanto, route supondría que 191.72.1.0 es la dirección de una máquina en vez de una red, debido a que no sabe que hemos dividido el espacio de direcciones en subredes. Por tanto hemos de decírselo de forma explícita utilizando el indicador –net.
Por supuesto, escribir el comando route es tedioso y susceptible de muchos errores de escritura. Un método más conveniente es usar los nombres definidos en /etc/networks como vimos más arriba. Esto hace el comando más inteligible; de este modo incluso podemos evitar escribir el indicador –net, porque route sabe que 191.72.1.0 representa una red:

# route add brew-net

Una vez finalizados los pasos básicos de configuración, debemos asegurarnos de que la interfaz Ethernet está funcionando correctamente. Elija una máquina de su red, por ejemplo vlager, y escriba:

# ping vlager PING vlager: 64 byte packets 64 bytes from 172.16.1.1: icmp_seq=0. time=11. ms 64 bytes from 172.16.1.1: icmp_seq=1. time=7. ms 64 bytes from 172.16.1.1: icmp_seq=2. time=12. ms 64 bytes from 172.16.1.1: icmp_seq=3. time=3. ms ^C ----vstout.vbrew.com PING Statistics---- 4 packets transmitted, 4 packets received, 0 round-trip (ms) min/avg/max = 3/8/12

Si el resultado no es similar a éste, algo va mal, obviamente. Una tasa de pérdida de paquetes inusualmente alta, sugiere un problema de hardware, como terminaciones en mal estado o incluso la ausencia de las mismas, etc. Si no recibe ningún paquete, debe comprobar la configuración de la interfaz mediante netstat, que describiremos después en Sección 5.9”. Las estadísticas de paquetes producidas por ifconfig le indican si algún paquete ha sido enviado mediante esa interfaz. Si tiene acceso a una máquina remota, también debería dirigirse a esa máquina y comprobar las estadísticas de la interfaz. De este modo puede determinar exactamente en qué momento se han descartado los paquetes. Además, debe consultar la información de encaminamiento con route para ver si ambas máquinas han registrado ésta correctamente en sus tablas. route imprime la tabla de encaminamiento del núcleo completa si se ejecuta sin argumentos (la opción –n hace que utilice la notación de cuaternas en vez de los nombres de las máquinas):

# route -n Kernel routing table Destination Gateway Genmask Flags Metric Ref Use Iface 127.0.0.1 * 255.255.255.255 UH 1 0 112 lo 172.16.1.0 * 255.255.255.0 U 1 0 10 eth0

El significado de cada uno de los campos. La columna Flags contiene una lista de los indicadores activos en cada interfaz. U indica que la interfaz está activa y H indica que la dirección de destino es una máquina. Si encuentra que el indicador H se ha activado para una ruta que pretendía usar para una red, entonces debe usar la opción –net con el comando route. Para comprobar si alguna ruta esta siendo usada o no, debe mirar si el campo Use en la penúltima columna se incrementa entre dos ejecuciones sucesivas de ping.

5.7.3. Encaminamiento a través de una pasarela

En la sección anterior, cubrimos sólo el caso en el que la máquina sólo tiene una única Ethernet. Frecuentemente, es posible encontrar redes conectadas unas a otras a través de pasarelas o máquinas de enlace. Estas pasarelas pueden simplemente unir dos o más Ethernets, pero pueden también servir de enlace con el exterior, con Internet. Para usar una pasarela, es necesario añadir información adicional a la capa de red.
Por ejemplo, las Ethernets de la Cervecera Virtual y de la Vinatera Virtual están unidas a través de una pasarela, vlager. Suponiendo que la máquina vlager ha sido configurada ya, sólo tenemos que añadir otro registro a la tabla de encaminamiento de la máquina vstout que le comunique al núcleo que puede acceder a todas los nodos de la red de la Vinatera a través de vlager. La orden apropiada usando route se muestra a continuación; la palabra clave gw indica que el argumento siguiente es una pasarela:

# route add wine-net gw vlager

Por supuesto, cualquier nodo en la red de la Vinatera al que quiera dirigirse debe tener un registro análogo referido a la red de la Cervecera, o de otro modo sólo podría enviar datos a la red de la Vinatera desde la Cervecera, pero las máquinas de la Vinatera serían incapaces de responder.
Este ejemplo describe únicamente una pasarela que conmuta paquetes entre dos redes Ethernet aisladas. Supongamos ahora que vlager también tiene una conexión a la Internet (digamos que a través de un enlace SLIP). Nos gustaría que los datagramas destinados a cualquier dirección fuera de la red de la Cervecera fueran entregados a vlager. Esto se puede conseguir convirtiéndolo en la pasarela por omisión para vstout:

# route add default gw vlager

El nombre de red default es una abreviatura que representa la red 0.0.0.0, o ruta por omisión. La ruta por omisión analiza cada destino, y es la que será usada si no se encuentra ninguna ruta más específica. No es necesario añadir este nombre a /etc/networks, porque esta información esta contenida en el código de route.
Una tasa alta de pérdida de paquetes usando ping hacia una máquina situada detrás de una o más pasarelas, puede deberse a que la red está muy congestionada. La pérdida de paquetes no se debe tanto a deficiencias técnicas como a exceso temporal de carga en las máquinas que actúan de enlace, provocando retrasos o incluso el descarte de datagramas entrantes.

5.7.4. Configuración de una Pasarela

Configurar una máquina para conmutar paquetes entre dos Ethernets es bastante sencillo. Suponga que nos encontramos en vlager, que contiene dos tarjetas Ethernet, respectivamente conectadas a cada una de las dos redes. Todo lo que necesitará hacer es configurar ambas interfaces de forma separada, dándole a cada una su dirección IP correspondiente, y eso es todo.
Es bastante útil incluir la información de ambas interfaces en el fichero hosts del modo indicado a continuación, de forma que tengamos nombres para referirnos a ellas también:

172.16.1.1 vlager.vbrew.com vlager vlager-if1 172.16.2.1 vlager-if2

La secuencia de comandos para establecer las dos intefaces es por tanto:

# ifconfig eth0 vlager-if1 # route add brew-net # ifconfig eth1 vlager-if2 # route add wine-net

Si esta secuencia no funciona, asegúrese de que el núcleo ha sido compilado con el soporte para transmisión IP (IP forwarding). Una buena forma de hacerlo es comprobar que el primer número de la segunda línea de /proc/net/snmp es un 1.

5.7.5. La interfaz PLIP

Si usa un enlace PLIP para conectar dos máquinas, las cosas son un poco diferentes de lo visto para una Ethernet. En caso de PLIP se trata de un enlace conocido como punto-a-punto, lo que significa que sólo hay una máquina a cada extremo del enlace. A las redes como Ethernet se les llama redes de difusión. La configuración de enlaces punto a punto es diferente porque a diferencia de las redes de difusión, los enlaces punto a punto no son una red por sí mismos.
PLIP ofrece conexión muy barata y portable entre ordenadores. A modo de ejemplo, consideremos un ordenador portátil de un empleado en la Cervecera Virtual que se conecta a vlager mediante PLIP. El portátil se llama vlite, y tiene un único puerto paralelo. Durante el arranque, este puerto será registrado como plip1. Para activar el enlace, ha de configurar la interfaz plip1 mediante las órdenes siguientes:

# ifconfig plip1 vlite pointopoint vlager # route add default gw vlager

La primera orden configura la interfaz, diciéndole al núcleo que se trata de un enlace punto-a-punto, donde la parte remota tiene la dirección de vlager. El segundo instala la ruta por omisión que usa a vlager como pasarela. En vlager se necesita ejecutar ifconfig con argumentos similares para activar el enlace (en este caso no es necesario usar route):

# ifconfig plip1 vlager pointopoint vlite

Es interesante notar que la interfaz plip1 en vlager no necesita tener una dirección IP diferente, sino que puede usar la misma dirección 172.16.1.1. Las redes punto-a-punto no representan directamente una red, así que las interfaces no necesitan una dirección en ninguna red soportada. El núcleo usa la información de la interfaz que hay en la tabla de enrutamiento para prevenir cualquier posible equivocación. 
Una vez hemos configurado el encaminamiento desde el portátil a la red de la Cervecera, sólo resta arbitrar un modo para que cualquier máquina en esa red pueda acceder a vlite. Un modo particularmente enrevesado seríia añadir una ruta a las tablas de encaminamiento de cada una de las máquinas de la red para usar vlager como pasarela hacia vlite:

# route add vlite gw vlager

Una opción mejor cuando tenemos que trabajar con rutas temporales es usar encaminamiento dinámico. Una forma de conseguirlo es usando gated, un demonio de encaminamiento, que deberá instalar en cada una de las máquinas de la red de modo que distribuya la información de encaminamiento de forma dinámica. La forma más sencilla, sin embargo, consiste en usar proxy ARP. Con la sustitución ARP, vlager responde a cualquier pregunta ARP dirigida a vlite enviando su propia dirección Ethernet. El efecto conseguido es que todos los paquetes dirigidos a vlite terminan yendo a vlager, que se encarga de reenviárselos al portátil. Volveremos a hablar de sustitución ARP en la sección Sección 5.10.”
Las actuales versiones de net-tools contienen una herramienta llamada plipconfig, que permite configurar algunos parámetros que permiten ajustar ciertos parámetros del la temporización de PLIP. La IRQ que va a usarse por el puerto de la impresora puese especificarse usando la orden ifconfig.

5.7.6. Las interfaces SLIP y PPP

A pesar de que los enlaces SLIP y PPP son simples enlaces punto-a-punto igual que las conexiones PLIP, hay mucho más que decir de ellas. Generalmente, el establecimiento de un enlace SLIP incluye una llamada a un lugar de conexión remoto a través de un módem y el establecimiento del modo SLIP en la línea de comunicaciones serie. El uso de PPP es similar. Las herramientas necesarias para establecer un enlace SLIP o PPP

5.7.7. La Interfaz Comodín

La interfaz comodín (dummy) parece un tanto exótica y sin embargo es bastante útil. Resulta especialmente ventajosa para máquinas aisladas y para las que se conectan a una red IP mediante un enlace telefónico. Se trata en realidad de máquinas que trabajan de forma aislada la mayor parte del tiempo.
El dilema con las máquinas aisladas es que el único dispositivo activo es el de bucle local, al que generalmente se le asigna la dirección 127.0.0.1. En ocasiones, sin embargo, le resultará necesario enviar datos a la dirección IP “oficial“ de la máquina. Supongamos, por ejemplo, el caso del portátil vlite cuando no esta conectado a ninguna red. Una aplicación en vlite puede querer enviar datos a otra aplicación en la misma máquina. Buscar vlite en /etc/hosts dará como resultado 172.16.1.65, y por tanto intentará enviar los datos a esa dirección. Como la única interfaz activa en ese momento es la de bucle local, el núcleo no sabe que la dirección se refiere a la misma máquina. En consecuencia el núcleo descarta el datagrama y genera un error en la aplicación.
En esta situación es cuando la interfaz comodín es útil, resolviendo el dilema actuando como alter ego de la interfaz de bucle local. En el caso de vlite, simplemente debe asignarle la dirección 172.16.1.65 y añadir una ruta que apunte a ella. Cada datagrama para 172.16.1.65 es enviado entonces localmente. La forma correcta es pues:

# ifconfig dummy vlite # route add vlite

5.7.8. Alias de IP

Los nuevos núcleos llevan una funcionalidad que puede sustituir por completo a la interfaz comodín, y que tiene otras útiles funciones. IP Alias permite configurar múltiples direcciones IP en un sólo dispositivo físico. En el caso más simple, usted puede reproducir la función de la interfaz comodín configurando la dirección del nodo como un alias de la interfaz de bucle local, y evitar por completo usar la intefaz comodín. Para usos más complejos, usted puede configurar su máquina para simular ser varias máquinas, cada una con su propia dirección IP. Esta configuración es llamaba a veces “Hosting Virtual,” aunque técnicamente se usa también para otras muchas técnicas.[6]
Para configurar un alias para una interfaz, primero debe asegurarse de que su núcleo ha sido compilado con soporte para Alias de IP (compruebe que tiene un fichero /proc/net/ip_alias ; si no es así, debe recompilar el núcleo). La configuración de un alias de IP es virtualmente idéntica a la configuración de un dispositivo de red real; se usa un nombre especial para indicar que lo que usted quiere es un alias. Por ejemplo:

# ifconfig lo:0 172.16.1.1

Esta orden creará un alias para la interfaz de bucle local con la dirección 172.16.1.1. Los alias de IP se señalan anteponiendo :n al dispositivo actual de red, donde “n” es un entero. En nuestro ejemplo, el dispositivo de red donde estamos creando el alias es lo, y estamos creando un alias numerado como cero para él. De esta forma, un único dispositivo físico puede soportar varios alias.Cada alias debe ser tratado como si fuera un dispositivo diferente, y en lo referente al software de IP del núcleo, así es; por más que esté compartiendo su hardware con otro interfaz.