Community discussions

MikroTik App
 
User avatar
samea
just joined
Topic Author
Posts: 9
Joined: Tue Jan 31, 2023 7:33 pm

Slow Hex file transfer speed

Fri Mar 10, 2023 9:24 pm

I'm running Mikrotik Hex with RoS v7.8. I have setup where port2 is my desktop PC and port3 is connected to my Thinkcentre home server. I have VLAN enabled on bridge. Both PC and server are located to main-vlan vlan. I have simple VLAN setup with main-vlan containing most of my devices and separate iot-vlan for iot-devices.

My intention is to have network shared directory on server and mount it to my Linux desktop using fstab and sshfs mount. This works fine but the file transfer speed is less than I hoped. Below are my iperf3 results:
iperf3 -c server -p 5201                                                                                   
Connecting to server, port 5201
[  5] local 10.0.10.254 port 46302 connected to 10.0.10.100 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  58.5 MBytes   491 Mbits/sec    0    348 KBytes       
[  5]   1.00-2.00   sec  56.2 MBytes   471 Mbits/sec    0    348 KBytes       
[  5]   2.00-3.00   sec  56.1 MBytes   470 Mbits/sec    0    348 KBytes       
[  5]   3.00-4.00   sec  56.1 MBytes   470 Mbits/sec    0    348 KBytes       
[  5]   4.00-5.00   sec  56.1 MBytes   471 Mbits/sec    0    348 KBytes       
[  5]   5.00-6.00   sec  57.1 MBytes   479 Mbits/sec    0    348 KBytes       
[  5]   6.00-7.00   sec  56.7 MBytes   475 Mbits/sec    0    348 KBytes       
[  5]   7.00-8.00   sec  60.5 MBytes   508 Mbits/sec    0    348 KBytes       
[  5]   8.00-9.00   sec  61.6 MBytes   517 Mbits/sec    0    348 KBytes       
[  5]   9.00-10.00  sec  61.5 MBytes   516 Mbits/sec    0    348 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   580 MBytes   487 Mbits/sec    0             sender
[  5]   0.00-10.02  sec   579 MBytes   484 Mbits/sec                  receiver
So the average seems to be a bit less than 60MB/s. I know that Hex is not a speed demon but I had hoped a bit faster speeds. At least 100MB/s.

RoS 6.x and Ros 7.x
I first got similar results when using RoS 6.x. After reading VLAN enabled bridges and hw offloading, I thought that updating to 7.x would help me here. Something definitely changed since when I ran iperf3 test on RoS 6.x the Hex CPU usage was around 50% when viewed in Tools > Profile. Now the CPU usage barely changes from idle during the test. So hw-offload seems to work? Still, the average transfer speed is pretty much exactly the same.

WLAN test
For comparison I also ran iper3 test over TPLink EAP access point from my laptop to the PC. Here I get similar results to the PC - Server. Perhaps even slightly better:
[  5] local 10.0.10.243 port 45960 connected to 10.0.10.254 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  73.3 MBytes   614 Mbits/sec    0   2.64 MBytes       
[  5]   1.00-2.00   sec  71.2 MBytes   598 Mbits/sec    0   3.00 MBytes       
[  5]   2.00-3.00   sec  65.0 MBytes   545 Mbits/sec    0   3.00 MBytes       
[  5]   3.00-4.00   sec  68.8 MBytes   577 Mbits/sec    0   3.00 MBytes       
[  5]   4.00-5.00   sec  55.0 MBytes   461 Mbits/sec    0   3.00 MBytes       
[  5]   5.00-6.00   sec  70.0 MBytes   587 Mbits/sec    0   3.00 MBytes       
[  5]   6.00-7.00   sec  65.0 MBytes   545 Mbits/sec    0   3.00 MBytes       
[  5]   7.00-8.00   sec  68.8 MBytes   577 Mbits/sec    0   3.00 MBytes       
[  5]   8.00-9.00   sec  68.8 MBytes   577 Mbits/sec    0   3.00 MBytes       
[  5]   9.00-10.00  sec  60.0 MBytes   503 Mbits/sec    0   3.00 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   666 MBytes   558 Mbits/sec    0             sender
[  5]   0.00-10.01  sec   663 MBytes   556 Mbits/sec                  receiver
So is there anything I can do to improve the speed? I have read about fasttrack rules but tbh I am a bit confused on when they truly get activated and what kind of rules I'd need with my VLAN setup.
I guess these speeds are okay to me but I'd like to know if there is some configuration error or option I could enable to gain a bit faster connection.

