MikroTik

Hi,

My Network Scenario is as follows.

Site -1 : RB750G=======RB450G(MAIN Router)========RB750G
Site -2 : RB750G=======RB450G(MAIN Router)========RB750G
Site -3 : RB750G=======RB450G(MAIN Router)========RB750G
* Only 1 Main Router is there RB450G, and 6 nos of RB750G

My main router is connected to ether1 using the Trunk Line

and Other RB750G are on separately connected at their in same network, but network provider allowed communication to trunk only , all 6 RB750G cannot communicate together so i am planning to put RB450G on trunk with help of network provider

I want to achieve transparent bridge between RB750G of every site, i don't want that 3 sites can communicate each other, want to keep the separate please suggest how can i achieve this.

Read about Bridge -> Horizon.

Regards.

Thank for the reply, i got your point now i have confusion which one is best Horizon Bridging or else i can have virtual ethernet interface and bridge them separately which one is good option please suggest

Which one is best Horizon bridging or virtual ethernet interfaces in separate bridges

This is how I understand your topology. I also understand that the ISP only allows communication directly between hub and spoke - a point-to-multipoint topology.

If you use bridging with split horizon, then the sites on the same horizon will not be able to communicate with each other (same as now).
You really can't use MLPS/VPLS very easily because it wants to communicate directly between endpoints.

Long story short - all communications must go in, and then back out your connection at the hub location.

If you're bridging all of these sites, I hope your broadcast traffic is very small. If you have ~10Kbps of broadcast traffic at one site, then that's going to be 10K in at the hub, and then 50K out at the hub - 5x multiplication...

If you really want bridging, and don't feel the above is a strong concern, then I would recommend:
Create a bridge on the 450G and 6 EoIP tunnel interfaces, connected to the bridge. If you want to completely block some sites from seeing each other, you can place them on the same horizon in the bridge. At each location, you connect the EoIP tunnel interface to the LAN bridge.

I personally recommend that you use layer3 in this situation, and use routing to reach each site via the hub.
e.g.: at each site, route 192.168.0.0/16 to the 450g, and at the 450G route each site's networks
192.168.1.0/24 -> site1
192.168.2.0/24 -> site2
etc...

This way, only traffic that explicitly needs to go to a specific site will go there.

Thank you very much zerobyte for very specific explanation, i have successfully established VPLS with horizon bridge and it is working well, i am also trying your given solution on different site of mine, i will keep this post updated with the status.

Thanks for the karma - and I have a suggestion for your lab/testing with Layer3 forwarding between sites.

If you want to make this solution such that you can easily add more sites in the future, use OSPF to enable dynamic routing between the sites.

If my assumption is true, that the branch locations cannot ping directly to each other, even if using the same IP range (e.g. 192.168.1.x/24), then you will need to put a special configuration on the interfaces - network type should be point-to-multipoint (ptmp) at the hub location, and point-to-point at the branches. This way, all routes learned at the branches will correctly bounce through the main location first.

If the branches can directly ping to each other as well, then just enabling OSPF with the normal broadcast interface type should be fine.

If you've successfully set up VPLS, then this should not be a challenge for you.

Drawing1.png

This is how I understand your topology. I also understand that the ISP only allows communication directly between hub and spoke - a point-to-multipoint topology.

If you use bridging with split horizon, then the sites on the same horizon will not be able to communicate with each other (same as now).
You really can't use MLPS/VPLS very easily because it wants to communicate directly between endpoints.

Long story short - all communications must go in, and then back out your connection at the hub location.

If you're bridging all of these sites, I hope your broadcast traffic is very small. If you have ~10Kbps of broadcast traffic at one site, then that's going to be 10K in at the hub, and then 50K out at the hub - 5x multiplication...

