MikroTik

Posted: **Wed Jan 25, 2023 3:27 pm**

Hello,
I am trying to understand why I have to enable DHCP snooping to enable DHCP clients on different VLANS be able to get IP address.
My config:

# jan/02/1970 03:35:44 by RouterOS 7.7
# software id = XMRC-DMUB
#
# model = CCR2004-16G-2S+
# serial number = censored
/interface bridge
add frame-types=admit-only-vlan-tagged ingress-filtering=no \
    name=bridge protocol-mode=none vlan-filtering=yes
/interface vlan
add interface=bridge name=vlan-private vlan-id=25
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/port
set 0 name=serial0
set 1 name=serial1
/snmp community
set [ find default=yes ] addresses=10.0.0.101/32
/interface bridge port
add bridge=bridge frame-types=admit-only-vlan-tagged interface=sfp-sfpplus1
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether16 pvid=25
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether8 pvid=55
/ip neighbor discovery-settings
set discover-interface-list=!dynamic
/interface bridge vlan
add bridge=bridge tagged=sfp-sfpplus1,bridge vlan-ids=25
add bridge=bridge tagged=sfp-sfpplus1 vlan-ids=55
add bridge=bridge tagged=sfp-sfpplus1 vlan-ids=99
add bridge=bridge tagged=sfp-sfpplus1 vlan-ids=255
/ip address
add address=10.0.0.6/24 interface=vlan-private network=10.0.0.0
/snmp
set enabled=yes
/system identity
set name=mktk-example
/system routerboard settings
set auto-upgrade=yes enter-setup-on=delete-key

Situation:
I have main router RB4011 with DHCP servers per VLAN, everything working normally, ether10 is trunk port with vlans 25,55,99,254 - this is connected via RB260 - into sfp-sfpplus1 on CCR2014.
CCR has trunk 25,55,99,255 on sfp, untagged port ether16 for vlan 25, untagged port ether8 for vlan 55.
When i connect laptop to ether16 (vlan25) it normally get IP from dhcp on vlan25. When I connect same laptop to ether8 (vlan55) dhcp is not working, I cannot see any vlan55 packet on sfp-sfpplus1.
When I enable DHCP snooping on bridge and set sfp-sfpplus1 as trusted, now dhcp is working also on ether8 (vlan55) and I get right IP. Why? Am I doing anything wrong? Or is it "works-as-designed" situation?

Posted: **Wed Jan 25, 2023 6:33 pm**

Your CCR is configured as a switch (which is damn pitty for device which is a very capable router ... far more capable than your RB4011). Since it serves as a switch between tagged sfp-sfpplus1and access port ether8, it should pass any DHCP packets between tgese ports, just like it does between sfp-sfpplus1 and ether16. You should not need to run DHCP snooper.

If you run sniffer, do you see DHCP packets enter CCR through ether8 and not leave through sfp-sfpplus1?

It is possible (not very often, but it does happen) that configuration in the device got somehow corrupted ... but that's not shown in configuration export. It happens more often when device is upgraded from v6 to v7. The solution is to export config to text file (don't use binary backup), netinstall device and import config from textual export.

Posted: **Wed Jan 25, 2023 6:49 pm**

My CCR is now configured as a switch, because I am trying to learn right VLAN approach (instead filtering vlan at interface and having multiple per-vlan bridges), clean overall config and then it will replace 4011. I have already found my error (but I do not fully understand the matter) - I have to add also bridge interface into vlan itself, same as with vlan25. DHCP snooping was only "walking around" this error, no other traffic was forwarded.

BAD:

/interface bridge vlan
add bridge=bridge tagged=sfp-sfpplus1,bridge vlan-ids=25
add bridge=bridge tagged=sfp-sfpplus1 vlan-ids=55
add bridge=bridge tagged=sfp-sfpplus1 vlan-ids=99
add bridge=bridge tagged=sfp-sfpplus1 vlan-ids=255

GOOD

/interface bridge vlan
add bridge=bridge tagged=sfp-sfpplus1,bridge vlan-ids=25
add bridge=bridge tagged=sfp-sfpplus1,bridge vlan-ids=55
add bridge=bridge tagged=sfp-sfpplus1,bridge vlan-ids=99
add bridge=bridge tagged=sfp-sfpplus1,bridge vlan-ids=255

Posted: **Wed Jan 25, 2023 7:19 pm**

correct plus I normally for each bridge port line, unless a hybrid port
/interface bridge port
Trunk Ports ( carrying one or more tagged vlans)
ingress-filtering=yes frame-types=admit-only-vlan-tagged

Access Ports ( carrying one ONE untagged vlan )
ingress-filtering=yes frame-types=admit-priority-and-untagged pvid=vlan#

Hybrid Ports ( carrying one or more tagged vlans and ONE untagged vlan )
pvid=vlan# (of untagged vlan )

This I dont do.................. especially because it seem contrary to what the bridge is actually handling............ plus all covered in bridge port settings above.
/interface bridge
add frame-types=admit-only-vlan-tagged ingress-filtering=no \
name=bridge protocol-mode=none vlan-filtering=yes

