[Berlin-wireless] vpn03e & vpn03b schlecht erreichbar

Fr Mai 27 23:27:30 CEST 2016

Wie kommen wir in der Sache jetzt weiter?

On Thu, May 19, 2016 at 02:24:21PM +0200, Bastian wrote:
> Mit einem SFP-Switch koennen wir tg3 umgehen und auch so tolle sachen wie
> FTTR realisieren. Ohne Switch gibt es entweder FTTR oder direkte Verbindung
> zu a36s-hyp01. Verbindungen zu einem weiteren Transit (und damit Redundanz)
> oder zum FFRL oder IN-Berlin (und damit Standort Alt-Moabit) geht auch nur
> mit SFP-Switch.
> 
> Ja, wir koennen das Kabel austauschen um das als Fehlerquelle
> auszuschliessen. Der Switch muss aber trozdem frueher oder spaeter
> eingesetzt werden, wenn wir irgend eine Art von weiterer connectivity
> wollen. Ich werde die Anzahl der DC Besuche auf das wirklich noetige minimum
> begrenzt halten.
> 
> Der einzige mir bekannte Switch mit genug Ports und vertretbarem
> Stromverbrauch ist der TL-SG5412F.
> 
> 
> tg3 issue on a36s-cr1:
> [6451184.679914] tg3 0000:03:00.0 eth0: transmit timed out, resetting
> [6451185.935858] tg3 0000:03:00.0 eth0: 0x00000000: 0x165f14e4, 0x00100446,
> 0x02000000, 0x00800010
> [6451185.936048] tg3 0000:03:00.0 eth0: 0x00000010: 0xf97f000c, 0x00000000,
> 0xf97e000c, 0x00000000
> [...]
> [6451186.013329] tg3 0000:03:00.0 eth0: 0x00007010: 0x89658a28, 0x01c08072,
> 0x00d70081, 0x03008200
> [6451186.013515] tg3 0000:03:00.0 eth0: 0x00007020: 0x00000000, 0x00000000,
> 0x00000406, 0x10004000
> [6451186.013702] tg3 0000:03:00.0 eth0: 0x00007030: 0x00020000, 0x00004ab4,
> 0x00150030, 0x00000000
> [6451186.013892] tg3 0000:03:00.0 eth0: 0: Host status block
> [00000005:00000003:(0000:0000:0000):(0000:0000)]
> [6451186.014097] tg3 0000:03:00.0 eth0: 0: NAPI info
> [00000003:00000003:(0000:0000:01f4):0000:(01f7:0000:0000:0000)]
> [6451186.014312] tg3 0000:03:00.0 eth0: 1: Host status block
> [00000001:00000004:(0000:0000:0000):(0003:0000)]
> [6451186.014516] tg3 0000:03:00.0 eth0: 1: NAPI info
> [00000004:00000004:(0000:0000:01f4):0003:(0003:0003:0000:0000)]
> [6451186.014731] tg3 0000:03:00.0 eth0: 2: Host status block
> [00000001:0000000e:(0000:0000:0000):(0000:000e)]
> [6451186.014935] tg3 0000:03:00.0 eth0: 2: NAPI info
> [0000000e:0000000e:(000e:000e:01f4):0000:(0000:0000:0000:0000)]
> [6451186.104106] tg3 0000:03:00.0 eth0: Link is down
> 
> Alle Offloadings und Auto-Negotiations sind auf beiden Seiten des Kabels
> deaktiviert - hat keine Besserung gebracht.
> 
> 
> Am 2016-05-19 14:09, schrieb Philipp Borgers:
> > Moin,
> > 
> > können wir das Kabel nicht einfach austauschen um eine Fehlerquelle
> > auszuschließen?
> > 
> > Gibt es mehr Informationen zu einem vermuteten Bug im tg3 Treiber?
> > 
> > Ich habe die Rolle des Switchs noch nicht verstanden. Könntest du
> > nochmal
> > erklären für was der wichtig wäre und wie der sich in das bestehende
> > Setup
> > einfügen würde? Gibt es da schon einen favorisierten Switch? Wenn es im
> > Interesse der Community ist, kann man den sicher besorgen.
> > 
> > Gruß Philipp
> > 
> > On Thu, May 19, 2016 at 01:48:38PM +0200, Bastian wrote:
> > > Hallo,
> > > 
> > > vpn03e rennt auf a36s-hyp01, welcher mit einem Kabel direkt (ohne
> > > Switch, da
> > > warte ich schon seit Monaten drauf) am bare-metal-router a36s-cr1
> > > haengt.
> > > 
> > > a36s-cr1 ist auch fuer Transit (alles was nicht am BCIX peert) zu
> > > l105-cr1/hyp1 (aka vpn03b,vpn03c,icvpn02) verantwortlich.
> > > 
> > > Auf a36s-cr1 und a36s-hyp01 flappt das Interface das beide miteinander
> > > direkt verbindet. Kann ein kaputtes Kabel sein, oder ein bug im tg3
> > > Treiber.
> > > 
> > > Ich hab das Interface jetzt deaktiviert. Somit ist a36s-hypo01, und
> > > damit
> > > eben auch vpn03e, jetzt nicht mehr erreichbar. Aber wir haben ja genug
> > > Redundanz...
> > > 
> > > Ich guck mir das wieder an wenn der Switch mal da mal ist, nur dann
> > > kann ich
> > > ohne tg3 testen.
> > > 
> > > Cheers, Bastian
> > > 
> > > 
> > > Am 2016-05-19 09:40, schrieb Marlen Caemmerer:
> > > > Hallo,
> > > >
> > > > die 2 VPN-Server haben einen extrem schwankenden Ping, von 2
> > > > verschiedenen Standorten aus.
> > > > Kann da bitte mal jemand nachgucken? Der "komische Zustand" besteht
> > > > seit gestern ca. 17 Uhr.
> > > > Ich hab keine Ahnung ob man da überhaupt ein Problem merkt, würde mich
> > > > interessieren.
> > > >
> > > > VG
> > > > nosy
> > > >
> > > >
> > > > PS:
> > > >
> > > > hier noch ein bisschen mtr von einem DFN-Anschluss:
> > > >
> > > >
> > > >                              My traceroute  [v0.86] sony (0.0.0.0)
> > > >                                     Thu May 19 09:35:20 2016 Keys:
> > > > Help   Display mode   Restart statistics   Order of fields   quit
> > > >                                        Packets               Pings
> > > >  Host                                Loss%   Snt   Last   Avg  Best
> > > > Wrst StDev
> > > >  1. devil.asfh-berlin.de              0.0%    17    0.5   0.5   0.4
> > > > 0.5   0.0
> > > >  2. 195.37.142.105                    0.0%    17    0.9   0.8   0.5
> > > > 1.1   0.0
> > > >  3. xr-zib1-ge9-15.x-win.dfn.de       0.0%    17    4.6   4.2   2.5
> > > > 12.0   2.2
> > > >  4. cr-tub2-te0-0-0-7-8.x-win.dfn.de  0.0%    16    4.3   4.1   3.2
> > > > 4.9   0.0
> > > >  5. freifunk-rheinland.bcix.de        0.0%    16    3.1   3.9   2.9
> > > > 5.3   0.4
> > > >  6. eth3.bb-a.ak.ber.de.ffrl.de       0.0%    16    4.9   4.4   3.3
> > > > 5.9   0.5
> > > >  7. ???
> > > >  8. freifunk.bcix.de                  0.0%    16  128.9  22.5   3.5
> > > > 169.2  49.9
> > > >  9. vpn03b.berlin.freifunk.net        0.0%    16   15.3   8.3   3.6
> > > > 55.7  12.9
> > > >
> > > >
> > > >
> > > >                              My traceroute  [v0.86] sony (0.0.0.0)
> > > >                                     Thu May 19 09:34:37 2016 Keys:
> > > > Help   Display mode   Restart statistics   Order of fields   quit
> > > >                                        Packets               Pings
> > > >  Host                                Loss%   Snt   Last   Avg  Best
> > > > Wrst StDev
> > > >  1. devil.asfh-berlin.de              0.0%    36    0.2   0.4   0.2
> > > > 1.2   0.0
> > > >  2. 195.37.142.105                    0.0%    36    1.1   0.8   0.6
> > > > 1.1   0.0
> > > >  3. xr-zib1-ge9-15.x-win.dfn.de       0.0%    36    2.9   4.2   2.5
> > > > 32.5   4.8
> > > >  4. cr-tub2-te0-0-0-7-8.x-win.dfn.de  0.0%    36    3.6   4.3   3.2
> > > > 8.4   0.9
> > > >  5. freifunk-rheinland.bcix.de        0.0%    35    4.5   4.0   2.8
> > > > 5.8   0.4
> > > >  6. eth3.bb-a.ak.ber.de.ffrl.de       0.0%    35    3.5   4.5   3.1
> > > > 10.3   1.2
> > > >  7. ???
> > > >  8. vpn03e.berlin.freifunk.net       44.1%    35  723.7  42.1   3.1
> > > > 723.7 165.1
> > > >
> > > >
> > > > _______________________________________________
> > > > Berlin mailing list
> > > > Berlin at berlin.freifunk.net
> > > > http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> > > > Diese Mailingliste besitzt ein �ffentlich einsehbares Archiv
> > > 
> > > _______________________________________________
> > > Berlin mailing list
> > > Berlin at berlin.freifunk.net
> > > http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> > > Diese Mailingliste besitzt ein ffentlich einsehbares Archiv
> > 
> > _______________________________________________
> > Berlin mailing list
> > Berlin at berlin.freifunk.net
> > http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> > Diese Mailingliste besitzt ein �ffentlich einsehbares Archiv
> 
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> Diese Mailingliste besitzt ein ffentlich einsehbares Archiv
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: nicht verfügbar
URL         : <https://lists.berlin.freifunk.net/pipermail/berlin/attachments/20160527/c87d7c84/attachment.sig>