Hi to all,

I'm currently working with a big network (/16) that I want to splice in different vlans. There are many switch and all are attached to a trunk port on my ccr1009.
At the moment I've only one vlan interface, with the vid 1 on that trunk port, and all the LAN traffic come from that.
I'm using the mikrotik as the main firewall, router, dhcp-server and hotspot.
My idea is to splice the current network in about 25/30 vlan, but to do that I need to configure all the single switch port (and it require many days), and during this days from the new vlan I need to reach and be part of the old network.
So my first idea was to create all the vlan interfaces on the trunk port of the mikrotik, bridge them and assign the ip address, dhcp-server to the bridge.

Here's is an example of part of my config: I've tried this configuration and currently I cannot reach the client on vlan 2 from vlan 98, and from vlan 98 I don't always reach the mikrotik (sometime If I ping from the pc to the mikrotik or from the mikrotik to the pc it lose all the packets... if I wait some second and I retry, it work)

I've noticed that in the arp table of the mikrotik the pc from vlan 98 come 3 times: from interface vlan 98, from interface vlan 3 and from the bridge, so I've tried to switch the two vlan interfaces to arp-reply only, but that doesn't help.

Any suggestion? I'm doing something wrong or something that cannot be done?
In my mind I'm simply bridging 2 interface, so it should work as if I'm bridgind to physical interface

There's any other method to do something similar?

Thanks to all

Nobody can help?

Your goal is unclear.

Are you trying to do host isolation?
Are you trying to subnet the /16 into smaller IP networks?

If you're trying to subnet the /16, then you shouldn't use a bridge. You should put the various subnets of your master prefix onto the various VLAN interfaces.
e.g.:
10.0.1.0/24 interface=vlan1
10.0.2.0/24 interface=vlan2
10.0.3.0/24 interface=vlan3
...etc
(obviously, the subnets can be smaller than /24 if needed - this is just an example)

In this scenario, the hosts in vlan2 may reach those in vlan3 via routing - meaning that they use the router as a gateway to reach each other. They will not see each other's MAC addresses, and they will not see broadcast traffic from each other because they are in different vlans.
In the absence of any firewall rules / policy-based routing rules, this will "just work" because it's the most basic function of a router: forward IP packets between networks.

If you use a bridge, then you're connecting multiple interfaces together into a single broadcast domain - so if you bridge vlan2 and vlan3 together, then while they may use different 802.1q vlan headers, they are in fact a part of the same broadcast, so they may as well be considered to be in the same vlan.... however, there are some host isolation capabilities that this sort of thing can allow - suppose that the vlan interfaces are bridged together, but have the same split-horizon value set to both. This means that both ports are in the same VLAN, but may not communicate directly with each other.... In this second case, you would use a larger IP subnet with enough host addresses to cover all hosts that are included in the bridge - and you would put that IP address on the bridge interface, not on any vlan interfaces.
e.g. 10.0.16.1/22 -> interface=bridge1
Any hosts on any vlans included in this bridge will be part of this one single IP subnet, and should use netmask of 255.255.252.0 with gateway of 10.0.16.1

Your goal is unclear.

Are you trying to do host isolation?
Are you trying to subnet the /16 into smaller IP networks?

If you're trying to subnet the /16, then you shouldn't use a bridge. You should put the various subnets of your master prefix onto the various VLAN interfaces.
e.g.:
10.0.1.0/24 interface=vlan1
10.0.2.0/24 interface=vlan2
10.0.3.0/24 interface=vlan3
...etc
(obviously, the subnets can be smaller than /24 if needed - this is just an example)

In this scenario, the hosts in vlan2 may reach those in vlan3 via routing - meaning that they use the router as a gateway to reach each other. They will not see each other's MAC addresses, and they will not see broadcast traffic from each other because they are in different vlans.
In the absence of any firewall rules / policy-based routing rules, this will "just work" because it's the most basic function of a router: forward IP packets between networks.

If you use a bridge, then you're connecting multiple interfaces together into a single broadcast domain - so if you bridge vlan2 and vlan3 together, then while they may use different 802.1q vlan headers, they are in fact a part of the same broadcast, so they may as well be considered to be in the same vlan.... however, there are some host isolation capabilities that this sort of thing can allow - suppose that the vlan interfaces are bridged together, but have the same split-horizon value set to both. This means that both ports are in the same VLAN, but may not communicate directly with each other.... In this second case, you would use a larger IP subnet with enough host addresses to cover all hosts that are included in the bridge - and you would put that IP address on the bridge interface, not on any vlan interfaces.
e.g. 10.0.16.1/22 -> interface=bridge1
Any hosts on any vlans included in this bridge will be part of this one single IP subnet, and should use netmask of 255.255.252.0 with gateway of 10.0.16.1

Thanks for the answer, probably I wasn't clear:
The final goal is to have many /24 vlan. But while I'm configuring the switches to the new vlans, I need to have all this new vlans in the same /16 network (the current network that there's on vlan 1).
So I've tried to create the bridge on the mikrotik and when I will finish the work, I will disable it and use the single interface. But it doesn't work: a client from one vlan cannot communicate with one in another, and many time cannot communicate with the mikrotik (as I was saying in the post)

