Zum Inhalt wechseln


Foto

GW nur anpingbar wenn nur ein Port im Etherchannel aktiv ist


  • Bitte melde dich an um zu Antworten
9 Antworten in diesem Thema

#1 Kartfahrer

Kartfahrer

    Newbie

  • 60 Beiträge

 

Geschrieben 29. Juli 2015 - 06:18

Hallo, ich hab momentan ein interessantes Phänomen wo mir gerade weng der Lösungsansatz fehlt.

 

Ich hab zwischen zwei 2960S die gestackt sind und zwei 3750X die ebenfalls gestackt sind einem Etherchannel mit zwei LWL-Uplinkports die als Trunk konfiguriert sind.

An dem 3750X hängen per LWL noch weitere Switche wo irgendwann der Uplink ins Vlan 178 erfolgt. Das Netz hinter dem Vlan 178 wird von uns selber nicht betreut sondern lediglich auf L2 geswitcht.

 

So grundsätzlich läuft auch alles soweit problemlos, ich kann von Acceesports die im Vlan 178 hängen auf das Netzwerk zugreifen.

Ich kann an Accessports in anderen Vlans an dem gestackten 2960S problemlos alle möglichen IPs erreichen und im Netzwerk arbeiten.

 

Wenn ich jetzt allerdings auf dem 2960S einen Port ins Vlan 178 schalte bekomme ich per DHCP sauber eine IP-Adresse zugewiesen und kann den DHCP / DNS-Server auch anpingen.

Beim Versuch den Gateway anzupingen bekomme ich leider nur Zeitüberschreitungen. Allerdings nur solange wie ich beide Ports die zum Etherchannel zwischen den zwei 2960S und dem zwei 3750X konfiguriert sind. Wird einer der zwei Ports disabled kann ich den Gateway nun auch problemlos anpingen. Es ist jetzt auch egal welchen der zwei Ports ich abschalte, das Phänomen ist bei beiden Ports reproduzierbar.

 

Wäre super wenn mir jemand weiterhelfen könnte.

Kartfahrer


CCNA SECURITY pass


#2 Otaku19

Otaku19

    Expert Member

  • 1.948 Beiträge

 

Geschrieben 29. Juli 2015 - 08:01

zeig mal die config der beiden Po Interface + der physikalischen Interfaces


Done: 640-801; 640-553; 642-524; 642-515; 642-892; 642-832; 642-504; 640-863; 642-627; 642-874; 642-785; ITIL v3 Foundation
Enterasys Systems Engineer; CompTIA Sec+; CompTIA Mobility+; CISSP; CISSP-ISSAP; Barracuda NGSE/NGSX; CISM


#3 Kartfahrer

Kartfahrer

    Newbie

  • 60 Beiträge

 

Geschrieben 29. Juli 2015 - 08:13

3750X:

 

interface Port-channel11
 description Neubau-1.04-A IP=210.180.241
 switchport trunk encapsulation dot1q
 switchport mode trunk
end
!
interface GigabitEthernet2/0/6
 description Neubau-1.04-A Switch 1 P52 IP=210.180.241
 switchport trunk encapsulation dot1q
 switchport mode trunk
 channel-group 11 mode on
end
!
interface GigabitEthernet3/0/6
 description Neubau-1.04-A Switch 2 P52 IP=210.180.241
 switchport trunk encapsulation dot1q
 switchport mode trunk
 channel-group 11 mode on
end
_____________________________________________________________________________________________________________
 

2960S:

 

interface Port-channel1
 description Uplink Core
 switchport mode trunk
end
!
interface GigabitEthernet1/0/52
 description Uplink Core
 switchport mode trunk
 channel-group 1 mode on
end
!
interface GigabitEthernet2/0/52
 description Uplink Core
 switchport mode trunk
 channel-group 1 mode on
end

CCNA SECURITY pass


#4 Otaku19

Otaku19

    Expert Member

  • 1.948 Beiträge

 

Geschrieben 29. Juli 2015 - 13:10

OK...was ist dann das gateway ? ist das irgnediene "merkwürdige" hochverfügbarkeitstechnologie ? Denn bei einem Stack müssen alle 4 switches das vlan 178 in ihrer database haben. mode on ist übrigens keine gute Idee, mach lieber LACP


Done: 640-801; 640-553; 642-524; 642-515; 642-892; 642-832; 642-504; 640-863; 642-627; 642-874; 642-785; ITIL v3 Foundation
Enterasys Systems Engineer; CompTIA Sec+; CompTIA Mobility+; CISSP; CISSP-ISSAP; Barracuda NGSE/NGSX; CISM


#5 Kartfahrer

Kartfahrer

    Newbie

  • 60 Beiträge

 

Geschrieben 29. Juli 2015 - 14:22

Bei dem Vlan 178 handelt es sich um ein "einfaches" Schulnetzwerk das von den Lehrern betreut wird.

Das Gateway ist in dem Fall ein DSL-Router mit ein paar Firewallfunktionen, also eigentlich nix exotisches.

Der 3750X (Core) ist bei uns VTP-Server und alle anderen Switches VTP-Clients und bekommen ausschließlich vom Server die Vlan propagiert.

 

Warum ist mode on in einer homogenen Cisco Umgebung keine gute Idee? Das LACP Herstellerübergreifend mehr Sinn macht versteh ich, aber bis jetzt hatte wir mit mode on noch keine Schwierigkeiten. 


CCNA SECURITY pass


#6 Otaku19

Otaku19

    Expert Member

  • 1.948 Beiträge

 

Geschrieben 30. Juli 2015 - 05:21

