Wireless ISP Network IP Scheme

For those of you starting out in the WISP field here is a good overview of a scalable Ip scheme for your WISP network. There are some caveats to this, which we will discuss later. This does not address IPV6, I have done some articles on IPv6 in the past that addresses IPV6.

Some benefits of this scheme
1.Logically separates equipment into groups.
2.Cookie-Cutter design. Fast time to depoyment
3.Easy to train on for techs and office

This following scheme uses private IP space for infrastructure. This scheme does not address end-user addressing. More on this in a later guide.

For each tower I route a /16 out of the IP space. For example my first tower is . Your first thought is that is alot of IP space. Yes it. However, it is private IP space and you can use as much as you want. The second thought is you can only use this scheme 255 times. Yes this is true. How many WISPs are growing beyond 255 towers. Most of the wisps I know are in the 100 tower sweet spot. There are larger and smaller wisps.

So lets break this down. We are using tower 1 as an example.

Wired Infrastrudture 
1-Not used due to default being VLAN 1 on most devices. Quarantine vlan

2- Power and UPSes

3- Switches and routers

5-9 reserved for  future uses

Backhaul Management VLANS 

10-19 – Backhaul 1 – BackHaul 2

Infrastructure Radio VLANS (tagged management) 

20-29 – 2GHZ equipment – First 2.4GHZ AP – Send 2.4GHZ AP – Third 2.4 GHZ AP Management

30-39 – 3GHZ Equipment – First 3GHZ AP

40-49 – RESERVED  

50-59 -5GHZ equipment 

60-69 – 60GHZ equipment 

70-79 – RESERVED  

80-89 – 80 GHZ 

90-99 – RESERVED possible IOT 

Customer VLANS (untagged) 

120-129 – 2GHZ equipment – Customer CPE on first 2.4GHZ AP

130-139 – 3GHZ Equipment 

140-149 – RESERVED 

150-159 -5GHZ equipment 

160-169 – 60GHZ equipment 

170-179 – RESERVED 

180-189 – 80 GHZ 

Point to Point customers 


So why so much IP space? It helps keep your routing table small.

IPV6 Point-to-point addressing

Recently, there has been a discussion on what to use for point-to-point links under ipv6. Over the years I have seen providers use a wide variety of subnets across a point-to-point link.  Anything from a /64, to /122,124, and the 127. There are arguments for each. But let’s look at some RFCs.
This was the original RFC on point-to-point links advocating for a /127. It was moved to a “historical” status in 2012 after a /127 was found to be damaging.
This RFC explains some of the issues with using a /127. In a nutshell.

 Using /127 can be especially harmful on a point-to-point link when
   Subnet-router anycast address is implemented.

All of this brings us to some current RFC drafts and further reading

Some notes on point-to-point addressing
1. A subnet mask using something shorter than a /64 breaks some IPv6 functionality. A point-to-point link does not use the “broken” features anyway.

  1. The above 6164 RFC said vendors had to support /127s.  Many wrote code to comply with the RFC, which has now been obsoleted.
  2. A /64 could expose the link to security issues.

As of this writing, there are many approaches.  One approach is to set aside a /64 for the point-to-point but only use a /127 out of that /64.  You don’t re-use anything else out of that /64.  Other approaches involve using a  /126, /120 or a /112 are being accepted until this is all figured out.  So, why not a /122 or something? In short, it all has to do with the math of the subnet breakdown.

More IPV6 resources

This content is for Patreon subscribers of the j2 blog. Please consider becoming a Patreon subscriber for as little as $1 a month. This helps to provide higher quality content, more podcasts, and other goodies on this blog.
To view this content, you must be a member of Justin's Patreon
Already a qualifying Patreon member? Refresh to access this content.