Just
/interface bridge
name=bridge protocol-mode=none vlan-filtering=yes

In terms of /interface bridge vlan settings.
Every line with a tagged interface reguires the bridge to be tagged ( its going from bridge to somewhere )
Every line with an untagged interface where that interface has not been identified elsewhere also needs the bridge to be tagged.

In your case, its clear you have one trunk port and the rest are access ports.
Thus for vlan interface as you have it, each line has the bridge tagged because another interface is tagged and for example
if vlan99 was not going to sffplus you would put,
add bridge=bridge tagged=bridge vlan=99.

I personally detest any configuraion that on purpose leaves out the untags as that is a communication piece even though not required ( the router on the fly adds the untagged port based on the pvid in bridge port settings.
Thus my config would be
add bridge=bridge tagged=bridge untagged=etherX vlan=99.

Communication in that since its dynamic,
a. it wont show up on the printed export config
b. I use it to cross check my work tieing together bridge ports or vlans.
(its also easier to see where someone has messed up on a more complete config output)

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

In any case your config is not complete or shown and thus warrants no further comments

Posted: **Wed Jan 25, 2023 8:03 pm**

Which device should serve as DHCP server for "other" VLANs, e.g. VLAN 55?

Posted: **Wed Jan 25, 2023 8:42 pm**

Which device should serve as DHCP server for "other" VLANs, e.g. VLAN 55?

Did you not see the end of my post.........

Here again.
In any case your config is not complete or shown and thus warrants no further comments

In other words, unless we see the full config, we cannot comment further!!!!

Posted: **Wed Jan 25, 2023 8:43 pm**

Which device should serve as DHCP server for "other" VLANs, e.g. VLAN 55?

RB4011, but this is not issue, as I already found error in my config.

anav: this is my full config to date, I was only playing with VLANs on clean device.

Posted: **Wed Jan 25, 2023 8:49 pm**

Which device should serve as DHCP server for "other" VLANs, e.g. VLAN 55?
RB4011, but this is not issue, as I already found error in my config.

In this case you should not need neither DHCP snooper nor bridge interface member of those VLANs ... as I already explained.

bridge interface only needs to be member of those vlans with which device interacts on L3 (IP layer). Switching/bridging between other bridge member ports is a L2 (ethernet) function and only ports which have to exchange traffic on particular vlan have to be members (either tagged or untagged) of that vlan.

Posted: **Wed Jan 25, 2023 9:03 pm**

mkx = KISS!! Concur.

Posted: **Wed Jan 25, 2023 9:12 pm**

mkx: so my config in first post should work, but is not working for vlan55. Or I do not understand where is problem, if I should not add bridge interface itself to bridge vlan.

Posted: **Wed Jan 25, 2023 9:31 pm**

See last paragraph in my post #2 above.

Posted: **Wed Jan 25, 2023 9:47 pm**

Yes, I have twice exported config, reset configuration and imported config with no change. So this is not the issue here. Maybe its related to SFP, as this is not connected to switch chip?

Posted: **Wed Jan 25, 2023 9:49 pm**

I wrote netinstall ... it's not the same as reset config.

You're right, it might have to do with hardware ... if netinstalling and configuring this simple setup won't get tge device working, then I'd say you should open support ticket with mikrotik ... create a supout file and provide it to them.

Posted: **Wed Jan 25, 2023 9:51 pm**

When I completely change sfp-sfpplus1 for ether1 and make trunk port there, reconnect cable and it is working as you are suggesting (eg without bridge itself configured as vlan port). So it has definitely something to do with SFP connected to CPU and not to switch chip.

Posted: **Wed Jan 25, 2023 9:59 pm**

The problem should be the same if using ether ports from different switch chips (ether1-8 are on switch chip 1 and ether9-16 are on switch chip 2). Traffic between these two port grouos also has to pass CPU.

Could be that L2HW offloading is flawed, I seem to remember a thread about similar problems on another device also using two switch chips (it might have been a RB4011). You can try to verify this theory by setting hw=no on all bridge members. This is not exactly wanted config because it loads main CPU with traffic which should be handled by switch chips but in your particular case it doesn't do any harm, all traffic between sfp and ether ports has to pass CPU anyway.

Posted: **Wed Jan 25, 2023 10:26 pm**

Yes, when I turn off HW offloading for ether8 vlan55 works with SFP without having bridge in bridge vlan interface as it should. Looks like bug for me...

Posted: **Wed Jan 25, 2023 10:34 pm**

I also did netinstall and replicated same situation on fresh router. Should I fill some bug report?

Posted: **Wed Jan 25, 2023 10:54 pm**

For a switch setup, THIS is what it should look like.............
Only one vlan is identified as its the management/trusted vlan the other vlans are entered correctly only in the bridge port and bridge vlan interface settings.
I use one port for direct access in case the bridge burps on me....... Easier to config from there as well. In this case used ether2 (not on bridge)
NO FIREWALL RULES ARE REQUIRED!!!

/interface bridge
add ingress-filtering=no name=bridge vlan-filtering=yes { vlan-filtering=yes is last item added }
/interface ethernet
set [ find default-name=ether2 ] name=emergaccess
/interface vlan
add interface=bridge name=homeVlan vlan-id=AA { mandatory, management/trusted vlan must be identified as being part of the bridge in /interface vlan }
/interface list
add name=management
/interface bridge port
{ As Per Your Requirements }
/ip neighbor discovery-settings
set discover-interface-list=management
/interface bridge vlan
{ As Per Your Requirements }
/interface list member
add interface=homeVlan list=management
add interface=emergaccess list=management
/ip address
add address=192.168.X.yy/24 interface=homeVlan network=192.168.X.0 comment="IP of Switch on trusted subnet"
add address=192.168.36.1/24 interface=emergaccess network=192.168.36.0 comment="ether2 access off bridge"
/ip dns
set allow-remote-requests=yes servers=192.168.X1 comment="dns through trusted subnet gateway"
/ip route
add disabled=no dst-address=0.0.0.0/0 gateway=192.168.X.1 comment="ensures route avail through trusted subnet gateway"
/system ntp client
set enabled=yes
/system ntp client servers
add address=192.168.X.1
/tool mac-server
set allowed-interface-list=none
/tool mac-server mac-winbox
set allowed-interface-list=management

++++++++++++++++++++++++++++++++++++++++++++++++++++++++

When you go to move this to replace the 4011, in no particular order

ADD other interface list entries
ADD other interface list members
ADD firewall rules required
ADD VLANS required (with interface bridge)
ADD VLAN information ---> IP address, dhpc pool, dhcp-server, dhcp-server network.

Posted: **Thu Jan 26, 2023 10:22 pm**

I also did netinstall and replicated same situation on fresh router. Should I fill some bug report?

I would file a bug report.

MT might get back to you with some other workaround which would not hamper performance that much.

Posted: **Fri Jan 27, 2023 10:46 am**

Hi everyone.

As OP and others have noticed, this problem is related to HW offloaded vlan-filtering and CCR2004-16G-2S+ switch design.

Since RouterOS 6.48, we have added a VLAN mapping between the bridge interface and switch-cpu port. Below is the related changelog entry:
*) crs3xx - added switch-cpu port VLAN filtering (switch-cpu port is now mapped with bridge interface VLAN membership when vlan-filtering is enabled);