If you really want bridging, and don't feel the above is a strong concern, then I would recommend:
Create a bridge on the 450G and 6 EoIP tunnel interfaces, connected to the bridge. If you want to completely block some sites from seeing each other, you can place them on the same horizon in the bridge. At each location, you connect the EoIP tunnel interface to the LAN bridge.

I personally recommend that you use layer3 in this situation, and use routing to reach each site via the hub.
e.g.: at each site, route 192.168.0.0/16 to the 450g, and at the 450G route each site's networks
192.168.1.0/24 -> site1
192.168.2.0/24 -> site2
etc...

This way, only traffic that explicitly needs to go to a specific site will go there.

I am having problem again, when i added 4 VPLS in bridge i cannot configure horizon, please confirm what's wrong.

RB450G Main Router Config :
Bridge 1 = ether1, vpls-A, vpls-B, vpls-C, vpls-D

1) i want vpls-A & vpls-B to have transparent traffic
2) i also want vpls-C & vpls-D to have transparent traffic

please confirm how i need to configure horizon to isolate the vpls

You should put all 4 sites on the same horizon at the hub site, and on sites A and B, configure a direct peering between them.

::NOTE::
Make certain that at site A, you put Hub and Site B on the same horizon, and that on site B, you put site A and Hub on the same horizon.

Make sure that router at site A can ping the peering IP at B. (OSPF should be giving the hub as the next hop address.)
Basically, even though the traffic will physically pass through hub when going from A to B, logically it should go directly between the two sites. MPLS will be smart enough to build a LSP that links A and B via Hub as long as your routing protocol shows this as the way to go.

Once this works, do the same between sites C and D.

If you want B to see A and E, but you don't want E to see A, just add a peering between B and E.
Etc.

In all cases, at every site, all VPLS interfaces should have the same horizon on the bridge!

This example shows why:
1. Host at site A sends a broadcast to ARP for a host at site B.
2. RouterA picks up the broadcast frame on ether1, realizes it's on the VPLS bridge, and then forwards the broadcasts to all other interfaces - vplsB, vplsHub, ether3, ether4.
3. RouterB receives the broadcast on vplsA, and forwards it to ether1, ether3, and ether4, but does not forward it to vplsHub because vplsHub and vplsA are both on horizon1.
4. vplsHub also receives the broadcast - via interface vplsA. It does not send the broadcast to any other vpls peer (including B) because all sites are on horizon1.
* If B were not on a split horizon, then you would create a network loop as B would get two copies of the broadcast - one directly from A, and a second copy from Hub.

If you're worried about bandwidth - consider this, only broadcast traffic wastes bandwidth. Unicast traffic already must go A->Hub->B. Direct peering just makes this invisible on the bridge. It's only when a broadcast starts at A... A will send two copies of each broadcast packet - one for site B and one for Hub. B will do the same when it has a broadcast for the network - it will send a copy for A and a copy for H.

You should put all 4 sites on the same horizon at the hub site, and on sites A and B, configure a direct peering between them.

::NOTE::
Make certain that at site A, you put Hub and Site B on the same horizon, and that on site B, you put site A and Hub on the same horizon.

Make sure that router at site A can ping the peering IP at B. (OSPF should be giving the hub as the next hop address.)
Basically, even though the traffic will physically pass through hub when going from A to B, logically it should go directly between the two sites. MPLS will be smart enough to build a LSP that links A and B via Hub as long as your routing protocol shows this as the way to go.

Once this works, do the same between sites C and D.

If you want B to see A and E, but you don't want E to see A, just add a peering between B and E.
Etc.

In all cases, at every site, all VPLS interfaces should have the same horizon on the bridge!

This example shows why:
1. Host at site A sends a broadcast to ARP for a host at site B.
2. RouterA picks up the broadcast frame on ether1, realizes it's on the VPLS bridge, and then forwards the broadcasts to all other interfaces - vplsB, vplsHub, ether3, ether4.
3. RouterB receives the broadcast on vplsA, and forwards it to ether1, ether3, and ether4, but does not forward it to vplsHub because vplsHub and vplsA are both on horizon1.
4. vplsHub also receives the broadcast - via interface vplsA. It does not send the broadcast to any other vpls peer (including B) because all sites are on horizon1.
* If B were not on a split horizon, then you would create a network loop as B would get two copies of the broadcast - one directly from A, and a second copy from Hub.