Weil LACP auch direkt linkfehler erkennt, wenn LACP nicht funktioniert, dann gibts nachher auch Probleme payload über den link zu bekommen. Daher verwenden wir nur noch LACP, udld hin oder her.

 

Hm...das ist dann wirklich seltsam, würde mir mal genau den mac table anschauen bei aktiviertem und deaktiviertem Portchannel (bzw wenn du einen link aus dem Portchannel nimmst)


Done: 640-801; 640-553; 642-524; 642-515; 642-892; 642-832; 642-504; 640-863; 642-627; 642-874; 642-785; ITIL v3 Foundation
Enterasys Systems Engineer; CompTIA Sec+; CompTIA Mobility+; CISSP; CISSP-ISSAP; Barracuda NGSE/NGSX; CISM


#7 Kartfahrer

Kartfahrer

    Newbie

  • 60 Beiträge

 

Geschrieben 31. Juli 2015 - 07:54

Ich bin momentan leider krank und kann es nicht genau prüfen, ich schau aber mal das ich nächste Woche mal in der Außenstelle vorbei schau und das vor Ort prüfe.

Ich bin aber der Meinung das ich die mac vom GW jederzeit am 2960S laut mac tabel am PO1 gefunden wurde. Also auch wenn ich auf den PING keine Antwort bekomme.

Wenn ich den Ping permanent laufen lass ist es so, das in dem Moment wo ich ein Interface auf dem Portchannel deaktiviere der Ping funktioniert, und sobald beide wieder Online sind ich Zeitüberschreitung bekomme.

Ist also wirklich eine Sache von Sekunden.

 

Ich werd nächste Woche nach Möglichkeit mich mit dem Wireshark dazwischen hängen und schauen wo ich welches Paket noch seh.

Was aber noch viel Interessanter ist was ich dagegen machen könnte um das Problem zu lösen.

Danke aber schon mal für die Unterstützung


CCNA SECURITY pass


#8 Kartfahrer

Kartfahrer

    Newbie

  • 60 Beiträge

 

Geschrieben 06. August 2015 - 14:33

So gestern war ich jetzt mal wieder vor Ort und hab versucht ein paar neue Erkenntnisse zu bekommen.

Ich hab mal kurz eine Grafik angehängt wo die relevanten Gerätschaften zusehen sind.

 

Beim Versuch mittels Wireshark ein Ping-Paket zum Gateway und das dazugehörige Antwortpaket zu verfolgen konnte folgendes festgestellt werden.

1. Wenn alles wie in der Grafik zu sehen geschalten ist, seh ich mein Paket am Problemswitch, aber es kommt nie am Übergabepunkt zum Lehrernetz an.

2. Wenn nur eine der roten Leitungen zum Problemswitch geschaltet ist, kann ich mein Paket am Problemswitch sowie am Übergabepunkt zum Lehrernetz verfolgen. Das dazugehörige Antwortpaket ist auch wieder am Test-Laptop angekommen.

3. Jetzt hab ich den Etherchannel zwischen dem Problemswitch und dem Core so umkonfiguriert das beide Leitungen auf einem Switch enden. Jetzt konnte das Ping-Paket auch mit ZWEI aktiven Leitungen zum GW und wieder zurück verfolgt werden.

 

 

Ein Ping der gleichzeitig auf die IP des DHCP-Servers geschickt wurde ist permanent am Übergabepunkt zum Lehrernetz sowie das Antwortpaket am Test-Laptop angekommen.

Die MAC des Gateway war jederzeit in der mac-address-table des Problemswitches vorhanden.

 

Nachdem wir sämtliche SFP-Module (weils einfach im laufenden Betrieb möglich) ausgetauscht, auch wenn ich mir keine Verbesserung davon versprochen hab.

Ich hätte jetzt vermutet das mein Problem von einem defektem Stack-Modul kommen dürfte, allerdings habe ich im Vorfeld den kompletten Probelmswitch-Stack rebootet wovon ich mir auch keine Verbesserung versprochen habe. Nach dem Bootvorgang wurde ich allerdings eines besseren belehrt als ich plötzlich eine Antwort auf meinen PING erhalten hatte obwohl wieder alles so wie ursprünglich geschalten war.

 

Ich hab jetzt noch ein ungutes Gefühl da ich keine wirkliche Fehlerquelle lokalisieren konnte, aber ich werde es in nächster Zeit mal intensiver im Auge behalten.

Angehängte Dateien


CCNA SECURITY pass


#9 NachfrageSpecht

NachfrageSpecht

    Newbie

  • 22 Beiträge

 

Geschrieben 06. August 2015 - 19:19

 

Nach dem Bootvorgang wurde ich allerdings eines besseren belehrt als ich plötzlich eine Antwort auf meinen PING erhalten hatte obwohl wieder alles so wie ursprünglich geschalten war.

Puhh...das alles ist 'ne Horror Story. Gut für dich, das der Reboot den Hokus-Pokus beendet hat...manche Dinge wird man nie verstehen.



#10 Kartfahrer

Kartfahrer

    Newbie

  • 60 Beiträge

 

Geschrieben 07. August 2015 - 05:22

Puhh...das alles ist 'ne Horror Story. Gut für dich, das der Reboot den Hokus-Pokus beendet hat...manche Dinge wird man nie verstehen.

Ich hoff das der Hokus-Pokus so wirklich beendet ist, aber ehrlich gesagt wäre es mir lieber wenn ein Stackmodul oder so kaputt wäre und getauscht werden müsste.

So richtig trau ich dem Frieden so leider noch nicht.  :wink2:


CCNA SECURITY pass