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?
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.
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.
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 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.
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.
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?
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.
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.
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.
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…
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.
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.
