I got two internet fiber access in with a provider and I would like to remove their box and use my own Firewall.
Actually my firewall cannot change vlan priority for a paquet send by himself (dhcpv4 request and dhcpv6-pd solicit).
I would like to insert in a transparent way a Mikrotik hEX S on each fiber with the following :
Fiber → SFP ONT Nokia → sfp1 hEX S → ether3 hEX S → Firewall
ether1 hEX S → Mikrotik switch with PoE for management
I got two bridge :
default all port except sfp1 and ether3
orange_pro sfp1 and ether3
Before I try to use only a Mikrotik router with SFP ONT (with or without TP-LINK MC220) to access internet and I add the following filter or switch rule (depending of the Mikrotik used for test) :
with a bridge filter :
/interface vlan
add interface=ether1 name=vlan832 vlan-id=832
How to do the same for DHCPv4 request initiated by the Firewall on vlan=832 trough a MikroTik hEX S on port ether3 who has a SFP ONT on port sfp1 and needs to change the vlan-priority to 6 only for this DHCPv4 request to be able to mount the internet access on the firewall for IPv4 ? The Mikrotik will be managed using the other ports and will be acting as a transparent router.
How to do the same for DHCPv6-PD solicit initiated by the Firewall on vlan=832 trough a MikroTik hEX S on port ether3 who has a SFP ONT on port sfp1 and needs to change the vlan-priority to 6 only for this DHCPv6 solicit to be able to mount the internet access on the firewall for IPv6 ? The Mikrotik will be managed using the other ports and will be acting as a transparent router.
It’s almost the same except that in the bridge filter rules, you have to use chain=forward rather than chain=output, and add an in-interface=ether3 match condition. And you still have to use a dedicated bridge for VLAN 832, because the bridge filter rules currently do not support matching on IP headers of packets carried by VLAN-tagged frames, so the frame carrying the DHCP/PD packet must get tagged after passing through the bridge. So ether3 <-U-> bridge832 <-U-> interface vlan 832 <=T=> sfp1.
Depending on the bandwidth you get from the ISP, you may find the hEX S to be a bottleneck.
In /interface ethernet switch rules, you would have to attach the rule to ether3 rather than to switch1-cpu, but this is not relevant to hEX S as switch rules are not supported there.
Thanks for the answer, seems to be clear for me.
My bridge filter will be applied between ether3 and the bridge using forward chain and got my vlan832…
If I got switch rule with a compatible hardware it’s the same where I need to apply the switch rule instead a bridge filter ?
Agree that the hEX S will be the bottleneck and switch rules are not supported for vlan and also for sfp1. It’s mainly to do a technical validation and then decide how to tune the setup to expect to match maximum bandwidth available…
I got 2 fiber access and would like to replace both box, one is 2Gbps/600Mbps and the other 1Gbps/1Gbps.
I plan to replace my hEX S for each box by :
RB2011iLS-IN
or RB935GS-5HnT-RP
I will be able to use switch rule on the sfp port !
What is your advise for best Mikrotik product to fit this needs as a transparent sfp/ether CoS tagging device ?
What is your advise is I would like to have a sfp+ port instead ? (SFP ONT used is a Nokia G-010S-A with HSGMII at 2,5Gbps to be able to use the 2Gbps available on the fiber contract)
On MT7621 based routers, RouterOS doesn’t support switch chip rules at all, not only on sfp1.
Both should work fine at wire speed if you use switch chip rules.
According to the product information, CRS305-1G-4S+IN seems to be the best choice for your special purpose - one SFP+ towards the firewall, plain SFP towards the slower WAN, and another SFP+ towards the 2G/600M WAN if the firewall supports VLANs. But I’ve got no hands-on experience with this device. Don’t forget to disable xSTP before connecting it to the ISPs.
Thanks a lot for the first part of answer.
Concerning the CRS305, agree, seems to be the perfect match for me and I was thinking to use it for both fiber isolating each dual group of ports needed (SFP ONT into sfp1 and sfp2 going to firewall for Fiber 1 and Fiber 2 with sfp3 and sfp4 for example) and using the ethernet port for management…
I bought one 10 days ago and try to insert SFP ONT into one port, got nothing !!! SFP ONT invisible for the Mikrotik.. Try with 3 different SFP ONT and on each port same problem, so I decided to ship it back !
May be I made a mistake ? I miss something to have SFP ONT working ?
Mikrotik support for ONT SFPs is non existent so some might work and most don’t. Even compatibility with “normal” SFPs is incomplete (mildly put). Which means that trying to get ONT SFP to work with any MT device is similar to trying to win a jackpot, even if particular ONT SFP works with one model of MT, it might not with another model of MT.
Standards … one thing is to support normal SFPs which (semi-)transparently pass bits between left and right. And it’s a pitty these are not more compatible. Which mostly is not result of poor standards but rather bad practice by major players who introduced incompatible extensions.
The other problem is support for intelligent SFP devices, such as ONTs. In this case SFP devices implement (optional) interfaces and not every SFP “chassy” supports those. It’s somehow similar to SD cards where most of cards implement storage functionality, but SD can do more, like WiFi … but not every SD card reader supports the less common functions.
As you want it wirespeed, the switch chip must do all the job. Hence you have to make sfp1 and etherX member ports of a bridge with hw=yes on the respective /interface bridge port rows, and if you ever add any other port of that switch chip to any other bridge, it must be added with hw=no (only a single bridge can be “hardware accelerated” per switch chip, and RouterOS chooses autonomously if you permit hw=yes on multiple bridges).
If I remember it properly, you don’t need to configure VLAN 832 handling in the bridge configuration, just set
/interface ethernet switch port set etherX vlan-mode=secure default-vlan-id=832
/interface ethernet switch port set sfp1 vlan-mode=secure
In the unlikely case that the VLAN tag is added on ingress after the frame has been processed by the rules (I’m not 100 % sure here and can’t test right now), remove the vlan-id=832 from the match conditions of the rule. But in your case matching on vlan-id doesn’t matter much as no other VLANs will be used on the switch chip anyway.
Hi Sindy,
I just receive the RB2011 today !
I try quickly but not working yet. I decide to check and to add a mirror switch rule form sfp1 to ether5 to capture trafic. But I don’t know if the main switch rule to change CoS is still enabled ?
My firewall is on ether3 and the SFP ONT into sfp1.
I am connected on port ether6 for management.
I have a problem with mac-protocol=ip in the switch chip rule, because mac-protocol is vlan here if tagging is done before the rule is applied.
In bridge filter rules, the IP and port matching is only possible when mac-protocol=ip, but if I remember correctly, this is not the case with switch rules.
When I was using in the past a Mikrotik hEX PoE to replace my box using an ONT with ether1, switch rule was possible and working and got the following :
on the ether3 the DHCPv4 Request arriving from the Firewall is already tagged with vlanid=832 I just need to change the VLANs-prioirty to 6 that’s all before to go trough sfp1 into the Nokia SFP ONT.
OK, so I have debugged it locally, setting a switch chip rule to handle tagged traffic for the Tik’s own IP address, which therefore that lands at the bridge interface:
If VLAN tag is present, mac-protocol looks at the ethertype field in the VLAN tag, so my assumption above was wrong. If I change mac-protocol to vlan, the rule stops matching; if mac-protocol is set to ip or if it is not specified at all, the rule matches. If I change the vlan-id from the correct one to something else, the rule stops matching again. It also matches on dst-port=53 even if no mac-protocol is specified. And dst-address may be omitted as well, it still matches on dst-port.
So I can’t see what the problem is in your case. Switch chip rules don’t provide any statistics, so the only way to debug is to connect something to the egress port externally; you can use an Ethernet interface which is not a member port of any bridge and connect it to an unused member port of the bridge, and sniff on it (I suppose you don’t have an SFP with RJ-45 handy).
So e.g. permit vlan 832 on ether1 in addition to ether3 and sfp1 in /interface ethernet switch vlan, remove ether2 from /interface bridge port list and don’t attach any IP configuration to it, connect ether1 with ether2 using an external patch cable, make the command line window as wide as your screen permits, and run /tool sniffer quick interface=ether2 in it. Then, connect the firewall to ether3 and see what’s going on. In the VLAN column, you should see X or X:Y where X is the VLAN ID and Y is the CoS value if it differs from 0.
The mirroring of sfp1 traffic to ether5 as such works too (except that its slows down forwarding to/from sfp1 as both directions of a 1 Gbit/s link at sfp1 must fit into a single one at ether5, and there are buffers), but the problem is that if you sniff on ether5 using Wireshark running on Windows, you won’t see the VLAN tag at all as most Windows network card drivers strip the VLAN tag before handing the frame over to higher levels of the networking stack, including the point where npcap (or winpcap) is hooked. So both the VLAN ID and priority fields are lost. That’s why sniffing on Mikrotik itself is necessary, unless you have a modified driver or a linux machine.
I’ve realized that my suggestion above regarding sniffing may be overly complex and inconsistent.
To see that the switch chip rule works for the initial DHCPDISCOVER, which is sent to a broadcast address, it is enough to make the bridge a member port of the bridge (see this for clarification of this apparent nonsense) and sniff on the bridge, no need to use an external cable.
To see that the switch chip rule works also for the subsequent DHCPREQUEST, which the client sends to the unicast address of the DHCP server it has chosen among those that have sent it a DHCPOFFER, you either need the port mirroring if connecting to the real uplink via sfp1, or instead you can attach a test DHCP server to a VLAN interface attached to the bridge to see the full process of the firewall obtaining a DHCP lease from this test server.
So to sniff the firewall’s dialog with the ISP’s DHCP server without losing the VLAN tag in the process, you’d modify the suggestion above: you wouldn’t add ether1 to the bridge, and you would connect the mirror-target port (ether5) with the sniffer port (ether2) using an external cable.
