Juniper SRX240H verliert die Verbindung zum Upstream-Router

Ich habe zwei SRX240 zusammen gruppiert. Das Clustering wird mit 2 Redundanzgruppen und dann 3 RETHs konfiguriert.

reth1 ist über ge-0/0/5 und ge-5/0/5 mit unserer Internetverbindung verbunden. Unsere Internetverbindung ist eine Mietleitung mit 100 Mbit / s pro Strecke. Wir müssen sicherstellen, dass sie die Einstellungen für die automatische Aushandlung deaktivieren und die Geschwindigkeit und den Vollduplexmodus manuell einstellen.

Hier ist die Konfiguration, die diese Schnittstellen zeigt

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;
            }
        }
    } 
}

Das Upstream-NTE befindet sich auf der IP-Adresse 1.1.1.26/30 (IPs geändert).

Meine Verbindung funktioniert einwandfrei, ich komme der maximalen Download-Geschwindigkeit für die Leitungsgeschwindigkeit nahe. Ich habe eine geringe Latenz und alles andere, was Sie erwarten würden. Ab und zu kann ich die Upstream-NTE jedoch plötzlich nicht mehr anpingen. Die Konnektivität wird nur gestoppt.

Wenn ich den Schnittstellenstatus überprüfe, wird angezeigt, dass er aktiv ist.

{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

Der Grund für die letzte Klappe war, dass ich das Netzwerkkabel geändert habe, um dies auszuschließen. Wenn Sie das Kabel abziehen und ein neues anschließen, wird die Verbindung wiederhergestellt. Ich bin im Moment etwas zurückhaltend, ihm zu vertrauen.

Hat jemand andere Dinge, die ich mir ansehen kann, wenn es wieder passiert?

Ich habe den folgenden Beitrag http://kb.juniper.net/InfoCenter/index?page=content&id=KB16672 gefunden, der besagt, dass er auf unterstützten Versionen funktionieren sollte.

Die Versionen, speziell für High-End-SRX-Geräte, sind 11.2R1, 11.1R1, 10.3R3, 10.4R2, 10.2R4 oder höher. Für Branch SRX-Geräte wird dies nur ab Junos 11.1R4, 11.2R2 und 11.4R1 unterstützt.

Ich verwende Version 11.2R4.3

Hier sind einige Versionsinformationen, die helfen sollten. Ich denke, das andere, was mir sofort auffällt, ist die Deaktivierung der Autonegotiation, was nicht notwendig sein sollte. Ist dies etwas, wonach Ihr Anbieter fragt, oder basiert er auf erlernten Verhaltensweisen? Ich empfehle zu lesen, was da draußen ist, da Autonegotiation seit über 10 Jahren empfohlen wird. Alles, mit dem Sie sich verbinden, sollte auch gut funktionieren (das letzte Mal, als ich Probleme hatte, war auf einem 3500XL - wir sprechen von Ooooold). Auschecken:

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

Zunächst einmal ist Junos 11.4R7.5 die unterstützte Version, die für SRX240 ab dem 8. April 2013 gemäß JTAC empfohlen wird (da Sie Versionen erwähnt haben).

http://kb.juniper.net/InfoCenter/index?page=content&id=KB21476 (Login erforderlich)

Außerdem empfiehlt JTAC EEOL-Versionen der SRX- oder J-Serie für IPSec-Funktionen (möglicherweise zutreffend oder nicht, aber zu Ihrer Information). (Für mich sind die einzigen für SRX240H auf juniper.net verfügbaren Versionen 10.4, 11.4 und 12.1 - dies kann Ihnen dabei helfen, Ihre Erwartungen an die Ausführung festzulegen.)

http://www.juniper.net/alerts/viewalert.jsp?txtAlertNumber=PSN-2013-01-822&actionBtn=Search (Login erforderlich)

Sie führen auch eine Version aus, die veröffentlicht wurde, bevor die fehlerhafte TCP-Sicherheitsanfälligkeit aufgetreten ist. Ich schaudere, wenn ich denke, dass es einen Live-Exploit gibt, aber Sie müssen auf jeden Fall Versionen verwenden, die im Januar oder Februar 2013 oder später veröffentlicht wurden. Die Versionen, die Sie für 11.2 benötigen, sind 11.2R5.5 oder 11.2R7.5 (oder höher).

http://osvdb.org/89751

Ich habe Versionen erwähnt, weil der SRX ebenfalls eine sich schnell entwickelnde Plattform ist und anekdotische Beweise und Hörensagen darauf hindeuten, dass Sie häufiger aktualisieren möchten.