CPE Setup

From StarOS Community Wiki
Jump to: navigation, 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[edit]

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[edit]

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[edit]

With the WAR1 and StarOS 1.3 or 1.4, if you tell it to bridge the ethernet and wpci interfaces, and if the AP has any interfaces bridged, then WDS will be used to create a transparent bridge from AP through the WAR1 and to the client device(s). Beware that IP conflicts and other unpleasant things are possible since the bridge lets everything through.

RouterOS version 2 provides no built-in pseudo-bridge, but you can approximate the same by using proxy-arp on both interfaces, as described below. Beware that the unit will respond to ARP requests whenever the subject IP address is present in the routing table, regardless of whether such an IP address is actually online.

RouterOS version 3 (default on RB 411 and installable on RB 133) provides a pseudo-bridge station mode that acts like a typical conventional wireless pseudo-bridge.

Summary[edit]

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[edit]

The following proxy-arp setup is known to work for RouterOS 2.9. 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.