Messages

16

Deployment / Re: vmware esxi5.0 production environment

« on: March 26, 2014, 06:42:16 AM »

Hi, yes, this is possible since the appliance is a bridge/switch. Think of the inline device as another switch. This is also why no routing needs to be configured.

You can use either setup. If you want to keep just using one vlan, then the wan0 needs to be connected directly to the firewall internal interface. If the Firewall is connected to the switch or maybe you have two firewalls, then the two vlans (inside/outside) can be used. Wanos will bridge the two networks (vlan10 and vlan20), so they are actually one network. The two different vlans are used to ensure traffic flows through the bridge appliance.

17

Installation / Re: Hardware Compatibility

« on: March 25, 2014, 04:16:42 PM »

Great, thanks for the feedback Michael. This question gets asked frequently so I am sure this thread will help someone else as well.

18

Installation / Re: Hardware Compatibility

« on: March 25, 2014, 02:46:43 PM »

Yes, just ensure both have a link connect somewhere, so the second interface can connect to anything, just to give an 'up' operational state.

19

Installation / ESX vSwitch Topologies without physical NIC's

« on: March 25, 2014, 02:16:21 PM »

First see http://wanos.org/wan-optimization/?p=1324 for configuration without physical interfaces

Although it is best to run with physical interfaces, Wanos can run in-path without the physical network interfaces. Here are two more scenarios to achieve this:

1) When the routing function is handled by a virtual router or firewall that are not establishing encrypted tunnels, the Wanos device can be placed in front of the vRouter/vFW or on the Wan side in other words. Wanos is therefore placed between the router and the ISP.


2) When the routing function is handled by a vRouter/vFW and it also builds encrypted tunnels e.g. IPsec, Wanos can be placed between two vRouters/vFW's.


In both scenarios the lan0 and wan0 still needs to be in separate vswitches/port groups vlans with promiscuous enabled to bridge the traffic flow.

20

Installation / Re: Hardware Compatibility

« on: March 25, 2014, 02:06:05 PM »

Yes, very strange indeed. Did the switch perhaps disable the ports?

21

FAQ / Re: High Availability - Bypass

« on: March 25, 2014, 12:26:39 PM »

Another high availability design with dual WAN links and using VRRP/HSRP:

22

Deployment / Re: vmware esxi5.0 production environment

« on: March 25, 2014, 09:55:37 AM »

In this diagram lan0 and wan0 connects to the same switch using inside and outside VLANs (PVSTP)

23

Deployment / Re: vmware esxi5.0 production environment

« on: March 25, 2014, 09:54:08 AM »

Another diagram. In this scenario the wan0 connects directly to the Router/Firewall

24

Deployment / Re: vmware esxi5.0 production environment

« on: March 25, 2014, 07:32:03 AM »

Hi, very good questions

1) So far so good

2) No, Wanos is just a bridge/switch. No changes to the existing IP addressing is required. The IP Addresses on Wanos is used between the devices and for management of them, but other devices don't need to know about them or in other words no gateways need to be changed.

3) For production networks you need dedicated NIC's for the lan0 and wan0 or use different VLAN's. Since promiscuous is enabled it sounds like you got it right. Assuming both NIC's connect to the same 2960, they need to be in two different VLAN's as well. The switch should be running 'spanning-tree mode rapid-pvst' for best results, but make sure it's at least PVST or MST. MST is a bit more complicated, but essentially the inside and outside VLAN should be in different instances.

With both NIC's connected to the same switch and running Per Vlan Spanning Tree it should stay up. The Firewall should be on the same outside VLAN as wan0 and the VM's and other servers on the lan0 VLAN.

The concept is the same as for the high availability design, just without the second backup cable: High Availability

25

Installation / Re: Hardware Compatibility

« on: March 24, 2014, 10:45:14 PM »

Interesting yes, if both NIC's are exactly the same, then the driver should be ok. Is it possible that one of the interface cards needs a reset in the slot? Also try reset to defaults with /etc/wanos/clean.sh (Needed when MAC addresses change)

Troubleshooting commands:
ifconfig tun0
# If this is up and showing 192.168.1.200 it means everything booted up correctly. To access the GUI a PC is needed on the same 192.168.1.0/24 range or change the address from the cli with 'wanos-cfg'

ifconfig lan0
ifconfig wan0
# To check that the interfaces have been detected

/etc/wanos/wanos-log
# Maybe more info there

Very rarely it is needed to reinitialize the Ethernet drivers e.g. if the driver is bnx2 the following commands would reset the driver: 'rmmod bnx2 && modprobe bnx2'

26

