Ok, quindi devo ammettere che non sono un esperto di come funzionano i dispositivi Juniper in rete, quindi l'intero problema potrebbe essere il motivo per cui ho problemi a capire qualcosa che sto vedendo su un paio di SRX210H in cluster.
Quindi, quando eseguo SSH su uno di questi dispositivi Juniper in cluster, mi viene presentato un prompt BSD / Unix standard. Se eseguo il comando ifconfig , ricevo un lungo elenco di interfacce e le ultime due interfacce sono le seguenti:
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 po 'più in alto nella lista delle interfacce, anch'io ho un'interfaccia 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
Quando cerco il 30.17.0.200, ottengo il seguente:
IP Address: 30.17.0.200
Organization: DoD Network Information Center
ISP/Hosting: DoD Network Information Center
Updated: 10/01/2016 09:34 AM
Quando scrivo un po 'più a fondo, trovo un riferimento a un articolo KB di juniper intitolato
Che ha le seguenti informazioni
SUMMARY:
This article describes the issue of the 'show interface terse' command displaying fabric interface IP addresses with 30.0.0.0/8 addresses.
SYMPTOMS:
Fabric interface IP addresses are system-determined and not configurable. The following is a excerpt of the output of '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 downSOLUTION:
- This is expected behavior of the system.
- These addresses are used only for the internal communication of the cluster.
- No routes are installed for the fab0 subnets; it will not affect any transit traffic.
If, for whatever reason, a fabric interface was accidentally plugged into a production segment, the fabric traffic would still not be routed out, as it would not get processed at layer 2.
PURPOSE:
Implementation
Detto questo, perché esattamente è il comportamento previsto? Perché Juniper deciderà di utilizzare gli indirizzi IP pubblici di proprietà del Centro informazioni di rete DoD per preformare questa funzione per i dispositivi di rete in cluster? La mia preoccupazione principale è questa, all'inizio di quest'anno il DoD ha divulgato pubblicamente backdoor di sicurezza nei prodotti Juniper. Non lo troverei troppo strano se si trattasse di un'altra organizzazione, ma il fatto che il Dipartimento della Difesa sia stato ingannato nel chiamare Juniper ad avere delle backdoor nei loro prodotti. Vedi il seguente URL per maggiori informazioni sulla backdoor che è stata esposta all'inizio del 2016.
Qualcuno può spiegare quale sia lo scopo di utilizzare lo spazio pubblico degli indirizzi IP di proprietà del DoD sulle apparecchiature Juniper? Perché non dovrebbero semplicemente usare un punto per indicare un intervallo di indirizzi IP privati per le comunicazioni tra due dispositivi in cluster? Vorrei una spiegazione tecnica se possibile (non sono sicuro che esista una spiegazione non tecnica considerando la domanda che viene posta). Qualcuno degli esperti di Juniper si preoccupa di cantare?
Devo dire che quando guardo i contatori di pacchetti per entrambe le interfacce, c'è molto traffico di pacchetti in uscita, assolutamente 0 traffico di pacchetti in entrata sulle interfacce fab0.0 e fab1.0. Se venisse usato solo per il failover / clustering, non ci sarebbero sia pacchetti in entrata che in uscita?
Un'altra domanda è perché nell'articolo KB di Juniper fanno riferimento all'intervallo di indirizzi IP pubblico come 30.0.0.0/8 quando la linea dalla config che mostrano nell'esempio mostra chiaramente che la rete sta usando un / 24 ( 254 host)?