ÜbersichtHomepage des Chemnitzer Linux-Tags 2004offizielle Netzwerkbeschreibung

Verbesserungsvorschläge für's nächste Mal

WLAN segmentieren

Problem

Das WLAN-Netz (10.0.0.0/16, VLAN600) lag in einer Broadcastdomäne. Einige Tagungsmitglieder nutzten das aus, um wiederholt durch Ping- und TCP-Connection-Scans 10.0.0.0/16 auf Hosts bzw. Dienste zu durchsuchen. Das Resultat waren mehrere Überläufe des ARP-Neighbour-Caches auf dem zentralen Gateway:
Mar 5 22:17:13 gate kernel: Neighbour table overflow.
Mar 5 22:17:13 gate last message repeated 9 times
Mar 5 22:17:18 gate kernel: NET: 494 messages suppressed. 
Mar 5 22:17:18 gate kernel: Neighbour table overflow.
Mar 5 22:17:23 gate kernel: NET: 1105 messages suppressed.
Mar 5 22:17:23 gate kernel: Neighbour table overflow.
Mar 5 22:17:28 gate kernel: NET: 1049 messages suppressed.
Mar 5 22:17:28 gate kernel: Neighbour table overflow.
... 
Davon wurde das restliche Netz nicht weiter beeinträchtigt.

Die versuchten Verbindungsaufbauten sorgten aber auch für übermäßigen Broadcast-Traffic, der zu Hochzeiten 95% des gesamten Traffics im WLAN ausmachte. Da die ausgelösten ARP-Anfragen als Broadcast im gesamten VLAN verbreitet wurden, wurde damit das gesamte WLAN beeinträchtigt.

Mögliche Lösungen


Mehr Plattenplatz für Logfiles

Problem

Das Gateway stellte mehrfach seinen Dienst ein, weil der Speicherplatz auf /var erschöpft war. Der Squid bleibt in diesem Fall einfach hängen.

Lösung

Von vornherein mehr Platz zur Verfügung stellen. Wir hatten nicht mit dermaßen vielen Log-Daten gerechnet. Für den nächsten Linux-Tag halten wir eine dedizierte 6-GB-Partition für /var für empfehlenswert.


Gateway und Proxy trennen

Problem

Das Gateway hatte hohe Systemlast durch den Squid, was bei der Menge der Anfragen auch nicht verwundert.

Lösung

Wir empfehlen, zum nächsten Chemnitzer Linux-Tag Routing- und Proxy-Funktionen auf verschiedenen Maschinen zu betreiben um das zentrale Gateway zu entlasten.


Überlastung UNI-FTP

Problem

Der FTP-Server der TU-Chemnitz hat offenbar einen Grenzwert für Verbindungen pro IP-Adresse. Da das Tagungsnetzwerk über eine öffentliche IP-Adresse mit dem Uni-Netzwerk verbunden war, klagten Gäste wiederholt über die Meldung des FTP-Servers, die maximale Anzahl FTP-Verbindungen für die verwendete IP-Adresse sei erreicht.

Lösung

Es genügte, den betroffenen Gästen den Tip zu geben, die Daten via HTTP zu zu holen. Ließ das System des Nutzers das nicht zu (was bei einigen Installationsroutinen von Linux-Distributionen der Fall war) half das natürlich nicht.

Zwei kurzfristig von einem Aussteller des Linux-Tags zur Verfügung gestellte FTP-Server brachten kaum Entlastung, weil auf ihnen die Verzeichnishierarchie komplett anders als auf dem UNI-FTP-Server war und die Gäste sich zumeist nicht zurechtfanden.

Die Begrenzung von Verbindungen pro IP-Adresse sollte im Vorfeld der nächsten Veranstaltung dieser Art in Absprache mit dem FTP-Admin des Rechenzentrums deaktiviert werden.


Falsch eingesteckte Patchkabel an den Switches der Demo-Stände

Problem

Einige Demostand-Betreiber steckten ihre Netzwerkkabel in die Uplink-Ports der ihnen bereitgestellten Switches. Das hatte zur Folge, dass am Samstag Morgem an einigen Demo-Ständen das Netz ausfiel.

Lösung

Uplink-Ports vor der Veranstaltung mit Klebeband zukleben.


Zu wenig öffentliche Dosenports

Problem

Den Besuchern des Chemnitzer Linux-Tags 2004 wurden zwar 16 öffentlich zugängliche Dosenports zur Verfügung gestellt, diese Zahl erwies sich aber schnell als zu klein, weil das Interesse, einen längeren Download zu tätigen oder im kleinen Kreis zusammen mit mehreren Personen am Rechner etwas auszuprobieren unerwartet hoch war.

Lösung

Deutlich mehr Dosenports, Tische und Stühle für diesen Zweck zur Verfügung stellen.

© Sebastian Kratzert, Manuel Möller 2004