Netzwerk: Unterschied zwischen den Versionen

aus Metalab Wiki, dem offenen Zentrum für meta-disziplinäre Magier und technisch-kreative Enthusiasten.
Zur Navigation springenZur Suche springen
Zeile 1: Zeile 1:
=Netzwerk=
 
 
 
Die Antennen wurden vor einiger Zeit wieder neu Justiert (waren total verdreht) seit dem scheint die anzahl der beschwerden übers netzwerk rückläufig. Der Knoten am Dach soll so bald wie möglich weiter ausgebaut werden, um besser ins FunkFeuer netz integriert zu sein.
 
Im Fall des Falles hat man hier [http://sandwich.funkfeuer.at/cgi-bin/smokeping.cgi?target=metalab smokeping] fuers uplink monitoring/history
 
 
 
Siehe auch [[Serverfarm]] und http://metalab.at/wiki/Kategorie:Server
 
Siehe auch [[Serverfarm]] und http://metalab.at/wiki/Kategorie:Server
  
Zeile 11: Zeile 5:
 
Für alle, die am Netzwerk mitwerken wollen, gibt es eine eigene Mailinglist namens net at lists.metalab.at. Die Liste hat den Zweck Änderungen, Features und Bugs am und im Netzwerk zu diskutieren und zu beheben.  
 
Für alle, die am Netzwerk mitwerken wollen, gibt es eine eigene Mailinglist namens net at lists.metalab.at. Die Liste hat den Zweck Änderungen, Features und Bugs am und im Netzwerk zu diskutieren und zu beheben.  
  
==Ansprechpersonen==
+
=Jour fixe=
 +
* [[Netzwerk/Jour fixe]]
 +
* 2. und 4. Freitag im Monat, beginnend mit 12. 1. 2007
  
 +
=Bestehene Infrastruktur=
 +
* [[Serverfarm]]
 +
* [[Metacore]]
  
*du selbst: [[http://metalab.at/wiki/Netzwerk#Troubleshooting|Troubleshooting]]
+
==Netzwerk==
*[[User:Lynx|Lynx]] für allerlei, administriert auch die net at lists.metalab.at Liste und hört zu, wenn es "unspezifizierte" Probleme gibt.
+
geteilt in:
*[[User:Mihi|Mihi]] Für den Uplink
+
* 10.42.23.0/24 wired network
*[[User:Philip|Philip]] wenns weh tut
+
* 10.23.42.0/24 wireless network
 +
* 10.24.3.0/24, 10.24.4.0/24, 10.24.5.0/24, 10.24.7.0/24 openvpn networks
  
 
===Troubleshooting===
 
===Troubleshooting===
 
 
NEU!  Jetzt noch viel funktioneller!
 
 
[[User:Overflo|overflo]] hat gestern: 
 
* olsrd am nacl gestoppt
 
* routen zum funkfeuer gelöscht
 
 
warum?:  weil das komplette funkfeuer netz nicht erreichbar war vom metalab aus (weil die funkfeuer strecke kaputt ist :( )und da viele wichtige server im 0xFF housing stehen.
 
 
 
 
 
Wenn das Netz mal nicht zu funktionieren scheint:
 
 
am besten an net@lists.metalab.at wenden. fuers schnelle troubleshooting - irgendjemand im metalab kennt das passwort von nacl (dem gateway garantiert) - die struktur ist der deines homeoffice aehnlich:
 
 
* '''Verkabelung und Switch:''' Haben alle Interfaces bei 'status' 'active' stehen? ifconfig eingeben und bei rl0 und xl0 gucken:
 
 
[...]
 
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 
        lladdr 00:0e:2e:2c:c6:ad
 
        description: intern
 
        media: Ethernet 100baseTX
 
  -->  status: active
 
        inet 10.42.23.254 netmask 0xffffff00 broadcast 10.42.23.255
 
        inet6 fe80::20e:2eff:fe2c:c6ad%rl0 prefixlen 64 scopeid 0x1
 
[...]
 
 
:* kabel ueberpruefen, switch checken
 
 
* Kannst du nacl/10.42.23.254 pingen?
 
ping -n 10.42.23.254
 
** Kommst Du über Wlan? Versuch es mit Kabel.
 
*** Kabel geht auch nicht? Versuch einen anderen Switchport - die switches sind teilweise konfiguriert.
 
*** Über Kabel geht es? Schau nach ob Du (auf Kabel) osterei/10.42.23.253 (der linksys) pingen kannst
 
**** Nein? Verkabelung/Strom von osterei.metalab.at ueberpruefen.
 
**** Ja? Ohje, das wlan Kabel ist kaputt, viel spass beim debuggen. Nach 5 Sekunden resetknopf (LETZTER AUSWEG! gleichbedeutend mit einer Zwangsaufnahme ins Netzwerkteam.) druecken und schaun ob 192.168.1.1 erreichbar ist - und dann neu konfigurieren.
 
* Uebrigens: ein Switch kann auch eine Fehlerquelle sein, also gern mal ueberpruefen ob zwei Rechner am besagten Switch sich gegenseitig pingen koennen. Einfach mal zwei Notebooks auf die Ports haengen die da in Frage kommen.
 
* Ist status in der ausgabe von ifconfig active und bist obigen parcours ohne Ergebnis abgelaufen, dann ist was faul - reboote mal, oder besser noch, wirf tcpdump am internen interface an und schau ob icmp (echo request) Pakete  von deiner adresse daher kommen - so in der art
 
tcpdump -n -i rl0 host <insert your address>'
 
:* wenn was daher kommt UND nacl ein 'icmp echo reply' packet schickt, dann laeuft etwas was kapital falsch.
 
:* siehst Du nichts? Kabelueberpruefungsparcours von oben. Hoppauf.
 
:* wenn nur Request kommt, blockt irgend etwas.
 
::* willst du sicher gehen das es nicht nacl ist (weil jemand herumgspielt hat ..) dann mach mal ein 'sudo pfctl -d' um die firewall abzuschalten.
 
::* Ein kaputter Routingtable koennte auch das Problem sein - sieh nach ob die Netzroute fuer 10.42.23.0/255 vorhanden ist und am richtigen interface (rl0) liegt:
 
# netstat -rn |grep "10.42.23/24"
 
10.42.23/24        link#1            UC          6        0      -  rl0
 
:::* wenn das auch nach einem reboot nicht der fall ist: Lege dich auf den boden und warte bis Hilfe kommt.
 
* laueft olsrd?
 
# ps -ax |grep olsrd
 
  4886 ??  Is    31:46.62 /usr/local/sbin/olsrd -d 0  <---
 
27777 p0  I+      0:00.01 grep olsrd
 
:* nein: starte ihn - '/usr/local/sbin/olsrd -d 0' sollte reichen; oder reboote
 
:* ja: schau ob du bei der ausgabe von 'netstat -rn' viele hostrouten dabei hast, so in der art:
 
<pre>
 
Destination        Gateway            Flags    Refs    Use    Mtu  Interface
 
.....
 
....
 
...
 
193.238.156.2      193.238.156.115    UGH        0      390      -  xl0
 
193.238.156.3      193.238.156.115    UGH        0        0      -  xl0
 
193.238.156.11    193.238.156.115    UG          0        0      -  xl0
 
193.238.156.22    193.238.156.115    UGH        0        0      -  xl0
 
193.238.158.196    193.238.156.115    UG          0        0      -  xl0
 
193.238.158.251    193.238.156.115    UGH        0        0      -  xl0
 
193.238.159.8/29  193.238.156.115    UG          0        0      -  xl0
 
193.238.159.240/28 193.238.156.115    UG          0        0      -  xl0
 
</pre>
 
 
diese "host"routen (wo als gateway die .115 steht, jedesmal mit ner anderen destination) sind das was olsr macht - als manet-protokoll fuehrt es die ein. je mehr du hast, desto mehr router hast du zur verfuegeung koennte man sagen. also sollte alles passen. jetzt ist der zeitpunkt gut um ne mate/bier zu trinken.
 
::* gibt es diese route nicht, olsrd laeuft aber, dann restarte olsrd
 
pkill olsrd
 
und ein
 
/usr/local/sbin/olsrd -d 0
 
oder eleganter:
 
pkill -HUP olsrd
 
:::* es bauen sich dann nicht innerhalb der naechsten Minuten(!!!) o.g. routen auf, pinge bitte 193.238.156.115, das ist der linksys am dach. erreichst du ihn nicht, würde das [[Benutzer:Philip]] sehr interessieren, aber es hilft dir nichts. Lege dich auf den Boden und warte bis Hilfe kommt.
 
:::* die routen bauen sich auf, aber kein internet? Dann ist wohl der Internet Uplink von 0xFF gerade im Eimer. Lege dich auf den Boden und warte bis Hilfe kommt.
 
:::* Linksys am Dach ist erreichbar, aber Routingtable baut sich nicht auf? Lege dich auf den Boden und warte bis Hilfe kommt.
 
* Falls Du es bis jetzt noch nicht getan hast: Reboote.
 
 
==Änderungen bei SIP/VoIP Phones==
 
 
Wenn ihr ein SIP Phone ins netz haengt, waere es sinnvoll, dem ne fixe IP zuzuweisen und das nat mit einem statischen ephemeral port einzurichten, da es sonst bei viel traffic (==viele user) zu problemen kommen kann. Also das NOC/NSC darauf ansprechen.
 
 
<strike>Wir haben nun einen SIP Proxy auf dem Gateway installiert.</strike>
 
 
=Aufbau=
 
 
Derzeit noch klein, bestehend aus:
 
*[[nacl]] (OpenBSD 3.9 mit dhcpd, ntpd und caching-dns), die 10.42.23.0/24 auf 193.238.156.8 (metagw.funkfeuer.at) nattet
 
*einem hauptswitch im Maschinenraum,
 
**von dort 2 CAT5 Kabel Richtung Hauptraum;
 
***1es (war frueher in der Kueche, jetzt am Sicherungskasten) in die linksys von [[User:Lynx|Lynx]] (metalab,dhcp v. nacl)
 
***1es quer ueber den Raum Richtung Fenster.
 
 
 
==Schematics==
 
[[Image:Metalab netmap 03042006.png|thumb|right|250px|Graphische Version des Ganzen]]
 
<pre>
 
 
 
((0xFF))      ((0xFF))
 
((.))        ((.))
 
  |            |
 
  \|/          \|/ 
 
  V            V
 
  |            |
 
+----------  +--------+
 
|metatovivi| |metaomni|
 
+----------+ +--------+ 
 
  |        |
 
  +----------
 
  |
 
  |             
 
  |193.238.156.0/22
 
  | olsr          ---
 
  |                |
 
  |193.238.156.8    |
 
  |  +------+      |      \        /
 
  +--+ nacl +-------+        +-------+
 
  xl0+------+rl0    +--------+linksys|
 
                    |        +-------+ ssid metalab
 
                    |
 
                    |
 
                    |
 
                    |  +--------+
 
                    +---+ ph0ne1 | 10.42.23.23
 
                    |  +--------+
 
                    |
 
                    |
 
                    | 10.42.23.0/24                 
 
                    ---
 
 
</pre>
 
 
=Funktion=
 
 
ab hier kann's langweilig werden
 
 
==Generell==
 
 
wir filtern keinen traffic - wir natten nur und shapen den Traffic ein wenig
 
  
 
==Traffic Shaping==
 
==Traffic Shaping==
 
+
'''Section veraltet, bitte updaten''' (wir machen immer noch traffic shaping, aber das stimmt hier nicht mehr)
 
Den einzigen Eingriff den wir uns im Netzwerkbereich erlauben ist das "hoeher priorisieren" von Packeten in der Queue am Gateway - wir regulieren den Verkehr um uns - aus Netzwerksicht - wichtigeren Protokollen den Vorzug vor anderen zu geben; klingt gemein, isses aber nicht; lies die nachfolgende Aufstellung und versuchs zu verstehen. Was wir hoeher priorisieren als Surfen, Chatten, Mails lesen und saugen (und den Rest):
 
Den einzigen Eingriff den wir uns im Netzwerkbereich erlauben ist das "hoeher priorisieren" von Packeten in der Queue am Gateway - wir regulieren den Verkehr um uns - aus Netzwerksicht - wichtigeren Protokollen den Vorzug vor anderen zu geben; klingt gemein, isses aber nicht; lies die nachfolgende Aufstellung und versuchs zu verstehen. Was wir hoeher priorisieren als Surfen, Chatten, Mails lesen und saugen (und den Rest):
  
Zeile 177: Zeile 33:
 
hast du sonst noch Ideen, wirf sie im NOC ein. Grundsaetzlich erscheinen uns aber nur obige Protokolle  lebenswichtig.
 
hast du sonst noch Ideen, wirf sie im NOC ein. Grundsaetzlich erscheinen uns aber nur obige Protokolle  lebenswichtig.
  
==Operations ==
+
=Ansprechpersonen=
 
 
folgende Datein gibts, die als Regelwerke herangezogen werden koennen:
 
<pre>
 
# ls -al /etc/pf* 
 
-rw-------  1 root  wheel  1168 May  1 11:57 /etc/pf-altq.conf
 
-rw-------  1 root  wheel  1180 May  1 12:02 /etc/pf.conf
 
-rw-------  1 root  wheel    914 May  1 11:57 /etc/pf.conf.orig
 
</pre>
 
 
 
*/etc/pf-altq.conf: hier werden Trafficpriorisierungen editiert und getestet, bevor die Date ueber
 
*/etc/pf.conf kopiert wird, die das derzeit aktive Ruleset darstellt; das letztgueltige (also funktionierende) Ruleset ist
 
*/etc/pf.conf.orig - wenn das ueber pf.conf kopiert wird und aktiv ist, funktioniert alles so wie vorher.
 
 
 
 
 
wenn Aenderungen passieren sollen, gehe wie folgt vor:
 
 
 
*kopiere bitte /etc/pf.conf nach /etc/pf-<insert tag>.conf und editiere die entstehende Datei.
 
*danach guckst du ob mit ''pfctl -nf /etc/pf-<insert date tag>.conf'' ob die Syntax stimmt.
 
*dann verwendest du dein Ruleset als aktives mit ''pfctl -f /etc/pf-<insert date tag>.conf'', laesst es laufen und schaust ob alles geht (red mit den Leuten)
 
*erst wenn du dir sicher bist das alles gut ist, kopierst du das letzt-aktive nach /etc/pf.conf.orig, kopierst dein /etc/pf-<insert date tag>.conf nach ''/etc/pf.conf'' und enablest es mit ''pfctl -f /etc/pf.conf''
 
 
 
bitte Kommentiere was du getan hast. Nur dann weigern sich die Leute nicht, dir zu helfen ;)
 
 
 
==aktives Ruleset==
 
 
 
hier das derzeit aktive ruleset:
 
 
 
<pre>
 
 
 
TRANSLATION RULES:
 
nat on xl0 inet proto udp from 10.42.23.23 to any -> 193.238.156.8 static-port
 
nat on xl0 inet from 10.42.23.0/24 to any -> 193.238.156.8
 
 
 
FILTER RULES:
 
scrub in all fragment reassemble
 
pass in all
 
pass out log quick on xl0 inet proto udp from any to any port = domain keep state queue infra
 
pass out log quick on xl0 inet proto udp from any to any port = ntp keep state queue infra
 
pass out log quick on xl0 inet proto udp from any to any port = 698 keep state queue infra
 
pass out log quick on xl0 inet proto udp from any to any port = sip keep state queue infra
 
pass out log quick on xl0 inet proto tcp from any to any port = ssh keep state queue infra
 
pass out log all
 
 
 
ALTQ:
 
queue infra priority 14 priq( red )
 
queue rest priority 10 priq( default )
 
</pre>
 
 
 
==olsrd.conf==
 
<pre>
 
 
 
DebugLevel 1
 
IpVersion 4
 
ClearScreen    yes
 
 
 
Hna4
 
{
 
}
 
 
 
Hna6
 
{
 
}
 
 
 
AllowNoInt yes
 
 
 
IpcConnect
 
{
 
    MaxConnections  1
 
    Host            127.0.0.1
 
}
 
 
 
UseHysteresis no
 
HystScaling 0.50
 
HystThrHigh 0.80
 
HystThrLow 0.30
 
LinkQualityLevel  2
 
LinkQualityFishEye 1
 
Pollrate 0.05
 
 
 
Interface "xl0"
 
{
 
}
 
</pre>
 
 
 
=In Planung=
 
  
* Trennung der Netze auf nacl:
+
*[[User:Lfittl|Lfittl]]
** 10.42.23.0/24 fuer kabelnetz
+
*[[User:Philip|Philip]]
**:wegen druckersecurity und so
 
** 10.23.42.0/24 fuer wlan
 
***linksys bekommt eigenen link zu nacl
 
** 10.42.42.0/24 fuer management/serverwartung (z.b. ssh nur von diesem netz moeglich)
 
* entsprechende vlans am switch einrichten
 
* login von draussen ermoeglichen
 
*: needs: loginserver
 
  
 
[[Kategorie:Dokumentation]]
 
[[Kategorie:Dokumentation]]
 
[[Kategorie:Netzwerk]]
 
[[Kategorie:Netzwerk]]

Version vom 11. Januar 2007, 21:27 Uhr

Siehe auch Serverfarm und http://metalab.at/wiki/Kategorie:Server

Generell

Für alle, die am Netzwerk mitwerken wollen, gibt es eine eigene Mailinglist namens net at lists.metalab.at. Die Liste hat den Zweck Änderungen, Features und Bugs am und im Netzwerk zu diskutieren und zu beheben.

Jour fixe

Bestehene Infrastruktur

Netzwerk

geteilt in:

  • 10.42.23.0/24 wired network
  • 10.23.42.0/24 wireless network
  • 10.24.3.0/24, 10.24.4.0/24, 10.24.5.0/24, 10.24.7.0/24 openvpn networks

Troubleshooting

Traffic Shaping

Section veraltet, bitte updaten (wir machen immer noch traffic shaping, aber das stimmt hier nicht mehr) Den einzigen Eingriff den wir uns im Netzwerkbereich erlauben ist das "hoeher priorisieren" von Packeten in der Queue am Gateway - wir regulieren den Verkehr um uns - aus Netzwerksicht - wichtigeren Protokollen den Vorzug vor anderen zu geben; klingt gemein, isses aber nicht; lies die nachfolgende Aufstellung und versuchs zu verstehen. Was wir hoeher priorisieren als Surfen, Chatten, Mails lesen und saugen (und den Rest):

  • OLSR - das Routingprotokoll, das den Uplink ins Internet ueber 0xFF ueberhaupt erst moeglich macht ist.
  • DNS - ohne DNS kannste gar nix. nix. ausser du denkst in IP Adressen, dann haelst du diese Priorisierung fuer ueberzogen ;)
  • NTP - wir synchronisieren unser Gateway mit zuverlaessigen Zeitgebern - sehr wichtig um im Fehlerfall exakte Zeitstempel zu haben. Auch du kannst deinen Rechner mit 10.42.23.254 synchronisieren, wenn du im metalab bist.
  • SSH - kommen wir nicht aufs Gateway ist das schlecht. Du kannst, z.B. via ssh auf deine Kiste zuhause - also ist das auch gut fuer dich.
  • SIP - damit immer telefoniert werden kann

hast du sonst noch Ideen, wirf sie im NOC ein. Grundsaetzlich erscheinen uns aber nur obige Protokolle lebenswichtig.

Ansprechpersonen