Troubleshooting / Re: No traffic optimization

« on: March 21, 2014, 07:26:11 PM »

Hi Sasha,

Ok, thank you for the feedback. How Wanos works is by reducing traffic sent between the Core and Edge devices. Reducing the traffic normally translates to a speed increase. In your case you did the test multiple times with FTP. Since the firewall dropped traffic once optimization was enabled it is relatively safe to assume the setup is configured correctly (but there might be something if we look into the detail).

Under the following condition optimization will provide no reduction or acceleration:

• Encrypted traffic (SSL, HTTPS, Signed SMB)

Under the following conditions optimization will provide traffic reduction but not necessarily throughput acceleration:

• Core LAN speed is close to or less than WAN speed or put another way the WAN speed is close to or more than Core LAN speed. e.g. 1 Mbps WAN and 1 Mbps Internet Connection at the Core. Traffic can't transfer faster than the Core LAN network connection. Traffic needs to make it from the source all the way to the destination. If any of the links are lower than the Wanos link being optimized, traffic will be limited to the weakest link. Hence you want to put a Wanos solution over these type of links
• Latency between FTP server and Wanos Core. If the latency is very high between the Core and the FTP server. Remember, only traffic between the Core and the Edge is optimized, so if the file server is far away with a high latency then the link between the FTP server and Core LAN becomes the weakest link. Again the Wanos solution needs to span across the weakest links.
• The speeds being tested is faster than what the hardware can handle

To give you an accurate reason for why you are not seeing acceleration we can look at the following:

Free traffic and lan0 vs wan0 statistics:
1) The results either tell us traffic is being reduced over the WAN or
2) Traffic is not being reduced so we need to go back to the configuration, network layout and protocols to see whats going on

WAN speed, Core - FTP Server network speed and latency between the Core and the FTP server
1) We might find WAN speed is too high for the hardware
2) WAN speed is more or less the same as the Core LAN - FTP Server link
3) Core LAN - FTP Server link is held back by high latency
4) Test with WAN Simulation enabled

27

Troubleshooting / Re: No traffic optimization

« on: March 19, 2014, 12:41:15 PM »

There are two best case scenarios:

1) Best for compression is say a 10MB .txt/.doc/.xls with basically repetitive strings e.g. all 0's or 1's or some pattern that repeats. In this case it is possible to show a very good result like 90% reduction

2) Best for deduplication is when the same file is sent a second time. E.g take a 10MB .zip file and send over the WAN. The first copy should be near WAN speed since it is already compressed. The second copy should give you 4-10x speed throughput.

28

Troubleshooting / Re: No traffic optimization

« on: March 19, 2014, 12:37:17 PM »

Hi Sasha,

Thanks for the feedback. Some traffic might still pass-through without optimization. Is the firewall dropping the traffic without optimization or is the firewall dropping the optimized traffic?

29

Features / Re: Out-of-Path Options

« on: March 18, 2014, 01:24:18 PM »

PBR: Either a Router or Layer 3 switch is used to direct traffic from the lan to the virtual lan0 address. Return traffic from the wan is redirected to the wan0 addressl. Fail-over is achieved with an IP SLA tracking feature. During failover or maintenance for example, tracking removes the route policy.



Example Config:

ip sla 1
icmp-echo 10.0.0.2
frequency 4
ip sla schedule 1 life forever start-time now
!
ip access-list extended lan0
deny ip host 10.0.0.2 any
permit tcp 10.1.1.0/24 192.168.1.0/24
ip access-list extended wan0
permit ip 192.168.1.0/24 10.1.1.0/24
!
route-map lan0
match ip address lan0
set ip next-hop verify-availability 10.0.0.1 1 track 1
!
route-map wan0
match ip address wan0
set ip next-hop verify-availability 10.0.0.2 1 track 1
!
interface fastEthernet0
description LAN
ip policy lan0
interface Serial0
description WAN
ip policy wan0
!

 
In the Router mode, routing can be used to direct traffic from the wan to the wan0 address and traffic from lan to the lan0. It is also possible to set the default gateway to the virtual lan0 addresses.


Example Config:

ip route 10.1.1.0 255.255.255.0 10.0.0.2
ip route 10.2.2.0 255.255.255.0 10.0.0.2

30

Installation / Firewalls

« on: March 17, 2014, 10:06:48 AM »

When a firewall is used in the WAN in-between two Wanos appliances, it needs to permit IPComp (IP Proto 108) traffic and TCP option 76.
GRE Encapsulation is also available.

UDP Encapsulation is often the simplest method to work around firewalls, but introduce additional overhead.