New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Well, it deffinetely is possible and is widely done in my experience. Can't say if it is the best option, however at least at the time of speaking it is not causing any kernel instability.
The hosts involved have agreed to enable gre.
and tunnel broker is based on gre.
The main reason I'm looking at gre is stability as its at kernel level.
And he.net tunnel uses it.
Incorrect. HE.net uses 6in4 which is IP protocol number 41. GRE is IP protocol number 47. They are two completely different protocols.
Seriously? You might as well exit the industry then. What's ok to sell now may not be okay to sell later!!!!!oneoneone1111
Silliest argument I ever saw anywhere.
It is easier, use two Mikrotik instances on both locations and create an Ethernet over IP (EoIP) interface on both instances and all is fine
This can be done within 2 minutes.
We using this to bridge the client VXLANs for their private networks between all locations.
Interesting, what about the actual re-routing of the traffic, is it handled by mikrotik?
It would be more convincing if you can take a case that is related to my case to show me the flawed case though. But still, the argument still applies even for your case. Now HDD are still pretty dominant in both desktop and server environment. Imagine that 10 years later where SSD will be the norm, RAM with battery backup to be a more premium option, so selling hardware w/ normal HDD may not be a good option anymore.
Anyway, what I wanted to say is that if you're not planning to support it, then may as well as not enable it as you may not have the time or skills to handle with the rising potential issues when it comes by.
p/s: this is a bit offtopic, so if you still have desire for further discussion then cestpit is the way to go.
@Alex_LiquidHost It builds a layer 2 on top of your layer 3 infrastructure over ip encapsulation. You can give the layer 2 interfaces ip addresses to route some networks to it or build a big layer 2 between all locations.
We have in all our colos two or three CCR1036 to handle the traffic and it works fine. We have in this network for our VTEPs (OpenvSwitch) to handle the private networks over multicast.
While that is true, it is not really related to the issue at hand. That is OVZ is not as stable as xen, for example, the more processes you have, the higher the instability, softlocks, race conditions, etc.
There is nothing wrong in trying to add as little straws to the camel as possible and the fact that bugs are introduced all the time is not helping either.
reduce the surface of attack is a very good defense method, the fewer modules and features enabled, the better the chances it wont crash, at least in theory. And, it is simple for a provider to do it, if a certain feature is required by one/two customers, it is worth to tell them you do not support it than annoy 100 with crashes and instability. Experience shows that if you experience 2-3 crashes a month on one node, about 10% of the customers will leave, which means 6-10 on larger nodes, if one new customer comes and asks for x module, it is better to say no and try to protect the old ones.
I agree with the above but...
VPS Providers should enable the most common required kernel modules on OpenVZ Nodes by default. I regularly setup OpenVZ Nodes.. and each time I set them up I enable the same modules each time. Kernel/IPTable Modules.. each time I find one that is not enabled. I will enable it for that particular client and schedule maintenance when possible. And then add that module to my list for future deployments.
Not many people that use OVZ need gre... Not many people in general, here it is a technical forum and I bet half of the people here never setup a gre tunnel, the other half is probably using some sort of xen/kvm/vmware/virtualbox, whatever, just a tiny minority will need it on OVZ and it is simply not worth it.
I'm surprised that people still use OVZ when there is XEN or KVM. I guess alot people just prefer a lower price over Quality.. Pretty shocking. Ovz should die already.. The only people that I've seen supporting this virtualization are providers who provide it or employees of a company providing it.
@Mark_R You're on lowendbox. You'll find most providers who do charge a considerable amount of money will use Xen or KVM or VM Ware. Low End Box only represents a small amount of the hosting/vps business.
Because when it comes to bare-metal performance, OVZ wins?
but didn't u know some OVZ providers oversell? that makes it bad!!!one!!1
OMG DO ALL THE OVERSELLING! WHOOP! WHOOP!
Did any of you guys consider it might not be just because OVZ is just easily oversold? my major problem with it is that alot of stuff just doesn't work with it by default. I really dont feel like sending tickets in to get every single module enabled just to get something done I could've done within seconds in a KVM/XEN virtualization.
And do you know why? Because all containers share the same kernel which has it's own benefits (and disadvantages).
Why doesn't that kernel has everything enabled like XEN/KVM? It sounds like you know alot about it.
It's not that Xen/KVM have it all enabled by default it's that you're running your own kernel (with its own overhead - RAM/CPU/etc usage, aswell as other drawbacks like stability) and you can add and remove modules on the fly. With OpenVZ the host node can add and remove modules at will but it is disabled for the containers to be able to change which modules are enabled as it effects everyone else on the node.
When you ask your host to enable a module they're doing on the host node what you'd do on your KVM/Xen VPS.
I think this is more about market/price than virtualization. Strictly comparing features, technical capabilities and price, not really the technical means on how they are achieved.
OVZ has advantages and disadvantages, same, xen/kvm, xen pv is difficult to repartition, does not support some oses or the support is sketchy/alpha grade, KVM is slower with much overhead and they are both more expensive than OVZ. Since in this market every penny counts, OVZ is still strong, some people are overselling, others are only overcommiting, still, OVZ is a bit unstable, even without overselling, but does have some advantages, among which speed and price are the most notable.