switch set up with two briges switching two completely different networks ?

[antoniocerasuolo]

Hi,

I wanted to ask a question maybe someone has already done this maybe it will not work?

is it possible to set up a switch with two bridges each bridge as client of two completely different routers? will it work?

I hope my question was clear

ciao,
Antonio

[loloski]

you don’t need two bridge to isolate both network what you need is a VLAN and a router

[antoniocerasuolo]

you don’t need two bridge to isolate both network what you need is a VLAN and a router

yes agree but assuming there is only one router..

I have my WAN switch which has the main line coming from my ISP router, and I want to connect a switch to the port of my firewall for more output ports.

therefore for example ports 1-4 could be my WAN switch and ports 5-8 could be my Firewall ports, otherwise I would need to buy a second switch for my firewall.

if this is possible are there pros and cons?

[lurker888]

Here goes my take.

You don’t specify the model that you are using, but for this I’m going to assume that you’re using one of the CRS3xx devices. These are proper managed switches, so… they do managed switch stuff.

These devices can only offload one bridge to hardware, therefore basically for all useful purposes you should have a VLAN-aware (VLAN filtering on) bridge with all the ports where switching is expected assigned to that. (Another way of saying it is: the default is to have all ports as part of a bridge, and you have the ability to exempt some ports from switching and have the interfaces directly available.)

The usual advice when setting up vlan-aware bridges for the first time is to (temporarily) take one port out of bridging, and assign an IP address, etc. and use this as a “management” port, because if you mess up the VLAN configuration, you can easily lose access to your device, have to reset it to regain access, etc. This is not fun, when you have to do it for the fifth time.

Other than this, the my next question is going to be: are the packets you’re going to be switching vlan-tagged or not? You don’t specify, and based on your setup, I’m going to assume that they are untagged.

In this case the way to solve your problem:

1. Assign all (both groups) of ports to a bridge, and turn on VLAN filtering
2. Configure the ports as access ports (this means: set pvid, enable ingress filtering, and set admit only-untagged-and-priority-tagged), assign e.g. pvid=100 to one set of ports, pvid=200 to the other. (This is done in the bridge->port part of the configuration.)
3. Add the two vlans. You don’t have to manually add the ports, this is done automatically based on pvid. (This is done in the bridge->vlan part of the configuration.)

There. Complete. What this means is that a packet coming in on your ports will be tagged with the pvid assigned to that port, and will only be able to leave the switch via ports marked with the same pvid. The tag is removed on egress, so the tag only exists internal to the switch logic.

If you want to access the switch itself (winbox, ssh, etc.) from one of these ports, you’ll have to add a vlan interface to the bridge with the appropriate vlan id (same as the pvid you assigned to the group of ports) from where you want access. Then treat this vlan interface as your interface for purposes such as assigning an IP address, using a DHCP client, enabling access in the firewall, etc.

[antoniocerasuolo]

Here goes my take.

You don’t specify the model that you are using, but for this I’m going to assume that you’re using one of the CRS3xx devices. These are proper managed switches, so… they do managed switch stuff.

These devices can only offload one bridge to hardware, therefore basically for all useful purposes you should have a VLAN-aware (VLAN filtering on) bridge with all the ports where switching is expected assigned to that. (Another way of saying it is: the default is to have all ports as part of a bridge, and you have the ability to exempt some ports from switching and have the interfaces directly available.)

The usual advice when setting up vlan-aware bridges for the first time is to (temporarily) take one port out of bridging, and assign an IP address, etc. and use this as a “management” port, because if you mess up the VLAN configuration, you can easily lose access to your device, have to reset it to regain access, etc. This is not fun, when you have to do it for the fifth time.

Other than this, the my next question is going to be: are the packets you’re going to be switching vlan-tagged or not? You don’t specify, and based on your setup, I’m going to assume that they are untagged.

In this case the way to solve your problem:

1. Assign all (both groups) of ports to a bridge, and turn on VLAN filtering
2. Configure the ports as access ports (this means: set pvid, enable ingress filtering, and set admit only-untagged-and-priority-tagged), assign e.g. pvid=100 to one set of ports, pvid=200 to the other. (This is done in the bridge->port part of the configuration.)
3. Add the two vlans. You don’t have to manually add the ports, this is done automatically based on pvid. (This is done in the bridge->vlan part of the configuration.)

There. Complete. What this means is that a packet coming in on your ports will be tagged with the pvid assigned to that port, and will only be able to leave the switch via ports marked with the same pvid. The tag is removed on egress, so the tag only exists internal to the switch logic.

If you want to access the switch itself (winbox, ssh, etc.) from one of these ports, you’ll have to add a vlan interface to the bridge with the appropriate vlan id (same as the pvid you assigned to the group of ports) from where you want access. Then treat this vlan interface as your interface for purposes such as assigning an IP address, using a DHCP client, enabling access in the firewall, etc.

I’m actually using the L009UiGS as a switch, and the packets are untagged as you guessed!

probabaly the easiest way to manage is to take one port out of the bridge as you suggest and use as management port for example the SFP port with RJ45 converter.

my problem is rack space and a clean configuration of the whole setup, and in effect this configuration you suggest is cool, I am also actually thinking of getting a second L009 which can sit nicely in the same rack ears and the nice FERRARI red color!!!

[lurker888]

I’m actually using the L009UiGS as a switch, and the packets are untagged as you guessed!

probabaly the easiest way to manage is to take one port out of the bridge as you suggest and use as management port for example the SFP port with RJ45 converter.

my problem is rack space and a clean configuration of the whole setup, and in effect this configuration you suggest is cool, I am also actually thinking of getting a second L009 which can sit nicely in the same rack ears and the nice FERRARI red color!!!

