106
Deployment / Re: Cabling guide for VirtualBox
« on: November 18, 2016, 10:40:00 AM »
Yup, was about to say either mac spoofing if Hyper-V or promiscuous if ESXi / Virtualbox
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
108
General Discussion / Wanos 450 benchmark
« on: September 08, 2016, 11:03:50 PM »
Uploaded a video of a benchmark of the NOS-450 under ideal conditions. The 450 is replacing the 400.
Peak: 300Mbps Cold, 600Mbps Warm (approaching 5400rpm notebook drive limit)
https://vimeo.com/182006632
Peak: 300Mbps Cold, 600Mbps Warm (approaching 5400rpm notebook drive limit)
https://vimeo.com/182006632
109
Configuration / Documentation
« on: September 02, 2016, 08:42:51 PM »
Please see full configuration guide at: Admin Guide
The Quick Configuration Guide be found at: Quick Config Guide
The Quick Configuration Guide be found at: Quick Config Guide
110
Installation / Re: typo in hyperv guide
« on: August 12, 2016, 10:18:30 PM »
Good point, thanks Kyle.
111
General Discussion / v.3.1.x
« on: July 07, 2016, 04:22:31 PM »
Note : Change Log moved to: http://wanos.co/docs/docs/knowledgebase/changelog/
Version 3.1.x:
This is a major update, and not backwards compatible with earlier versions.
The update requires a v2.6.2 - 3.1.3 systems. v.3.1.x will likely be one of the last v3 updates. The much anticipated v4 should be the next major update.
wget http://wanos.org/updateinfo/update-3.2.3.sh
wget http://wanos.org/updateinfo/update-3.2.3.tar
bash update-3.2.3.sh update
v.3.1.4
Minor fix to set NetFlow REAP time to 4 minutes instead of 4 seconds
v.3.1.3
Fixed UDP Encapsualation WRED in 3.1.2
v.3.1.2
Major:
PLR optimization - PLR causes TCP sessions to accelerate which is good when there is available bandwidth, but when drops occur due to congestion the PLR acceleration can cause TCP to not slow down sufficiently causing the congestion not to equalize. 3.1.2 implements a special Random Early Detection algorithm to avoid congestion when PLR acceleration causes TCP to not slow down sufficiently. In short PLR and stream compression should now play better together with congestion on the WAN yet still provide the acceleration when bandwidth is available.
Minor:
New graphs displayed NaN values when value was larger than 4GB in the total column.
Changes to make console access more reliable. Console access limited to ttyS0 / Com0 port.
Fixed IO benchmark on Ubuntu.
Ubuntu bare metal image should now partition and format free space automatically on first boot.
Minor cosmetic fixes, e,g platform info, WAN Tx shaper tooltip, graph values.
450 and 300 NIC bypass drivers added.
450 bypass on/off switch via LCD panel.
v.3.1.1
Optimization to reduce netflow load spikes every 2 minutes.
Static routes can now be added via the static_routes file.
Additional TCP and UDP header checks added whether offloading is supported or not.
Additional 2-byte checksum added to catch damaged compressed packets.
v.3.1.0
The update has been created for clients experiencing instability when handling corrupt TCP headers.
The patch also enables receive checksumming on to the NIC if it is supported.
Version 3.1.x:
This is a major update, and not backwards compatible with earlier versions.
The update requires a v2.6.2 - 3.1.3 systems. v.3.1.x will likely be one of the last v3 updates. The much anticipated v4 should be the next major update.
wget http://wanos.org/updateinfo/update-3.2.3.sh
wget http://wanos.org/updateinfo/update-3.2.3.tar
bash update-3.2.3.sh update
v.3.1.4
Minor fix to set NetFlow REAP time to 4 minutes instead of 4 seconds
v.3.1.3
Fixed UDP Encapsualation WRED in 3.1.2
v.3.1.2
Major:
PLR optimization - PLR causes TCP sessions to accelerate which is good when there is available bandwidth, but when drops occur due to congestion the PLR acceleration can cause TCP to not slow down sufficiently causing the congestion not to equalize. 3.1.2 implements a special Random Early Detection algorithm to avoid congestion when PLR acceleration causes TCP to not slow down sufficiently. In short PLR and stream compression should now play better together with congestion on the WAN yet still provide the acceleration when bandwidth is available.
Minor:
New graphs displayed NaN values when value was larger than 4GB in the total column.
Changes to make console access more reliable. Console access limited to ttyS0 / Com0 port.
Fixed IO benchmark on Ubuntu.
Ubuntu bare metal image should now partition and format free space automatically on first boot.
Minor cosmetic fixes, e,g platform info, WAN Tx shaper tooltip, graph values.
450 and 300 NIC bypass drivers added.
450 bypass on/off switch via LCD panel.
v.3.1.1
Optimization to reduce netflow load spikes every 2 minutes.
Static routes can now be added via the static_routes file.
Additional TCP and UDP header checks added whether offloading is supported or not.
Additional 2-byte checksum added to catch damaged compressed packets.
v.3.1.0
The update has been created for clients experiencing instability when handling corrupt TCP headers.
The patch also enables receive checksumming on to the NIC if it is supported.
113
Deployment / Re: How to Deploy WANOS on AWS
« on: June 19, 2016, 08:17:37 PM »
According to the AWS documentation:
Error starting instances: Invalid value <instance ID> for instanceId. Instance does not have a volume attached at root (/dev/sda1).
You attempted to start the instance before the VM import process and all conversion tasks were complete.
Resolution
Wait for the VM import process and all conversion tasks to completely finish, and then start the instance.
I am not sure if this is accurate though and whether it will be the only snag you run into.
The AMI image is on the road map, so we can accelerate this if you have a specific use case that requires Wanos on AWS.
Error starting instances: Invalid value <instance ID> for instanceId. Instance does not have a volume attached at root (/dev/sda1).
You attempted to start the instance before the VM import process and all conversion tasks were complete.
Resolution
Wait for the VM import process and all conversion tasks to completely finish, and then start the instance.
I am not sure if this is accurate though and whether it will be the only snag you run into.
The AMI image is on the road map, so we can accelerate this if you have a specific use case that requires Wanos on AWS.
114
Deployment / Re: How to Deploy WANOS on AWS
« on: June 19, 2016, 07:49:09 PM »
Hi, is this the MicroCore or Ubuntu version?
115
General Discussion / Re: Experience with vmotion traffic
« on: June 06, 2016, 06:22:55 PM »
Hi Pandora,
Lets just make a note for the record this is for a research project and that the recommendations here may not be applicable to business production networks. That said the very early vMotion tests showed promising results.
Yes, I see L2 and L3 is now supported and upto 150ms latency.
The vSphere server benchmarks seemed sufficient for testing? Perhaps the datastore just needs to move to the SSD drives? The Atom and Celeron based appliances will probably have less throughput than the current servers. Perhaps reserving more CPU Mhz may improve things if this is the goal.
If dedicated hardware is required, the replacement for the end of sale 200 is the 250. Using compression only the 250 should be able to do 100 Mbps over 50 Mbps at 2x compression ratio. For vMotion the 250 can provide 30 Mbps with deduplication enabled.
But what I really think is required is to define the long distance vMotion link speed. I did not read the cloudnet paper word for word but I see they mention that they got good results at 50 Mbps. What is your target vMotion WAN link speed?
I think the target WAN link rate, in this unique case, is the most important metric and then the hardware can be spec'd around the target rate.
Lets just make a note for the record this is for a research project and that the recommendations here may not be applicable to business production networks. That said the very early vMotion tests showed promising results.
Yes, I see L2 and L3 is now supported and upto 150ms latency.
The vSphere server benchmarks seemed sufficient for testing? Perhaps the datastore just needs to move to the SSD drives? The Atom and Celeron based appliances will probably have less throughput than the current servers. Perhaps reserving more CPU Mhz may improve things if this is the goal.
If dedicated hardware is required, the replacement for the end of sale 200 is the 250. Using compression only the 250 should be able to do 100 Mbps over 50 Mbps at 2x compression ratio. For vMotion the 250 can provide 30 Mbps with deduplication enabled.
But what I really think is required is to define the long distance vMotion link speed. I did not read the cloudnet paper word for word but I see they mention that they got good results at 50 Mbps. What is your target vMotion WAN link speed?
I think the target WAN link rate, in this unique case, is the most important metric and then the hardware can be spec'd around the target rate.
118
Configuration / Re: Issues with initial Setup
« on: May 26, 2016, 05:35:13 PM »
Hi,
Yes, that is correct. This means to avoid connecting wan0 and lan0 to the same LAN or VLAN. To be more precise a switch that does not run spanning-tree. Wanos is a two port switch. The same care when connecting a switch to the network must be taken when connecting Wanos.
To recap yes, the pfSense needs to connect to the wan0 side and the rest of the network to the lan0 side. This could be simply to connect the pfSense directly into the wan0 port and lan0 into the switch.
Alternatively, when connecting both lan0 and wan0 to the same switch: wan0 and pfSense could be connected to a VLAN X and the rest of the network and lan0 can remain in the default current VLAN. The Wanos switch then becomes a Layer2 gateway for traffic between the LAN and the WAN.
Yes, that is correct. This means to avoid connecting wan0 and lan0 to the same LAN or VLAN. To be more precise a switch that does not run spanning-tree. Wanos is a two port switch. The same care when connecting a switch to the network must be taken when connecting Wanos.
To recap yes, the pfSense needs to connect to the wan0 side and the rest of the network to the lan0 side. This could be simply to connect the pfSense directly into the wan0 port and lan0 into the switch.
Alternatively, when connecting both lan0 and wan0 to the same switch: wan0 and pfSense could be connected to a VLAN X and the rest of the network and lan0 can remain in the default current VLAN. The Wanos switch then becomes a Layer2 gateway for traffic between the LAN and the WAN.
119
Installation / Re: Install to ESXi 4.1
« on: May 19, 2016, 03:27:00 PM »
Pleasure,
Also before testing, first update:
wget http://wanos.org/updateinfo/update-3.0.3.sh
wget http://wanos.org/updateinfo/update-3.0.3.tar.gz
bash update-3.0.3.sh update
Also before testing, first update:
wget http://wanos.org/updateinfo/update-3.0.3.sh
wget http://wanos.org/updateinfo/update-3.0.3.tar.gz
bash update-3.0.3.sh update
120
General Discussion / Re: Experience with vmotion traffic
« on: May 19, 2016, 11:15:55 AM »
Hi Pandora,
Thanks for the email. Sure, accepted the meeting invite to take a look at the configuration.
Thanks for the email. Sure, accepted the meeting invite to take a look at the configuration.