Recent posts

[EDIT:]

#11

German - Deutsch / Re: MTU bei PPPoe | Deutsche G...

Last post by Patrick M. Hausen - Today at 04:15:55 PM

Und, ja. stimmt. MTU ungleich Payload.

Die MTU ist die Größe des Layer 2 Payloads. Also die Ethernet MTU, von der wir hier die ganze Zeit reden.

Ich wollte an deinem vorangegangenen Post nur korrigieren, dass du geschrieben hattest, die MTU sei Layer 3. Im Layer 2 Payload sind üblicherweise Layer 3 Frames. So stimmt's dann.

Cisco IOS kennt übrigens eine Ethernet MTU und eine IP MTU. Ich muss nochmal nachgucken, was letztere eigentlich genau angibt.

EDIT:

Die Interface MTU in Cisco IOS ist erwartungsgemäß die Layer 2 MTU, also meistens aber nicht immer Ethernet. Die IP MTU gibt ebenfalls die Layer 2 MTU an, aber nur für die Frames, bei denen Layer 3 IP ist. Wenn sie größer ist als die MTU wird die Einstellung verworfen und die MTU gilt. Wenn sie kleiner ist, gilt für IP die IP MTU und für alles andere die MTU.

Wozu man das braucht erschließt sich mir nicht auf Anhieb, aber jedes Feature hat eine Geschichte. Ich hab nie selbst MPLS oder L2TP Tunnel für andere geliefert - evtl. kommt das daher.

#12

General Discussion / Re: Where is TCP processed - C...

Last post by chemlud - Today at 04:07:41 PM

... BTW based on this when you only run the update for the slow, result is the same correct?

Yes, SLOW ist slow for years, all other Tumbleweeds are normal download speed.

RE ASPM

Apparently regulated in BIOS (not reachable with Coreboot) or via a kernel boot command.

Have to check when not remote, don't want to loose the machine by tinkering with kerne boot.

#13

Zenarmor (Sensei) / Re: Upgraded to newer version ...

Last post by sy - Today at 04:03:39 PM

Hi,

The issue arises from the "Block All Internet Access" option, which restricts all connections. Are you aiming to block all web traffic for devices on the vmx1 interface?
 

#14

German - Deutsch / Re: MTU bei PPPoe | Deutsche G...

Last post by s.meier68 - Today at 04:03:21 PM

Genau, natürlich gibt es eine Maximalgröße des gesamten Pakets. Diese ist bei der Verwendung von vLAN aber normalerweise um den vLAN-Header ergänzt (dann 1518) damit der Payload weiterhin 1500 Byte groß sein kann. Das gilt dann auch noch nicht als Jumboframe.... Und, ja. stimmt. MTU ungleich Payload.... :-)

#15

25.7, 25.10 Series / Intel Thermal Sensor Virtually...

Last post by WhatAMess - Today at 03:58:39 PM

I have Opnsense OPNsense 25.7.11_2-amd64 installed on two different mini-pcs, on one the temperatures are clearly visible and posted inside a green box on the other the text is white on white background and barely visible, plus the temperature is way off (.1C).  Should be near to 34 deg C since it is a fanless unit.  I am using Opnsense-Dark theme on both units, they are different brands but both Intel based.  Searches for the thermal sensor problem appear to be a little dated, I am using a current version of Opnsense so hopefully someone has an idea of a fix.--Thanks.

#16

German - Deutsch / Re: MTU bei PPPoe | Deutsche G...

Last post by Patrick M. Hausen - Today at 03:51:05 PM

Die MTU gehört zum Layer3 Header "Teil" des Paketes. Der VLAN Header befindet sich vor dem Layer 3 Header im Layer2 "Teil" des Paketes.

Die MTU gilt für den Layer 2 Payload und der beginnt dann üblicherweise mit dem Layer 3 Header, ja. Falls es ein Layer 3 gibt, was ja nicht sein muss. Also hier bei OPNsense schon, aber es gibt so Audio-Kram und ähnliches, was direkt auf Ethernet aufsetzt.

