Ich hab auf Des1 und Des2 per default bgp_local_pref die standard IPv6-Route von Fra nach Ber verlegt, da die Pakete ohnehin von dort reinkommen und es bei Verbindungen über Fra Paketverluste gab.
Grüße
Matthias
Ich hab auf Des1 und Des2 per default bgp_local_pref die standard IPv6-Route von Fra nach Ber verlegt, da die Pakete ohnehin von dort reinkommen und es bei Verbindungen über Fra Paketverluste gab.
Grüße
Matthias
Auf Des2 war das IPv4 auch auf Fra gestellt, das hab ich auch noch geändert.
Und Greyworm-01 hat seit heute Nachmittag wieder Anschluss an @FanLin s Gateway. Die Konfiguration des GRE-Tunnels erfolgte erstmals durch Ansible. @Fungur hat dazu die Templatedatei für die Ansible-Rolle tun_ffms_supernodes noch robuster gemacht.
Domäne-01 auf bird6-radv umgestellt, radvd und isc-dhcp6-server abgeschaltet. Letzterer funktionierte ohnehin nicht korrekt mit Ansible.
Ich habe jetzt die Ansible-Konfiguration auch auf die Domäne-02 ausgerollt und die Verbindung zwischen Greyworm-02 und Des1 wiederhergestellt.
Auf greyworm-2 war die v6 Konfig kaputt, korrigiert, networking restartet. Ping6’ed.
Danke für’s Reparieren, Ingomar!
Domäne-03 ist soweit fertig: Domäne-03 Steinfurt-West kann getestet werden
@as1 hat heute Zugriff auf die beiden VMs der Steinfurt-West/Domäne-03 bekommen.
Auf den neuen Domänen-SNs ist nach einem “systemctl restart networking” das Interface mesh-vpn nicht mehr im Batman gewesen. Deshalb habe ich folgende Zeile zum bat0-Interface hinzugefügt:
post-up batctl if add mesh-vpn ||:
( ||: sorgt dafür, dass ifup nicht fehlschlägt, wenn mesh-vpn nicht verfügbar ist.)
Per Ansible ausgerollt.
collectd rollen auf den Maschinen von domaene-01, domaene-02, domaene-03 und testdomaene ausgerollt
Remü heute morgen wieder abgestürzt. Da kommt jetzt VMware drauf und fertig.
Remü-02 ist abgeschaltet, IPv6 in Domäne-03 iwie kaputt deswegen, obwohl die Pakete eigentlich umgeleitet werden müssten. Das hab ich noch nicht im Detail analysiert. Mein eigenes IPv6 scheint kaputt zu sein.
Ich habe gerade, auf allen FanLin-Maschinen, ein [bind9-Sicherheitsupdate][1] eingespielt.
@Parad0x @descilla @kgbvax @Fungur @MPW @void
Bitte alle anderen Maschinen ebenfalls überprüfen (apt-get update / upgrade)
[1]: https://www.debian.org/security/2015/dsa-3420
master
nach entwicklungszweig
im ansible-ffms
repo bzgl. der collectd Rolle.group_vars
entsprechend angepasst.backbone.*
.Du hast auch auf alle Maschinen Zugriff ;).
Ich hab es jetzt auf allen der Domänen 1-3 eingespielt, auf Des1, Des2, Parad0x und Fussel.
Es fehlen noch die Superknoten der Münsterland-Domäne!
Die Supermodels fahren kein Bind ergo gibt es hier nichts zu tun.
Ich habe die neue Service-VM jetzt mit gretap-Tunneln zu allen laufenden Domänen-SN angebunden. Die Kartengenerieung läuft dort jetzt auch und wird ffms-map.fungur.eu ersetzten: http://89.163.231.228/
Der Alfred-Master ist schon auf den neuen Rechner umgezogen. Zu überlegen ist noch, wie wir dauerhaft die Domänen-Einzelseiten zur Verfügung stellen wollen.
bat0
nicht erreichbar war. DHCP Server auf entsprechenden Maschinen neu gestartet. DHCP funktioniert nun wieder.fastd
Instanzen weggehangen. Socket entfernt, neu gestartet, geht jetzt wieder.parad0x
waren die iptables voll daher wurden massenhaft Pakete gedroppt:[...]
Dec 18 15:17:04 parad0x kernel: [2036297.188169] net_ratelimit: 11007 callbacks suppressed
Dec 18 15:17:04 parad0x kernel: [2036297.188173] nf_conntrack: table full, dropping packet.
Dec 18 15:17:04 parad0x kernel: [2036297.188182] nf_conntrack: table full, dropping packet.
Dec 18 15:17:04 parad0x kernel: [2036297.188190] nf_conntrack: table full, dropping packet.
Dec 18 15:17:04 parad0x kernel: [2036297.188197] nf_conntrack: table full, dropping packet.
Dec 18 15:17:04 parad0x kernel: [2036297.188204] nf_conntrack: table full, dropping packet.
Dec 18 15:17:04 parad0x kernel: [2036297.188211] nf_conntrack: table full, dropping packet.
Dec 18 15:17:04 parad0x kernel: [2036297.188226] nf_conntrack: table full, dropping packet.
Dec 18 15:17:04 parad0x kernel: [2036297.188248] nf_conntrack: table full, dropping packet.
Dec 18 15:17:04 parad0x kernel: [2036297.188256] nf_conntrack: table full, dropping packet.
Dec 18 15:17:04 parad0x kernel: [2036297.188264] nf_conntrack: table full, dropping packet.
Dec 18 15:17:09 parad0x kernel: [2036302.193716] net_ratelimit: 10655 callbacks suppressed
Dec 18 15:17:09 parad0x kernel: [2036302.193720] nf_conntrack: table full, dropping packet.
Dec 18 15:17:09 parad0x kernel: [2036302.194015] nf_conntrack: table full, dropping packet.
Dec 18 15:17:09 parad0x kernel: [2036302.194392] nf_conntrack: table full, dropping packet.
Dec 18 15:17:09 parad0x kernel: [2036302.194828] nf_conntrack: table full, dropping packet.
Dec 18 15:17:09 parad0x kernel: [2036302.195164] nf_conntrack: table full, dropping packet.
Dec 18 15:17:09 parad0x kernel: [2036302.195634] nf_conntrack: table full, dropping packet.
Dec 18 15:17:09 parad0x kernel: [2036302.196310] nf_conntrack: table full, dropping packet.
Dec 18 15:17:09 parad0x kernel: [2036302.198030] nf_conntrack: table full, dropping packet.
Dec 18 15:17:09 parad0x kernel: [2036302.198056] nf_conntrack: table full, dropping packet.
Dec 18 15:17:09 parad0x kernel: [2036302.199143] nf_conntrack: table full, dropping packet.
Dec 18 15:17:14 parad0x kernel: [2036307.196277] net_ratelimit: 11576 callbacks suppressed
[...]
Vorherige max-Values und in Verwendung:
root@parad0x:~# /sbin/sysctl -a|grep -i nf_conntrack_max
net.netfilter.nf_conntrack_max = 65536
net.nf_conntrack_max = 65536
root@parad0x:~# /sbin/sysctl net.netfilter.nf_conntrack_count
net.netfilter.nf_conntrack_count = 65534
root@parad0x:~# /sbin/lsmod | egrep 'ip_tables|conntrack'
nf_conntrack_ipv4 14078 3 nf_nat,iptable_nat
nf_defrag_ipv4 12483 1 nf_conntrack_ipv4
nf_conntrack 52720 3 nf_conntrack_ipv4,nf_nat,iptable_nat
ip_tables 22042 3 iptable_filter,iptable_mangle,iptable_nat
x_tables 19118 10 ip_tables,iptable_filter,iptable_mangle,xt_mark,xt_tcpudp,xt_TCPMSS,iptable_nat,ip6_tables,ip6table_filter,ip6table_mangle
Limits verdoppelt mit:
root@parad0x:~# echo 32768 > /sys/module/nf_conntrack/parameters/hashsize
root@parad0x:~# echo 'net.netfilter.nf_conntrack_max = 131072' >> /etc/sysctl.conf
root@parad0x:~# /sbin/sysctl -p
Nun sieht es so aus (im Logfile erscheinen nun keine weiteren Meldungen):
root@parad0x:~# /sbin/sysctl -a|grep -i nf_conntrack_max
net.netfilter.nf_conntrack_max = 131072
net.nf_conntrack_max = 131072
root@parad0x:~# /sbin/sysctl net.netfilter.nf_conntrack_count
net.netfilter.nf_conntrack_count = 69898
root@parad0x:~# /sbin/lsmod | egrep 'ip_tables|conntrack'
nf_conntrack_ipv4 14078 3 nf_nat,iptable_nat
nf_defrag_ipv4 12483 1 nf_conntrack_ipv4
nf_conntrack 52720 3 nf_conntrack_ipv4,nf_nat,iptable_nat
ip_tables 22042 3 iptable_filter,iptable_mangle,iptable_nat
x_tables 19118 10 ip_tables,iptable_filter,iptable_mangle,xt_mark,xt_tcpudp,xt_TCPMSS,iptable_nat,ip6_tables,ip6table_filter,ip6table_mangle
Wir sollten ggf. überlegen die Timeout-Limits anzupassen, wenn erneut Probleme auftreten, da ja recht viele Clients NAT über wenige IP-Adressen machen:
root@parad0x:~# sysctl -a | grep conntrack | grep timeout
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_events_retry_timeout = 15
net.ipv4.netfilter.ip_conntrack_generic_timeout = 600
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent2 = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 432000
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 30
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10
net.ipv4.netfilter.ip_conntrack_tcp_timeout_max_retrans = 300
net.ipv4.netfilter.ip_conntrack_udp_timeout = 30
net.ipv4.netfilter.ip_conntrack_udp_timeout_stream = 180
net.ipv4.netfilter.ip_conntrack_icmp_timeout = 30
Selbes Problem bei GW fussel
. Dort war das Limit sogar noch geringer:
root@fussel ~ # /sbin/sysctl -a|grep -i nf_conntrack_max
net.netfilter.nf_conntrack_max = 32092
net.nf_conntrack_max = 32092
Über Fussel ging nichts mehr ins Rheinland. Es schien so, dass auch die FFRL-Tunnel nicht mehr korrekt liefen. Daher bird und bird6 anschließend neu gestartet.
Jetzt gehts wieder.
PS: Diese Seite hat mir sehr geholfen: http://pc-freak.net/blog/resolving-nf_conntrack-table-full-dropping-packet-flood-message-in-dmesg-linux-kernel-log/
greyworm-4 für dom4 bereitgestellt
Heute Nacht 8 VMs (4 für uns, 4 für Recklinghausen) für Supernodes, Gateways, what ever auf das Remü-Blech gelötet. Außerdem eine weitere VM für Ansible erstellt, die jedoch nur über ipv6 (sowie ssh auch über ipv4 nat) erreichbar ist.
Zuvor wurde das Blech Remü in der Adminrunde auf Basis von Debian jessie und libvirt neu aufgesetzt. Die VM remue-01 wurde bereits mit ansible behandelt.
Habe gerade auf meinem Virt-Host, auf Backofen FanLin und auf den Supernovas FanLin ein Kernel-Sicherheitsupdate eingespielt. Heute um 24:00 Uhr wird der Virt-Host, damit auch alle FanLin-Maschinen, restartet.
@void, @Fungur, @Parad0x, @kgbvax, @paulinsche, @MPW, @descilla
Bitte alle anderen Maschinen ebenfalls überprüfen (apt-get update / upgrade)
Ich weiß. Aber ich will nicht alle Maschinen „gleichzeitig“ updaten und restarten. Erst ein paar Stunden oder nen Tag laufen lassen, um zu sehen ob Probleme auftreten.
Da ich momentan unter chronischem Zeitmangel leide, wäre es super, wenn einer von euch den Rest übernehmen kann.
Gestern ist der fastd von sn-kgbvax-2 ausgefallen. Gerade neu gestartet und Knoten rüber geschubst.