John,
I just wanted to throw our hat into the MPLS wanted ( more like NEEDED) pile. We have hundreds of Mikrotik Routers installed and we are starting to hit some scaling issues for some new business models that we are looking at. We have the need to build in MPLS type of functionality to allow us to build virtual circuits across many routers. We need to be able to do this in a scalable way, tens of thousands of carefully managed, tracked and routed vlans is not going to cut it. Can you shed some light on where this is in the queue?
Mike Bernstein
SimplyBits, LLC.
MPLS is in the long term agenda, but there are extensive standards of which most parts are not needed. It will take allot of work to get the right mix without taking all of our development time. At the moment, we are getting close to completing our own bgp and moving on ospf -- in the routing-test.npk package. After this, we can move on mpls. We plan on implementing vlan in vland -- double vlan first. This is a simple alternative to mpls that is easier to administer and has the good benefits for the admin cost and uses of mpls. We know some large providers that prefer this to mpls.
John
John
I am very interested as to when this is going to be available.MPLS is in the long term agenda, but there are extensive standards of which most parts are not needed. It will take allot of work to get the right mix without taking all of our development time. At the moment, we are getting close to completing our own bgp and moving on ospf -- in the routing-test.npk package. After this, we can move on mpls. We plan on implementing vlan in vland -- double vlan first. This is a simple alternative to mpls that is easier to administer and has the good benefits for the admin cost and uses of mpls. We know some large providers that prefer this to mpls.
John
Any ideas ? I haven't really followed the BETA releases.
I'll second (or third, or whatever) the request for MPLS.
Q in Q will indeed be very useful, but it's not quite the same. The ability of MPLS to work, without any special configuration on intermediate devices, is VERY nice. Now that multiple complete routing planes are available in RouterOS, it should not be too much of a strech to get at least a basic MPLS implementation going.
Although, if given the choice, I would actually prefer VPLS, since most of our customers that need such a service have several locations. An intelegent, transparent multi-point bridge, with stringent control and QOS, yet only needs to be setup on the various end points (or even better, just in the provisioning DB, using something like radius for control); and which does not burden intermediate devices (like switches or radios) with any extra information (MACs mostly), would be truly wonderful (and would no doubt prompt another nice round of "vendor C" dumping, as MT has done many times before).
--Eric
Q in Q will indeed be very useful, but it's not quite the same. The ability of MPLS to work, without any special configuration on intermediate devices, is VERY nice. Now that multiple complete routing planes are available in RouterOS, it should not be too much of a strech to get at least a basic MPLS implementation going.
Although, if given the choice, I would actually prefer VPLS, since most of our customers that need such a service have several locations. An intelegent, transparent multi-point bridge, with stringent control and QOS, yet only needs to be setup on the various end points (or even better, just in the provisioning DB, using something like radius for control); and which does not burden intermediate devices (like switches or radios) with any extra information (MACs mostly), would be truly wonderful (and would no doubt prompt another nice round of "vendor C" dumping, as MT has done many times before).
--Eric
VPN PPTP like VPLS
Eric,Q in Q will indeed be very useful, but it's not quite the same.
--Eric
what did you mean about Q in Q ? How did you configure your network to improve Q in Q ? Is that a VPN PPTP authenticating users in Radius and configuring proxy-arp ?
Please, I search a lot in this forum and anothers, but i never saw a solution to improve like Frame Relay VPN´s using PPTP VPN in Mikrotik. I want sell solution that a group of users connnect at distributed PPTP Servers in one of my 6 Mikrotik towers authenticating at freeradius in our datacenter (Central Node). And that each PC or LAN (with linksys VPN router, i.e), at the same group, can connect each other. But VPN PPTP users in diferent groups can´t connect another, like frame relay vpn at carriers.
I hope have been clear with my awful english, but I would like to know how do you do there to improve various VPNs (various PPTP VPN groups) at your Mikrotik Network.
Thank´s !
Sérgio Brito
Q in Q does not have anything directly to do with VPNs. It is simply the layering of one VLAN tag upon another VLAN tag. Just basic double encapsulation.
It's a very useful techneique, but only works where you maintain a layer 2 infrastructure. The most common uses for Q in Q usually involve multi-access common carrier networks, where multiple ISPs can share the same physical network, be completely isolated in their own VLAN, yet not lose the ability to do their own VLAN scheme within their virtual lan.
This use is similar to some of the more common uses of non-VPN MPLS, except that it requires a consistant underlying layer 2 infrastructure, while MPLS operates at layer 3 (well, mostly...).
For your application, neither Q in Q, nor MPLS fits the bill exactly, athough you may find either or both useful (VPLS would be nice in this case).
MT has not, as of yet, implemented any of these. Apparently Q in Q will be first.
Here is an idea for your setup:
Setup your radius servers to pass back a framed-ip-address, as well as an in-filter and an out-filter.
Keep your various VPN groups tied to a particular range of IPs, and setup your in-filter and out-filter chains to allow communication only between addresses within the same range.
Then, depending on the scale of your opperation, set something up to properly attract the traffic to the destination concentrator. For a very small setup, proxy-arp would be fine; with a somewhat larger setup (not huge), OSPF with redistribute-connected would do the trick. With a huge setup, it becomes more complex.
--Eric
It's a very useful techneique, but only works where you maintain a layer 2 infrastructure. The most common uses for Q in Q usually involve multi-access common carrier networks, where multiple ISPs can share the same physical network, be completely isolated in their own VLAN, yet not lose the ability to do their own VLAN scheme within their virtual lan.
This use is similar to some of the more common uses of non-VPN MPLS, except that it requires a consistant underlying layer 2 infrastructure, while MPLS operates at layer 3 (well, mostly...).
For your application, neither Q in Q, nor MPLS fits the bill exactly, athough you may find either or both useful (VPLS would be nice in this case).
MT has not, as of yet, implemented any of these. Apparently Q in Q will be first.
Here is an idea for your setup:
Setup your radius servers to pass back a framed-ip-address, as well as an in-filter and an out-filter.
Keep your various VPN groups tied to a particular range of IPs, and setup your in-filter and out-filter chains to allow communication only between addresses within the same range.
Then, depending on the scale of your opperation, set something up to properly attract the traffic to the destination concentrator. For a very small setup, proxy-arp would be fine; with a somewhat larger setup (not huge), OSPF with redistribute-connected would do the trick. With a huge setup, it becomes more complex.
--Eric