Last time I did vlan setup was with ros 6.39. Now with ros 6.46 I though it would be simplified by the new way of bridge implementation. But I run into trouble.
The goal is to make a RB3011 have the following setup:
eth1: wan-interface (no vlan)
eth2,eth3: tagged vlans 40,41,42,43,44,45,46
eth4: untagged vlan 40
eth5: untagged vlan 41
eth6: untagged vlan 42
eth7: untagged vlan 43
eth8: untagged vlan 44
eth9: untagged vlan 45
eth10: untagged vlan 46
After setting up like I though it should be, I got all the tagged vlans on eth2 and eth3. But none of the untagged ports are just as if they were members of a regular bridge without any vlans defined. And if I connect a device with no vlan defined, even eth2 and eth3 seems to be members of that bridge. I don’t know how to explain this behaviour any better, so I’ll show the config.
With this setup I expected that if I put a pc on eth10 with the ip 172.27.46.2, it would be able to communicate with 172.27.46.1 (routers ip on vlan46). This is not the case. However if I give the pc the address 192.168.88.2 and enable the 192.168.88.1 address, the pc communicates with the router on that address.
Same goes for eth2 and eth3 - if I put the pc with address 192.168.88.2 on eth2 or eth3 - where there should be tagged packets only - it is able to communicate with the router at 192.168.88.1.
What does work is the tagged vlans. Any device connected to eth2 or eth3 using tagged vlan 40-46 communicates with the router on the addresses set on those vlans.
I tried to put ingress-filtering=yes on the bridge, but then the router stopped communicating tagged vlans on eth2 and eth3.
What am I missing for this config?
Thanks!
That was one thing I had missed. It makes sense just like in the old bridge one had to remember to include cpu-port in the switch config. But there must be one more thing I’ve missed:
Adding bridge as tagged interface on all vlans helped for the loss of communication on tagged packages when setting vlan-filtering=yes.
But the communication on the untagged ports are still not working - I suspect they get tagged with vlanid=1 on ingress.
Untagged ports use what they have as pvid. Each vlan is separate interface with different IP subnet, so access to anywhere else would be through routing. I’m not sure what was happening before. But check your firewall, make sure you have correct routes, etc.
This is not firewall related. It is within the bridge/vlan config. (There are no firewall output rule defined, and my test is from the router)
Ports pvid are as show in the config in first post.
Bridge pvid=1. Thats why I suspect packages get vlanid=1 on ingress. (Is there a way to see if that’s actually whats happening?)
So, if the bridge pvid overrules the ports pvid, how should a setup with untagged ports from several vlans look?
A pc with static ip192.168.88.2 is connected to eth9.
If I put ip 192.168.88.1 on vlan45 (which should be untagged on eth9) and ping 192.168.88.2, I get no reply.
If I put the same ip on bridge interface, I get reply.
According to the config the result should have been the other way around. To me it seems like it’s no vlan45 that is untagged at eth9. I have not changed anything in the switch menu. Maybe I should? (I though the idea of the new way to do config was to avoid dealing with vlan in the switch menu)
What is also worth noting is that this configuration disables switch hardware offloading. This setup is very similar to a rb3011 that is running ros 6.39.2. That box show that the hardware is capable of doing this in hw. (This setup has 6vlans doing untagged at 6 ports, the old box has 12 vlans, doing untagged at 4 ports) So it seems like this upgraded ros will increase cpu load.
Please post your entire config, otherwise we cannot provide accurate feedback.
Not sure what proxy settings will do, but since I dont have a clue about them, I dont use them.
/interface bridge
add admin-mac=B8:69:F4:BB:84:71 arp=proxy-arp auto-mac=no comment=defconf name=bridge
/interface vlan settings - no issues
/interface bridge port settings - no issues (trunk ports 2,3, and spf1, rest are access ports with assigned pvids)
(you dont have spf1 assigned to any vlan setting however, future use?)
/interface bridge vlan - as sob says, you need to add bridge in the taggings for all your bridge vlan lines.
/ip address - okay I recommend you get rid of any address on the bridge and just create a new vlan if you need one.
add address=192.168.88.1/24 comment=defconf disabled=yes interface=bridge network=192.168.88.0
(lots of stuff missing needed to ensure your setup is actually useful)
Based on description, there’s something wrong. But I don’t know what. Sharing config could help.
Bridge vlan filtering is (I guess) long-term plan for switch configuration. But on most devices it’s not there yet. It works for basic switching when you bridge all ports together, but add anything “advanced” like vlans and it’s only software.
What I’ve just realized is that setting bridge ingress-filtering=yes | no makes the difference if the router is communicating with pc on eth9 using ip on bridge interface (ingress-filtering=no) or not at all (ingress-filtering=yes). It doesn’t under any circumstances communicate with the pc on eth9 using ip on vlan45. However the pc on vlan45 does show up on network discovery.
Here is the full config after the changes suggested by Sob in first reply of this thread.
(3) These are pretty wide open… (can you narrow them down)
add action=accept chain=input in-interface=vlan40
add action=accept chain=input in-interface=vlan45
(4) Missing the dhcp settings, dhcp-server and dhcp-server network. Without a full config we cannot properly assess!!!
The interfaces in routeros default lists are there just for being there in the default config. I don’t think they block anything.
The 192.168.88.1-address I move between the vlan45- and bridge-interfaces for testing. Just a way for testing ping to the pc with address 192.168.88.2 without putting hands on the pc.
Firewall rules are maxed open to make sure firewall is not stopping any packages when I try to figure why there is no communication to devices that doesn’t have vlan configured.
DHCP is not in use. (Do you guys really set dhcp-server on networks where there are not regular users and no devices running dhcp-clients?)
Please focus on why the vlan config is not working, and not why you would not connect an enduser to this setup.
How about a test where you don’t move the address 192.168.88.1 between different interfaces, but rather configure PC (connected to ether9) with 172.27.45.x ?
Another action (not necessarily out of despair) would be to reset config to factory default and redo config (the parts needed to be done), but taking new default config philosophy into account… your device is running modern ROS but config seems to inherit from a pretty old default. New defaults make much more sense …
It’s the opposite of what you’re seeing. But I just don’t see any difference in config. So for the lack of better ideas, it’s maybe time for variant of magic “turn it off and on again”, i.e. system reset and start from scratch. There’s no reason why it should help, but it wouldn’t be the first time…
Note: This type of configuration should be used on RouterBOARD series devices, this includes RB4xx, RB9xx, RB2011, RB3011, hAP, hEX, cAP and other devices.
That note was under an example of old-way vlan config. I didn’t look at that part before, as I though it was for ros pre 6.41.
So maybe that is my issue, that the RB3011 needs the config to be old style? (only difference from old style is that master-port is managed by putting all ports in a bridge)