Juniper SRX240H pierde conectividad al enrutador ascendente

Tengo dos SRX240 agrupados. La agrupación se configura con 2 grupos de redundancia y luego 3 RETH.

reth1 está conectado a nuestra conexión a internet a través de ge-0/0/5 y ge-5/0/5. Nuestra conexión a Internet es una línea arrendada de 100 Mbps por trayecto. Tenemos que asegurarnos de que especifiquen desactivar la configuración de negociación automática y establecer manualmente la velocidad y el modo dúplex completo.

Aquí está la configuración que muestra esas interfaces

cluster {
    reth-count 3;
    redundancy-group 0 {
        node 0 priority 100;
        node 1 priority 99;
    }
    redundancy-group 1 {
        node 0 priority 100;
        node 1 priority 99;
        preempt;
        interface-monitor {
            ge-0/0/5 weight 255;
            ge-5/0/5 weight 255;
        }
     }
}

interfaces {
    ge-0/0/5 {
        speed 100m;
        link-mode full-duplex;
        gigether-options {
            no-auto-negotiation;
            redundant-parent reth1;
        }
    }
    ge-5/0/5 {
        speed 100m;
        gigether-options {
            no-auto-negotiation;
            redundant-parent reth1;
        }
    }
    reth1 {
        redundant-ether-options {
            redundancy-group 1;
        }
        unit 0 {
            family inet {
                address 1.1.1.25/30;
            }
        }
    } 
}

El NTE ascendente se encuentra en la dirección IP 1.1.1.26/30 (IP modificada).

Mi conexión funciona bien, me acerco a las velocidades máximas de descarga para la velocidad de la línea. Tengo baja latencia y todo lo que esperas. Sin embargo, de vez en cuando de repente no puedo hacer ping al NTE aguas arriba. La conectividad simplemente se detiene.

Si verifico el estado de la interfaz, se muestra como activa

{primary:node0}
gareth@FW01> show interfaces ge-0/0/5
Physical interface: ge-0/0/5, Enabled, Physical link is Up
  Interface index: 139, SNMP ifIndex: 527
  Link-level type: Ethernet, MTU: 1514, Link-mode: Full-duplex, Speed: 100mbps,
  BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled,
  Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled,
  Remote fault: Online
  Device flags   : Present Running
  Interface flags: SNMP-Traps Internal: 0x0
  Link flags     : None
  CoS queues     : 8 supported, 8 maximum usable queues
  Current address: 00:10:de:ff:20:01, Hardware address: 08:81:f4:cd:a1:05
  Last flapped   : 2013-05-16 01:35:08 UTC (03:39:01 ago)
  Input rate     : 7144 bps (10 pps)
  Output rate    : 34488 bps (58 pps)
  Active alarms  : None
  Active defects : None
  Interface transmit statistics: Disabled

  Logical interface ge-0/0/5.0 (Index 74) (SNMP ifIndex 528)
    Flags: SNMP-Traps 0x0 Encapsulation: ENET2
    Input packets : 20966964
    Output packets: 13453431
    Security: Zone: Null
    Protocol aenet, AE bundle: reth1.0   Link Index: 0

{primary:node0}
gareth@FW01> show interfaces reth1.0
  Logical interface reth1.0 (Index 68) (SNMP ifIndex 578)
    Flags: SNMP-Traps 0x0 Encapsulation: ENET2
    Statistics        Packets        pps         Bytes          bps
    Bundle:
        Input :      20967161         12   19068965037         9320
        Output:      13454302         44    3387733487        29088
    Security: Zone: untrust-internet
    Allowed host-inbound traffic : ping
    Protocol inet, MTU: 1500
      Flags: Sendbcast-pkt-to-re
      Addresses, Flags: Is-Preferred Is-Primary
        Destination: 1.1.1.24/30, Local: 1.1.1.25,
        Broadcast: 1.1.1.27

La razón de la última aleta fue porque cambié el cable de red para descartarlo. Desenchufar el cable y conectar uno nuevo hace que la conexión regrese. Soy un poco reacio a confiar en él en este momento.

¿Alguien tiene alguna otra cosa que pueda ver si sucede de nuevo?

Encontré la siguiente publicación http://kb.juniper.net/InfoCenter/index?page=content&id=KB16672 que dice que debería funcionar en las versiones compatibles.

Las versiones, específicamente para dispositivos High End SRX, son 11.2R1, 11.1R1, 10.3R3, 10.4R2, 10.2R4 o posterior. Para dispositivos Branch SRX, esto solo es compatible desde Junos 11.1R4, 11.2R2 y 11.4R1 en adelante.

Estoy ejecutando la versión 11.2R4.3

Aquí hay información de la versión que debería ayudar. Creo que lo otro que me llama la atención de inmediato es la desactivación de la negociación automática, lo que no debería ser necesario. ¿Es esto algo que su proveedor está pidiendo o basado en comportamientos aprendidos? Recomiendo leer lo que hay ahí fuera, ya que la negociación automática se ha recomendado durante más de 10 años. Cualquier cosa a la que te estés conectando también debería funcionar bien (la última vez que tuve problemas fue en un 3500XL, estamos hablando demasiado). Revisa:

http://etherealmind.com/ethernet-autonegotiation-works-why-how-standard-should-be-set/

En primer lugar, Junos 11.4R7.5 es la versión compatible recomendada para SRX240, a partir del 8 de abril de 2013, según JTAC (ya que mencionó las versiones).

http://kb.juniper.net/InfoCenter/index?page=content&id=KB21476 (necesita iniciar sesión)

Además, JTAC recomienda las versiones EEOL en SRX o J Series para las características de IPsec (puede o no aplicarse, pero para su información). (Para mí, los únicos lanzamientos disponibles para SRX240H en juniper.net son 10.4, 11.4 y 12.1, que pueden ayudarlo a establecer sus expectativas sobre qué ejecutar).

http://www.juniper.net/alerts/viewalert.jsp?txtAlertNumber=PSN-2013-01-822&actionBtn=Search (necesita iniciar sesión)

También está ejecutando una versión que se lanzó antes de que apareciera la vulnerabilidad TCP malformada. Me estremezco al pensar que existe un exploit en vivo, pero definitivamente necesitas estar en versiones que se publicaron alrededor de enero o febrero de 2013, o más tarde. Las versiones que necesita para 11.2 son 11.2R5.5 o 11.2R7.5 (o superior)

http://osvdb.org/89751

Mencioné versiones porque el SRX también es una plataforma de 'evolución rápida', y la evidencia anecdótica y los rumores sugieren que querrá actualizar con más frecuencia.