Finally here is my /export:
/interface bridge
add admin-mac=<mac> auto-mac=no comment=defconf name=bridge pvid=10 vlan-filtering=yes
/interface ethernet
set [ find default-name=ether1 ] comment=WAN
set [ find default-name=ether2 ] comment=PC
set [ find default-name=ether3 ] comment=HomeServer
set [ find default-name=ether4 ] comment=Other
set [ find default-name=ether5 ] comment=WAP
/interface vlan
add interface=bridge name=iot-vlan vlan-id=20
add interface=bridge name=main-vlan vlan-id=10
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
add name=VLAN
add name=MGMT
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=hotspot
/ip pool
add name=main-pool ranges=10.0.10.2-10.0.10.254
add name=iot-pool ranges=10.0.20.2-10.0.20.254
/ip dhcp-server
add address-pool=main-pool interface=main-vlan name=main-dhcp
add address-pool=iot-pool interface=iot-vlan name=iot-dhcp
/port
set 0 name=serial0
/user group
add name=terraform policy=local,read,write,api,!telnet,!ssh,!ftp,!reboot,!policy,!test,!winbox,!password,!web,!sniff,!sensitive,!romon,!rest-api
/interface bridge port
add bridge=bridge comment=defconf frame-types=admit-only-untagged-and-priority-tagged interface=ether2 pvid=10
add bridge=bridge comment=defconf frame-types=admit-only-untagged-and-priority-tagged interface=ether3 pvid=10
add bridge=bridge comment=defconf frame-types=admit-only-untagged-and-priority-tagged interface=ether4 pvid=10
add bridge=bridge comment=defconf frame-types=admit-only-vlan-tagged interface=ether5 pvid=10
/ip neighbor discovery-settings
set discover-interface-list=MGMT
/ipv6 settings
set accept-redirects=no accept-router-advertisements=no disable-ipv6=yes forward=no
/interface bridge vlan
add bridge=bridge comment=main-vlan tagged=bridge,ether5 untagged=ether2,ether3,ether4 vlan-ids=10
add bridge=bridge comment=iot-vlan tagged=bridge,ether5 vlan-ids=20
/interface list member
add comment=defconf interface=ether1 list=WAN
add interface=main-vlan list=LAN
add interface=iot-vlan list=LAN
add interface=main-vlan list=MGMT
/ip address
add address=10.0.10.1/24 interface=main-vlan network=10.0.10.0
add address=10.0.20.1/24 interface=iot-vlan network=10.0.20.0
/ip dhcp-client
add comment=defconf interface=ether1
/ip dns
set allow-remote-requests=yes servers=10.0.10.1,1.1.1.1
/ip dns static
<redacted>
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="Allow main-vlan/MGMT access to all router services" in-interface-list=MGMT
add action=accept chain=input comment="Allow VLAN DHCP" dst-port=67 in-interface-list=LAN log=yes log-prefix=VLANDHCP protocol=udp
add action=accept chain=input comment="Allow VLAN DNS UDP" dst-port=53 in-interface-list=LAN protocol=udp
add action=accept chain=input comment="Allow VLAN DNS TCP" dst-port=53 in-interface-list=LAN protocol=tcp
add action=drop chain=input comment="Drop all other traffic"
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="Block internet access for clients" log=yes log-prefix="Block internet" out-interface-list=WAN src-address-list=\
    "Block internet access"
add action=accept chain=forward comment="VLAN Internet Access Only" connection-state=new in-interface-list=LAN log-prefix="VLAN ACCESS" out-interface-list=\
    WAN
add action=accept chain=forward comment="Allow access to IoT devices from main-vlan" in-interface=main-vlan out-interface=iot-vlan src-address-list=\
    "Access IoT devices"
add action=accept chain=forward comment="Allow MQTT to HA" dst-address=10.0.10.251 dst-port=1883 protocol=tcp src-address-list=\
    "MQTT traffic to main-vlan HA"
add action=accept chain=forward comment="TF: Allow Wireguard traffic" dst-port=51820 fragment=no in-interface=ether1 log=yes log-prefix=Wireguard \
    out-interface=main-vlan protocol=udp
