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.


Messages - ahenning

Pages: 1 ... 40 41 [42]
616
Configuration / By-pass rules required on which end?
« on: April 04, 2014, 10:11:35 AM »
Traffic policy rules apply to traffic going out on wan0.

To bypass traffic from a Server going towards a remote site, the rule would normally be applied on the server side device.
To bypass upstream traffic from the remote site going towards the server, the rule would be applied on the user side device.

617
Configuration / Re: Traffic Policies
« on: April 03, 2014, 03:28:31 PM »
Hi,

Ok, the traffic policy should work as intended if one more line is added:

Rule #99 as in this image:


Basically the only thing needed is to replace 172.16.100.0/24 with 192.168.100.0/24

618
Troubleshooting / Re: No traffic optimization
« on: March 31, 2014, 06:49:33 PM »
Hi Sasha,

Ok, great to hear that. Yes, optimization is enabled in both directions on both Edges and Cores by default. The configuration of the resources is optimized to provide the best Core -> Edge optimization, but it is still possible to do 10X between fully meshed Edges.

The reason behind this is since the majority of network users receive more traffic from a central point than they normally send between each other. This allows for a very small Edge device but also ensures the majority of the resources are applied to the source of the network problem.

619
General Discussion / Re: Its Alive!
« on: March 15, 2014, 07:26:16 PM »
Hi, yes, for it to work both devices are needed, since deduplication works on a database of bit patterns. Essentially only the database references are sent over the WAN, and the receiving end knows how to recreate the original data. Having both at the same site is ok as a lab to test, but for a production network all traffic is still going to be sent over the WAN/VPN/Internet, so a device on the remote site is needed.

620
FAQ / High Availability - Bypass
« on: March 10, 2014, 01:46:41 PM »
How can high availability be achieved to avoid total loss of network traffic flow?

1) Bypass NIC's. Wanos Appliance 200 has a built-in bypass NIC.

2) Since Wanos is a bridge, another easiest method to create high availability is to run a second backup network cable along side the Wanos bridge appliance. Convergence happens within a few milliseconds and the switch-over is unlikely to be detected by a continuous ping. Unlike leading vendor fail-over scenarios, traffic sessions are not reset during the switch-over and users are unaware of the network change.

3) With out of path deployment, IP SLA can be used to track the status of the optimization device and remove the PBR rule when required.

4) External bypass switches. This is an option if they are gathering dust.

621
Installation / Re: Installing.
« on: March 09, 2014, 04:58:48 PM »
Good point about the installation. I agree, it is a bit tricky to get going. Many of these network appliances don't have CD-Rom's, but perhaps an external  CD-Rom is still a better option to get the install on disk than using dd/win32disk imager.

I could be wrong but I think the 1020's are dell 850 machines, so the network interface could possibly be something like a Dell CH833 (Silicom MPB-PXG2BPI). This card model would be the first step to see if it would be possible.

622
Installation / Re: Installing.
« on: March 09, 2014, 04:05:35 PM »
Ok, yes, unexpected errors there. I'll take a look into it to see if it is possible to provide a better description. Any feedback from testing would also go a long way in improving the solution. What would you consider key features/functionality?

A note on the Riverbed (and similar) appliances, there have been a number of requests to enable the bypass NIC. Depending on the model this may be possible.

623
Installation / Re: Installing.
« on: March 09, 2014, 02:36:50 PM »
Alternatively adding a third network interface or a USB ethernet adapter could also work. It is also a good idea to reset to defaults with '/etc/wanos/clean.sh' when changing network interfaces.

624
Deployment / Re: Working with VPN
« on: March 06, 2014, 10:07:29 AM »
Ok, got it, so the FW's are establishing the VPN tunnels between the sites. In this case, since the traffic will be encrypted, the Wanos device needs to be between the users and the FW.

Regarding inline deployment: The IP addresses on the machines are for management of the devices and communication between them. The rest of the network is not aware of these IP addresses (e.g. no need for configuring additional gateways). In other words, if the FW is handing out DHCP at the moment to the users, this stays the same when the appliance is placed inline. One physical interface (wan0) connects to the FW and the second to the switch (lan0).


Edit:
For the archive: In this topology, the FW might need configuration to allow IPComp (IP Proto 108) and the auto detection TCP Option 76.
This is the recommended action. Alternatively UDP Encapsulation can be used.

625
Deployment / Re: Working with VPN
« on: March 05, 2014, 05:47:28 PM »
Hi there,

Ok, first thing to note is that for Wanos to work a device is needed on each side of the VPN. If the ISP-Router is establishing the VPN tunnel, a network topology more or less as the following would work:
Data Center / Server Network > FW > Wanos-Core > ISP-Router > VPN > Remote-Site-Router > Wanos-Edge > Remote-Users

Which Hypervisor will be used and will virtual machines be required on both sides? The best is to dedicate two network interfaces for the VM, then it behaves as a standalone appliance.

Did I understand the requirement right?

Pages: 1 ... 40 41 [42]