If you're worried about bandwidth - consider this, only broadcast traffic wastes bandwidth. Unicast traffic already must go A->Hub->B. Direct peering just makes this invisible on the bridge. It's only when a broadcast starts at A... A will send two copies of each broadcast packet - one for site B and one for Hub. B will do the same when it has a broadcast for the network - it will send a copy for A and a copy for H.

i am not able to ping from site A to site B because both ports are protected(isolated) and can only talk to trunks where i have placed my RB450G (Hub) in which i have configured vpls now without configuring horizon i can ping both site and work transparently as traffic is passing through HUB but if i configure same horizon vpls interfaces in HUB then i am not able to ping A to B

pl explain

... if i configure same horizon vpls interfaces in HUB then i am not able to ping A to B pl explain

This is long - if you just want a fix for your problem, skip to TLDR below.....

Split horizon means block interfaces on the same horizon from seeing each other.

It's the opposite of what you might think. It might seem to mean "let these interfaces see each other but block from everywhere else" but that's completely backwards from the reality. So how is it useful to only block one set of interfaces from each other, but to allow them to talk normally to all other interfaces?

Split horizon is useful as a way to allow full mesh connectivity without using a tree topology.

VPLS is a great example:
Suppose each site A, B, C, and D have direct connections with VPLS, and 3 local ethernet interfaces all bridged together...

If site A receives a broadcast on ether2, it will forward it to ether1, ether3, vplsB, vplsC, and vplsD, since these are all members of the bridge.

No split horizon and no spanning tree = death!
If there was no split horizon, then when site B receives the broadcast on interface vplsA, it will forward it to ether1, ether2, ether3, (all of these are correct so far), vplsC!, and vplsD! (note that this makes a second copy of the broadcast for C and D)
Site C will receive the original broadcast from A, and forward it to ether1, ether2, ether3, vplsB, and vplsD.
Then it will receive the same broadcast from B and forward it to ether1, ether2, ether3, vplsA, and vplsD. (see the snowball starting yet?)

Site D will receive the original from A, --> e1, e2, e3, vplsB, vplsC
the duplicate from B --> e1, e2, e3, vplsA, vplsC
and two duplicates from C --> e1, e2, e3, vplsA, vplsB

It will only take a few repeats to reach full bandwidth at all sites doing nothing but make infinite copies of the original broadcast packet! This is an out of control chain reaction. (and what happens if you plug a bunch of un-managed switches into each other and create a loop, by the way)

VPLS with split horizon
With all vplsX interfaces configured to the horizon=1, the behavior is much more normal.
A receives broadcast on ether2 --> e1, e3, vplsB, vplsC, vplsD.
B receives broadcast from vplsA --> e1, e2, e3 (split horizon stops it from going out to other VPLS sites)
C receives broadcast from vplsA --> e1, e2, e3 (split horizon stops it from going out to other VPLS sites)
D receives broadcast from vplsA --> e1, e2, e3 (split horizon stops it from going out to other VPLS sites)
-- every port in the network has now received the broadcast, and only once. (yay!)



Split horizon in general:
All switches do split horizon by default - even unmanaged ones - but each interface is on it's own seperate horizon.
(eth1=horizon1, eth2=horizon2, eth3=horizon3, etc)
So if a switch gets a broadcast on eth1, it will send it to eth2 .. eth24, but will not echo it back to eth1.

When you assign multiple interfaces to the same horizon, this gets expanded. Suppose eth1 - eth8 are horizon1 and eth9-24 are horizon2. Then a broadcast received on any of those 8 ports will not be reflected to eth9-eth24, but NOT 1-8 because they're all on the same horizon.