Good to hear. The L009 is a proper switch, so this is fully applicable. The proper documentation is actually here:

https://help.mikrotik.com/docs/spaces/ROS/pages/328068/Bridging+and+Switching#BridgingandSwitching-BridgeHardwareOffloading

The L009 has the 88e6190 switch, and for what you currently need the “VLAN filtering” and possibly later the “S/RTP” columns are relevant. You can also do similar things with some of the cheaper devices like those in the hEX series (but beware that for the refresh series, only 4 of the ports are actually connected to the switch chips.)

I think it’s a but pricey, but the L009 is a fine device, especially for your use case.

I would only use the SFP for management if you have the converter handy. I strongly suggest using a separate port for this during configuration for the reasons stated, however after you have setup access through your normal network (and verified it), it can be freely enrolled into the bridge setup. (Or it can be left separate, if that’s what you prefer - some people do.)

EDIT: Btw if you do get more switches, the usual way of integrating them into such a setup is to establish a “trunk” port between them, which carries both (or all) vlans as tagged packets. This way both switches have access to these vlans, and depending on their configuration can have their port assigned to either. The packets then - if they have to - seamlessly transit the link between the switches. Actually this is what I would use the SFP ports for, and as an added bonus, they support 2.5Gb speeds, so there’s less of a chance for this interconnect to bottleneck bandwidth.

[antoniocerasuolo]

I’m actually using the L009UiGS as a switch, and the packets are untagged as you guessed!

probabaly the easiest way to manage is to take one port out of the bridge as you suggest and use as management port for example the SFP port with RJ45 converter.

my problem is rack space and a clean configuration of the whole setup, and in effect this configuration you suggest is cool, I am also actually thinking of getting a second L009 which can sit nicely in the same rack ears and the nice FERRARI red color!!!

Good to hear. The L009 is a proper switch, so this is fully applicable. The proper documentation is actually here:

https://help.mikrotik.com/docs/spaces/ROS/pages/328068/Bridging+and+Switching#BridgingandSwitching-BridgeHardwareOffloading

The L009 has the 88e6190 switch, and for what you currently need the “VLAN filtering” and possibly later the “S/RTP” columns are relevant. You can also do similar things with some of the cheaper devices like those in the hEX series (but beware that for the refresh series, only 4 of the ports are actually connected to the switch chips.)

I think it’s a but pricey, but the L009 is a fine device, especially for your use case.

I would only use the SFP for management if you have the converter handy. I strongly suggest using a separate port for this during configuration for the reasons stated, however after you have setup access through your normal network (and verified it), it can be freely enrolled into the bridge setup. (Or it can be left separate, if that’s what you prefer - some people do.)

EDIT: Btw if you do get more switches, the usual way of integrating them into such a setup is to establish a “trunk” port between them, which carries both (or all) vlans as tagged packets. This way both switches have access to these vlans, and depending on their configuration can have their port assigned to either. The packets then - if they have to - seamlessly transit the link between the switches. Actually this is what I would use the SFP ports for, and as an added bonus, they support 2.5Gb speeds, so there’s less of a chance for this interconnect to bottleneck bandwidth.

Thank you this sounds clear!!!

Yes I purchased a few of these RJ45 to SFP converters so thats not a problem.

one quick question regarding internet access to be able to upgrade the firmware and general stuff.

therefore on the SFP assigning an IP address or maybe even setting up a DHCP server on this one port or whatever.. the question is..

If I’m using the sfp port as management how would I be able to get out to internet through this port?

[lurker888]

Thank you this sounds clear!!!

Yes I purchased a few of these RJ45 to SFP converters so thats not a problem.

one quick question regarding internet access to be able to upgrade the firmware and general stuff.

therefore on the SFP assigning an IP address or maybe even setting up a DHCP server on this one port or whatever.. the question is..

If I’m using the sfp port as management how would I be able to get out to internet through this port?

If you have the converters, then why not use them. Generally however you want to avoid the RJ45 SFPs because of the amount of heat they generate. (Some are better, e.g. fs.com sells some that have a newer chipset than the ones sold by Mikrotik, also there are some that only support up to 2.5GbE, and those run cooler as well.)

Regarding internet access. This is one of those questions, where if you knew how to phrase it, then you wouldn’t ask

Basically there are two separate issues: if you want access for device itself or the other devices that are connected to the management port.

Regarding the device itself, it simply has to obtain an address probably via DHCP from the network it should use (probably the ISP router, but maybe the after-firewall network), and this will add the other necessary settings: the default route, and a DNS server. This DHCP client has to be added to a vlan interface created on the bridge - this is how the device itself gains access to the vlans.

The management port, as you correctly assume, has to have a management network. This - in its most basic form - is created by adding as address to the etherX (or sfpX) port, such as 192.168.111.1/24. This creates both the address and the route into that network. It is then a matter of convenience to set up a dhcp server specifically for this network (otherwise manual configuration is needed on the e.g. laptop connecting to the management port.) This should be done normally. This actually allows the device connected to the management port access to the internet, if masquerading is properly configured.

This leads on to how to configure your firewall. A basic working configuration may be obtained by modifying the default config, so that the management port becomes the only member of the LAN interface group, while WAN consists of the vlan interface through which internet is obtained. This should only be a starting point and proper configuration should be done.

As to updating. I would suggest that this should be the first thing you do before you begin setting up anything else. I suggest a fairly recent version, such as 7.18.2. I usually do upgrades manually, by downloading the appropriate .npk from the Mikrotik site and uploading it to the device. This way you don’t have to have internet access for the device itself, and you can choose exactly which version to install.