6
Duplicate ICMP Replys
Hallo zusammen,
ich möchte mich gleich schonmal im vorraus für den Umfang dieses Posts entschuldigen, dieses Forum ist aber wirklich meine letzte Hoffnung dem Problem auf die schliche zu kommen.
Folgendes Ausgangssituation:
- Ich habe drei Switches (Cisco SLM2048, Cisco SRW2048, Cisco Catalyst 3500XL)
- Ich habe zwei große 16er Netze (10.10.0.0 Servernetz, 172.16.0.0 Storagenetz)
- Ich habe viele Server die mit 2 Netzwerkkarten im Mode 0 (balance-rr) Bond auf Switch 1 (SLM2048, 10.10.0.0), mit 2 Netzwerkkarten im Bond Mode 0 auf Switch 2 (SRW2048, 172.16.0.0) und mit einem Kabel auf den 3 Switch (3500XL, 10.10.0.0) verbunden sind.
- Alle drei Switches sind mit Crosslinks verbunden und haben Management IP's in dem 10.10.0.0er Netz
- Es gibt keinen Router der Pakete zwischen den beiden Netzen routed
- Auf den Switches ist nichts (keine VLAN's, kein STP, usw....) konfiguriert, einfach nur "dumme" Switches (auch wenn sie mehr könnten).
Zu meinem Problem:
Wenn ich in diesem Konstrukt ein Ping von Server A (10.10.5.11) zu Server B (10.10.5.12) schicke, passiert was seltsames. Ich erhalte massenhaft DUP! Pakete. Allerdings nicht immer die gleiche Anzahl an doppelten Antworten sondern mal 1 Duplikate auf ein ICMP Paket, manchmal aber auch 4.
Es mag sein das ich micht mit diesem Posting dem Spott Preisgebe, aber ich bin wirklich am Ende meines Lateins. Hat irgendwer eine Erklärung woher diese Duplicates kommen und vielleicht sogar einen Lösungsansatz dazu? Ich bin auch bereit über mein Subnetting nachzudenken. In diesem Konstrukt ist zum jetzigen Zeitpunkt nichts festgeschrieben, ich will einfach nur dieses Problem lösen.
Ich bedanke mich bereits im voraus bei allen die sich die Mühe machen diesen Posting zu lesen und zu verstehen.
Beste Grüße
Sebastian
ich möchte mich gleich schonmal im vorraus für den Umfang dieses Posts entschuldigen, dieses Forum ist aber wirklich meine letzte Hoffnung dem Problem auf die schliche zu kommen.
Folgendes Ausgangssituation:
- Ich habe drei Switches (Cisco SLM2048, Cisco SRW2048, Cisco Catalyst 3500XL)
- Ich habe zwei große 16er Netze (10.10.0.0 Servernetz, 172.16.0.0 Storagenetz)
- Ich habe viele Server die mit 2 Netzwerkkarten im Mode 0 (balance-rr) Bond auf Switch 1 (SLM2048, 10.10.0.0), mit 2 Netzwerkkarten im Bond Mode 0 auf Switch 2 (SRW2048, 172.16.0.0) und mit einem Kabel auf den 3 Switch (3500XL, 10.10.0.0) verbunden sind.
- Alle drei Switches sind mit Crosslinks verbunden und haben Management IP's in dem 10.10.0.0er Netz
- Es gibt keinen Router der Pakete zwischen den beiden Netzen routed
- Auf den Switches ist nichts (keine VLAN's, kein STP, usw....) konfiguriert, einfach nur "dumme" Switches (auch wenn sie mehr könnten).
Zu meinem Problem:
Wenn ich in diesem Konstrukt ein Ping von Server A (10.10.5.11) zu Server B (10.10.5.12) schicke, passiert was seltsames. Ich erhalte massenhaft DUP! Pakete. Allerdings nicht immer die gleiche Anzahl an doppelten Antworten sondern mal 1 Duplikate auf ein ICMP Paket, manchmal aber auch 4.
Es mag sein das ich micht mit diesem Posting dem Spott Preisgebe, aber ich bin wirklich am Ende meines Lateins. Hat irgendwer eine Erklärung woher diese Duplicates kommen und vielleicht sogar einen Lösungsansatz dazu? Ich bin auch bereit über mein Subnetting nachzudenken. In diesem Konstrukt ist zum jetzigen Zeitpunkt nichts festgeschrieben, ich will einfach nur dieses Problem lösen.
Ich bedanke mich bereits im voraus bei allen die sich die Mühe machen diesen Posting zu lesen und zu verstehen.
Beste Grüße
Sebastian
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 142823
Url: https://administrator.de/contentid/142823
Printed on: April 20, 2024 at 04:04 o'clock
6 Comments
Latest comment
Mahlzeit,
vorweg: Ich habe keine Ahnung
Erfahrungsgemäß kann ich aber sagen das bei solchen Problemen es oft schon hilft das ganze als Diagramm aufzuzeichnen.
Speziell hier im Forum wirst du dann bestimmt eine Antwort bekommen.
So ein Bild weckt halt immer etwas mehr die Neugier...
Nur so als Tip.
Ich hoffe dein Problem wird gelöst
Gruss Uti
vorweg: Ich habe keine Ahnung
Erfahrungsgemäß kann ich aber sagen das bei solchen Problemen es oft schon hilft das ganze als Diagramm aufzuzeichnen.
Speziell hier im Forum wirst du dann bestimmt eine Antwort bekommen.
So ein Bild weckt halt immer etwas mehr die Neugier...
Nur so als Tip.
Ich hoffe dein Problem wird gelöst
Gruss Uti
Mehrere Dinge solltest du klären:
Wenn alle Switches untereinander verbunden sind, dann musst du zwingend STP aktivieren um einen Loop zu vermeiden. Es sei denn du nutzt nur eine simple Sternförmige Verkabelung OHNE redundante Links.
Auf dich lauern mehrere gefährliche Fussfallen in diesem Szenario mit Link Aggregation / Teaming in die du vermutlich blindlings aus Unwissenheit reingetappt bist !!!
a.) Alle Switches support lediglich Link Aggregation nach 802.3ad mit LACP !! Du musst also zwingend sicherstellen, das deine Server auch dieses Link Aggregation Verfahren supporten und konfiguriert haben ! Die Switchports dieser Links müssen ebenfalls korrekt analog dazu konfiguriert sein. Die Linksys Teile machen das über ein Web Setup der 3500er über das CLI !!
b.) Eine Besonderheit erwartet dich beim Cat 3500, denn der macht beim Link Aggregation (Ether Channel wie Cisco es nennt) per default sein proprietäres PaGP Protokoll statt LACP, was kein Endgerät supportet !! Hier musst du zwingend LACP konfigurieren ! Ein "shaow lacp" zeigt dir immer ob der Trunk aktiv ist !
c.) Ein Trun /aggregierter Link darf niemals gesplittet werden auf unterschiedliche Switches sondern MUSS immer auf einem physischen Switch enden. Das (Splitting) supportet der 802.3ad Standard NICHT !!
d.) Deine Äußerung "...nichts.. konfiguriert, einfach nur "dumme" Switches.." lässt Böses erahnen, das du das Teaming / Bonding NICHT auf der Switchseite konfiguriert hast...das erzeugt eben solche Verhältnisse wie bei dir !!
Bevor wir nun ins Eingemachte gehen prüfe bitte genau diese Vorgaben und lies dir unbedingt dazu diese Threads durch die das Verhalten im einzelnen erklären:
Motherboard mit 2 Onboard LAN Anschlüssen
Traffic am Server auf 2 NICs verteilen
Kann man einen Server zur Performacesteigerung mit 2 Netzwerkkarten parallel an einem Switch betreiben? Wenn ja mit welcher Konfiguration ?
Bonding mit Broadcom - SLB
Eine saubere Link Aggregation / Bonding / Temaing Konfig mit LACP/802.3ad auf dem Catalyst 3500 sieht vereinfacht so aus:
interface Port-channel1
!
interface FastEthernet1
description LAG Trunk -> Server
channel-group 1 mode active
!
interface FastEthernet2
description LAG Trunk -> Server
channel-group 1 mode active
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.1/19ew/con ...
- "Alle drei Switches sind mit Crosslinks verbunden.."
- "Auf den Switches ist nichts (keine VLAN's, kein STP, usw....)"
Wenn alle Switches untereinander verbunden sind, dann musst du zwingend STP aktivieren um einen Loop zu vermeiden. Es sei denn du nutzt nur eine simple Sternförmige Verkabelung OHNE redundante Links.
Auf dich lauern mehrere gefährliche Fussfallen in diesem Szenario mit Link Aggregation / Teaming in die du vermutlich blindlings aus Unwissenheit reingetappt bist !!!
a.) Alle Switches support lediglich Link Aggregation nach 802.3ad mit LACP !! Du musst also zwingend sicherstellen, das deine Server auch dieses Link Aggregation Verfahren supporten und konfiguriert haben ! Die Switchports dieser Links müssen ebenfalls korrekt analog dazu konfiguriert sein. Die Linksys Teile machen das über ein Web Setup der 3500er über das CLI !!
b.) Eine Besonderheit erwartet dich beim Cat 3500, denn der macht beim Link Aggregation (Ether Channel wie Cisco es nennt) per default sein proprietäres PaGP Protokoll statt LACP, was kein Endgerät supportet !! Hier musst du zwingend LACP konfigurieren ! Ein "shaow lacp" zeigt dir immer ob der Trunk aktiv ist !
c.) Ein Trun /aggregierter Link darf niemals gesplittet werden auf unterschiedliche Switches sondern MUSS immer auf einem physischen Switch enden. Das (Splitting) supportet der 802.3ad Standard NICHT !!
d.) Deine Äußerung "...nichts.. konfiguriert, einfach nur "dumme" Switches.." lässt Böses erahnen, das du das Teaming / Bonding NICHT auf der Switchseite konfiguriert hast...das erzeugt eben solche Verhältnisse wie bei dir !!
Bevor wir nun ins Eingemachte gehen prüfe bitte genau diese Vorgaben und lies dir unbedingt dazu diese Threads durch die das Verhalten im einzelnen erklären:
Motherboard mit 2 Onboard LAN Anschlüssen
Traffic am Server auf 2 NICs verteilen
Kann man einen Server zur Performacesteigerung mit 2 Netzwerkkarten parallel an einem Switch betreiben? Wenn ja mit welcher Konfiguration ?
Bonding mit Broadcom - SLB
Eine saubere Link Aggregation / Bonding / Temaing Konfig mit LACP/802.3ad auf dem Catalyst 3500 sieht vereinfacht so aus:
interface Port-channel1
!
interface FastEthernet1
description LAG Trunk -> Server
channel-group 1 mode active
!
interface FastEthernet2
description LAG Trunk -> Server
channel-group 1 mode active
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.1/19ew/con ...
Vielen Dank für deine Antwort. Ich war mir nicht im klaren darüber das bei einer Round-Robin Lastverteilung auch LACP konfiguriert werden müssen, ich dachte bisher das, dass nur bei Bonds via 802.3ad nötig wäre. Vielen Dank
Round Robin supportet KEIN einziger Switch am Markt !! Der IEEE Standard 802.3ad erzeugt einen Hash über die Mac Adressen (oder IP wenn du Layer 3 machst..) der Partner (Client und Server) und wählt so aus welcher Link (Mac Pärchen) auf welchem physsichen Link des Trunks arbeitet !!
Es findet so also lediglich eine Verteilung der Clients pro Link statt.
Round Robin funktioniert nicht da 802.3ad/LACP kein Paket Assembling/Reassembling Verfahren hat und so kein per Paket Balancing supportet...logisch !!
Lies dir bitte die o.a. Threads GENAUER dazu durch !!
Somit ist klar das deine Konfig so niemals sauber laufen kann denn vermutlich ist die Anbindung entweder gar nicht, nur einseitig oder völlig falsch konfiguriert !!!
Es findet so also lediglich eine Verteilung der Clients pro Link statt.
Round Robin funktioniert nicht da 802.3ad/LACP kein Paket Assembling/Reassembling Verfahren hat und so kein per Paket Balancing supportet...logisch !!
Lies dir bitte die o.a. Threads GENAUER dazu durch !!
Somit ist klar das deine Konfig so niemals sauber laufen kann denn vermutlich ist die Anbindung entweder gar nicht, nur einseitig oder völlig falsch konfiguriert !!!
Da kann ich dir leider nicht ganz zustimmen. Hier die definition für Bonding nach Mode0 (balance-rr):
Die genutzte Netzwerkschnittstelle wird im Round-Robin-Verfahren festgelegt, das heißt die verfügbaren Schnittstellen werden in Senderichtung wechselweise genutzt. In Empfangsrichtung kann max. die Geschwindigkeit einer einzelnen Schnittstelle erreicht werden - je mehr Teilnehmer, umso mehr Upload-Gesamtbandbreite, denn diese werden auf die übrigen freien Schnittstellen aufgeteilt.
Linux ist schlau und legt über beide Interfaces ein logisches Netzwerkinterface dem eine statische MAC zugeordnet wird, der Linux Treiber übernimmt dabei die Lastverteilung. Auf dem Swicht muss nur ein Etherchannel eingerichtet sein.
Alle gängigen Bonding Mode (0-6) werden von den aktuellen Ciso Switches supported (http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186 ..).
Die genutzte Netzwerkschnittstelle wird im Round-Robin-Verfahren festgelegt, das heißt die verfügbaren Schnittstellen werden in Senderichtung wechselweise genutzt. In Empfangsrichtung kann max. die Geschwindigkeit einer einzelnen Schnittstelle erreicht werden - je mehr Teilnehmer, umso mehr Upload-Gesamtbandbreite, denn diese werden auf die übrigen freien Schnittstellen aufgeteilt.
Linux ist schlau und legt über beide Interfaces ein logisches Netzwerkinterface dem eine statische MAC zugeordnet wird, der Linux Treiber übernimmt dabei die Lastverteilung. Auf dem Swicht muss nur ein Etherchannel eingerichtet sein.
Alle gängigen Bonding Mode (0-6) werden von den aktuellen Ciso Switches supported (http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186 ..).
Du redest vom Server und ich meine die Switchinfrastrukur !! Es mag ja sein das der Server das kann aber der Switch vesteht nur Bahnhof, denn der kann das de facto NICHT !!
Ist so wenn du mit einem Chinesen redest und der versteht kein Deutsch !!
Wenn du das Cisco WP genau durchliest erkennst du das eben NICHT alle Bonding Methoden supportet werden...schon gar nicht Round Robin !!
Zitat:
The switch chooses the link on the basis of the destination or source MAC address of the frame. The default is to use the source MAC address. This default means that all packets that the switch receives on a non-Fast EtherChannel port with the same MAC source address that have a destination of the MAC addresses on the other side of the channel take the same link in the channel.
Was für deinen 3500er gilt (Für die Linksys Teile allemal, denn die können eh weniger..)
Das einzige was du konfigurieren kannst ist ob der Hash nach Destination Mac (Default) oder Source Mac berechnet wird. Deshalb gibts unten in der Tabelle beim 3500erXL auf ein etwas zu wohlwollendes "configurable" !
Fazit: Die Kombination der MAC Adresse Source und Destination bestimmt immer den physischen Link innerhalb eines Bundles ! Bei dir ist es so das deine Seite einfach Round Robin sended der Switch dies aber nicht versteht und somit inkonsistent ist in seiner Mac Forwading Database !
Logisch das das dann alles im 3ten Gang arbeitet bzw. solche Effekte wie deine auftreten. Die sind ja ein eindeutiges Indiz das es eben NICHT richtig konfiguriert ist bei dir ! Sonst würde das natürlich nicht auftreten !
Viele Serveradmins fallen darüber, da die Kartenhersteller erheblich mehr Möglichkeiten anbieten..nur was nützt das wenn der Switch das nicht kann. Es lohnt also immer auf BEIDE Enden zu sehen um Problemen aus dem Weg zu gehen !
Ist so wenn du mit einem Chinesen redest und der versteht kein Deutsch !!
Wenn du das Cisco WP genau durchliest erkennst du das eben NICHT alle Bonding Methoden supportet werden...schon gar nicht Round Robin !!
Zitat:
The switch chooses the link on the basis of the destination or source MAC address of the frame. The default is to use the source MAC address. This default means that all packets that the switch receives on a non-Fast EtherChannel port with the same MAC source address that have a destination of the MAC addresses on the other side of the channel take the same link in the channel.
Was für deinen 3500er gilt (Für die Linksys Teile allemal, denn die können eh weniger..)
Das einzige was du konfigurieren kannst ist ob der Hash nach Destination Mac (Default) oder Source Mac berechnet wird. Deshalb gibts unten in der Tabelle beim 3500erXL auf ein etwas zu wohlwollendes "configurable" !
Fazit: Die Kombination der MAC Adresse Source und Destination bestimmt immer den physischen Link innerhalb eines Bundles ! Bei dir ist es so das deine Seite einfach Round Robin sended der Switch dies aber nicht versteht und somit inkonsistent ist in seiner Mac Forwading Database !
Logisch das das dann alles im 3ten Gang arbeitet bzw. solche Effekte wie deine auftreten. Die sind ja ein eindeutiges Indiz das es eben NICHT richtig konfiguriert ist bei dir ! Sonst würde das natürlich nicht auftreten !
Viele Serveradmins fallen darüber, da die Kartenhersteller erheblich mehr Möglichkeiten anbieten..nur was nützt das wenn der Switch das nicht kann. Es lohnt also immer auf BEIDE Enden zu sehen um Problemen aus dem Weg zu gehen !