Split horizon is great for blocking client-to-client connectivity

People who activate client isolation in a WiFi deployment (default-forward='no' in Mikrotik terminology) are sometimes surprised that they can still see other wireless devices. This is because while two devices on the same AP are blocked from seeing each other, they can see the devices on every other AP at the site just fine. If the APs are connected to a switch that puts the APs all on the same horizon, then wireless clients are blocked from seeing wireless devices on ALL other APs, not just their own AP. They also can't see things plugged into the rest of the LAN, such as a guest computer in the lobby.

Suppose you have a DHCP server or a printer that you want everyone to see, then you simply don't put a horizon on its port, and everyone can talk to the server, but not to each other.

Explanation done - now back to your exact situation

TLDR:
You can accomplish your goal by using forwarding rules in the bridge firewall on the central site - make rules:
1: accept in-interface=vplsA out-interface=vplsB
2: accept in-interface=vplsB out-interface=vplsA
3: accept in-interface=vplsC out-interface=vplsD
4: accept in-interface=vplsD out-interface=vplsC
5: drop all

One final thought
I suspect that you CAN ping from one site to another, even across the provider's hub-and-spoke network.
Try this to see if it works, and if it does, you can extend to the rest of the sites:
at SiteA, put a static route /32 to B with gateway=ip.of.hub.site
at SiteB, put a static route /32 to A with gateway=ip.of.hub.site
Then try to ping. If this works, then you can do this everywhere. You may also need to drop ICMP redirect packets on the uplink interfaces at all spoke sites. (hub will forward the packets, but will also try to give siteB a 'hint' to go directly to A next time)

If THIS works, then you can just set up VPLS for full mesh with split horizon as in the example.

... if i configure same horizon vpls interfaces in HUB then i am not able to ping A to B pl explain

This is long - if you just want a fix for your problem, skip to TLDR below.....

Split horizon means block interfaces on the same horizon from seeing each other.

It's the opposite of what you might think. It might seem to mean "let these interfaces see each other but block from everywhere else" but that's completely backwards from the reality. So how is it useful to only block one set of interfaces from each other, but to allow them to talk normally to all other interfaces?

Split horizon is useful as a way to allow full mesh connectivity without using a tree topology.

VPLS is a great example:
Suppose each site A, B, C, and D have direct connections with VPLS, and 3 local ethernet interfaces all bridged together...

If site A receives a broadcast on ether2, it will forward it to ether1, ether3, vplsB, vplsC, and vplsD, since these are all members of the bridge.

No split horizon and no spanning tree = death!
If there was no split horizon, then when site B receives the broadcast on interface vplsA, it will forward it to ether1, ether2, ether3, (all of these are correct so far), vplsC!, and vplsD! (note that this makes a second copy of the broadcast for C and D)
Site C will receive the original broadcast from A, and forward it to ether1, ether2, ether3, vplsB, and vplsD.
Then it will receive the same broadcast from B and forward it to ether1, ether2, ether3, vplsA, and vplsD. (see the snowball starting yet?)

Site D will receive the original from A, --> e1, e2, e3, vplsB, vplsC
the duplicate from B --> e1, e2, e3, vplsA, vplsC
and two duplicates from C --> e1, e2, e3, vplsA, vplsB

It will only take a few repeats to reach full bandwidth at all sites doing nothing but make infinite copies of the original broadcast packet! This is an out of control chain reaction. (and what happens if you plug a bunch of un-managed switches into each other and create a loop, by the way)

VPLS with split horizon
With all vplsX interfaces configured to the horizon=1, the behavior is much more normal.
A receives broadcast on ether2 --> e1, e3, vplsB, vplsC, vplsD.
B receives broadcast from vplsA --> e1, e2, e3 (split horizon stops it from going out to other VPLS sites)
C receives broadcast from vplsA --> e1, e2, e3 (split horizon stops it from going out to other VPLS sites)
D receives broadcast from vplsA --> e1, e2, e3 (split horizon stops it from going out to other VPLS sites)
-- every port in the network has now received the broadcast, and only once. (yay!)



