Add WLAN model for creating/connecting wireless PtP/PtMP links

[cbock-clairglobal]

Environment

• Python version: 3.5.4
• NetBox version: v2.6.11

Proposed Functionality

Ability to create wireless interfaces such as wlan0 or br0 and then connect them to each other as either wireless point-to-point or point-to-multipoint connections. This is similar but in contrast to a cable connection, which is admittedly not the right way to document a 5 mile wireless bridge between two radios. This would allow WISPs and other RF operators to more accurately document wireless L2 connections between sites.

Key fields to add for further documenting radio links would be:

Channel/Frequency : 2412MHz/Chan1, 2437MHz/Chan6, 5805MHz/Chan161, 60.48GHz, etc
Channel-width : 20MHz, 40MHz, 80MHz, etc
RSSI : -55db, -70db, -90db, etc
SSID : yourSSIDhere
Distance: 100m 5km, 100', etc

Use Case

This functionality would allow for documenting:

• Point-to-point Links
  A typical example would be a connection from device ubnt-nanostation-ap on interface br0 to ubnt-nanostation-st on br0. From there, the devices would also have your traditional eth0 interfaces that connect the radios back VIA cabling to a switch or POE injector. This would allow a full cable and WLAN trace from one end to another.

• Point-to-multipoint Links
  Similar to PTP links with the exception that multiple remote radio br0 interfaces would be connecting back to a single AP br0 interface.

Example: Interface br0 on ubnt-nanostation1-st, ubnt-nanostation2-st, ubnt-nanostation3-st all connect back to interface br0 on the primary backhaul radio ubnt-nanostation-ap

• Meshed WLAN
  This would typically be a situation where an access point is providing a meshed wireless uplink to a nearby access point that isn't directly connected to the network otherwise. For instance, a guard station in the middle of a parking lot might have a small office with no network cabling/infrastructure. A common solution would be to power an isolated AP via a POE injector, and then "mesh" over wireless to the nearest AP. This could look like meraki-mr74-outside connected via wlan0 to meraki-mr74-inside

Database Changes

N/A (that I'm aware of)

External Dependencies

N/A (that I'm aware of)

[jeremystretch]

Per the contributing guide:

Only comment on an issue if you are sharing a relevant idea or constructive feedback. Do not comment on an issue just to show your support (give the top post a 👍 instead) or ask for an ETA. These comments will be deleted to reduce noise in the discussion.

[DanSheps]

This was previously discussed here: #2067 and there are a number of duplicates linked as well

[jeremystretch]

The previous issues were to extend the cable model to support wireless connections, which obviously does not make sense. I believe this is the first proper FR we've had for modeling wireless networks, so I'm fine with leaving it open for discussion.

[tyler-8]

rssi is a measurement of the signal's environment rather than a setting attached to a device. IMO that would fall under monitoring data and be outside the scope of Netbox.

I do like this idea however, it could potentially function for LTE/5G connectivity modeling.

[cbock-clairglobal]

rssi is a measurement of the signal's environment rather than a setting attached to a device. IMO that would fall under monitoring data and be outside the scope of Netbox.

@tyler-8
True and fair enough. I only proposed it as RSSI is one of the key metrics useful to document and reference should issues pop up or the environment change. 👍

[millijuna]

Except for the fact that Netbox deliberately seems to avoid having per-interface info other than IP and so froth, I think EIRP would be a better metric to record, rather than RSSI. That said, adding similar functionality for fiber links might also be good (record wavelength for CWDM/DWDM links, and Tx power for long-haul links). The latter is probably its own FR though.

[mokas01]

wouldn't it be useful to know which config (PtP or PtMP) has been set on each AP antenna ? Could avoid some trouble on the field (at least some PtMP AP kick all connected clients if you try to connect to them with a PtP configured station)

[MajesticFalcon]

rssi is a measurement of the signal's environment rather than a setting attached to a device. IMO that would fall under monitoring data and be outside the scope of Netbox.

@tyler-8
True and fair enough. I only proposed it as RSSI is one of the key metrics useful to document and reference should issues pop up or the environment change. 👍

I agree. It it extremely useful to know what the "installed rssi" is. Same with fiber. "installed tx-power" and "installed rx-power." Your monitoring system "should" be able to maintain these values, but it having it documented as a custom field would also be helpful.

[MajesticFalcon]

As I am mid way through attempting to migrate different portions of our entire device management software over to netbox I have now encountered why it might not fit as well as originally hoped. We have just under 1000 radio links and there is specific information that needs to be coupled with the radio. I started using custom fields, but then quickly realized that you can't add a custom field to a specific device type. It definitely doesn't pertain to everybody, but we have the following fields for each radio. Freqency band, Service class (backhaul, repeater, access), SSID, Channel Width, Center Frequency, Azimuth, Beamwidth, Downtilt, height.

#722