From StarOS Community Wiki
Jump to navigation Jump to search

How to create a PTP VDS link between two StarV3 devices

A Virtual Distribution System has several benefits, here are a few...

  • Valemount-approved method of creating a transparent bridge between two StarV3 devices.
  • Enables the operator to provide an Advanced Encryption Standard wireless link.
  • Allows you to quickly and easily create links between any StarV3 devices, anywhere.

Requirements: To proceed you must have two working StarV3 devices, and you are able to pass traffic between the two.

First you need to create a VDS Interface on the AP (Master) and CPE (Client).

select interfaces > virtual distribution system (VDS) setup -> create new vds

VDS Link Configuration

  • VDS Device = Unique device name (vds1, vds2, vds3..etc). Anything you want.
  • Enable Profile = You may enable or disable the VDS Interface by selecting this check box.
  • VDS roll = select whether the VDS Interface will be "master" or "client"
  • Status = This displays the current status of the VDS Interface. Displays "linked" or "not linked"
  • Profile Name = Create a unique profile name, both Master and Client must match.
  • Password = Anything you want, both Master and Client must match.
  • Enable CBQ = If you would like to bandwidth limit the VDS Link you will need to enable this feature.
  • RX = Set your receive throughput rate here.
  • TX = Set your transmit throughput rate here.
  • Compression Level = Decide here whether you want to enable Compression and the level, 1 - 9 with 9 being the most compression, of compression you would like.
  • AES Encryption = Enable or Disable AES Encryption.
  • Keepalive = Enable or Disable the Keepalive feature.
  • VDS Master IP = Gateway IP of the "Master" side of the VDS Link.

Click "OK"

Once you have made all necessarry config changes you will be able to reconfigure, set IP assignments, monitor net traffic(Beacon) and delete the newly created interface.

select interfaces > virtual distribution system (VDS) setup -> vds1

  • Reconfigure this device = You may make any changes previously made to the VDS Interface here.
  • IP Assignments = Assign your IP assignments here.
  • Beacon Realtime Traffic Monitor = Monitor network traffic flowing through your VDS link here.
  • Delete This Device = Delete the VDS Interface.

To complete the VDS link you will need to bridge the VDS and ethernet interfaces together (Client Side).

Valemount's vision of VDS application

Following text was posted by Lonnie on 10. July 2008. on StarOS forums and explains how he thinks VDS should be applied:

We create a Master VDS with multiple sessions on the new Server firmware. The Master has a bridge number set, but that is simply for its own internal bridging of the clients as they connect. It is NOT bridged to any physical device. It gets a public subnet assigned to the Master device. We use ISC DHCP listening on the VDS device and it hands out dynamic and static (based on the MAC address) IP addresses. We set compression to 1 on the Master.

The client gets an ESSID, mode (x2,x4, B,G, A, etc), power, rate auto, distance, country code, vds1 gets ID and password, IP of Master. The Ethernet gets no IP and is bridged to the VDS device. The radio use DHCP Client to get IP and default route. No automated routing is required, ie RIP or OLSR.

What this does is connect the client devices back to the Master device, as if a long cat5 patch cord had been used. The DHCP Server hears all their Ethernet broadcasts and gives them the TCP info using DHCP.

Pluses -->

If you deny the user an IP and proper info, then they are not connected. The Ethernet does not have an IP so they cannot beat on your SSH. If they do get a VDS tunnel, then they cannot see your underlying network and cannot beat on your repeaters trying to get in with SSH. All they can see is the Master VDS and using simple firewall rules you can block them from seeing the other customers and all underlying backbone infrastructure.

This allows you to have a perfectly routed backbone and it simplifies the routing tables because you do NOT need the individual radio entries for the Client Ethernet IP subnet --> it does not exist. So we have removed the bulk of routing entries from the backbone. No longer do you have to bridge your entire network simply because you started with the wrong design. Just use the multiple VDS and have the best of both worlds. It gives you a LAN on a LAN, and they are separate.

Using this you can even do authentication and IP handout for other areas, anywhere in the world. All you need is to be able to ping the Master IP. We have Thailand and Minnesota connecting to us and they have full use of everything. Compression helps with traffic over the Internet.

If you change the AP the client connects to then it is still seen by the Master as UNCHANGED. It gets the same IP, etc, so it roams, but not the way people want IP phones to roam.

Minuses --> We do lose QOS with this technique, but we are working to fix that.