Split horizon in general:
All switches do split horizon by default - even unmanaged ones - but each interface is on it's own seperate horizon.
(eth1=horizon1, eth2=horizon2, eth3=horizon3, etc)
So if a switch gets a broadcast on eth1, it will send it to eth2 .. eth24, but will not echo it back to eth1.

When you assign multiple interfaces to the same horizon, this gets expanded. Suppose eth1 - eth8 are horizon1 and eth9-24 are horizon2. Then a broadcast received on any of those 8 ports will not be reflected to eth9-eth24, but NOT 1-8 because they're all on the same horizon.

Split horizon is great for blocking client-to-client connectivity

People who activate client isolation in a WiFi deployment (default-forward='no' in Mikrotik terminology) are sometimes surprised that they can still see other wireless devices. This is because while two devices on the same AP are blocked from seeing each other, they can see the devices on every other AP at the site just fine. If the APs are connected to a switch that puts the APs all on the same horizon, then wireless clients are blocked from seeing wireless devices on ALL other APs, not just their own AP. They also can't see things plugged into the rest of the LAN, such as a guest computer in the lobby.

Suppose you have a DHCP server or a printer that you want everyone to see, then you simply don't put a horizon on its port, and everyone can talk to the server, but not to each other.

Explanation done - now back to your exact situation

TLDR:
You can accomplish your goal by using forwarding rules in the bridge firewall on the central site - make rules:
1: accept in-interface=vplsA out-interface=vplsB
2: accept in-interface=vplsB out-interface=vplsA
3: accept in-interface=vplsC out-interface=vplsD
4: accept in-interface=vplsD out-interface=vplsC
5: drop all

One final thought
I suspect that you CAN ping from one site to another, even across the provider's hub-and-spoke network.
Try this to see if it works, and if it does, you can extend to the rest of the sites:
at SiteA, put a static route /32 to B with gateway=ip.of.hub.site
at SiteB, put a static route /32 to A with gateway=ip.of.hub.site
Then try to ping. If this works, then you can do this everywhere. You may also need to drop ICMP redirect packets on the uplink interfaces at all spoke sites. (hub will forward the packets, but will also try to give siteB a 'hint' to go directly to A next time)

If THIS works, then you can just set up VPLS for full mesh with split horizon as in the example.

... if i configure same horizon vpls interfaces in HUB then i am not able to ping A to B pl explain

This is long - if you just want a fix for your problem, skip to TLDR below.....

Split horizon means block interfaces on the same horizon from seeing each other.

It's the opposite of what you might think. It might seem to mean "let these interfaces see each other but block from everywhere else" but that's completely backwards from the reality. So how is it useful to only block one set of interfaces from each other, but to allow them to talk normally to all other interfaces?

Split horizon is useful as a way to allow full mesh connectivity without using a tree topology.

VPLS is a great example:
Suppose each site A, B, C, and D have direct connections with VPLS, and 3 local ethernet interfaces all bridged together...

If site A receives a broadcast on ether2, it will forward it to ether1, ether3, vplsB, vplsC, and vplsD, since these are all members of the bridge.

No split horizon and no spanning tree = death!
If there was no split horizon, then when site B receives the broadcast on interface vplsA, it will forward it to ether1, ether2, ether3, (all of these are correct so far), vplsC!, and vplsD! (note that this makes a second copy of the broadcast for C and D)
Site C will receive the original broadcast from A, and forward it to ether1, ether2, ether3, vplsB, and vplsD.
Then it will receive the same broadcast from B and forward it to ether1, ether2, ether3, vplsA, and vplsD. (see the snowball starting yet?)