add action=drop chain=forward comment="Drop all other traffic" log=yes log-prefix="Drop all forward"
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment="TF: Port forward Wireguard to PiVPN" dst-port=51820 fragment=no in-interface-list=WAN protocol=udp to-addresses=\
    10.0.10.51 to-ports=51820
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set api disabled=yes
set api-ssl address=10.0.10.0/24 certificate=terraform
/ip ssh
set strong-crypto=yes
/ipv6 firewall filter
add action=drop chain=input comment="Drop all" log=yes log-prefix=IPV6
add action=drop chain=forward comment="Drop all" log=yes log-prefix=IPV6
/system clock
set time-zone-name=Europe/Helsinki
/system identity
set name=RouterOS
/system ntp client
set enabled=yes
/tool bandwidth-server
set enabled=no
/tool graphing interface
add allow-address=10.0.10.0/24 interface=main-vlan
add allow-address=10.0.10.0/24 interface=iot-vlan
/tool graphing resource
add allow-address=10.0.10.0/24
/tool mac-server
set allowed-interface-list=none
/tool mac-server mac-winbox
set allowed-interface-list=MGMT
/tool mac-server ping
set enabled=no

 
User avatar
k6ccc
Forum Guru
Forum Guru
Posts: 1490
Joined: Fri May 13, 2016 12:01 am
Location: Glendora, CA, USA (near Los Angeles)
Contact:

Re: Slow Hex file transfer speed

Fri Mar 10, 2023 10:20 pm

