☰

¿Dirección IPv4 a mapeo de máscara de red y viabilidad de múltiples rutas predeterminadas?

tag-icon • tag-icon ipv4 network-protocols
¿Dirección IPv4 a mapeo de máscara de red y viabilidad de múltiples rutas predeterminadas?

Tenemos,

Class   Range      NetMask         Bits    Bits   hosts#
----------------------------------------------------------
A        0-127    255.0.0.0         8      24     16777216   (i.e. 114.0.0.0)

B      128-191    255.255.0.0      16      16        65536   (i.e. 150.0.0.0)

C      192-254    255.255.255.0    24       8          256   (i.e. 199.0.0.0)

También,

$cat /proc/version 
Linux version 2.6.32-amd64 (gcc version 4.3.2 (Debian 4.3.2-1.1) ) #1 SMP Tue Jul 1 18:36:07 UTC 2011

$ip route show
114.0.0.0/24 dev eth1  scope link 
114.0.0.0/16 dev eth1  scope link 
114.0.0.0/8 dev eth1  scope link 
199.0.0.0/8 dev eth1  scope link 
122.0.0.0/8 dev eth1  scope link 
default via 16.107.200.1 dev eth0
default via 16.107.200.1 dev eth1 
default via 16.107.200.20 dev eth1 
default via 16.107.200.21 dev eth1 
default via 16.107.200.22 dev eth1 
default via 16.107.200.23 dev eth1

Pregunta 1.Según la imagen anterior, al utilizar la versión iproute 2009 obtengo una dirección IPv4 de clase A con netamsk de clase C o B y viceversa. ¿Es una configuración válida?

Pregunta 2.Según la imagen anterior, si iproute permite agregar múltiples rutas predeterminadas, ¿cuál sería el comportamiento del flujo de paquetes cuando los paquetes deben enrutarse usando solo una ruta predeterminada (donde existen muchas rutas predeterminadas)? ¿También cómo el iproute filtra múltiples rutas predeterminadas? Además, ¿es una característica válida que iproute permita múltiples rutas predeterminadas en la configuración de un servidor?

Respuesta1

R1: Sí, perfectamente válido. El direccionamiento IP con clase fue reemplazado alrededor de 1993 porCIDR(Itinerario entre recesos). Incluso sin CIDR, esto seguiría siendo válido, ya que simplemente tendría "subredes" definidas.

R2: En la mayoría de los casos, la ruta "predeterminada" utilizada será la primera que aparezca en la tabla de enrutamiento. En términos (muy) simplistas, el núcleo recorre la tabla de enrutamiento hasta que encuentra una coincidencia y transmite el paquete por el enlace coincidente. En su caso, la mayor parte del tráfico "predeterminado" se enviará para su posterior enrutamiento 16.107.200.1en su eth0interfaz.

información relacionada