It means that you can filter what VLANs are allowed to enter the CPU by adding the bridge interface as a VLAN member. This was working nicely in RouterOS v6, as CRS3xx series switches were the only ones that support HW offloaded vlan-filtering and all of them have a single switch chip.

With RouterOS v7, issues become more apparent as more devices now support HW offloaded vlan-filtering, and there are different switching designs. Multiple switch chips and single switch chips with additional interfaces going directly to the CPU. In these cases, when a VLAN span across switches or switch-to-CPU-interface, you will need to add a bridge (CPU) as a VLAN member to allow traffic through.

Currently, possible examples:
hEX S ether1-ether5 switchable, SFP directly to CPU
RB4011 ether1-ether5 switchable, ether6-ether10 switchable, SFP and wireless directly to CPU
RB1100AHx4 ether1-ether5 switchable, ether6-ether10 switchable, ether11-ether13 switchable
CCR2004-16G-2S+ ether1-ether8 switchable, ether9-ether16 switchable, SFPs directly to CPU

We had a discussion about dynamically adding the bridge interface (CPU) as a VLAN member when this kind of configuration is detected, and even adding the bridge as a tagged VLAN member when you create a routable VLAN interface on the bridge, but I cannot provide any release date for this feature.

Posted: **Fri Jan 27, 2023 10:59 am**

Is this configuration with bridge port inside VLAN somehow related to security of device, eg exposing some router interface into network? How (and where) should this situation be filtered?

Posted: **Fri Jan 27, 2023 11:35 am**

I do not see any harm when you allow the bridge interface to receive tagged packets. These packets will get decapsulated and processed only if you create a matching routable VLAN interface on the bridge. So you filter the traffic by not adding routable VLANs on the bridge where it is not necessary.

Posted: **Fri Jan 27, 2023 11:40 am**

Great, so its no-problem here. Thanks!

Posted: **Sat Feb 11, 2023 6:44 pm**

and even adding the bridge as a tagged VLAN member when you create a routable VLAN interface on the bridge, but I cannot provide any release date for this feature.

This would be a welcomed change. There is already dynamic things (e.g. PVID). And needing the bridge interface in the vlan table for L3 to work is just a time-consuming topic to both explain and troubleshoot.

On systems with multiple switch chips, it be nice if hardware offloading worked when you created multiple bridges (e.g. one-to-one map between bridge interface and switch chip, switch1=bridge1, etc.). Like on RB1100AHx4, using 3 bridges (with correct port assignments), should also be possible to hardware offload without single bridge+VLANs. Thus you could model the physical switch chips to the configuratable L2 in RouterOS – without using the /interface/ethernet/switch stuff & still have portable config file (that may not be hardware offload but still work on all devices).

MikroTik

DHCP vs VLANS

DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS

Re: DHCP vs VLANS