CPE Setup

From StarOS Community Wiki
Jump to navigation Jump to search

There are several approaches to setting up the addresses and the routing to the customer's equipment. Quite a lot of the StarOS forums deal with these issues. Two major factors are whether to provide a public IP address to the customer's equipment, and whether to use any kind of bridging on the CPE. A spirited discussion of some of the issues can be seen on the 11+ pages of this thread: [1]. The folks at Valemount are generally opposed to bridging in any form, apparently for theoretical, practical, or religious reasons, and they seek to discourage StarOS users from using it. Many of us use it anyway, successfully.

Below are descriptions of some approaches that people use to setup a customer radio.

CPE Setup w/NAT and DHCP Auto-Auth

This is my standard CPE setup. We provide a public IP address to the CPE's wpci interface and NAT a private subnet to the customer's LAN.

interface configuration

  • Setup the wireless interface.
    • interface > wpci1 > ip assignments. Assign your static IP assignments here.
    • interface > wpci1 > wireless configuration > config current card.
      • ENABLED = Turn your wireless card on or off, select for on.
      • ESSID = your essid
      • Channel = auto
      • Transmit Rate = (<-75 lock on 11)
      • Link Distance = (actual +2 miles)
      • Country Code = US
      • TX Power Overide = Only set as high as you need it. Not above 20.
      • Cloaking = 1x/2x/4x - 20/10/5MHz channel sizes. AP and Client must match.
      • Antenna Select = Antenna A/B/Diversity - MAIN/AUX/BOTH Radio Antenna Ports.
      • HIDE SSID = enable to hide your ESSID from AP scanners.
      • InterBSS Relay = enable for client to client communication. Not a good idea.
      • Outdoor Only = Channel Display Column will only show outdoor channels.
      • Short Preamble = Enable
      • Super A/G = Enable
      • AP Power Savings = Enable
      • Network Type = Station
      • Operating Mode = 802.11a/b/g, 802.11b/g mixed or Turbo (select your operating mode)
    • WEP Setup
      • WEP Mode = Disabled/40/104/128bit
      • Passphrase = To generate a wep key using a passphrase.
      • WEP Key 1/2/3/4 = WEP Keys must match and they must match the same Key slot as the AP.
      • Selct either "Open" or "Shared Key"
    • interface > interface feature > "select" enable DHCP client. Your CPE will dynamicly obtain IP address from your AP.
  • Setup the ethernet interface
    • interfaces > ether1 >
    • ip assingments = 192.168.200.1/24
    • ethernet link settings = auto/10/100mbps + full duplex on/off
    • dhcp auto-auth configurations > configurations =
      • Gateway: 192.168.200.1
      • Subnet Mask: 255.255.255.0
      • Pri. DNS: 1.2.3.4
      • Sec. DNS: 1.2.3.5
      • Lease: 1700
      • USE Radius = on or off
      • create hotspot session = on or off
      • IP Range = 192.168.200.100 - 254
    • interface features > enable dhcp auto-auth


routing


  • Routing > dynamic routing (rip, ospf & mesh) = enable rip
  • routing > static and default routes = remove default routes


dns server list


  • advanced > dns server list...
    • hostname = jdoe
    • domain = wisp.domain.net
    • name server 1 = 1.2.3.4
    • name server 2 = 1.2.3.5
    • name server 3 = 1.2.3.6


ntp and timezone


  • advanced > ntp and timezone setup...
    • offset = enter your offset here (example -06:00)
    • NTP Server = ntp.server.net


qshape


  • advanced > scripts > class based queing...

example

qshape user 100 bw 1536k 512k 192.168.200.0/24 on ether1

see qshape article for more details


nat and static nat


  • advanced > scripts > nat and static nat...

example

masq from 192.168.200.0/24 to dev wpci1

file > activate changes > yes

That's it.

Once you have a working config you like, create a backup using starutil and pre-load your CPEs during assembly.

Comments welcome.

Use an off-the shelf bridging CPE and route a subnet on the AP

Vendors of plug-and-play CPE units often provide what acts like a bridge between the customer's network and the wpci interface at your AP. At the AP, you assign one or more subnets to that wpci interface of whatever size you need (/29, /28, /27, or whatever); each CPE radio has one or more of those addresses assigned to it. You might want to have one subnet of private addresses and assign one of those to the CPE itself for management purposes, and one subnet of public addresses and assign one of those to the customer's router sitting behind the CPE.

If you have more than one wireless interfaces at the AP serving customers, you can assign different subnets to them, or you can bridge them at the AP so that the same subnets are shared among those interfaces.

It should go without saying that you should normally isolate the interfaces that serve customers directly, whether wired or wireless, from those that are part of your backhaul. The backhaul interfaces should have their own addressing scheme and routing methods.

Build your own bridging CPE and route a subnet on the AP

Unfortunately, there seems to be no good way to set up your own bridging CPE using the new WAR1 board. It seems there was a way with StarOS v2. It would be useful if someone would track down how that can be done with v2 and document it on this wiki...

The new Routerboard 133C is a $59 SBC that has the abundance of routing features of the Mikrotik OS. Its speed and wireless performance may not match the WAR1, but it can provide adequate power for many applications (multiple Mbps). By using proxy-arp on both the wired and wireless interfaces, you can cause it to act as a bridge. Despite their extensive documentation, Mikrotik does not provide good information on this important point.


Summary

Proxy-arp bridging is supported nicely in the Linux 2.6 kernel (used in both Mikrotik and StarOS products). If proxy-arp is enabled on interface1 and interface2, then the kernel will discover attached hosts on each interface and make their presence known on the other interface. So only the following things are needed to create a pseudo-bridge using proxy-arp:

 1. Give each interface at least one usable address.
    Otherwise, packets cannot be sent!
 2. Tell the system where to find the IP addresses you care about.  
    A default route on one interface will suffice, 
    but the other interface must have some routes showing what hosts are there.
 3. Enable proxy-arp on both interfaces.

Example

The following setup is known to work. Assume the access point deploys 1.1.1.1/24 and 10.10.10.1/24, the CPE management address is 10.10.10.10, and the customer equipment is 1.1.1.9/24 with default gateway 1.1.1.1.

 /interface ethernet set ether1 arp=proxy-arp
 /interface wireless set wlan1 arp=proxy-arp
 /ip address add interface=wlan1 address=10.10.10.10/24
 /ip route add dst-address=0.0.0.0/0 gateway=10.10.10.10.1
 /ip address add interface=ether1 address=10.10.10.10/32 network=1.1.1.9 broadcast=0.0.0.0

Of the above commands, only the last one is mysterious. It is a way to define a point-to-point relationship on the LAN. It says my address is 10.10.10.10 and the other guy's address is 1.1.1.9. What the broadcast setting means is anyone's guess, but it works.

Note two curiosities: (1) the customer's default gateway 1.1.1.1 is unknown to the CPE, but proxy-arp allows the customer to find it; (2) the CPE uses 10.10.10.10 on two different interfaces; this is allowed by linux only with proxy-arp.