FTTH Pingzeiten von über 10 Sekunden

Wie ist den die MTU wenn du ifconfig pppoe0 machst ?

Holger

Code:
router# ifconfig -a
pppoe0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1492 
        index 6 priority 0 llprio 3 
        dev: vlan35 
        state: session 
        sid: 0x1 PADI retries: 3 PADR retries: 0 time: 00:24:51 
        sppp: phase network authproto pap authname "redacted" 
        dns: z.z.z.z z.z.z.z
        groups: pppoe egress 
        status: active inet y.y.y.y --> x.x.x.x netmask 0xffffffff
 
hm

zum einen wuerde ich, wenn nur getagged vlans auf em0 laufen die MTU auf 1518 setzen.
die MTU des pppoe0 interfaces setzt du statisch, via hostname.pppoe0.

ist diese abgesprochen mit dem provider oder gibt der ggf. einen anderen wert vor ?

ggf. mal aus der config die MTU rausnehmen und dann :

ifconfig pppoe0 destroy
sh /etc/netstart pppoe0


Holger
 
Mit einer MTU auf em0 von 1518 habe ich mal "systat ifstat 1" ausgeführt:

Code:
   1 users Load 0.01 0.02 0.00                            router.local 13:05:35

IFACE     STATE DESC             IPKTS IBYTES IFAILS  OPKTS OBYTES OFAILS  COLLS
em0       up:U                      17   5298      0     30   8003      0      0
em1       up:U  local LAN           34   8534      0     15   4981      0      0
em2       up:D  DMZ                  0      0      0      0      0      0      0
enc0      dn:U                       0      0      0      0      0      0      0
lo0       up                         0      0      0      0      0      0      0
pppoe0    up:U                      17   4924      0      0    180      0      0
vlan35    up:U                      17   5298      0     30   8003      0      0
Totals                              85  24054      0     75  21167      0      0

Allerdings blieb das Symptom unverändert.
 
Der einzige Unterschied zwischen funktioniert und funktioniert nicht ist PPPoE. Ich hätte eigentlich erwartet, dass es allenfalls langsam ist, aber nicht, dass es gar nicht geht. Der Paketstau deutet ja mehr in Richtung eines Queueing-Problems als irgendwelche HW-Limitierungen. Denke ich werde das Thema an dieser Stelle zu den Akten legen und mich nach neuer HW umsehen, dann mit OPNSense. Es sei denn jemand hat noch eine Idee, die man ausprobieren könnte. Andernfalls allen vielen Dank für die Unterstützung bei der Fehlersuche!
 
Ich hatte mich hier etwas rausgezogen, da mir das Wissen über die Details von OpenBSD fehlt. Aber trotzdem: Bedenke, dass wir hier von Pings, also ICMP Echo Request reden. Die Pakete sind mit 56 Kilobyte Payload plus ein paar Header winzig klein und sie sind bei normaler Ping-Rate mit einem Paket pro Sekunde selten. @mark05 hat völlig recht, dass der VLAN-Header sich irgendwo in der MTU widerspiegeln muss. Ob implizit oder explizit sei mal dahingestellt. Aber die Pings werden aufgrund ihrer geringen Größe nicht in MTU-Probleme laufen. Bei einem Paket pro Sekunde sollten Queue-Probleme auch keine Rolle spielen, außer da ist was ganz massiv und grundsätzlich kaputt.

Wir hatten es oben ja schon so weit eingegrenzt, dass es irgendwie an pf liegt. LAN eingesteckt mit pf aus funktionierte ja. Wenn es FreeBSD oder Linux wäre, was es aber nicht ist und bei OpenBSD weiß ich es nicht, wäre mein erster Tipp LRO (oder jegliches andere Hardware-Offload) auf em0 auszuschalten. Weil hier gestackte Interfaces, also em0 -> vlan -> pppoe, im Spiel sind und LRO bei sowas gerne Ärger macht. Wenn das nicht hilft, würde ich die pf.conf einmal testweise auf das absolute Minimum für funktionierendes NAT reduzieren und wenn das hilft sie schrittweise erweitern. So sollte sich das Problem finden lassen. Wäre es FreeBSD, was es immer noch nicht ist, müssten auf jeden Fall em0 und vlan35 gescipt werden.
 
Also ich hab auch nochmal etwas versucht zu googeln. Ich finde @Yamagi sachen solltest du zuerst ausprobieren.

Was mir noch aufgefallen ist:

Deine vlan-config sieht irgendwie komplett anders aus als meine - die sieht so aus und das geht auch eher mit der manpage über ein - deine scheint aber lt. google einfach eine ältere schreibweise zu sein dürfte also auch passen.

parent vport2 <-müsste bei dir natürlich em0 sein
vnetid 102 <- dito 35
inet 192.168.102.1 0xffffff00 <- musst du logischerweise weg lassen
up

Dann MTU von em0 auf 1518 spuckt mir google noch aus und ein "match on pppoe0 scrub (max-mss 1452)" für die pf.conf

(MTU hinweis steht auf auf der vlan man pages, du solltest hier: https://man.openbsd.org/em auch schauen ob deine spezifische em jumbo-frames kann, wenn nicht könnte das schon das problem sein.)

Was du auch mal schauen könntest ist ob du dem vlan ne andere mac als die em0 gibts, villeicht mag das der provider irgendwie nicht.
 
vport ?

ist das irgendwo ne bridge im spiel ? ( veb??? oder bridge??? )

keine gute sache ....

und ein pppoe0 mit parent vport?? ist gar nicht gut.

als parent sollte das vlan if angezeigt werden.

wenn in der config nicht explizit via pppoedev das parent if gesetzt wird das die
automatische auswahl schonmal verkehrt sein.

im zweifel das scrub im pf abschalten. ( zeile auskomentieren ) .
eigentlich sollte pf das schon von sichaus machen .

wenn man pfctl -vvv -sr macht sollte die regel samt statistics

wie gesagt , wenn sauber konfiguriert das laeuft pppoe mit vlan einwandfrei.
und wenn die leitung irgendwas im gbit bereich ist sollte die hardware reichen.

@Yamagi das LRO sollte in kombination mit Intel Karten unter obsd problemlos sein.

ein ifconfig em0 -tcplro sollte das ganze abschalten , was ich aber nicht empfehlen würde.

ein ifconfig em0 hwfeatures zeigt dir was die karte kann.

holger


holger
 
vport ?

ist das irgendwo ne bridge im spiel ? ( veb??? oder bridge??? )

keine gute sache ....

und ein pppoe0 mit parent vport?? ist gar nicht gut.

Das war ein Copy-n-Paste einer meiner vlan konfigurationen, ich hab ja mit den Pfeilen entsprechen kommentiert was bei ihm da hin muss. Mein Setup war ein ganz anderes, ohne pppoe, dafür aber mit 802.1AX - ich wollte nur auf den anderen syntax aufmerksam machen. Von der pppoe config hab ich ncihts geschrieben.

Die tipp mit 1518 stehen so in der manpage und auch das einige karten evtl. mit den "jumboframes" dann nicht umgehen können (ja auch 1518 ist schon ein Jumboframe). Das könnte ein wichtiger hinweise sein.
 
Zurück
Oben