Hi. I’m trying to get my feet wet in VLANs, and for right now I’m trying to do something I thought would be really simple and it’s just not working.
The initial state of my router is pretty simple: a bridge named mainBridge has ether2-ether8 assigned to it. ether1 is WAN, and masquerading is set up in a simple home network configuration. The bridge is set up with default rules, PVID set 1 on all bridge ports. There are no VLANS.
What I want to do is simple: I want to shave off ether3 into a VLAN and setup a DHCP server on that VLAN it. That’s it. All I want to do is to be able to plug into that port and do nothing more than get a different IP address from a different pool.
Here’s what I tried:
Create a Layer 2 VLAN on the bridge with ID 2 and tag it for untagged egress from ether3
/interface bridge vlan add bridge=mainBridge vlan-ids=2 untagged=ether3
Create a new Layer 3 VLAN interface on mainBridge with ID 2
/interface vlan add name=rentalVLAN vlan-id=2 interface=mainBridge
Assign the Layer 3 VLAN interface an IP address and network
/ip address add address=192.168.102.1/24 interface=rentalVLAN
Create a new IP pool
/ip pool add name=rentalHDCPIPPool ranges=192.168.102.100-192.168.102.254
Create a new HDCP network
/ip dhcp network add address=192.168.102.0/24 gateway=192.168.102.1 dns-server=192.168.102.1
Create a new HDCP server on the VLAN interface
/ip dhcp add name=rentalHDCP interface=rentalVLAN address-pool=rentalHDCPIPPool
Drop all packets from one network to the other
/interface bridge set mainBridge vlan-filtering=yes
The moment of truth, set my port to PVID2
/interface bridge port set [find interface=ether3] pvid=2
But as soon as I do the last step, I lose all connection to the router, even via MAC address and must move my Ethernet cable to another port to recover.
If you did the last step while being connected to your router via ether3, then that’s expected. Because at that point ether3 becomes member of VLAN 2 while all of your generic stuff (including management access) is configured for VLAN 1.
And a gotcha: PC doesn’t know it moved to another ethernet broadcast domain because its physical connectivity did not break. If you disconnect network cable for a few seconds and connect it back, then it should receive IP configuration, relevant for VLAN 2. If it doesn’t, then please post actual resulting config to verify that everything is done correctly. Open terminal window, execute /export hide-sensitive file=anynameyouwish, fetch resulting file, open it in text editor, redact any remaining sensitive information such as serial number, WiFi passwords, public IP address) and copy-paste it here inside code block ( icon in button ribbon when editing a post).
I see that you configure eth2 with pvid, but eth3 not. While both are configured on the /bridge/port/vlan. Think you should at least have this corrected. Besides that, I don’t see any reason why it is not working. Anything in the log?
don’t add VLAN interface (anchored on the bridge) back to bridge, that would create a nasty loop (and is detected as error in most recent ROS versions)
add pvid to ether3 if you want to make that port untagged member of VLAN 2
the show stopper: add mainBridge interface to list of tagged ports:
/interface/bridge/vlan
set [ find vlan-id=2 ] tagged=mainBridge
This interface needs to be tagged member of VLAN 2 as you are creating vlan interface VLAN_Interface anchored to mainBridge interface
Yes, it does sound confusing, but bridge has multiple personalities. You can find out more by going through this great tutorial.
A note: MAC access for management of device (great as backup access using winbox - MAC connectivity) is only allowed via interfaces, members of LAN interface list. The same interface list is used quite extensively in firewall config. However, interface list membership has to be maintained manually. So you may want to add the VLAN_Interface interface to that interface list. After you get your VLAN setup up to speed (and you verify it does work as intended), you will probably want to remove mainBridge interface from that list.
Hint, do all your vlan and bridge configuration OFF BRIDGE.
Take an unused port give its own IP address like 192.168.55.1/24 interface=etherX network=192.168.55.0
Then change ipv4 setting on your computer to anything within the subnet 192.168.55.XX and you will have access…
Sorry for the delayed reply, it was my bedtime. 4:29AM here =)
erlinden/mkx:
The reason I have both ether2 and ether3 that way is because during testing I’ve been moving my ethernet cable back and forth between the two cables. I can set the PVID of ether2 to 2, lose connection, move my cable to ether3, set ether2 back to pvid 1, make some changes, then set ether3 to pvid 2 to test again, then repeat the other direction.
mkx:
Thanks for smacking me on the head, I should have done that first. I checked the log. I’m getting “defconf offering lease 192.168.1.251 for [my mac address]”. For whatever reason, my packets are arriving at 192.168.1.0/24 and not 192.168.102.0/24.
mkx:
Thanks. I didn’t originally have the port added, but when it didn’t work I went ahead an added it wondering if that might fix it. I’ve taken it out. Just to be clear, I removed:
/interface bridge port
add bridge=mainBridge comment=defconf frame-types=\
admit-only-untagged-and-priority-tagged interface=ether2 pvid=2
I have added
/interface/bridge/vlan
set [ find vlan-id=2 ] tagged=mainBridge
but I am still getting "defconf offering lease 192.168.1.251 for [my mac address]". (It’s still seeing Ether2 on the 192.168.1.0/24 subnet instead of 192.168.102.0/24 subnet).
you don’t have dhcp network settings for either IP subnets … I wonder how any of DHCP clients can get usable lease?
why this firewall rule?
add action=drop chain=input dst-address=192.168.102.1 in-interface=VLAN_Interface
I already mentioned importance of LAN interface list … and this firewall rule is one of those places:
add action=drop chain=input comment=“defconf: drop all not coming from LAN” in-interface-list=!LAN
etc.
If you haven’t already, you may want to read this nice tutorial about VLANs in ROS (hopefully you do understand basic principles of VLANs).
I wanted to see if the problem was that ingress traffic from was not making it to the VLAN_Interface or if it was because the defconf DHCP server was responding on VLAN_Interface. It seems like the traffic is not ever making it VLAN_Interface. I don’t know if this is because the traffic is not getting tagged or because tagged traffic is not being directed to VLAN_Interface. After adding this, defconf is still responding to the DHCP request instead of VLAN_HDCP so AFAIK traffic is never making it to VLAN_Interface. Regardless, it was just a debugging thought. I’ve removed it.
I tried disabling that rule, but nothing changed. I went ahead and added VLAN_Interface to LAN, but that didn’t change the behavior either. I’m a bit confused by this: if the VLAN_Interface is on mainBridge, do I still have to add VLAN_Interface to LAN?
Yes, I did find and read that tutorial, but I’m still having problems. =( I’m starting to think there is something more basic that is wrong because the traffic just doesn’t ever make it to VLAN_Interface. In fact, I just now pulled up the Interface List window and notice that there is 0 data flowing thorough VLAN_Interface, but I don’t know why. When I ping 192.168.102.1, it works, which is bizzare, especially because the traffic still shows as zero even while the pinging is working.
When talking about firewall, only interfaces with assigned IP addresses matter … In your case that’s interface named VLAN_Interface for traffic in VLAN 2 and interface named mainBridge for traffic in VLAN 1 (default config has pvid=1 all over the place a d if you don’t override this with some other settings, then whatever might seem untagged is actually VLAN 1). Interface list membership is not inherited, if you anchor vlan interface to another (trunk) interface, without explicit configuration it isn’t member of any interface list.
This doesn’t mean anything, router will reply when any of its IP addresses are pinged, ingress interface doesn’t matter. However, properly working VLAN setup would end up with DHCP lease for intended VLAN/IP subnet. But incomplete DHCP setup may create confusion about the actual problem.
Interface list membership is not inherited, if you anchor vlan interface to another (trunk) interface, without explicit configuration it isn’t member of any interface list.
Ah, that’s a huge misunderstanding on my part! Thanks!
The confusion comes because bridge has multiple personalities (read more about bridge mysteries).
I did read that, to be honest I’m still trying to wrap my head around it, but if I understand correctly, tagged traffic from the router has to egress to the
built in switch before it can egress to an Ethernet port, and that’s why it’s required, yes?
Does the second entry (which is for VLAN 2) have netmask defined? It’s not shown in your latest post …
I must say that it’s a RPITA working through this thread … with you either not providing information or redacting too much (one example is bridge MAC … not necessary to redsct it since nobody can use unless they are already connected to your LAN … this particular example doesn’t really matter but does illustrate your will to hide things which you don’t know whether they’re important or not). I’m slowly loosing all good will to help you in this thread.
The concept of bridge in ROS has nothing to do with hardware … it’s the same also on devices without switch chips (e.g. CCR1xxx). So you have to try to understand the concept. And layering (e.g. port vs. interface), the two major functions of bridge (interface which allows CPU to interact with connected devices vs. switch-like device which connects ports), the different details of each of these functions, how they interact, what part of bridge config is actually about which detail. Etc.
So if you plug your PC to ether2 (or ether3), which is configured with pvid=2, verify what do DHCP settings look like? Are values as they should be? Ideally you should run wireshark on your PC and capture packets belonging to DHCP handshake.
I might have spoken too soon, I think there is a change but I’m out on the town and remoting in by phone so it might take me a bit to figure out whats going on exactly.
edit: behavior changes, but still not what’s expected. it got an IP, but was 192.254.64.71?
I can’t do more until I get home.
thanks for all your help so far, you helped me understand some critical things already.
Unfortunately, I was mistaken. There was no change in behavior. When I released my HDCP hold and tried to renew it I still got “unable to contact your DHCP server. Request has timed out” and defconf (the wrong DHCP server) is still trying to offer leases without success.
Somehow traffic is not getting routed to the VLAN from ether2 properly =(
And yes, if I switch to ether3 with PVID=1, I get an IP from DHCP defconf exactly as expected, on the correct subnet 192.168.1.1/24 no problems, but as soon as I switch it to PVID=2 it fails out and can’t reach the DHCP server on VLAN 2, but instead the request goes to VLAN 1 and the response is never recieved because port 2/3 isn’t configured to egress VLAN 1 traffic.
On a lark, I tagged ether2 and ether3 for VLAN 1, and yes, I then get the reply from the VLAN 1 HDCP server and am assigned a VLAN 1 IP even though the port is marked PVID 2 for ingress. (?!)
The egress portion appears to work, it’s the ingress that’s messed up, and I have no idea why.
Ah, I figured it out! You’re a life saver. Thanks so much for the help.
It was stupid. I thought I added the bridge as tagged to VLAN1 and VLAN2, but when I checked again it was added as UNTAGGED egress!
But one thing still eludes me. I thought that setting the tagging option set egress from the router to the switch, but the behavior seems to imply it also set the egress from the switch to the router! That was surprising. Anyway, it’s now working properly.
Thank you so much for you help, I was really going crazy trying to figure this out on my own. You certainly pointed out enough flaws in what I was doing! All those little mistakes added up, but with this exercise I feel like I have a much better understanding of how everything works.
Sorry, I mean that when I realized I didn’t have mainBridge marked for tagged VLAN2 egress, I initially tried marking mainBridge for both tagged VLAN2 egress AND tagged VLAN1 egress.
That didn’t work either, and I’m guessing that by marking mainBridge tagged for VLAN1 egress, the mainBridge switch must be handing the mainBridge interface tagged packets and the mainBridge interface must not be stripping the tags causing the DHCP server not to see them.
I.E., with mainBridge tagged for VLAN1 and ether 4 set for untagged VLAN1 and with PVID 1, this is what I think must be going on:
client → (untagged) → ether4 → (tagged VLAN1) → (mainBridge switch) → (tagged VLAN1) → mainBridge intreface → (tagged VLAN1 ?) → DHCP Server doesn’t get the packet
This surprised me because the mainBridge interface is set to PVID 1, so I expected VLAN1 tags to be stripped on ingress, but things were clearly not working this way.