Du hast aber m.E. vollkommen Recht, dass ein 802.1q (VLAN) Header immer "außen" an den Layer 2 Frame dran geklebt wird und nicht auf Kosten der MTU geht. Ich hab das noch nie gesehen und wir haben mit VLANs angefangen, als man auch noch ISL statt 802.1q verwendet hat, ein proprietäres Format von Cisco.

#17

German - Deutsch / Re: MTU bei PPPoe | Deutsche G...

Last post by s.meier68 - Today at 03:44:04 PM

Exklusiv oder nicht, das ändert nichts daran, dass bei virtualisierten NICs die MTU auf dem PVE-Host bereits vergrößert werden muss, ehe die OpnSense VM das auch nutzen kann.

Das habe ich jetzt schon ein paar mal gelesen und das ist aus meiner Sicht falsch. Die MTU und die Größe des Ethernetframes haben nur bedingt etwas miteinander zu tun. Die MTU gehört zum Layer3 Header "Teil" des Paketes. Der VLAN Header befindet sich vor dem Layer 3 Header im Layer2 "Teil" des Paketes. Dieser hat mit der MTU überhaupt nichts zu tun.
Die MTU kleiner machen, damit das gesamte Paket unter einer bestimmten Größe bleibt ist ungefähr so als wenn man ein Ikea-Paket aufteilt ohne zu wissen was die Spedition für einen LKW verwendet. (Was übrigens auch im Bezug zum Ethernetpaket vollkommen egal ist, da sich die Spedition drum kümmert und nicht das Ikea-Paket!!!)

#18

Zenarmor (Sensei) / Re: Latest Zenarmor update bre...

Last post by sy - Today at 03:38:19 PM

Hi,

We have received the report and are currently investigating the matter. I will provide you with regular updates regarding the ticket.

#19

25.7, 25.10 Series / GeoIP list no more correct for...

Last post by jfou1987 - Today at 03:15:10 PM

Hello, i'm on 25.10.1_2 business Version.
Today, a road warrior user told me he can't connect anymore to VPN server.
I tried on cellular with the same issue.
I found the problem. It's GeoIP. I only give access to Belgian IP (BE). When disabled, it works again.
The geoip database was updated about 15 minutes ago. In the alias IP list (diagnostic/alias) i cannot found any of my belgian (verified) IP adsresses.
I temporary add a whitelist for my user to let him work. But he's behind a dynamic IP internet connexion. I will add his new IP when change.
Does anyone know if the provider of the business GeoIP list has an issue today ?

#20

General Discussion / Re: Where is TCP processed - C...

Last post by Seimus - Today at 03:05:44 PM

RE 2: Mirrors are "hardcoded" and identical on FAST and SLOW. The download of weekly packages on FAST and SLOW is simultaneously in the attachment of OP, so how/why only one client should be rate limited?

True if this is the case. I assumed you have dynamic mirrors and downloads are in different intervals. If you would be rate limited it would be for the Public IP. But if both of them are NATed behind one, it would affect them both. BTW based on this when you only run the update for the slow, result is the same correct?

Congestion algorithm? Hmmm... ;-)

I could talk about this whole day long, but to simplify it, its the often omitted brother of the TCPs scaling window.
Sender > Responsible for the Scaling Window
Receiver > Responsible for the Congestion management

Congestion tells the sender to slow down, and how to recover from the congestion event (this not 100% correct but enough to see both of them are important).


Current enabled congestion algo, default should be at least CUBIC

Code Select Expand

sysctl net.ipv4.tcp_congestion_control
All available congestion algos

Code Select Expand

sysctl net.ipv4.tcp_available_congestion_control
For BRR you you usally need to enable some extra flags in system but nothing to hard...

Regards,
S.