Site D will receive the original from A, --> e1, e2, e3, vplsB, vplsC
the duplicate from B --> e1, e2, e3, vplsA, vplsC
and two duplicates from C --> e1, e2, e3, vplsA, vplsB

It will only take a few repeats to reach full bandwidth at all sites doing nothing but make infinite copies of the original broadcast packet! This is an out of control chain reaction. (and what happens if you plug a bunch of un-managed switches into each other and create a loop, by the way)

VPLS with split horizon
With all vplsX interfaces configured to the horizon=1, the behavior is much more normal.
A receives broadcast on ether2 --> e1, e3, vplsB, vplsC, vplsD.
B receives broadcast from vplsA --> e1, e2, e3 (split horizon stops it from going out to other VPLS sites)
C receives broadcast from vplsA --> e1, e2, e3 (split horizon stops it from going out to other VPLS sites)
D receives broadcast from vplsA --> e1, e2, e3 (split horizon stops it from going out to other VPLS sites)
-- every port in the network has now received the broadcast, and only once. (yay!)



Split horizon in general:
All switches do split horizon by default - even unmanaged ones - but each interface is on it's own seperate horizon.
(eth1=horizon1, eth2=horizon2, eth3=horizon3, etc)
So if a switch gets a broadcast on eth1, it will send it to eth2 .. eth24, but will not echo it back to eth1.

When you assign multiple interfaces to the same horizon, this gets expanded. Suppose eth1 - eth8 are horizon1 and eth9-24 are horizon2. Then a broadcast received on any of those 8 ports will not be reflected to eth9-eth24, but NOT 1-8 because they're all on the same horizon.

Split horizon is great for blocking client-to-client connectivity

People who activate client isolation in a WiFi deployment (default-forward='no' in Mikrotik terminology) are sometimes surprised that they can still see other wireless devices. This is because while two devices on the same AP are blocked from seeing each other, they can see the devices on every other AP at the site just fine. If the APs are connected to a switch that puts the APs all on the same horizon, then wireless clients are blocked from seeing wireless devices on ALL other APs, not just their own AP. They also can't see things plugged into the rest of the LAN, such as a guest computer in the lobby.

Suppose you have a DHCP server or a printer that you want everyone to see, then you simply don't put a horizon on its port, and everyone can talk to the server, but not to each other.

Explanation done - now back to your exact situation

TLDR:
You can accomplish your goal by using forwarding rules in the bridge firewall on the central site - make rules:
1: accept in-interface=vplsA out-interface=vplsB
2: accept in-interface=vplsB out-interface=vplsA
3: accept in-interface=vplsC out-interface=vplsD
4: accept in-interface=vplsD out-interface=vplsC
5: drop all

One final thought
I suspect that you CAN ping from one site to another, even across the provider's hub-and-spoke network.
Try this to see if it works, and if it does, you can extend to the rest of the sites:
at SiteA, put a static route /32 to B with gateway=ip.of.hub.site
at SiteB, put a static route /32 to A with gateway=ip.of.hub.site
Then try to ping. If this works, then you can do this everywhere. You may also need to drop ICMP redirect packets on the uplink interfaces at all spoke sites. (hub will forward the packets, but will also try to give siteB a 'hint' to go directly to A next time)

If THIS works, then you can just set up VPLS for full mesh with split horizon as in the example.

I have created bridge filter rules as suggested by you

1: accept in-interface=vplsA out-interface=vplsB
2: accept in-interface=vplsB out-interface=vplsA
3: accept in-interface=vplsC out-interface=vplsD
4: accept in-interface=vplsD out-interface=vplsC
5: drop all

and it works, it isolate the traffic between 2 vpls sites.

Another issue:
If i enable all 4 sites which are in same bridge along with ether1(physical interface) at RB450G Central site, router reboots frequently, when i checked log it shows the following.

System rebooted because of kernel failure
Out of memory condition was detected
Router was rebooted without proper shutdown