Disclaimer: I am SERIOUSLY WEAK on bridges in RouterOS (I don't use them at all), so take this with a grain of salt.

However unless I missed it (cause I don't know where to look), you are not hardware offloading the bridge. That means that all traffic - even on the same VLAN,on the bridge - has to go through the CPU. That makes it far slower. Assuming that the Hex has the ability to offload the bridge to the switch chip, it will be far faster. Sorry, I can't really tell you how to set that up. Hopefully that give you a place to look.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11381
Joined: Thu Mar 03, 2016 10:23 pm

Re: Slow Hex file transfer speed

Fri Mar 10, 2023 11:01 pm

However unless I missed it (cause I don't know where to look), you are not hardware offloading the bridge.

Config looks fine to me. I don't have any idea why it doesn't perform wirespeed.
The fact that it's possible to get around 0.5Gbps of throughput without any noticeable CPU load tells that very likely config is HW offloaded. To verify, check output of
/interface bridge port print
. Each port, which is HW offloaded, has a 'H' flag shown in column #2.
 
User avatar
samea
just joined
Topic Author
Posts: 9
Joined: Tue Jan 31, 2023 7:33 pm

Re: Slow Hex file transfer speed

Sat Mar 11, 2023 12:22 am

Yes, looks like all of the ports are HW offloaded:
Flags: I - INACTIVE; H - HW-OFFLOAD
Columns: INTERFACE, BRIDGE, HW, PVID, PRIORITY, PATH-COST, INTERNAL-PATH-COST, HORIZON
#    INTERFACE  BRIDGE  HW   PVID  PRIORITY  PATH-COST  INTERNAL-PATH-COST  HORIZON
;;; defconf
0  H ether2     bridge  yes    10  0x80             10                  10  none   
;;; defconf
1  H ether3     bridge  yes    10  0x80             10                  10  none   
;;; defconf
2 IH ether4     bridge  yes    10  0x80             10                  10  none   
;;; defconf
3  H ether5     bridge  yes    10  0x80             10                  10  none   
Is there possibility that firewall rules somehow slow it down? I'm using couple of address lists in my rules though the lists itself are small. Just couple of entries in each to forbid some devices to connect wan etc. My ethernet cables are cat5e and disks are SSD. It is quite possible that the problem is somewhere else than in the router but need some pointers where to start looking for.

Edit: I ran the test with all FW rules disabled (WAN disconnected) and the results were same.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Slow Hex file transfer speed

Sat Mar 11, 2023 2:44 am

The config is not correct............

(1) WRONG
/interface bridge
add admin-mac=<mac> auto-mac=no comment=defconf name=bridge pvid=10 vlan-filtering=yes


CORRECT
/interface bridge
add admin-mac=<mac> auto-mac=no comment=defconf name=bridge vlan-filtering=yes


(2) WRONG
/interface bridge port
add bridge=bridge comment=defconf frame-types=admit-only-untagged-and-priority-tagged interface=ether2 pvid=10
add bridge=bridge comment=defconf frame-types=admit-only-untagged-and-priority-tagged interface=ether3 pvid=10
add bridge=bridge comment=defconf frame-types=admit-only-untagged-and-priority-tagged interface=ether4 pvid=10

add bridge=bridge comment=defconf frame-types=admit-only-vlan-tagged interface=ether5 pvid=10


CORRECT
/interface bridge port
add bridge=bridge comment=defconf frame-types=admit-only-untagged-and-priority-tagged interface=ether2 pvid=10
add bridge=bridge comment=defconf frame-types=admit-only-untagged-and-priority-tagged interface=ether3 pvid=10
add bridge=bridge comment=defconf frame-types=admit-only-untagged-and-priority-tagged interface=ether4 pvid=10

add bridge=bridge comment=defconf frame-types=admit-only-vlan-tagged interface=ether5


(3) Dont need VLAN interface list you can remove it.
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN

add name=VLAN
add name=MGMT


(4) Why do you have this rule ????
add action=accept chain=input comment="Allow VLAN DHCP" dst-port=67 in-interface-list=LAN log=yes log-prefix=VLANDHCP protocol=udp

(5) Firewall rules need work.
add action=drop chain=forward comment="Block internet access for clients" log=yes log-prefix="Block internet" out-interface-list=WAN src-address-list=\
"Block internet access"
add action=accept chain=forward comment="VLAN Internet Access Only" connection-state=new in-interface-list=LAN log-prefix="VLAN ACCESS" out-interface-list=\
WAN


BETTER (replace both with)
add action=accept chain=forward comment="authorized internet access" in-interface-list=LAN src-address-list=!"Block internet access" out-interface-list=WAN

(6) What are you doing with a wirgeguard rule.........it makes NO SENSE!
add action=accept chain=forward comment="TF: Allow Wireguard traffic" dst-port=51820 fragment=no in-interface=ether1 log=yes log-prefix=Wireguard \
out-interface=main-vlan protocol=udp


PLUS you have no wireguard interface
PLUS you have no wireguard peer settings.

a. to allow handshake is an input chain rule
b. to allow remoteuser to configure router is input chain rule using wg interface name
c. to allow access to subnets via wireguard is a forward chain rule using wg interface name.

GET RID OF IT!!!
 
User avatar
samea
just joined
Topic Author
Posts: 9
Joined: Tue Jan 31, 2023 7:33 pm

Re: Slow Hex file transfer speed

Sat Mar 11, 2023 10:01 am

Thanks for corrections anav.

1-4. Fixed.
5. This is clever, thanks.
6. I'm using Terraform to spin up Wireguard container to my home server infrastructure so I'm not using RoS7 wireguard. Thus config is different. Might consider using RoS WG in future though.

For speed debug I did some more tests and I suppose the problem is not in the router. Still any advice is welcome.
  • Iperf3 PC -> Server speed is ~60MBytes/s
  • Iperf3 Server -> PC speed is ~95MBytes/s
  • Iperf3 Laptop (wifi) -> Server ~67MBytes/s
  • Iperf3 Server -> Laptop (wifi) ~60MBytes/s
  • Iperf3 Laptop (wired) -> Server >110MBytes/s
  • Iperf3 Server -> Laptop (wired) -> ~93MBytes/s
  • Iperf3 Laptop (wifi) -> PC ~67MBytes/s
  • Iperf3 PC -> Laptop (wifi) ~47MBytes/s
 
User avatar
Buckeye
Forum Veteran
Forum Veteran
Posts: 883
Joined: Tue Sep 11, 2018 2:03 am
Location: Ohio, USA

Re: Slow Hex file transfer speed

Sat Mar 11, 2023 10:54 am

As pointed out by @anav, you are giving the hEX mixed messages about whether vlan 10 should be tagged or untagged. ROS assumes you know what your are doing, and provides very little hand holding in the configuration, it won't even generate warnings sometimes. And his advice should work as long as you do want ether5 to use tagged frames on the wire to/from the WAP for vlan 10.

The bridge base device would normally have pvid 1 when it is not specified, and untagged traffic it receives from the switch ASIC will be delivered to the bridge interface. Since you don't have any ip address associated with the bridge device, and you do have an /interface vlan for vlan 10, traffic received from the switch ASIC with vlan 10 tag would normally be delivered to the interface you named main-vlan, but because you also set the pvid to 10 on ether5 (but are blocking untagged frames) I am not sure exactly what it is doing. If it is working except for not getting the performance you were expecting, I can only guess that it is sending tagged frames for vlan 10 out of ether5. Even though the pvid is set to 10 on ether5, and if would normally then send traffic out ether5 untagged for vlan 10, since you explicitly told it to use tagged on ether5 in the / following the normal rule of untagging the traffic egressing for a vlan that matches the pvid of the port.

So, start by verifying what you expect traffic for vlan 10 to be handled on ether5. Does the WAP expect tagged traffic for vlan 10, or untagged traffic for vlan 10?

And if you are going to create a vlan interface for vlan 10 (i.e. main-vlan), then you should not use the same vlan as the pvid on the bridge. If you are not going to use an ip address on the bridge device, just make sure that the vlan associated with the bridge device isn't used elsewhere. You can leave it at one, or you could specify a high vlan that isn't going to be used anywhere, e.g. like 4094 or some other high vlan that you don't plan to use anywhere else. Or better also set the bridge to accept only tragged frames, then nothing will leak through to the base bridge interface input even if an ip address was there.
Bridge PVID and frame type.png

In the following the highlighted things in same color are the "contradictory instructions" you are giving the hEX.

/interface bridge
add admin-mac=<mac> auto-mac=no comment=defconf name=bridge pvid=10 vlan-filtering=yes
/interface vlan
add interface=bridge name=main-vlan vlan-id=10
/interface bridge port
add bridge=bridge comment=defconf frame-types=admit-only-vlan-tagged interface=ether5 pvid=10
/interface bridge vlan
add bridge=bridge comment=main-vlan tagged=bridge,ether5 untagged=ether2,ether3,ether4 vlan-ids=10
You do not have the required permissions to view the files attached to this post.
Last edited by Buckeye on Sun Mar 12, 2023 2:36 am, edited 1 time in total.
 
User avatar
samea
just joined
Topic Author
Posts: 9
Joined: Tue Jan 31, 2023 7:33 pm

Re: Slow Hex file transfer speed

Sat Mar 11, 2023 12:06 pm

Thanks @Buckeye for explanation. I had some misconception on should the bridge have vlan tag or not. My WAP is configured to only communicate with tagged frames (10, or 20). My idea was that all communication should be in either vlan 10 or 20. I think I'll use pvid 1 for bridge for now.

I set the bridge to admit only VLAN tagged frames as you suggested.

As for the rules, if I understood the "contradictionary rules" you pointed out correctly, this config then should be ok?
/interface bridge
add admin-mac=<mac> auto-mac=no comment=defconf frame-types=admit-only-vlan-tagged name=bridge vlan-filtering=yes
/interface bridge port
add bridge=bridge comment=defconf frame-types=admit-only-vlan-tagged interface=ether5
/interface bridge vlan
add bridge=bridge comment=main-vlan tagged=bridge,ether5 untagged=ether2,ether3,ether4 vlan-ids=10
Fyi, no change in transfer performance but I really appreciate pointing out the other config mistakes and explanations behind them!
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Slow Hex file transfer speed

Sat Mar 11, 2023 1:47 pm

The only thing the bridge needs is vlan-filtering=yes, there is no reason to put frame types, that is done on bridge ports.
 
User avatar
baragoon
Member Candidate
Member Candidate
Posts: 294
Joined: Thu Jan 05, 2017 10:38 am
Location: Kyiv, UA
Contact:

Re: Slow Hex file transfer speed

Sat Mar 11, 2023 2:03 pm

The only thing the bridge needs is vlan-filtering=yes, there is no reason to put frame types, that is done on bridge ports.
May I ask a stupid question?
I'm currently "playing" with VLANs on my Tiks... so bridge interface should be PVID=1 (as by default) untagged? And VLANs section of brigde shows VLAN1 as dynamic?
Thanks.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11381
Joined: Thu Mar 03, 2016 10:23 pm

Re: Slow Hex file transfer speed

Sat Mar 11, 2023 2:36 pm

so bridge interface should be PVID=1 (as by default) untagged? And VLANs section of brigde shows VLAN1 as dynamic?

It's not "should". But it's IMO a very good practice to have bridge interface (which is a "gateway" between CPU and the rest of LANs) configured as trunk port and hence all IP setup goes to vlan interfaces (anchored to bridge interface) without exception. Having set pvid on bridge means that one of VLANs (often confusingly called "native VLAN") should be treated as if there was no VLANs (i.e. set IP address on bridge interface directly).

PVID=1 setting is default and if one tries to use same VID explicitly without doing things 100% correctly it will act sporadically ... in same scenario using different PVID/VID will break things more clearly giving chance to fix things easier. And those default settings aren't shown in text export ... even if one tries to set things to same values explicitly.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Slow Hex file transfer speed

Sat Mar 11, 2023 5:56 pm

I have no clue what you just said or recommended.
Set bridge to vlan-filtering=yes works and causes no issues.
If you want to be anal and correct
then assign ingress filtering on every bridge port (except hybrid ports)
then assign frame types allowed specific to trunk ports and access ports ( hybrid gets all frames).

Nothing ambiguous about that and as per pcunite's advice - viewtopic.php?t=143620

My question yet unanswered to any satisfaction is what about the ingress filtering checkbox on the bridge
a. should that be checked.
b. what does it do
c. how is it related to ingress filtering on each /interface bridge port line.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11381
Joined: Thu Mar 03, 2016 10:23 pm

Re: Slow Hex file transfer speed

Sat Mar 11, 2023 6:29 pm

My question yet unanswered to any satisfaction is what about the ingress filtering checkbox on the bridge
a. should that be checked.
b. what does it do
c. how is it related to ingress filtering on each /interface bridge port line.

It's about bridge port - the one that allows CPU/ROS to interact (via bridge interface) with (V)LAN(s) passing bridge (the switch-like entity). So if you construct multiple vlan interfaces, anchored to bridge (as in /interface vlan add name=anavsitches interface=bridge vlan-id=666) but not all vlans are allowed to pass the port on L2 (i.e. bridge is not set as neither tagged nor untagged member of some, e.g. vlan 666), then bridge port (the entity which extrudes from bridge the switch like entity towards ROS/CPU) will block those packets from being injected into bridge the switch like entity.
And this has nothing to do with settings of other bridge ports.

You can see it as feature protecting bridge switch-like entity (configured by @anav) from being breached by bridge the interface (configured by @anav at some other occasion when he was in another state of mind). You see, @anav and @anav sometimes contradict each other :-P
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Slow Hex file transfer speed

Sat Mar 11, 2023 8:48 pm

No capiche! Sorry. Zilcho Nada, this is what I read....

אין לי מושג מה אתה מנסה להגיד.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11381
Joined: Thu Mar 03, 2016 10:23 pm

Re: Slow Hex file transfer speed

Sat Mar 11, 2023 9:00 pm

I'm sorry, but somebody else will have to explain it to you in Hebrew, I'm not fluent in it.

Perhaps it would help you if you revisited explanation of bridge mysteries by @sindy?
 
User avatar
Buckeye
Forum Veteran
Forum Veteran
Posts: 883
Joined: Tue Sep 11, 2018 2:03 am
Location: Ohio, USA

Re: Slow Hex file transfer speed

Sun Mar 12, 2023 12:13 pm

No capiche! Sorry. Zilcho Nada, this is what I read....

אין לי מושג מה אתה מנסה להגיד.
Google translated that for me. "I have no idea what you are trying to say."

Read this: From Bridging and Switching Case Studies -> Bridge VLAN Table -> Background which is a glossary of terminology. Then look at Trunk/Access port setup (note this is really worth a read if you want to understand the vlan-filtering bridge. I think it is reasonably easy to follow as long as you understand how vlans work. It has some examples with a router as a separate entity and also an example where the bridge PVID is set 30 and ether3 given untagged access. The base bridge interface uses untagged on the "internal trunk" between the CPU and the Switch for the vlan that the bridge has its PVID set to. For example, in the following snippet untagged traffic from the bridge interface will be mapped to vlan 30 in the switch ASIC. From the switch ASIC, packets for vlan 30 could leave other bridge ports either untagged or tagged. In this example ether3 is an access port for vlan 30, and it will be "connected" to the base bridge1 interface (which has pvid 30) and is using untagged traffic between the switch ASIC and the CPU.

/interface bridge set [find name=bridge1] pvid=30
/interface bridge vlan set [find vlan-ids=30] untagged=bridge1,ether3

Just before the Diagram with bold title "Without Ingress Filtering" you will find the following:
preventing use untagged traffic on bridge.png
I agree in this case it is probably being paranoid, and it is a belt and suspenders solution, since the bridge has no ip address on it anyway.

A downside of this is that it makes it easier to lock yourself out when switching to vlan-filtering.
You do not have the required permissions to view the files attached to this post.
Last edited by Buckeye on Fri May 12, 2023 11:10 pm, edited 1 time in total.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Slow Hex file transfer speed

Sun Mar 12, 2023 1:27 pm

My questions yet unanswered (when using vlan-filtering=yes as per pcunite's work)
to any satisfaction is what about the ingress filtering checkbox on the bridge
a. should that be checked.
b. what does it do
c. how is it related to ingress filtering on each /interface bridge port line.
d. how is it related to frame type settings on each /interface bridge port line.
 
User avatar
Buckeye
Forum Veteran
Forum Veteran
Posts: 883
Joined: Tue Sep 11, 2018 2:03 am
Location: Ohio, USA

Re: Slow Hex file transfer speed

Sun Mar 12, 2023 2:07 pm

My question yet unanswered to any satisfaction is what about the ingress filtering checkbox on the bridge
a. should that be checked.
b. what does it do
c. how is it related to ingress filtering on each /interface bridge port line.
My interpretation, stealing the graphic from @sindy
Bridge PVID, frame-type and ingress filtering.png
Consider if you had a Router with a dedicated routed port, perhaps on a RouterOS x86. And you want to have multiple subnets, so you create vlan interfaces on the eth port and connect it to a switch.

The base ethernet will still have a linux interface associated with it, and traffic coming from the ethernet base interface will not be tagged with any vlan, in fact there is no vlan. However when you connect this to a vlan-aware switch, that traffic will be "mapped" into one vlan on the switch, whatever vlan the switch's port has its pvid set to. When you create vlan interfaces anchored to the ethernet interface, traffic from those vlan interfaces will be tagged with the vlan specified when creating the vlan interface.

What if you didn't want any traffic "leaking" from the ethernet base port into the switch? One way would be to block all traffic without a tag by using frame-type filtering on the switch port. Likewise if you created a vlan interface for vlan 666 on the router, but didn't have any vlan 666 defined on any port on the switch, using ingress filtering on the trunk port will drop the frame as soon as it arrived at the switch-port.

When the interface is a bridge device on the router instead of an ethenet port, I think creating the vlan interface will allow tagged frames to be sent to the switch. Until you add a bridge vlan to the "trunk" with the /interface bridge vlan ... tagged=bridge ... vlan-ids=#, the switch port connecting to the CPU port won't have the vlan configured on the switch-port, but the switch-port could still receive a frame tagged with the vlan. So I think traffic could leak into the switch's vlan, but any return traffic won't be allowed back (because the vlan isn't configured on the "switch-port to the CPU" I suppose this could be tested in a lab, but I don't have time right now.

In summary:

a. I can't think of any reason checking ingress filtering would break anything (other than "asymmetric vlans" where SVL must be used, and there are better ways to achieve "isolated ports" than using asymmetric vlans).
b. it prevents frames tagged with a vlan and arriving as ingress to the switch-port from the CPU-port from being accepted if the switch-port is not a member of the vlan (I think this corresponds to the switch feature vlan-mode=secure).
c. it is always an "ingress" feature. it just applies to the switch-port that doesn't have an external physical port associated with it, the switch port that is connected to the "internal" trunk link to the CPU.
d. the unasked question. What does frame-type do on the "bridge". I think this really applies to the switch-port side, e.g. it can block untagged frames from entering the switch. As I typed this, it makes me wonder it if could affect spanning tree protocol. Does anyone know? For example on the hEX, I think any spanning tree is done by the CPU.
You do not have the required permissions to view the files attached to this post.
Last edited by Buckeye on Tue Apr 25, 2023 10:01 pm, edited 5 times in total.
 
User avatar
Buckeye
Forum Veteran
Forum Veteran
Posts: 883
Joined: Tue Sep 11, 2018 2:03 am
Location: Ohio, USA

Re: Slow Hex file transfer speed

Sun Mar 12, 2023 2:10 pm

That's funny. I had not seen @anav's latest post, when I just posted. it wasn't what I quoted. I quoted post #13.

But I think my answer d matched his question.

BTW, @sindy's excellent RouterOS bridge mysteries explained post has the following:

However, I think the following section

In particular:
  • parameters bearing the same names as those on the /interface bridge port rows, such as pvid or ingress-filtering, are parameters of the router-facing port of the virtual switch
  • parameters bearing the same names as those on the /interface ethernet rows, such as mtu or arp-timeout, are parameters of the switch-facing interface of the router
  • parameters that don’t fit to any of the two groups above are mostly parameters of the virtual switch; an exception are the admin-mac and auto-mac parameters, which are also parameters of the switch-facing interface of the router.
should be changed to:

In particular:
  • parameters bearing the same names as those on the /interface bridge port rows, such as pvid, ingress-filtering or frame-types, are parameters of the external ports of the virtual switch and apply to ingress traffic entering the virtual switch from external devices.
  • parameters bearing a vlan-ids=<vlan #> /interface bridge vlan rows, such as tagged=<interface(s)> or untagged=<interface(s)>, are parameters of either the the external ports of the virtual switch or to the router-facing port of the virtual switch and apply to egress traffic leaving the virtual switch to external devices or to the Router. Note that all traffic from the switch to the router (the bridge interface) must be tagged, with the exception being the pvid of the bridge interface itself with is untagged.
  • parameters on the bridge definition line i.e the /interface bridge row, such as pvid, ingress-filtering or frame-types, are parameters of the router-facing port of the virtual switch and apply to ingress to the switch entity from the CPU port of the router.
  • parameters bearing the same names as those on the /interface ethernet rows, such as mtu or arp-timeout, are parameters of the switch-facing interface of the router
  • parameters that don’t fit to any of the two groups above are mostly parameters of the virtual switch; an exception are the admin-mac and auto-mac parameters, which are also parameters of the switch-facing interface of the router.
And perhaps the "switch ports" on the right side of the graphic should be changed to blue
router_and_switch_schematic (blue).png
You do not have the required permissions to view the files attached to this post.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11381
Joined: Thu Mar 03, 2016 10:23 pm

Re: Slow Hex file transfer speed

Tue Apr 25, 2023 4:19 pm

What if you didn't want any traffic "leaking" from the ethernet base port into the switch?
It's always up to proper configuration of device to make sure traffic in egress is correct. So in this particular case, where there's no bridge/switch between L3 of device and physical port, it should be enough if physical port is not used directly as interface (e.g. if we're talking about etherX and there are a few vlan interfaces anchored to etherX, one should not set IP address on etherX).

If the port is member of a bridge, then it's always possible to configure bridge to do proper filtering ... and remember, bridge interface is access port to VLAN ID 1 by default (it has pvid=1 set), which means it should be enough to set port as trunk (tagged only) and to make sure port is not member of VLAN 1.

Basically, I've problem understanding what is your dilemma here?
When the interface is a bridge device on the router instead of an ethenet port, I think creating the vlan interface will allow tagged frames to be sent to the switch. Until you add a bridge vlan to the "trunk" with the /interface bridge vlan ... tagged=bridge ... vlan-ids=#, the switch port connecting to the CPU port won't have the vlan configured on the switch-port, but the switch-port could still receive a frame tagged with the vlan. So I think traffic couuld leak into the switch's vlan, but any return traffic won't be allowed back (because the vlan isn't configured on the "switch-port to the CPU" I suppose this could be tested in a lab, but I don't have time right now.
There's /interface/bridge/port property ingress-filtering ... if enabled, then on ingress port will reject frames belonging to VLANs of which port is not member. And this is true also for the router-facing port of the switch (which is, unluckily, also named "bridge"). So if one sets set [ find name=bridge ] ingress-filtering=yes, then bridge (the switch-like entity) will reject to accept frames from bridge (the switch-facing interface of the router) if the VLAN tag has "wrong" ID set.
d. the unasked question. What does frame-type do on the "bridge". I think this really applies to the switch-port side, e.g. it can block untagged frames from entering the switch. As I typed this, it makes me wonder it if could affect spanning tree protocol. Does anyone know? For example on the hEX, I think any spanning tree is done by the CPU.
Exactly. The problem with xSTP is that xSTP is a L2 "thing" ... so when a bridge does xSTP, it'll directly use bridge ports without going through the L3 or VLAN logic. Except for MSTP, which is VLAN aware.

Who is online

Users browsing this forum: h1ghrise, lifeboy, RobertsN and 52 guests