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