Juniper SRX240H perde conectividade com o roteador upstream

Eu tenho dois SRX240 agrupados. O cluster é configurado com 2 grupos de redundância e, em seguida, 3 RETHs.

reth1 está conectado à nossa conexão à Internet via ge-0/0/5 e ge-5/0/5. Nossa conexão à Internet é de 100mbps em cada linha alugada. Temos que garantir que eles especificem desativar as configurações de negociação automática e definir manualmente a velocidade e o modo full duplex.

Aqui está a configuração mostrando essas 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;
            }
        }
    } 
}

O NTE upstream fica no endereço IP 1.1.1.26/30 (IPs alterados).

Minha conexão funciona bem, chego perto das velocidades máximas de download para a velocidade da linha. Tenho baixa latência e tudo o que você esperaria. No entanto, de vez em quando, de repente, não consigo executar ping no NTE upstream. A conectividade simplesmente para.

Se eu verificar o status da interface, ela será exibida.

{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

O motivo do último retalho foi porque mudei o cabo de rede para descartar isso. Desconectar o cabo e conectar um novo faz com que a conexão volte. Estou um pouco relutante em confiar no momento.

Alguém tem outras coisas que eu possa ver se acontecer novamente?

Eu encontrei o seguinte post http://kb.juniper.net/InfoCenter/index?page=content&id=KB16672, que diz que deve funcionar nas versões suportadas.

Os lançamentos, especificamente para dispositivos SRX High End, são 11.2R1, 11.1R1, 10.3R3, 10.4R2, 10.2R4 ou posterior. Para dispositivos Branch SRX, isso é suportado apenas a partir dos Junos 11.1R4, 11.2R2 e 11.4R1 em diante.

Estou executando a versão 11.2R4.3

Aqui estão algumas informações da versão que devem ajudar. Eu acho que a outra coisa que imediatamente me impressiona é a negociação automática sendo desativada, o que não deve ser necessário. Isso é algo que seu provedor está pedindo ou com base em comportamentos aprendidos? Eu recomendo a leitura do que está por aí, pois a negociação automática é recomendada há mais de 10 anos. Qualquer coisa com a qual você está se conectando também deve funcionar bem (a última vez que tive problemas foi em um 3500XL - estamos falando demais). Verificação de saída:

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

Primeiro, o Junos 11.4R7.5 é a versão suportada recomendada para SRX240, a partir de 8 de abril de 2013, por JTAC (desde que você mencionou as versões).

http://kb.juniper.net/InfoCenter/index?page=content&id=KB21476 (é necessário fazer login)

Além disso, a JTAC recomenda lançamentos de EEOL nos recursos SRX ou J Series for IPsec (podem ou não ser aplicáveis, mas para a FYI). (Para mim, os únicos lançamentos disponíveis para o SRX240H no juniper.net são 10.4, 11.4 e 12.1 - que podem ajudar a definir suas expectativas sobre o que executar.)

http://www.juniper.net/alerts/viewalert.jsp?txtAlertNumber=PSN-2013-01-822&actionBtn=Search (é necessário fazer login)

Você também está executando uma versão que foi lançada antes da vulnerabilidade TCP malformada. Estremeço ao pensar que existe uma exploração ao vivo, mas você definitivamente precisa estar em versões publicadas por volta de janeiro ou fevereiro de 2013 ou mais tarde. As versões necessárias para o 11.2 são 11.2R5.5 ou 11.2R7.5 (ou superior)

http://osvdb.org/89751

Mencionei versões porque o SRX também é uma plataforma de "evolução rápida", e evidências e boatos sugerem que você desejará atualizar com mais frequência.