Hope it's more clear now
Thanks

Okay - the solution for you is not bridging, but proxy arp.

on the "original" vlan, set arp=proxy-arp

Then as you add new vlans, just configure the subnet directly on the vlan interfaces in your router.
Then reconfigure the hosts in each vlan with the correct subnet mask and default GW.
In fact, you can set arp=proxy-arp on the new vlans as a "migration patch" so that hosts with the original /16 netmask can still function properly when they're connected to a certain vlan (provided that their actual IP address falls within the subnet on that vlan)

Whenever all hosts in a new vlan have been updated, you can safely remove proxy-arp from that interface.
When no more hosts remain in the original /16, just remove that IP address and remove the proxy-arp from the original VLAN interface.

e.g.
/interface ethernet set ether1 arp=proxy-arp
(ip address=10.0.0.1/16 lives on ether1)
/interface vlan add name=vlan2 interface=ether1 vlan-id=2 arp=proxy-arp
/interface vlan add name=vlan3 interface=ether1 vlan-id=3 arp=proxy-arp
/interface vlan add name=vlan4 interface=ether1 vlan-id=4 arp=proxy-arp
... etc
/ip address add address=10.0.2.1/24 interface=vlan2
/ip address add address=10.0.3.1/24 interface=vlan3
/ip address add address=10.0.4.1/24 interface=vlan4
... etc

proxy arp will allow hosts in the 10.0.2.X range to talk with hosts on the original 10.0.0.0/16 interface (as long as the "vlan 1" host is not also using a 10.0.2.x address).

Okay - the solution for you is not bridging, but proxy arp.

on the "original" vlan, set arp=proxy-arp

Then as you add new vlans, just configure the subnet directly on the vlan interfaces in your router.
Then reconfigure the hosts in each vlan with the correct subnet mask and default GW.
In fact, you can set arp=proxy-arp on the new vlans as a "migration patch" so that hosts with the original /16 netmask can still function properly when they're connected to a certain vlan (provided that their actual IP address falls within the subnet on that vlan)

Whenever all hosts in a new vlan have been updated, you can safely remove proxy-arp from that interface.
When no more hosts remain in the original /16, just remove that IP address and remove the proxy-arp from the original VLAN interface.

Uh, thanks for the tip
Only a question: if I have some other vlan interface that i would not "proxy" with this new vlan, I can simply not enable proxy arp on that, and they remain isolated?

And just for my curiosity, Why it's wrong to create a bridge of vlan interfaces? I've see some suggested configuration that bridge a vlan interface with a phisical vlan, so why bridge togheter two vlan interfaces doesn't work?

Thanks again, I'll do some test with proxy arp
Byz

Bridging can blend things together in ways you don't want.
For instance, all broadcasts are going to get amplified because they'll have to be sent out each and every vlan.

The proxy-arp solution lets you switch immediately to using pure layer 2 separation between the vlans as you want, but placing a band-aid over the original /16 so that un-migrated hosts can talk to migrated hosts.

Do realize that hosts in the various subnets will be able to communicate with each other via routed (IP) connectivity through the router. If you want to block vlans from talking to each other, you can make firewall rules that do so. (this is going to be the final case, regardless of whether you used proxy arp or bridging as your migration technology)


The way proxy arp works is that in the main interface /16 - all hosts will consider other addresses inside the /16 range as "local" neighbors, and will send out ARP requests to learn the MAC address of the host they're trying to send a packet to. If your router knows that the target IP address is on some other interface, then it will answer the sender's ARP request with the router's own MAC address on behalf of the target host (who never will receive that ARP request because it's not actually attached to the same network).

The sender will then transmit the IP packet with the desired destination IP address, and with the destination MAC of the router so that the router will receive it and forward it along properly. The sender just doesn't realize that it's using the router, but the router doesn't care - it'll forward the packet properly. In your situation, the recipient will have the new /24 netmask, and will already consider the sender's IP as "remote" and automatically forward replies to the router w/o any need for proxy arp.

Haven't considered the broadcast flooding :uhm:
I've see the example above
Here's a real case I've:
vlan 1 -> 10.1.0.0/16 <- current vlan
vlan 20 -> 10.1.20.0/24 <- new sub vlan
vlan 30 -> 10.1.30.0/24

Should this work? Or does the new vlan to be in a different class to work?
If I have to change the ip class, I don't even need the proxy arp... I simply can allow the communication from the new vlans to the old throught the firewall.. but my goal is to mantain the same ip, only resize the subnet.
Thanks again

Should this work? Or does the new vlan to be in a different class to work?
If I have to change the ip class, I don't even need the proxy arp... I simply can allow the communication from the new vlans to the old throught the firewall.. but my goal is to mantain the same ip, only resize the subnet.
Thanks again

Good question! Yes it will work - I actually tested it in a virtual Mikrotik I had running before I recommended this solution (just to make sure the 'tik wouldn't get mad)

ZeroByte .. kindly can you take a look at the post mentioned in the url below..  I really need your suggestions and what to do to solve my issue

http://forum.mikrotik.com/viewtopic.php?f=2&t=109927