28
Mikrotik CRS NAT-Performance
Hallo in die Runde.
Die letzten Wochen habe ich ja etwas mit RouterOS 7.1.1 und zwei CRS rumgespielt (326 und 328). Die HW der beiden ist ja ziemlich vergleichbar (inkl. System-Image) – von PoE abgesehen.
https://mikrotik.com/product/CRS326-24G-2SplusRM#fndtn-downloads
Folgende Erkenntnisse fielen da über mich her:
a) Mache ich @aquis vLAN-Standardsetup über die Bridge, bleibts bei rund 300 Mbit/s von einem vLAN ins andere. Dabei ist in der Bridge hw-offloading schon per MT-Default aktiviert. RAM ist durchgängig bei ca. 400 MB-Auslastung, Prozessor springt aber im iperf3 auf rund 50%
b) Der Switch-Chip im CRS kann natürlich mehr. Dazu muss aber ZUSÄTZLICH im Menue "Switch" ... hw-offloading Layer 3 aktiviert werden (/interface ethernet switch set 0 l3-hw-offloading=yes name=switch) mit nachfolgendem Neustart (Screenshots). Dann bekomme ich da problemlos die 940 Mbit/s im iPerf3 von einem ins andere vLAN hin. Innerhalb der vLANs ist das alles ja eh kein Thema.
Um Internetzugang am WAN-Port nutzen zu können muss ich jedoch leider das Layer3-offloading deaktivieren ... was dann wieder zu a) führt. Die FW-Regeln machen da keinen Unterschied. NAT ist aktiv (CRS hängt an einem gebridgten Vodefone-Kabel-Modem).
Jetzt die Fragen:
1. In wie fern ist NAT etwas anderes als "Routing"?!
2. Warum muss ich Layer3-hw-offload in diesem Fall überhaupt deaktivieren?!
Viele Grüße
PS: Mir ist völlig klar, dass die "Router-Branch" bei Mikrotik und den Konkurrenten – nicht umsonst – die doppelte CPU-Performance hat. Bei mir hing bis letzte Woche auch noch ein EdgeRouter mit 2 x 880 Mhz vor dem CRS: Der kann zwar kein hw-offload im Routing (d.h. max 600 Mbit/s zwischen vLAN), dafür aber 1 Gbit/s am WAN.
Mir gehts aber konkret um die 2 Fragen.
Die letzten Wochen habe ich ja etwas mit RouterOS 7.1.1 und zwei CRS rumgespielt (326 und 328). Die HW der beiden ist ja ziemlich vergleichbar (inkl. System-Image) – von PoE abgesehen.
https://mikrotik.com/product/CRS326-24G-2SplusRM#fndtn-downloads
Folgende Erkenntnisse fielen da über mich her:
a) Mache ich @aquis vLAN-Standardsetup über die Bridge, bleibts bei rund 300 Mbit/s von einem vLAN ins andere. Dabei ist in der Bridge hw-offloading schon per MT-Default aktiviert. RAM ist durchgängig bei ca. 400 MB-Auslastung, Prozessor springt aber im iperf3 auf rund 50%
b) Der Switch-Chip im CRS kann natürlich mehr. Dazu muss aber ZUSÄTZLICH im Menue "Switch" ... hw-offloading Layer 3 aktiviert werden (/interface ethernet switch set 0 l3-hw-offloading=yes name=switch) mit nachfolgendem Neustart (Screenshots). Dann bekomme ich da problemlos die 940 Mbit/s im iPerf3 von einem ins andere vLAN hin. Innerhalb der vLANs ist das alles ja eh kein Thema.
Um Internetzugang am WAN-Port nutzen zu können muss ich jedoch leider das Layer3-offloading deaktivieren ... was dann wieder zu a) führt. Die FW-Regeln machen da keinen Unterschied. NAT ist aktiv (CRS hängt an einem gebridgten Vodefone-Kabel-Modem).
Jetzt die Fragen:
1. In wie fern ist NAT etwas anderes als "Routing"?!
2. Warum muss ich Layer3-hw-offload in diesem Fall überhaupt deaktivieren?!
Viele Grüße
PS: Mir ist völlig klar, dass die "Router-Branch" bei Mikrotik und den Konkurrenten – nicht umsonst – die doppelte CPU-Performance hat. Bei mir hing bis letzte Woche auch noch ein EdgeRouter mit 2 x 880 Mhz vor dem CRS: Der kann zwar kein hw-offload im Routing (d.h. max 600 Mbit/s zwischen vLAN), dafür aber 1 Gbit/s am WAN.
Mir gehts aber konkret um die 2 Fragen.
/interface bridge
add admin-mac=08:55:31:5E:00:7F auto-mac=no ingress-filtering=no name=bridge \
vlan-filtering=yes
/interface ethernet
set [ find default-name=ether1 ] name=WAN1
set [ find default-name=ether2 ] name=WAN2
set [ find default-name=ether3 ] name=ether3_33
set [ find default-name=ether4 ] name=ether4_99
set [ find default-name=ether5 ] name=ether5_11
set [ find default-name=ether6 ] name=ether6_11
set [ find default-name=ether7 ] name=ether7_11
set [ find default-name=ether8 ] name=ether8_22
set [ find default-name=ether9 ] name=ether9_22
set [ find default-name=ether10 ] name=ether10_33
set [ find default-name=ether11 ] name=ether11_33
set [ find default-name=ether12 ] name=ether12_33
set [ find default-name=ether13 ] name=ether13_33
set [ find default-name=ether14 ] name=ether14_33
set [ find default-name=ether15 ] name=ether15_bonding
set [ find default-name=ether16 ] name=ether16_bonding
set [ find default-name=ether17 ] name=ether17_44
set [ find default-name=ether18 ] name=ether18_44
set [ find default-name=ether19 ] name=ether19_44
set [ find default-name=ether20 ] name=ether20_44
set [ find default-name=ether21 ] name=ether21_44
set [ find default-name=ether22 ] name=ether22_44
set [ find default-name=ether23 ] name=ether23_11
set [ find default-name=ether24 ] name=ether24_wifi-trunk
/interface wireguard
add listen-port=51888 mtu=1420 name=wg_xxx
/interface vlan
add interface=bridge name=vlan1 vlan-id=1
add interface=bridge name=vlan11 vlan-id=11
add interface=bridge name=vlan22 vlan-id=22
add interface=bridge name=vlan33 vlan-id=33
add interface=bridge name=vlan44 vlan-id=44
add interface=bridge name=vlan99 vlan-id=99
/interface ethernet switch
set 0 l3-hw-offloading=yes name=switch
/interface ethernet switch port
set 0 l3-hw-offloading=no
set 1 l3-hw-offloading=no
/interface list
add name=LAN
add name=WAN
add name=listBridge
/interface lte apn
set [ find default=yes ] ip-type=ipv4
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=pool11 ranges=10.98.11.10-10.98.11.49
add name=pool22 ranges=10.98.22.10-10.98.22.49
add name=pool33 ranges=10.98.33.10-10.98.33.49
add name=pool44 ranges=10.98.44.10-10.98.44.49
add name=pool99 ranges=10.98.99.10-10.98.99.49
/ip dhcp-server
add address-pool=pool11 interface=vlan11 lease-script=":local DHCPtag\r\
SCRIPT =dhcp11
add address-pool=pool22 interface=vlan22 lease-script=":local DHCPtag\r\
SCRIPT =dhcp22
add address-pool=pool33 interface=vlan33 lease-script=":local DHCPtag\r\
DHCP =dhcp33
add address-pool=pool44 interface=vlan44 lease-script=":local DHCPtag\r\
DHCP=dhcp44
add address-pool=pool99 interface=vlan99 lease-script=":local DHCPtag\r\
DHCP=dhcp99
/port
set 0 name=serial0
/zerotier
set zt1 comment="ZeroTier Central controller - https://my.zerotier.com/" \
identity="ajfödsfjdsfaödjsfsöa" name=zt1 port=9993
/zerotier interface
add inxxxnce=zt1 mac-address=1E:61:67:54:F5:E4 name=zerotier1 network=\
jdsaöfsdjfaflfasdfdsöa
/interface bridge port
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
ingress-filtering=no interface=ether3_33 pvid=33
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
ingress-filtering=no interface=ether4_99 pvid=99
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
ingress-filtering=no interface=ether5_11 pvid=11
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
ingress-filtering=no interface=ether6_11 pvid=11
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
ingress-filtering=no interface=ether7_11 pvid=11
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
ingress-filtering=no interface=ether8_22 pvid=22
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
ingress-filtering=no interface=ether9_22 pvid=22
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
ingress-filtering=no interface=ether10_33 pvid=33
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
ingress-filtering=no interface=ether11_33 pvid=33
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
ingress-filtering=no interface=ether12_33 pvid=33
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
ingress-filtering=no interface=ether13_33 pvid=33
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
ingress-filtering=no interface=ether14_33 pvid=33
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
ingress-filtering=no interface=ether15_bonding pvid=33
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
ingress-filtering=no interface=ether16_bonding pvid=33
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
ingress-filtering=no interface=ether17_44 pvid=44
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
ingress-filtering=no interface=ether18_44 pvid=44
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
ingress-filtering=no interface=ether19_44 pvid=44
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
ingress-filtering=no interface=ether20_44 pvid=44
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
ingress-filtering=no interface=ether21_44 pvid=44
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
ingress-filtering=no interface=ether22_44 pvid=44
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
ingress-filtering=no interface=ether23_11 pvid=11
add bridge=bridge ingress-filtering=no interface=ether24_wifi-trunk
add bridge=bridge ingress-filtering=no interface=sfp-sfpplus1
add bridge=bridge ingress-filtering=no interface=sfp-sfpplus2
/ip neighbor discovery-settings
set discover-interface-list=listBridge
/ip settings
set max-neighbor-entries=8192
/ipv6 settings
set disable-ipv6=yes
/interface bridge vlan
add bridge=bridge tagged=bridge,ether24_wifi-trunk vlan-ids=33
add bridge=bridge tagged=ether24_wifi-trunk,bridge vlan-ids=44
add bridge=bridge tagged=bridge,ether24_wifi-trunk vlan-ids=11
add bridge=bridge tagged=bridge untagged=ether24_wifi-trunk vlan-ids=1
add bridge=bridge tagged=bridge vlan-ids=99
add bridge=bridge tagged=bridge vlan-ids=22
/interface detect-internet
set detect-interface-list=all internet-interface-list=all lan-interface-list=\
all wan-interface-list=all
/interface list member
add interface=bridge list=LAN
add interface=bridge list=listBridge
/interface wireguard peers
add allowed-address=192.168.66.0/24,10.98.200.0/29 endpoint-address=\
fdasdffsafsa.goip.de endpoint-port=51888 interface=wg_XXX public-key=\
"HxChs13Xxxxxxxxxxxxxxxy4JxxqewzgdsurQIi4Fg="
/ip address
add address=10.98.1.1/26 interface=vlan1 network=10.98.1.0
add address=10.98.11.1/26 interface=vlan11 network=10.98.11.0
add address=10.98.22.1/26 interface=vlan22 network=10.98.22.0
add address=10.98.33.1/26 interface=vlan33 network=10.98.33.0
add address=10.98.44.1/26 interface=vlan44 network=10.98.44.0
add address=10.98.99.1/26 interface=vlan99 network=10.98.99.0
add address=10.98.200.1/30 interface=wg_xxx network=10.98.200.0
/ip cloud
set ddns-enabled=yes
/ip dhcp-client
add interface=WAN1
add interface=WAN2
/ip dhcp-server lease
add address=10.98.33.9 mac-address=00:09:A7:04:55:04 server=dhcp33
add address=10.98.44.2 mac-address=B4:22:00:0B:6B:BC server=dhcp44
add address=10.98.33.4 mac-address=B4:22:00:23:71:50 server=dhcp33
add address=10.98.22.2 mac-address=7C:2F:80:E0:7A:9C server=dhcp22
add address=10.98.33.6 mac-address=5C:85:7E:4A:D8:21 server=dhcp33
add address=10.98.33.7 mac-address=52:54:00:D0:6C:14 server=dhcp33
/ip dhcp-server network
add address=0.0.0.0/24 gateway=0.0.0.0 netmask=24
add address=10.98.1.0/26 gateway=10.98.1.1 netmask=26
add address=10.98.11.0/26 gateway=10.98.11.1
add address=10.98.22.0/26 dns-server=10.98.33.2 gateway=10.98.22.1
add address=10.98.33.0/26 dns-server=10.98.33.2 gateway=10.98.33.1
add address=10.98.44.0/26 gateway=10.98.44.1
add address=10.98.99.0/26 dns-server=10.98.33.2 gateway=10.98.99.1
/ip dns
set servers=10.98.33.2
/ip firewall filter
add action=accept chain=forward comment="allow zerotier" in-interface=zerotier1
add action=accept chain=input in-interface=zerotier1
add action=accept chain=input comment="allow ICMP" disabled=yes in-interface=\
WAN1 protocol=icmp
add action=accept chain=input comment="allow Winbox" disabled=yes in-interface=\
WAN1 port=8291 protocol=tcp
add action=accept chain=input comment="accept established,related" \
connection-state=established,related
add action=drop chain=input connection-state=invalid
add action=accept chain=input comment="allow SSH" in-interface=WAN1 port=22 \
protocol=tcp
add action=drop chain=input comment="block everything else" in-interface=WAN1
/ip firewall nat
add action=masquerade chain=srcnat log=yes out-interface=WAN1
add action=dst-nat chain=dstnat disabled=yes in-interface=WAN1 log=yes port=\
51888 protocol=udp to-addresses=10.98.33.6 to-ports=51888
/ip route
add dst-address=192.168.66.0/24 gateway=wg_xxx
add check-gateway=ping comment=WAN1 disabled=no distance=1 dst-address=\
0.0.0.0/0 gateway=WAN1 routing-table=main scope=30 suppress-hw-offload=no \
target-scope=10
add check-gateway=ping comment=WAN1 disabled=no distance=2 dst-address=\
0.0.0.0/0 gateway=WAN2 routing-table=main scope=30 suppress-hw-offload=no \
target-scope=10
add comment=WAN1-Check distance=1 dst-address=8.8.8.8 gateway=WAN1 scope=30 \
target-scope=10
add comment=WAN1-Check distance=1 dst-address=8.8.4.4 gateway=WAN2 scope=30 \
target-scope=10
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes
set api disabled=yes
/ip ssh
set strong-crypto=yes
/system clock
set time-zone-name=Europe/Berlin
/system identity
set name=xxx_CRS326-24G-2S+
/system ntp server
set enabled=yes
/system routerboard settings
set boot-os=router-os
/system swos
set allow-from-ports="p1,p2,p3,p4,p5,p6,p7,p8,p9,p10,p11,p12,p13,p14,p15,p16,p17\
,p18,p19,p20,p21,p22,p23,p24,p25,p26" identity=MikroTik static-ip-address=\
10.98.0.254
/tool mac-server
set allowed-interface-list=listBridge
/tool mac-server mac-winbox
set allowed-interface-list=listBridge
/tool netwatch
add comment=WAN1 down-script="/ip route disable [find comment=\"WAN1\"]" host=\
8.8.8.8 interval=5s up-script="/ip route enable [find comment=\"WAN1\"]"
add comment=WAN1 down-script="/ip route disable [find comment=\"WAN1\"]" host=\
8.8.4.4 interval=5s up-script="/ip route enable [find comment=\"WAN1\"]" 
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1731592255
Url: https://administrator.de/contentid/1731592255
Ausgedruckt am: 17.11.2024 um 05:11 Uhr
28 Kommentare
Neuester Kommentar
Moin,
ich kann dir gerade keine gesicherten Infos liefern.
NAT ist jedoch eine Tabelle für die Portzuordnung. Das kann, soweit ich weiß, nur mit spezial-HW auf der HW selbst gemacht werden.
Ähnliches gilt übrigens für BGP Router mit der Routingtable. Da kann ich dann doch aus Erfahrung sprechen. (Im 7er Release gab es da gerade Anpassungen bei Mikrotik)
Der Punkt weswegen ich mich melden, ist die Aktivierung von "L3 Hw Offloading". Ich habe das gerade bei meinem CRS326 aktiviert und einen immensen Performance Schub feststellen können, obwohl die CPU vorher auch nicht großartig ausgelastet war. Ich frage mich, wieso dies nicht default aktiviert wird? (Die Ports zeigen in der Bridge das offloading auch ohne den Haken an, daher dachte ich, dies wäre bereits aktiv.) Hast du da eine Idee?
Gruß
Spirit
ich kann dir gerade keine gesicherten Infos liefern.
NAT ist jedoch eine Tabelle für die Portzuordnung. Das kann, soweit ich weiß, nur mit spezial-HW auf der HW selbst gemacht werden.
Ähnliches gilt übrigens für BGP Router mit der Routingtable. Da kann ich dann doch aus Erfahrung sprechen. (Im 7er Release gab es da gerade Anpassungen bei Mikrotik)
Der Punkt weswegen ich mich melden, ist die Aktivierung von "L3 Hw Offloading". Ich habe das gerade bei meinem CRS326 aktiviert und einen immensen Performance Schub feststellen können, obwohl die CPU vorher auch nicht großartig ausgelastet war. Ich frage mich, wieso dies nicht default aktiviert wird? (Die Ports zeigen in der Bridge das offloading auch ohne den Haken an, daher dachte ich, dies wäre bereits aktiv.) Hast du da eine Idee?
Gruß
Spirit
Der Punkt weswegen ich mich melden, ist die Aktivierung von "L3 Hw Offloading".
Cool, gelle?! Ging mir ähnlich. Ich habe den 326 jetzt seit Mai/21 und ihn mit - viel Ausdauer von @aqui - damals schon versucht zu konfigurieren. Der hatte dann max 165 Mbit/s zwischen den vLANs und auch dem Support von Mikrotik ist dazu nix eingefallen, außer, dass sie es im Labor nachstellen konnten ...
Für mich war das dann ein sehr unbefriedigender "Bug" und die Kiste lief deshalb bis letzte Woche erstmal mit switchOS hinter dem edgerouter der die vlans verwaltete.
Das mit dem "Switch-Menue" hatte ich irgendwo in der Doku von Mikrotik gefunden und jetzt mal ausprobiert. Der Kunden-CRS328 kam mir dafür gerade Recht.
Beruhigt mich irgendwie, dass ich nicht der einzige bin, der das noch nicht wusste
Hast du da eine Idee?
Nö. Evtl. aber weil es bei den WAN-Ports ja nicht aktiviert sein darf und man sich diese Komplikation sparen möchte?! Ich verstehe auch nciht, warum der Support damit so Probleme hattte?! Die hatten mein komplettes Setup ja vorliegen gehabt. Es scheint aber ein reines "CRS"Thema unter routerOS zu sein.
Ich habe ebenfalls irre lange an dem Hobel herumgebastelt.
Mit dem flag konnte ich gerade echt die Bandbreite im selben VLan über mehrere Ports hinweg auf 1Gbit steigern. Meine Test blieben dabei ziemlich konstant.
Allerdings muss ich auch gestehen, dass ich mit aquis Guides nicht 100% konform gehe, oder sie ggf. nicht ganz verstanden habe.
Ein Bridge Setup bau ich immer wie folgt auf:
Damit ist die Performance schon sehr gut. Ich fahre hier im Regelfall 600-800MBit ohne das offloading flag im Switch selbst. Die Bridge zeigt aber, wie schon erwähnt, das offloading an. Sehr merkwürdig.
Zugegeben trifft dies jetzt nicht dein Setup. Fürs Routing/NAT nutze ich persönlich meine Sense oder im Business Bereich einen Router.
Mit dem flag konnte ich gerade echt die Bandbreite im selben VLan über mehrere Ports hinweg auf 1Gbit steigern. Meine Test blieben dabei ziemlich konstant.
Allerdings muss ich auch gestehen, dass ich mit aquis Guides nicht 100% konform gehe, oder sie ggf. nicht ganz verstanden habe.
Ein Bridge Setup bau ich immer wie folgt auf:
- tagged Ports immer tagged in der bridge eintragen.
- nur eine einzige bridge verwenden.
- untagged Ports untagged in der bridge eintragen und PVID setzen.
- Nur für Mgmt oder Router Dienste ein Interface mit IP sowie VLan erstellen und der bridge tagged hinzufügen.
Damit ist die Performance schon sehr gut. Ich fahre hier im Regelfall 600-800MBit ohne das offloading flag im Switch selbst. Die Bridge zeigt aber, wie schon erwähnt, das offloading an. Sehr merkwürdig.
Zugegeben trifft dies jetzt nicht dein Setup. Fürs Routing/NAT nutze ich persönlich meine Sense oder im Business Bereich einen Router.
Zitat von @Visucius:
Hast du da eine Idee?
Es scheint aber ein reines "CRS"Thema unter routerOS zu sein.Okay, das ist schon interessant. Bin gespannt ob sich das noch irgendwie vereinfachen lässt.
Was passiert denn, wenn du das Offloading im Switch Chip aktivierst und es für den WAN Port explizit raus nimmst?
Dieser WAN Port darf ja auch nicht Teil der Bridge sein, wenn man aquis Tut folgt.
Edit: habe es gerade in deiner Konfig gesehen. Die WAN Ports sind zumindest nicht Teil der bridge.
Edit 2: Und das hier deaktiviert es, wie von mir vorgeschlagen, richtig?
/interface ethernet switch port
set 0 l3-hw-offloading=no
set 1 l3-hw-offloading=noHast du hiermit schonmal Probleme gehabt?:
/interface detect-internet
set detect-interface-list=all internet-interface-list=all lan-interface-list=\
all wan-interface-list=all
Servus,
Hast du dir das Beispiel (und die Erläuterungen darüber) hier durchgelesen?
Inter-VLAN Routing with Upstream Port Behind Firewall/NAT
Zu Frage 1:
NAT ist ein Firewall-Feature in der POST- und PREROUTING Chain und um dieses nutzen zu können muss der entsprechende Port vom L3 HW Offload ausgenommen werden da die Pakete sonst an der CPU/Firewall vorbei gehen.
Zu Frage 2:
L3 HW Offload musst du nur am Uplink (WAN) Switch-Port deaktivieren da dort sonst die Firewall umgangen wird (siehe Beispiel im Link).
Grüße Uwe
Hast du dir das Beispiel (und die Erläuterungen darüber) hier durchgelesen?
Inter-VLAN Routing with Upstream Port Behind Firewall/NAT
Zu Frage 1:
NAT ist ein Firewall-Feature in der POST- und PREROUTING Chain und um dieses nutzen zu können muss der entsprechende Port vom L3 HW Offload ausgenommen werden da die Pakete sonst an der CPU/Firewall vorbei gehen.
Zu Frage 2:
L3 HW Offload musst du nur am Uplink (WAN) Switch-Port deaktivieren da dort sonst die Firewall umgangen wird (siehe Beispiel im Link).
Grüße Uwe
1
Hallo,
Du wirfst die Layer durcheinander!
Das Hardware-Offloading in der VLAN-Bridge betrifft das Layer2-Forwarding. Ohne dieses muss der MT bereits die Ethernetframes zwischen den Switchports auf der CPU verarbeiten.
Beim L3-Hardware-Offloading geht es - wie der Name schon sagt - um Layer3-Forwarding, also um die IP-Ebene.
Wie Uwe schon richtig ausführte, macht der MT Firewalling und dessen Abfallprodukt NAT auf der CPU. Lässt Du den IP-Traffic vom Switch-Chip abarbeiten, dann läuft dieser am Firewallregelwerk vorbei.
Ich erinnere mich aber noch ganz dunkel an meine MTCNA-Schulung vor ziemlich genau 10 Jahren, dass es mittels "Fasttrack" dennoch die Möglichkeit gab, auch den Firewalltraffic zu beschleunigen. Viel mehr als der Begriff ist mir aber leider nicht hängen geblieben. Ich nutze MT im Wesentlichen nur privat als Accesspoints und beruflich nur für ganz wenige Spezialfälle, wo es auf Performence bisher nie ankam.
Gruß
Steffen
Zitat von @Visucius:
Mache ich @aquis vLAN-Standardsetup über die Bridge, bleibts bei rund 300 Mbit/s von einem vLAN ins andere. Dabei ist in der Bridge hw-offloading schon per MT-Default aktiviert. ... Der Switch-Chip im CRS kann natürlich mehr. Dazu muss aber ZUSÄTZLICH im Menue "Switch" ... hw-offloading Layer 3 aktiviert werden (/interface ethernet switch set 0 l3-hw-offloading=yes name=switch) mit nachfolgendem Neustart (Screenshots). Dann bekomme ich da problemlos die 940 Mbit/s im iPerf3 von einem ins andere vLAN hin.
Mache ich @aquis vLAN-Standardsetup über die Bridge, bleibts bei rund 300 Mbit/s von einem vLAN ins andere. Dabei ist in der Bridge hw-offloading schon per MT-Default aktiviert. ... Der Switch-Chip im CRS kann natürlich mehr. Dazu muss aber ZUSÄTZLICH im Menue "Switch" ... hw-offloading Layer 3 aktiviert werden (/interface ethernet switch set 0 l3-hw-offloading=yes name=switch) mit nachfolgendem Neustart (Screenshots). Dann bekomme ich da problemlos die 940 Mbit/s im iPerf3 von einem ins andere vLAN hin.
Du wirfst die Layer durcheinander!
Das Hardware-Offloading in der VLAN-Bridge betrifft das Layer2-Forwarding. Ohne dieses muss der MT bereits die Ethernetframes zwischen den Switchports auf der CPU verarbeiten.
Beim L3-Hardware-Offloading geht es - wie der Name schon sagt - um Layer3-Forwarding, also um die IP-Ebene.
Wie Uwe schon richtig ausführte, macht der MT Firewalling und dessen Abfallprodukt NAT auf der CPU. Lässt Du den IP-Traffic vom Switch-Chip abarbeiten, dann läuft dieser am Firewallregelwerk vorbei.
Ich erinnere mich aber noch ganz dunkel an meine MTCNA-Schulung vor ziemlich genau 10 Jahren, dass es mittels "Fasttrack" dennoch die Möglichkeit gab, auch den Firewalltraffic zu beschleunigen. Viel mehr als der Begriff ist mir aber leider nicht hängen geblieben. Ich nutze MT im Wesentlichen nur privat als Accesspoints und beruflich nur für ganz wenige Spezialfälle, wo es auf Performence bisher nie ankam.
Gruß
Steffen
1
Danke für die Erklärung!
@Spirit-of-Eli
https://help.mikrotik.com/docs/display/ROS/Bridging+and+Switching
und Teilen dieses Videos hier:
https://www.youtube.com/watch?v=YLtGQAQ8iS0
zu Rate gezogen.
Jo, bei mir gibts auch nur eine Bridge und die 2 x WAN sind sozusagen "außerhalb" (siehe Screenshot).
Bridge > vLANs ist überall die Bridge als "tagged" eingetragen (siehe Video) und ggfs. die Trunk-Ports. Untagged ist NICHT eingetragen, das geht automatisch.
Das Mgmnt-vLAN kommt aktuell noch am Port4 untagged raus. Mit dem Konzept "mgmnt-vLAN" bin ich noch nicht so ganz warm geworden. Mikrotik bietet ja auch "Hybrid-Ports" an. Das wollte ich mir nochmal ansehen.
https://buananetpbun.github.io/mikrotik-failover-script-generator.html (netwatch).
Und aktuell testweise die "distance" in der 2. Route von 2 auf 5 erhöht.
@colinardo
Neee, habe ich nicht Aber Danke Dir, das erklärt mit dem Best-Practice-Beispiel ja die Performance-Aspekte. Ich vergleiche das mal mit meinem Setup nachher im Büro.
Und nochmals Danke für die Erläuterung des Verhaltens! Was allerdings auch dazu führt, dass ich das hw-offload an meinem Mgmnt-Port deaktivieren muss 😡
@sk
Mir war aber der Rest nicht klar. Wo was abläuft und das hw-offloading am "hirn" vorbeiführt. Auch wenn das jetzt - im Nachhinein - ganz logisch klingt
Das "Fasttrack"-Thema hatte ich irgendwo gesehen aber wusste nicht, was es damit auf sich hat. In @colinardo s Best-Practice-Setup ist es ebenfalls aktiviert und wenn ich mir mal die Ergebnisse auf nem lütten 600 Mhz RB2011 ansehe (ganz unten)
https://wiki.mikrotik.com/wiki/Manual:IP/Fasttrack
wird das mein Problem bestimmt hinreichend adressieren! Dickes Danke dafür, ich probiere das nachher gleich mal!
Viele Grüße aus dem verschneiten Süden
aquis Guides nicht 100% konform gehe
Also ich habe da zusätzlich noch:https://help.mikrotik.com/docs/display/ROS/Bridging+and+Switching
und Teilen dieses Videos hier:
https://www.youtube.com/watch?v=YLtGQAQ8iS0
zu Rate gezogen.
Jo, bei mir gibts auch nur eine Bridge und die 2 x WAN sind sozusagen "außerhalb" (siehe Screenshot).
Bridge > vLANs ist überall die Bridge als "tagged" eingetragen (siehe Video) und ggfs. die Trunk-Ports. Untagged ist NICHT eingetragen, das geht automatisch.
Das Mgmnt-vLAN kommt aktuell noch am Port4 untagged raus. Mit dem Konzept "mgmnt-vLAN" bin ich noch nicht so ganz warm geworden. Mikrotik bietet ja auch "Hybrid-Ports" an. Das wollte ich mir nochmal ansehen.
re hier im Regelfall 600-800MBit ohne das offloading flag im Switch selbst.
Wow, das sind ja Werte von denen ich nur träumen konnte. Meine 165 mbit waren halt einfach inakzeptabel ... weshalb ich mir das nochmal genauer angesehen habe.Was passiert denn, wenn du das Offloading im Switch Chip aktivierst und es für den WAN Port explizit raus nimmst?
Genau so ist es ja (wie Du schon anmerktest). "Global" wirds am Chip aktiviert. Ich meine - das müsste ich prüfen - damit ist es auf allen Ports auch aktiviert und muss bei den WAN-Ports wieder deaktiviert werden. Hatte ne Weile gedauert, bis ich das merkte. Ich kam nur drauf, wegen des dann "defekten" Internetzugangs /interface detect-internet
Hm, das ist ne super Frage. Ich hatte das nur aktiviert um zu sehen ob der Port das Internet "sieht". Weil mit hw-offloading ja der WAN Probleme machte. Und danach blieb das aktiviert. Manchmal scheint der Router allerdings extrem langsam auf Internet-Anfragen zu warten bzw. abzubrechen. Das habe ich aber aktuell eher auf meine 2 WANs bzw. deren Routing geschoben. Dafür habe ich mir übrigens dieses Script hier abgewandelt:https://buananetpbun.github.io/mikrotik-failover-script-generator.html (netwatch).
Und aktuell testweise die "distance" in der 2. Route von 2 auf 5 erhöht.
@colinardo
Neee, habe ich nicht
Aber Danke Dir, das erklärt mit dem Best-Practice-Beispiel ja die Performance-Aspekte. Ich vergleiche das mal mit meinem Setup nachher im Büro.Und nochmals Danke für die Erläuterung des Verhaltens! Was allerdings auch dazu führt, dass ich das hw-offload an meinem Mgmnt-Port deaktivieren muss 😡
@sk
Du wirfst die Layer durcheinander!
Bestimmt immer mal wieder – hier aber nicht. Ich habs nur ggfs. missverständlich formuliert. Layer3 = routing = zwischen vlans, Layer2 = switching innerhalb des vlans. Und die Frage kam dann, ob NAT was anderes ist als Layer3-Routing.Mir war aber der Rest nicht klar. Wo was abläuft und das hw-offloading am "hirn" vorbeiführt. Auch wenn das jetzt - im Nachhinein - ganz logisch klingt
Das "Fasttrack"-Thema hatte ich irgendwo gesehen aber wusste nicht, was es damit auf sich hat. In @colinardo s Best-Practice-Setup ist es ebenfalls aktiviert und wenn ich mir mal die Ergebnisse auf nem lütten 600 Mhz RB2011 ansehe (ganz unten)
https://wiki.mikrotik.com/wiki/Manual:IP/Fasttrack
wird das mein Problem bestimmt hinreichend adressieren! Dickes Danke dafür, ich probiere das nachher gleich mal!
Viele Grüße aus dem verschneiten Süden
Ich habe hier noch einen Foren Beitrag zum L3 HW Offloading gefunden:
https://help.mikrotik.com/docs/display/ROS/L3+Hardware+Offloading
Das macht einen guten Eindruck. Vor allem wird für mich die L2 und L3 Konfig explizit differenziert.
https://help.mikrotik.com/docs/display/ROS/L3+Hardware+Offloading
Das macht einen guten Eindruck. Vor allem wird für mich die L2 und L3 Konfig explizit differenziert.
Ein Bridge Setup bau ich immer wie folgt auf:
Entspricht doch vollständig auch dem was im Tutorial steht ?! Ist also konform zu dem was du auch machst.Ob man den WAN Port über einen dedizierten Port im Routing Mode laufen lässt oder über ein VLAN IP Port ist eher eine kosmetische Frage
UNtagged Ports müssen nicht in der VLAN Bridge eingetragen werden. Die richtige PVID Zuordnung reicht dafür völlig aus.
Steht aber so auch alles im Tutorial.
Zitat von @aqui:
Ein Bridge Setup bau ich immer wie folgt auf:
Entspricht doch vollständig auch dem was im Tutorial steht ?! Ist also konform zu dem was du auch machst.Okay, dann habe ich es doch richtig verstanden.
UNtagged Ports müssen nicht in der VLAN Bridge eingetragen werden. Die richtige PVID Zuordnung reicht dafür völlig aus.
Steht aber so auch alles im Tutorial.
Steht aber so auch alles im Tutorial.
Macht es einen unterschied ob die Ports auch untagged in der bridge stehen? Ich habe bisher immer beides gemacht.
Es schadet nicht, ist aber völlig überflüssige Arbeit. Denn wenn die Ports einen aktiven Link haben trägt der Switch sie eh automatisch ein. PVID reicht also völlig.
So, jetzt wollte ich doch nochmal kurz Feedback in die Runde werfen!
Neben dem oben genannten
https://help.mikrotik.com/docs/display/ROS/L3+Hardware+Offloading
ist zum Verständnis durchaus auch sinnvoll sich mal
https://help.mikrotik.com/docs/display/ROS/Basic+Concepts > FastTrack
durchzulesen.
Es genügt – von der Standard-FW aus kommend - unterhalb der Input-Chain noch eine Forward-Chain mit fasttrack (established, related) anzulegen. UND darunter(!) noch eine zweite identische OHNE FastTrack und OHNE hw-offload, als Fallback, bzw. den Datenverkehr, der nicht über Fasttrack laufen kann. Der Rest (z.B. Mangle-Rules) werden automatisch angelegt.
Anmerkung für Neulinge:
Ich habe den hw-offload dafür nicht übers Interface gefunden sondern nur über den CLI-Befehl. Ohne "hw-offload=yes" bringt die Regel nix und man sieht auch, dass kein Traffic darüber läuft. Das klingt zwar logisch ... im Mikrotik-Beispiel wird die Regel aber ohne hw-offload angelegt!
Dafür wird hier sogar noch eine Dritte Forward-Chain angelegt (die mittlere), ohne hw-offload aber mit Fasttrack, ... macht (imho) keine Sinn und geht auch ohne problemlos (unabhängig von der TCP-Einschränkung).
Lt. Mikrotik ist natürlich ausgerechnet mein CRS (328 und 326) mit dem 98DX3236 Chip vom hw-offloading im NAT und FastTrack ausgeschlossen. Ich kann aber berichten, dass der Datendurchsatz am WAN-Port trotzdem von 250 bis 300 Mbit/s auf 400 bis 450 Mbit/s angestiegen ist. Mehr ist natürlich immer toll – wir benötigen das außerhalb von Performance-Tests aber nicht
Anbei ein Screenshot meiner aktuellen FW - Feedback erbeten. Ganz besonders wegen der letzten Regel 7. Stimmt die überhaupt oder funktioniert die so nicht?! Bytes/Packets = 0:
Grundsätzlich tue ich mir etwas schwer mit der Mikrotik-Firewall. Nimmt man sich für den Anfang das "Configuration-Example" und deaktiviert "Allow ICMP", "Winbox and SSH" ... wird einem beim Portscan der öffentlichen IP erst Port 80 und dann das Login-Fenster präsentiert ... ;-(
Jetzt verstehe ich zwar, warum Mikrotik so viel Wert aufs PW legt ... das fand ich Naivling aber trotzdem etwas befremdlich?! Ganz davon abgesehen, dass das ja alles nur "Input-Chain" ist?! Ich hätte gedacht, dass auch im Standard-Setup etwas mehr Schutz von außen kommt, als nur NAT?! Ich will ja nicht ausschließlich meinen Router sichern, sondern auch das Netzwerk dahinter?!
PS: Eine Frage noch: Es scheint, als ob zwischen der Standard-FW und dem obigen Setup innerhalb eines vLANs der Chromcast nicht mehr erreichbar ist?! Airplay macht in den Nachbar-vLANs keine Probleme. Und wie gesagt - Chromcast UND Client arbeiten innerhalb des gleichen vLANs (kein Mgmnt-vLAN!). Kann doch eigentlich nur an Regel 7 liegen?! Ich kanns nur gerade nicht testen.
Neben dem oben genannten
https://help.mikrotik.com/docs/display/ROS/L3+Hardware+Offloading
ist zum Verständnis durchaus auch sinnvoll sich mal
https://help.mikrotik.com/docs/display/ROS/Basic+Concepts > FastTrack
durchzulesen.
Es genügt – von der Standard-FW aus kommend - unterhalb der Input-Chain noch eine Forward-Chain mit fasttrack (established, related) anzulegen. UND darunter(!) noch eine zweite identische OHNE FastTrack und OHNE hw-offload, als Fallback, bzw. den Datenverkehr, der nicht über Fasttrack laufen kann. Der Rest (z.B. Mangle-Rules) werden automatisch angelegt.
Anmerkung für Neulinge:
Ich habe den hw-offload dafür nicht übers Interface gefunden sondern nur über den CLI-Befehl. Ohne "hw-offload=yes" bringt die Regel nix und man sieht auch, dass kein Traffic darüber läuft. Das klingt zwar logisch ... im Mikrotik-Beispiel wird die Regel aber ohne hw-offload angelegt!
Dafür wird hier sogar noch eine Dritte Forward-Chain angelegt (die mittlere), ohne hw-offload aber mit Fasttrack, ... macht (imho) keine Sinn und geht auch ohne problemlos (unabhängig von der TCP-Einschränkung).
Lt. Mikrotik ist natürlich ausgerechnet mein CRS (328 und 326) mit dem 98DX3236 Chip vom hw-offloading im NAT und FastTrack ausgeschlossen. Ich kann aber berichten, dass der Datendurchsatz am WAN-Port trotzdem von 250 bis 300 Mbit/s auf 400 bis 450 Mbit/s angestiegen ist. Mehr ist natürlich immer toll – wir benötigen das außerhalb von Performance-Tests aber nicht
Anbei ein Screenshot meiner aktuellen FW - Feedback erbeten. Ganz besonders wegen der letzten Regel 7. Stimmt die überhaupt oder funktioniert die so nicht?! Bytes/Packets = 0:
Grundsätzlich tue ich mir etwas schwer mit der Mikrotik-Firewall. Nimmt man sich für den Anfang das "Configuration-Example" und deaktiviert "Allow ICMP", "Winbox and SSH" ... wird einem beim Portscan der öffentlichen IP erst Port 80 und dann das Login-Fenster präsentiert ... ;-(
Jetzt verstehe ich zwar, warum Mikrotik so viel Wert aufs PW legt ... das fand ich Naivling aber trotzdem etwas befremdlich?! Ganz davon abgesehen, dass das ja alles nur "Input-Chain" ist?! Ich hätte gedacht, dass auch im Standard-Setup etwas mehr Schutz von außen kommt, als nur NAT?! Ich will ja nicht ausschließlich meinen Router sichern, sondern auch das Netzwerk dahinter?!
PS: Eine Frage noch: Es scheint, als ob zwischen der Standard-FW und dem obigen Setup innerhalb eines vLANs der Chromcast nicht mehr erreichbar ist?! Airplay macht in den Nachbar-vLANs keine Probleme. Und wie gesagt - Chromcast UND Client arbeiten innerhalb des gleichen vLANs (kein Mgmnt-vLAN!). Kann doch eigentlich nur an Regel 7 liegen?! Ich kanns nur gerade nicht testen.
wird einem beim Portscan der öffentlichen IP erst Port 80 und dann das Login-Fenster präsentiert
Sorry, aber diese Aussage ist so nicht richtig !! Zumindestens nicht was die Mikrotik Default FW Konfiguration anbetrifft.Dort siehst du es ja eindeutig in der Regel 5:
Auch die L2 Infrastruktprotokolle wie LLDP, CDP und das WinBox Hello sind natürlich am WAN Port per Default immer deaktiviert (WAN Interface Liste, Neighbor Discovery).
Entweder hast du also dein Default Ruleset der Firewall verfummelt oder die Interface Zuordnung in deiner Mgmt Liste oder Interface Bezeichnung oder was auch immer stimmt nicht. So kann man deine Aussage jedenfalls nicht stehenlassen wenn du vermutlich selber PEBKAC Fehler am Regelwerk fabrizierst ?!
Ein Portscan auf den WAN Port mit Default Regeln zeigt erwartbar nix an. Wie auch mit Action drop ?!
Das kann schon sein .... nur ist es ja so, dass der CRS im Default KEINE Firewall mitbringt. Habe ich hier ja schon mal nen Thread zu gemacht (und auch belegt, falls das angezweifelt wird)
Sucht man sich dann erstmal ne Default-Lösung kann man - so wie ich - durchaus im Handbuch (auch) unter
https://help.mikrotik.com/docs/display/ROS/Basic+Concepts fündig werden.
Und das - hier jetzt hier nochmal(!) - Zitat "Configuration-Example" sieht dann so aus:
Natürlich erklärt mir hier jetzt jeder, dass ich nur richtig (und umfangreich) lesen muss, gefälligst verstehen soll, es auch ein Video dazu gibt, dass ich die "First config" durchgehen soll und ich auch die IP-Bereiche des Zugriffs einschränken kann.
Nur liest man ja kreuz und quer und diese Anleitungen unterscheiden sich auch jeweils ein wenig (z.B. in der Reihenfolge) und es besteht für so Naivlinge wie mich durchaus das Risiko den kleinen eingeschobenen "ether1" (den WAN-Port in der First-Config) zu übersehen, bzw. genau das "falsche" Beispiel zu nehmen
Das sich der Effekt am Ende mit der richtigen Konfiguration beheben lässt, sieht man ja (hoffentlich) an dem Screenshot meines aktuellen Setups?! Ich unterstelle nur, dass womöglich nicht jeder seine Setups prüft.
PS: Evtl. auch Ideen zu meinen Frage(n)?!
Sucht man sich dann erstmal ne Default-Lösung kann man - so wie ich - durchaus im Handbuch (auch) unter
https://help.mikrotik.com/docs/display/ROS/Basic+Concepts fündig werden.
Und das - hier jetzt hier nochmal(!) - Zitat "Configuration-Example" sieht dann so aus:
Natürlich erklärt mir hier jetzt jeder, dass ich nur richtig (und umfangreich) lesen muss, gefälligst verstehen soll, es auch ein Video dazu gibt, dass ich die "First config" durchgehen soll und ich auch die IP-Bereiche des Zugriffs einschränken kann.
Nur liest man ja kreuz und quer und diese Anleitungen unterscheiden sich auch jeweils ein wenig (z.B. in der Reihenfolge) und es besteht für so Naivlinge wie mich durchaus das Risiko den kleinen eingeschobenen "ether1" (den WAN-Port in der First-Config) zu übersehen, bzw. genau das "falsche" Beispiel zu nehmen
Das sich der Effekt am Ende mit der richtigen Konfiguration beheben lässt, sieht man ja (hoffentlich) an dem Screenshot meines aktuellen Setups?! Ich unterstelle nur, dass womöglich nicht jeder seine Setups prüft.
PS: Evtl. auch Ideen zu meinen Frage(n)?!
nur ist es ja so, dass der CRS im Default KEINE Firewall mitbringt.
Dann bleibt es ja beim PEBKAC Fehler...! 😉Das Beispiel Regelwerk von oben ist ja schon richtig. Nur das natürlich auch SSH und ganz besonders die WinBox nichts auf dem WAN Port zu suchen haben. Hier wäre es sinnvoller dann mit einer Liste "Mgmt" zu arbeiten dort alle Interfaces zu listen die den Zugang erlauben und die Input DROP Regel dann auf "!Mgmt" zu setzen, also alles was nicht Management ist.
Das sollte die WAN Port Problematik dann im Handumdrehen lösen.
Dann bleibt es ja beim PEBKAC Fehler...! 😉
Ja, kann man so sehen - wie bei fast allem, auf das man Einfluss hat. Deshalb habe ich das ja in meinem eigenem Setup letztens auch geändert.
Aber ich weise ebenso darauf hin, damit der geneigte "NOOB", der den Thread evtl. hier findet bei seinem Setup darauf achtet.
Wobei ich mir bei ner Firewall durchaus auch ne Rückfrage vorstellen könnte, a la: "Sehr geehrter Nutzer, Sie konfigurieren eine Firewall, wollen Sie das Management-Interface Ihres Routers ernsthaft mit dem nackten Arsch an Ihre öffentliche IP-Adresse dängeln?! (oder ähnliches
)
Auf welches Niveau, meinst du denn, müssen sich Firewall Hersteller herablassen für die Konfiguration die ein solch customizebares Produkt vertreiben was ja gerade deshalb verkauft und auch nachgefragt wird ? Vielleicht solltest du hier doch einmal ein klein wenig deine eigene Perspektive wechseln ???
Auch Profis verifizieren doch immer ob ihr Regelwerk wasserdicht ist oder willst du dich auf irgendwelche obskuren, DAU freundlichen Security Modelle der Hersteller verlassen ?
Auf solchen "Rückfrage" Produkten gibt es keine Rückfragen weil Hersteller DAUs aus guten Gründen niemals an so ein Regelwerk lassen. Die müssen dann mit dem des Herstellers leben oder hast du bei einer FritzBox schon einmal gesehen das man dort die Firewall so customizen kann wie du es oben kannst ?!
Du bist doch Netzwerk Profi ! Da sind solche Dinge wie "Sehr geehrter Nutzer..." ganz sicher überflüssig.
Aber genug geschwafelt... Sei ein Profi ! Heul nich, fixe dein Regelwerk und jutt iss... !!
Auch Profis verifizieren doch immer ob ihr Regelwerk wasserdicht ist oder willst du dich auf irgendwelche obskuren, DAU freundlichen Security Modelle der Hersteller verlassen ?
Auf solchen "Rückfrage" Produkten gibt es keine Rückfragen weil Hersteller DAUs aus guten Gründen niemals an so ein Regelwerk lassen. Die müssen dann mit dem des Herstellers leben oder hast du bei einer FritzBox schon einmal gesehen das man dort die Firewall so customizen kann wie du es oben kannst ?!
Du bist doch Netzwerk Profi ! Da sind solche Dinge wie "Sehr geehrter Nutzer..." ganz sicher überflüssig.
Aber genug geschwafelt... Sei ein Profi ! Heul nich, fixe dein Regelwerk und jutt iss... !!
1Du bist doch Netzwerk Profi !
Ich erkenne feine Ironie, wenn ich drüber stolpere!
Jetzt glaube ich ja
a) nicht, dass das MT-Handbuch und vor allem die einleitenden Firewall-Setups "Profis" als Zielgruppe haben.
Und lese
b) jede Woche auf IT-news-Seiten von gut ausgebildeten und bezahlten "Profis", nationaler und internationaler Unternehmen, bei denen eine zusätzlcihe Rückfrage im richtigen Moment ein Desaster verhindert hätte.
Ich - mit meiner Schusslichkeit - bin bestimmt der letzte der da Steine werfen möchte. Vermutlich sind wenig Mikrotiks in so kurzer Zeit so häufig neu aufgesetzt worden. Mittlerweile habe ich auch jede Zugangsmöglichkeit inkl. Console und jede Reset-Option ausgiebigst auf ihre Dauerbelastbarkeit testen dürfen
Guten Abend zusammen,
ich würde gerne nochmals das Layer3-offloading diskutieren.
Ich versuche die eigentliche Funktionsweise zu verstehen. Den einzigen Hinweis finde ich in L3HW Feature Support:
Ich verstehe es so. Für alle CRS300 und CCR2000 gilt:
Bei den DX8000 and DX4000 Series, sowie dem CCR2000 kommen noch zwei Punkte hinzu:
ich würde gerne nochmals das Layer3-offloading diskutieren.
Ich versuche die eigentliche Funktionsweise zu verstehen. Den einzigen Hinweis finde ich in L3HW Feature Support:
This works only for directly connected networks. Since HW does not know how to send ARP requests,
CPU sends an ARP request and waits for a reply to find out a DST MAC address on the first received packet of the connection that matches a DST IP address.
After DST MAC is determined, HW entry is added and all further packets will be processed by the switch chip.
CPU sends an ARP request and waits for a reply to find out a DST MAC address on the first received packet of the connection that matches a DST IP address.
After DST MAC is determined, HW entry is added and all further packets will be processed by the switch chip.
Ich verstehe es so. Für alle CRS300 und CCR2000 gilt:
- neues packet kommt an und geht durch die CPU und durchläuft alles wie in Manual:Packet Flow beschrieben, wenn eine direkte Route in ein benachbartes Netzwerk (VLAN) offen ist, ohne Einschränkungen/Sonderbehandlungen wie z. B. NAT, Queuing, etc. vorgesehen sind, wird ei Route in den Speicher des Switch-Chip eingetragen
- weitere Pakete der gleichen Verbindung gehen nun direkt über den Switch-Chip
- nicht aktive Verbindungen werden aus den Speicher des Switch-Chip entfernt
Bei den DX8000 and DX4000 Series, sowie dem CCR2000 kommen noch zwei Punkte hinzu:
- NAT, z.B. Masquerade
- das Erlernen der NAT Regel erfolgt analog zu allgemeinen Regel 1 oben
- die Übersetzung der IPs bei NAT'd wird in den Switch-Chip eingetragen
- weitere Pakete der gleichen Verbindung gehen nun direkt über den Switch-Chip und ich kann die individuellen IPs aus deinem VLAN bei der Kommunikation mit einem anderem VLAN verbergen
- FASTTRACK. für Verbindungen die nicht mehr über die gleiche Bridge laufen aber nachdem sie ESTABLISHED sind, keine Behandlung durch z. B.Queuing erfahren. Bestes Beispiel ist hier die LAN2WAN-Verbindung.
- das Erlernen der FASTTRACK-Verbindungen erfolgt analog zu allgemeinen Regel 1 oben
- Quell- und Zielschnittstellen der direkt verbundenen Netzwerke wird in den Switch-Chip eingetragen
- weitere Pakete der gleichen Verbindung gehen nun direkt über den Switch-Chip
bzgl. tagged traffic bin ich mir jetzt nicht mehr sicher wenn ich https://forum.mikrotik.com/viewtopic.php?p=910717 lese, sollte aber kommen.
Ich sach mal so (CRS326, ROS7.3.1 stable):
Vielleicht kann das ja jemand bestätigen. Der Support hat dafür nämlich keine Erklärung.
Ich habe im bestehenden Setup (Firewall, NAT, usw.) ein Failover realisieren wollen (LTE), entsprechend der MT-Anleitung: https://help.mikrotik.com/docs/pages/viewpage.action?pageId=26476608
Konnte das - der Anleitung entsprechend zwar nicht abschließen, da ich auf Port 1 kein Koppelnetz nutze ... ABER zufällig habe ich im Anschluss nen Performance-Test gemacht und glaubte meinen Auge nicht.
Vielleicht kann das ja jemand bestätigen. Der Support hat dafür nämlich keine Erklärung.
Ich habe im bestehenden Setup (Firewall, NAT, usw.) ein Failover realisieren wollen (LTE), entsprechend der MT-Anleitung: https://help.mikrotik.com/docs/pages/viewpage.action?pageId=26476608
/ip/firewall/nat
add chain=srcnat action=masquerade out-interface=ether1
add chain=srcnat action=masquerade out-interface=ether2
/routing/table
add fib name=to_ISP1
add fib name=to_ISP2
/ip/firewall/mangle
add chain=output connection-state=new connection-mark=no-mark action=mark-connection new-connection-mark=ISP1_conn out-interface=ether1
add chain=output connection-mark=ISP1_conn action=mark-routing new-routing-mark=to_ISP1 out-interface=ether1
add chain=output connection-state=new connection-mark=no-mark action=mark-connection new-connection-mark=ISP2_conn out-interface=ether2
add chain=output connection-mark=ISP2_conn action=mark-routing new-routing-mark=to_ISP2 out-interface=ether2Konnte das - der Anleitung entsprechend zwar nicht abschließen, da ich auf Port 1 kein Koppelnetz nutze ... ABER zufällig habe ich im Anschluss nen Performance-Test gemacht und glaubte meinen Auge nicht.
Nun, Mangling-Rules sind ein CPU intensives Feature, die eh schon sehr dürftige single Core 32bit CPU des CRS auch noch mit Mangling zu beschäftigen, dazu noch mit Regeln bei denen der Passthrough Parameter fehlt, da fehlt der CPU am Ende eben das letzte Quäntchen das es braucht deinen Anschluss vollständig auszulasten. Jedes zusätzliche Erweiterung über Firewall-Regeln/Mangle-Rules oder Queues werden bei dem Gerät bestraft! Du erwartest einfach zu viel von der Hardware .
.
Hm, das erklärt aber nicht, warum die NAT-Performance ansteigt, wenn ich die Mangle-Rule aktiviere.
Ich sach auch nicht, dass ich es verstehe.
Ich will das ja nur hier dranhängen - falls jemand den Thread findet und die gleichen Probleme hatte wie ich, kann er das ja mal probieren. Ist billiger als Globulis
Ich sach auch nicht, dass ich es verstehe.
Ich will das ja nur hier dranhängen - falls jemand den Thread findet und die gleichen Probleme hatte wie ich, kann er das ja mal probieren. Ist billiger als Globulis
Zitat von @Visucius:
Hm, das erklärt aber nicht, warum die NAT-Performance ansteigt, wenn ich die Mangle-Rule aktiviere.
Wo steht das? Du schreibst oben leider nicht voher / nachher bei welcher Konfiguration welcher Durchsatz, das ist leider ein etwas undurchsichtiger Post, mit einem Bild das man nicht zuordnen kann . Wir haben keine ganze Sicht auf deine Config Hm, das erklärt aber nicht, warum die NAT-Performance ansteigt, wenn ich die Mangle-Rule aktiviere.
. Wenn du das so dem Support geschildert hast kann ich verstehen das der nicht durchblickt.
Hm, transparenter wirds eigentlich nur, wenn man den Beitrag im Kontext zum Thread liest. Wir sind ja hier nicht bei Twitter, sondern in nem Forum!
Ich bin vorher - inkl. fasttrack und hw-offloading l3 - auf ungefähr 540 Mbit/s gekommen und erreiche mit Mangle-rule jetzt, aktuell:
Ich bin vorher - inkl. fasttrack und hw-offloading l3 - auf ungefähr 540 Mbit/s gekommen und erreiche mit Mangle-rule jetzt, aktuell:
Zitat von @Visucius:
Hm, transparenter wirds eigentlich nur, wenn man den Beitrag im Kontext zum Thread liest. Wir sind ja hier nicht bei Twitter, sondern in nem Forum!
Ja , nee offensichtlich manchmal doch.Hm, transparenter wirds eigentlich nur, wenn man den Beitrag im Kontext zum Thread liest. Wir sind ja hier nicht bei Twitter, sondern in nem Forum!
Nur das du dir mal ein Bild machen kannst wie du die Zahlen deines verwendeten "Speed-Diensleisters" einordnen kannst, mal ein Bild von meinem symmetrischen 400MBits UP/DOWN Glasfaser Anschlusses. Der fällt völlig aus dem Rahmen und zeigt vollkommen falsche Werte, ein Test mit meinem dedizierten Root-Server mit garantierte 1GBits Anbindung zeigt korrekte Werte 400 Up/Down, also niemals auf solche "Speed-Anbieter" verlassen sondern selbst messen!
Kann ich hier übrigens auf dem CRS326 aus der Grabbellkiste nicht nachvollziehen. Wäre ja auch ziemlich ungewöhnlich da durch die OUTPUT-Chain nur Traffic den der Router selbst erzeugt (eigene DNS-Abfragen, Ping-Checks, usw.) fliest und kein Traffic den der Client erzeugt.
1
Hm, hast Recht, ist spannend. Weil ja auch der Durchsatz im Laufe des Tests variiert und am Ende die Frage ist, ob Max- oder (gewichtete?) Mittelwerte ausgegeben werden, wieviel parallel-Streams und welche Dateigrößen übertragen werden. Ich habe mit anderen "Tools" auch niedrigere Werte!
Mit nem eigenen Server mit 1 Gbit/s als Gegenstück kann ich leider nicht dienen
Nachdem ich jetzt "Mangle-rule und Konsorten" deaktiviert habe ... sind die Werte aber so oder so wieder gesunken: Testmy.net (FRA), ZACK-AVM
Wie auch immer - vielleicht schaue ich mir das am WE in Ruhe nochmla an. Könnte es ein, dass je nach "Test-Verfahren" ein höherer Anteil durch den Fast-Track läuft?!
Mit nem eigenen Server mit 1 Gbit/s als Gegenstück kann ich leider nicht dienen
Nachdem ich jetzt "Mangle-rule und Konsorten" deaktiviert habe ... sind die Werte aber so oder so wieder gesunken: Testmy.net (FRA), ZACK-AVM
Wie auch immer - vielleicht schaue ich mir das am WE in Ruhe nochmla an. Könnte es ein, dass je nach "Test-Verfahren" ein höherer Anteil durch den Fast-Track läuft?!
