Netzwerk
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 smokeping fuers uplink monitoring/history
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.
Ansprechpersonen
- du selbst:
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:
- haben alle Interfaces (ifconfig eingeben und bei rl0 und xl0 gucken) bei 'status' 'active' stehen? wenn nicht, dann ist ein kabel lose
- kannst du nacl (deine default route oder auch 10.42.23.254) pingen ? wenn nicht, check obiges
- ist status in der ausgabe von ifconfig active und du kannst nacl nicht pingen, dann ist was faul - reboote mal oder besser noch, wirf tcpdump am internen interface an und schau ob icmp (echo request) packete von deiner adresse daher kommen - so in der art 'tcpdump -i rl0 host <insert your address>'
- wenn was daher kommt und nacl ein 'icmp echo reply' packet schickt, dann laeuft etwas was kapital falsch. wenn nicht 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.
- hilft das nix, finde jemanden der dir helfen kann. du kannst nacl auch rebooten aber das hilft in 99% der faelle gar nix
- wenn was daher kommt und nacl ein 'icmp echo reply' packet schickt, dann laeuft etwas was kapital falsch. wenn nicht 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.
- laueft olsrd? (guck mit 'ps -ax |grep olsrd' ob ein prozess laeuft, der nicht 'grep olsrd' heisst)
- wenn nicht - starte ihn - '/usr/local/sbin/olsrd -d 0' sollte reichen; oder reboote
- wenn ja, schau ob du bei der ausgabe von 'netstat -rn' viele hostrouten dabei hast, so in der art:
- wenn nicht - starte ihn - '/usr/local/sbin/olsrd -d 0' sollte reichen; oder reboote
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
- 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 'kill -SIGHUP `cat /var/run/named.pid`' tut das) - bauen sich dann nciht innerhalb der naechsten minuten o.g. routen auf, hat das ganze 0xFF netz ein problem und du kannst nix tun. trink ne mate oder ein bier. rebooten koenntest du auch noch, aber es bringt wahrscheinlich nix.
- 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.
- Lynx für allerlei, administriert auch die net at lists.metalab.at Liste und hört zu, wenn es "unspezifizierte" Probleme gibt.
- Mihi Für den Uplink
Troubleshooting
Wenn das Netz mal nicht zu funktionieren scheint:
- Have you tried turning it off and on again?
- ...
- bitte ergänzen: welche blinkenden Lichter kann man beobachten, auf welche roten Knöpfe kann man drücken, welche Kiste kann man treten, wen kann man aus dem Schlaf klingeln?
Ä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.
Wir haben nun einen SIP Proxy auf dem Gateway installiert.
Aufbau
Derzeit noch klein, bestehend aus:
- nacl (OpenBSD 3.8 mit dhcpd, ftpd, 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 Lynx (metalab,dhcp v. nacl)
- 1es quer ueber den Raum Richtung Fenster.
- von dort 2 CAT5 Kabel Richtung Hauptraum;
Schematics
((0xFF)) ((0xFF))
((.)) ((.))
| |
\|/ \|/
V V
| |
+---------- +--------+
|metatovivi| |metaomni|
+----------+ +--------+
| |
+----------
|
|
|193.238.156.0/22
| olsr ---
| |
|193.238.156.8 |
| +------+ | \ /
+--+ nacl +-------+ +-------+
xl0+------+rl0 +--------+linksys|
| +-------+ ssid eh@metalab
|
|
|
| +--------+
+---+ ph0ne1 | 10.42.23.23
| +--------+
|
|
| 10.42.23.0/24
---
Funktion
ab hier kann's langweilig werden
Generell
wir filtern keinen traffic - wir natten nur und shapen den Traffic ein wenig
Traffic Shaping
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.
Operations
folgende Datein gibts, die als Regelwerke herangezogen werden koennen:
# 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
- /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:
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 )
olsrd.conf
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"
{
}
