Das ist wirklich ein seltsames Problem.
Ich versuche, einen Juniper SRX 220H als Gateway zu installieren, um meinen alten Cisco-Router in meiner Testnetzwerkumgebung zu ersetzen. Die vereinfachte Topologie ist unten aufgeführt:
ISP ----- ONT ----- SRX ----- Other devices (Routers, switches, client computers...)
Die Verbindung von ISP zu SRX ist eine 802.1Q-Trunk-Verbindung, die zwei VLANs enthält (VLAN 35 für Internetzugang, von DHCP zugewiesene IP-Adresse, Lease für 20 Minuten. VLAN 34 für IPTV, das hier nicht verwendet wird).
SRX kann zunächst eine IP-Adresse vom ISP erhalten. Nach 12 bis 17 Minuten (nach der Erneuerung der ersten DHCP-Lease und vor der zweiten Erneuerung) verlor SRX den Internetzugang (kann das Gateway nicht anpingen). Es gibt nichts Besonderes oder gar einen Hinweis im Systemprotokoll oder im Systemstatus. "show interface" sagte, dass alles gut funktioniert. Aber überhaupt kein Verkehr in ge-0/0/0. Wenn ich das Kabel abziehe oder SRX neu starte, funktioniert es weitere 12 bis 17 Minuten und dann wird der gesamte Datenverkehr wieder gestoppt.
Bevor ich diesen SRX installiere, funktioniert der alte Cisco-Router mit derselben Konfiguration problemlos.
Irgendwelche Hinweise?
Die Teilkonfiguration von SRX ist unten aufgeführt:
interfaces {
ge-0/0/0 {
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members vlan-internet;
}
}
}
}
ge-0/0/1 {
unit 0 {
family ethernet-switching {
vlan {
members vlan-trust;
}
}
}
vlan {
mac xx:xx:xx:xx:xx:xx;
unit 0 {
family inet {
address 192.168.99.254/24;
}
}
unit 35 {
family inet {
dhcp;
}
}
}
}
vlans {
vlan-internet {
vlan-id 35;
l3-interface vlan.35;
}
vlan-trust {
vlan-id 3;
l3-interface vlan.0;
}
}
Entsprechende Cisco-Konfiguration:
interface GigabitEthernet0/0
description WAN
mac-address xxxx.xxxx.xxxx
no ip address
duplex auto
speed auto
media-type rj45
no negotiation auto
!
interface GigabitEthernet0/0.35
description FibreOP-Internet
encapsulation dot1Q 35
ip address dhcp
ip nat outside
ip virtual-reassembly in
!
BEARBEITEN:
Ich habe das Kabel ausgetauscht, das ISP und SRX ge-0/0/0 verbindet. Nichts Gutes.
EDIT2:
Ich habe einen Ersatz-Cisco-Switch konfiguriert, um meine ISP-Umgebung zu simulieren. VLAN-Trunk und dieselbe DHCP-Lease-Laufzeit werden festgelegt. Dann verbinde ich ge-0/0/0 von SRX mit diesem Switch. Die Konfiguration von SRX bleibt erhalten. In diesem Experiment ist das SRX-Verhalten normal. Das macht mich wirklich verwirrt.
EDIT3:
Ausgabe von @ryanklein angefordert
root@Firewall> show dhcp client statistics
warning: dhcp-service subsystem not running - not needed by configuration.
root@Firewall> show dhcp client binding
warning: dhcp-service subsystem not running - not needed by configuration.
EDIT4:
Ausgabe von @ryanklein angefordert
root@Firewall> show system services dhcp statistics
Packets dropped:
Total 0
Messages received:
BOOTREQUEST 0
DHCPDECLINE 0
DHCPDISCOVER 0
DHCPINFORM 0
DHCPRELEASE 0
DHCPREQUEST 0
Messages sent:
BOOTREPLY 0
DHCPOFFER 0
DHCPACK 0
DHCPNAK 0
root@Firewall> show system services dhcp client
Logical Interface name vlan.35
Hardware address xx:xx:xx:xx:xx:xx
Client status bound
Address obtained 142.xxx.xxx.xxx
Update server disabled
Lease obtained at 2015-01-18 03:35:47 NST
Lease expires at 2015-01-18 03:55:47 NST
DHCP options:
Code: 1, Type: ip-address, Value: 255.255.252.0
Name: server-identifier, Value: 142.yyy.yyy.yyy
Name: router, Value: [ 142.xxx.xxx.1 ]
Name: name-server, Value: [ 47.55.55.55, 142.166.166.166 ]
root@Firewall>
EDIT5:
Ich habe die Daten zwischen SRX und ISP erfasst und festgestellt, dass etwas nützlich sein kann.
Das Topologiediagramm wird aktualisiert (fehlendes ONT-Gerät zwischen SRX und ISP hinzugefügt).
Wenn das Internet weg ist, ist die Layer 2-Kommunikation zwischen ONT und SRX weiterhin aktiv. Es scheint, dass das ONT weiterhin ARP-Abfrageanforderungen an die IP-Adressen sendet, die mein ISP SRX zugewiesen hat. Nachdem das Internet verschwunden ist, kann ich diese ARP-Anfragen und -Antworten immer noch sehen. Ich denke, dieses Verhalten zeigt an, dass das ONT nicht die Wurzel dieses Problems ist.
Wenn das Internet nicht mehr verfügbar ist, erhalten DHCP-Anforderungspakete wie andere Datenverkehr keine Antworten. Ich habe versucht, meine IP-Adresse unter SRX zu erneuern, nachdem das Internet weg war, aber es ist fehlgeschlagen. Die erfassten Daten zeigen, dass keine Antworten von der Remote-Seite.
Die DHCP-Erneuerung ist erfolgreich, wenn das Internet normal ist. Wenn ich "Anforderungssystemdienst DHCP-Client erneuern vlan.35" ausgegeben habe, kann ich die DHCP-Anforderung und die entsprechende DHCP-ACK sehen.
(FALSCH. Siehe nächster Punkt.) Wenn das Internet nicht mehr verfügbar ist, geben Sie die aktuelle DHCP-Lease frei und fordern Sie eine neue an, um die Konnektivität wiederherzustellen. Ich habe versucht, die aktuelle DHCP-Lease freizugeben und zu erneuern, dann hat SRX eine neue IP-Adresse erhalten und das Internet ist zurück. Die erfassten Daten zeigen, dass ein einzelnes DHCP-Anforderungspaket zwar keine Antwort erhält (siehe oben), ein DHCP-Freigabepaket jedoch eine DHCP-NAK- Antwort ergibt . Danach wird eine DHCP-Erkennung ausgegeben und Sie erhalten das richtige DHCP-Angebot. Dann ist das Internet zurück. Als ich jedoch versuchte, dieses Ergebnis zu wiederholen, war nichts Gutes: Weder die DHCP-Version noch die DHCP-Erkennung erhalten Antworten. Ich habe den Befehl zum Freigeben und Erneuern direkt nach einem Erneuerungsbefehl ausgegeben. Ich bin nicht sicher, ob das nicht entsprechende Verhalten darauf zurückzuführen ist, dass diese Pakete zu schnell gesendet wurden oder nicht.
Nachdem das Internet nicht mehr verfügbar ist, stellen Sie eine DHCP-Erkennungsanforderung aus und verarbeiten Sie diese, wenn die erste Anforderung die Internetverbindung wiederherstellt. Erfasste Daten zeigen, dass die Ausgabe eines DHCP-Anforderungspakets bei Abwesenheit des Internets zu einer DHCP-NAK-Antwort führt. In Kombination mit dem Ergebnis des vorherigen Elements führt die Ausgabe einer DHCP-Anforderung und einer DHCP-Freigabe zu DHCP-NAK. Wenn Sie jedoch so vorgehen, als ob Sie zum ersten Mal eine IP-Adresse vom DHCP-Server anfordern (DHCP-Erkennung senden, dann DHCP-Anforderung), wird ein positives Ergebnis erzielt und der Internetzugang wiederhergestellt. AKTUALISIERT: Es scheint, dass die NAK nicht immer gesendet wird ... manchmal wird eine DHCP-Anfrage / Freigabe mit DHCP NAK zurückgegeben, manchmal nur Stille ...
quelle
Antworten:
Ich habe dieses Problem endlich gelöst. Beim Erfassen und Vergleichen von DHCP Discover-Paketen, die von JunOS und Cisco gesendet wurden, stellte ich fest, dass Cisco standardmäßig die Client-ID für Option 64 und den Hostnamen für Option 12 sendet. JunOS sendet sie jedoch nicht ohne ausdrückliche Anweisungen.
Ich denke, mein ISP richtet einen Filter oder etwas auf ihrer Seite ein. Die beiden oben genannten Optionen sind obligatorisch. Als ich meinen SRX so konfigurierte, dass er sie sendet, ging alles durch.
quelle
Eine Sache, die Sie möglicherweise bestätigen möchten, ist, dass der SRX anstelle eines anderen DHCPDISCOVER eine ordnungsgemäße DHCPREQUEST verwendet, um die Adresse zu erneuern.
Hier erfahren Sie, wie Sie das Debuggen aktivieren.
http://kb.juniper.net/InfoCenter/index?page=content&id=KB26748#DHCP_Client
Ich habe nur begrenzte Erfahrung mit Juniper, aber ich habe mindestens ein großes Betriebssystem gesehen, das dies tat, als die Systemuhr nicht korrekt war.
Zumindest möchten Sie sehen, was mit der Erneuerung passiert.
quelle