Bien, tengo que admitir que no soy un experto en cómo funcionan los dispositivos en red de Juniper, por lo que este problema podría ser el motivo por el que tengo problemas para entender algo que veo en un par de SRX210H agrupados.
Entonces, cuando hago SSH en uno de estos dispositivos Juniper agrupados, se me presenta un indicador BSD / Unix estándar. Si ejecuto el comando ifconfig , obtengo una larga lista de interfaces, y las dos últimas interfaces son las siguientes:
fab1: encaps: ether; framing: ether
flags=0x3/0xc000 <PRESENT|RUNNING>
curr media: i802 80:71:1f:b9:27:70
fab1.0: flags=0xc000 <UP|MULTICAST>
inet mtu 8996 local=30.18.0.200 dest=30.18.0.0/24 bcast=30.18.0.255
un poco más arriba en la lista de interfaces, yo también tengo una interfaz fab0
fab0: encaps: ether; framing: ether
flags=0x3/0xc000 <PRESENT|RUNNING>
curr media: i802 80:71:1f:b9:17:b0
fab0.0: flags=0xc000 <UP|MULTICAST>
inet mtu 8996 local=30.17.0.200 dest=30.17.0.0/24 bcast=30.17.0.255
Cuando busco el 30.17.0.200, obtengo lo siguiente:
IP Address: 30.17.0.200
Organization: DoD Network Information Center
ISP/Hosting: DoD Network Information Center
Updated: 10/01/2016 09:34 AM
Cuando profundizo un poco más, encuentro una referencia a un artículo de Juniper KB titulado
Que tiene la siguiente información
RESUMEN :
Este artículo describe el problema del comando 'show interface terse' que muestra las direcciones IP de la interfaz de tejido con 30.0.0.0/8 direcciones.
SÍNTOMAS :
Las direcciones IP de la interfaz de red Fabric están determinadas por el sistema y no son configurables. El siguiente es un extracto de la salida de 'show interface terse':
fab0 up up fab0.0 up up inet 30.17.0.200/24 fab1 up down fab1.0 up down inet 30.18.0.200/24 fxp0 up downSOLUCIÓN :
- Este es el comportamiento esperado del sistema.
- Estas direcciones se usan solo para la comunicación interna del clúster.
- No se instalan rutas para las subredes fab0; no afectará ningún tráfico de tránsito.
Si, por el motivo que fuera, una interfaz de tejido se conectó accidentalmente a un segmento de producción, el tráfico de tejido todavía no se enrutaría, ya que no se procesaría en la capa 2.
PROPÓSITO :
Implementación
Dicho esto, ¿por qué es exactamente el comportamiento esperado? ¿Por qué decidirá Juniper usar las direcciones IP públicas que son propiedad del Centro de Información de la Red DoD para realizar esta función en los dispositivos en red agrupados? Mi principal preocupación es esta: a principios de este año, el DoD divulgó públicamente las puertas traseras de seguridad de los productos Juniper. No me parecería demasiado extraño si se tratara de cualquier otra organización, pero el hecho de que el Departamento de Defensa estuviera involucrado en llamar a Juniper al tener puertas traseras en sus productos. Consulte la siguiente URL para obtener más información sobre la puerta trasera que se expuso anteriormente en 2016.
¿Alguien puede explicar cuál es el propósito de usar el espacio público de direcciones IP que posee el DoD en el equipo de Juniper? ¿Por qué no usarían un rango de direcciones IP privadas punto a punto para las comunicaciones entre dos dispositivos agrupados? Me gustaría una explicación técnica si es posible (no estoy seguro si existe una explicación no técnica considerando la pregunta que se está haciendo). ¿Algún experto en Juniper se preocupa por participar?
Debo mencionar que cuando miro los contadores de paquetes para ambas interfaces, hay mucho tráfico saliente de paquetes, absolutamente 0 tráfico de paquetes entrantes en las interfaces fab0.0 y fab1.0. Si se utilizara solo para la conmutación por error / agrupación en clúster, ¿no habría paquetes entrantes y salientes?
Otra pregunta es por qué, en el artículo de KB de Juniper, se refieren al rango de direcciones IP públicas como 30.0.0.0/8 cuando la línea de la configuración que muestran en el ejemplo muestra claramente que la red está usando un / 24 ( 254 anfitriones)?