Same problem before adding the bridge rules, and if i disable two sites (i.e. A&B or C&D) it works without any issue.

Below are the firmware details :
RouterOS 6.24

Note: I have tried replacing the router with new one but still same issue,

What is the exact issue which is causing the problem ?


Thanks

If i enable all 4 sites which are in same bridge along with ether1(physical interface) at RB450G Central site, router reboots frequently, when i checked log it shows the following.

System rebooted because of kernel failure
Out of memory condition was detected
Router was rebooted without proper shutdown

Same problem before adding the bridge rules, and if i disable two sites (i.e. A&B or C&D) it works without any issue.

Below are the firmware details :
RouterOS 6.24

Note: I have tried replacing the router with new one but still same issue,

What is the exact issue which is causing the problem ?


Thanks

How much ram does the 450G have? (It's been a while since i used one)
How much free memory does it have when running normally? (and all configurations enabled)
According to another thread here (don't have a link, sry) I was reading that below about 7MB free memory starts to have glitches and below 5MB free becomes unstable and crashes with watchdog timer.

We haven't discussed the other things this router is doing (bgp, large set of firewall rules, transparent proxy, hotspot?)
My three thoughts:
- if free memory is > 8MB normally, then it could be bugs - try latest firmware
- use a more powerful model of RB
- split this into two rb - one for being the hub site, and one for internet connection.

If i enable all 4 sites which are in same bridge along with ether1(physical interface) at RB450G Central site, router reboots frequently, when i checked log it shows the following.

System rebooted because of kernel failure
Out of memory condition was detected
Router was rebooted without proper shutdown

Same problem before adding the bridge rules, and if i disable two sites (i.e. A&B or C&D) it works without any issue.

Below are the firmware details :
RouterOS 6.24

Note: I have tried replacing the router with new one but still same issue,

What is the exact issue which is causing the problem ?


Thanks

How much ram does the 450G have? (It's been a while since i used one)
How much free memory does it have when running normally? (and all configurations enabled)
According to another thread here (don't have a link, sry) I was reading that below about 7MB free memory starts to have glitches and below 5MB free becomes unstable and crashes with watchdog timer.

We haven't discussed the other things this router is doing (bgp, large set of firewall rules, transparent proxy, hotspot?)
My three thoughts:
- if free memory is > 8MB normally, then it could be bugs - try latest firmware
- use a more powerful model of RB
- split this into two rb - one for being the hub site, and one for internet connection.

RB450G is having 256MB RAM, and nothing is configured on the router except above said VPLS configuration and i have monitored when i connected all 4 sites, it shows Free memory around 236MB and CPU load is around 1% or 2% it was getting restarted within 5 minutes when i enable all 4 sites, but according to your suggestion i have tried following tings to get rid of it.

I have added static route for /32 to HUB IP in all 4 spoke router
Created drop firewall rule for igmp redirection in all 4 spoke router,

after that it is not giving out of memory error, and not even restarted while memory consumption and cpu load is same, but i not able to understand what why it was restarting before adding static route & drop rule for firewall in spoke routers.


Thanks

It probably has something to do with LDP or MPLS in general - but I wouldn't think it should crash the router.
Did you try upgrading to latest ROS?

Honestly, I think your current setup is a little cleaner this way so unless you're just losing sleep to know why it was rebooting, I would leave things like this.

It probably has something to do with LDP or MPLS in general - but I wouldn't think it should crash the router.
Did you try upgrading to latest ROS?

Honestly, I think your current setup is a little cleaner this way so unless you're just losing sleep to know why it was rebooting, I would leave things like this.

I have upgraded OS to 6.27

Thank man, you helped in a lot and i appreciate you time invested in guiding me, let me know anything if you need help in this i can do.

I will udpate you in 2 days about how it is working

It probably has something to do with LDP or MPLS in general - but I wouldn't think it should crash the router.
Did you try upgrading to latest ROS?

Honestly, I think your current setup is a little cleaner this way so unless you're just losing sleep to know why it was rebooting, I would leave things like this.

I have upgraded OS to 6.27

Thank man, you helped in a lot and i appreciate you time invested in guiding me, let me know anything if you need help in this i can do.

I will udpate you in 2 days about how it is working

It worked successfully 1 day, but after that same it is restarting again, i am herewith sending you /export output and log screenshot, pl suggest how to solve this issue.

Note: I have already tried replacing main RB450G router with new one but still same issue.


# jan/02/1970 03:07:20 by RouterOS 6.27
#
/interface bridge
add name=bridge1
/interface ethernet
set [ find default-name=ether4 ] disabled=yes
set [ find default-name=ether5 ] disabled=yes
/interface vpls
add disabled=no l2mtu=1500 mac-address=02:97:B5:D6:36:62 name=jgas-midc \
remote-peer=12.12.10.10 vpls-id=4:4
add disabled=no l2mtu=1500 mac-address=02:43:48:B7:57:A7 name=jgas-office \
remote-peer=12.12.10.9 vpls-id=3:3
add disabled=no l2mtu=1500 mac-address=02:9F:60:BF:6A:A7 name=vpls1 \
remote-peer=12.12.10.7 vpls-id=1:1
add disabled=no l2mtu=1500 mac-address=02:AE:AB:49:62:17 name=vpls2 \
remote-peer=12.12.10.6 vpls-id=2:2
/port
set 0 name=serial0
/interface bridge filter
add chain=forward in-interface=jgas-midc out-interface=jgas-office
add chain=forward in-interface=jgas-office out-interface=jgas-midc
add chain=forward in-interface=vpls1 out-interface=vpls2
add chain=forward in-interface=vpls2 out-interface=vpls1
add action=drop chain=forward
/interface bridge port
add bridge=bridge1 horizon=1 interface=vpls1
add bridge=bridge1 interface=vpls2
add bridge=bridge1 interface=jgas-midc
add bridge=bridge1 interface=jgas-office
add bridge=bridge1 interface=ether2
/ip address
add address=12.12.10.8/24 interface=ether2 network=12.12.10.0
/mpls ldp
set enabled=yes lsr-id=12.12.10.8 transport-address=12.12.10.8
/mpls ldp interface
add interface=ether2
/system clock
set time-zone-autodetect=no
/system identity
set name="RB450G Main"
/system routerboard settings
set cpu-frequency=100MHz

I think you're going to need Mikrotik support with this one.

Maybe upping the debug level on your logging and start logging to a syslog server could help because then you might get a few more pieces of information - information that will survive a reboot of the RB.

Did you ever find a solution?
I was running 6.20, out of memory error, upgrade to 6.27 kept happening.

This started completely random. Nothing had been changed for days, same basic config had been running for years, then all of the sudden out of memory errors and messages about network loops that can't exist.

I would look at replacing the 450g as an MPLS router. It only supports a max L2 MTU of 1522 which means you can't get a full 1500 byte frame across VPLS without fragmentation. Whenever we consult on an MPLS network, the first thing we do is get rid of routers that don't support the minimum MTU for MPLS. I haven't touched the 450G in a while, but I remember pulling a bunch of them out of MPLS networks because of the MTU issues and low CPU capability.

Here is the quick and dirty rule of thumb on MTU for MPLS in order to get a 1500 byte frame across VPLS.

Untagged VPLS - requires 1526 byte L2MTU and MPLS MTU
Tagged VPLS - requires 1530 byte L2MTU and MPLS MTU

MPLS is extremely MTU sensitive and we see customers fight all kinds of issues usually that go away once MTU sizes have been set properly on hardware that will support it.

Here is a thread that highlights the importance of L2 MTU and MPLS MTU in running VPLS.

http://forum.mikrotik.com/viewtopic.php ... 4&start=50