Skip to content
Snippets Groups Projects
Commit d101ebe2 authored by Jakob Olsson's avatar Jakob Olsson
Browse files

Revert "traffic separation docs" 

This reverts commit 4cb687db.
parent d06a1bc9
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
docs/README-Traffic_Separation.md
+ 218
− 116
View file @ d101ebe2
......@@ -2,19 +2,104 @@
## Overview
This README documents important aspects regarding application of the Traffic Separation feature in Multi-AP system.
When Traffic Separation is in effect, traffic from different VLANs are isolated from each other.
Multiple SSIDs may belong to the same VLAN. The functionality for this is specified in Multi-AP Spec 2.0 chapter 19, which this
implementation is based on.
To achieve separation at layer 2 network, bridge vlan filtering feature is used and must be compiled into the kernel.
This README documents important aspects regarding application of the Traffic Separation feature in map-agent.
## Design
When Traffic Separation is in effect, traffic is to be isolated from eachother using different vlans.
The functionality for this is specified in Multi-AP Spec 2.0 ch 19, which is the base for this implementation.
The specification defines 3 differing kinds of interfaces towards the Multi-AP subsystem.
- Fronthaul (FH) - used to connect a client STA
- Backhaul (BH) - used to connect to another AP
- Logical Ethernet Interface (LEI) - used to interface between the Multi-AP subsystem and the rest of the node (including CPU and ethernet)
### Multi-AP subsystem separation
According to the specification the Multi-AP subsystem shall be a layer 2 device separate from the rest of the node features.
To fulfill this, we separate all Multi-AP Traffic Separation features into a separate bridge, which contains the FH and BH interfaces as well as a LEI interface towards the rest of the node (represented by another bridge).
```
No Traffic Separation Traffic Separation
┌───┐ ┌───┐
┌──┤Tag├──┤FH │
│ └───┘ └───┘
Agent/Controller bSTA │
┌─────┐ ┌───┐ ┌───┐ ┌───┐ ┌───────┐ │ ┌───┐ ┌───┐
│ CPU │ ┌────┤FH │ │BH ├──┤Tag├────┤bridge ├───┼──┤Tag├──┤FH │
└──┬──┘ │ └───┘ └───┘ └───┘ └───┬───┘ │ └───┘ └───┘
bSTA │ │ │ │
┌───┐ ┌───┴───┐ │ ┌───┐ ┌─┴─┐ │ ┌───┐ ┌───┐
│BH ├───────┤bridge ├───┼────┤FH │ │Tag│ └──┤Tag├──┤BH │
└───┘ └┬─────┬┘ │ └───┘ └─┬─┘ └───┘ └───┘
│ │ │ │ bBSS
┌─┴─┐ ┌─┴─┐ │ ┌───┐ ┌─┴─┐
│Eth│ │Eth│ └────┤BH │ │LEI│
└───┘ └───┘ └───┘ └─┬─┘
bBSS │ Agent/Controller
┌───┴───┐ ┌─────┐
│bridge ├──────┤ CPU │
└┬─────┬┘ └─────┘
│ │
┌─┴─┐ ┌─┴─┐
│Eth│ │Eth│
└───┘ └───┘
```
This setup is done in map-agent init script (**/etc/init.d/mapagent**), provided that the feature is enabled in Map Agent config.
The LEI interface is implemented with a linux *veth* device pair.
### Vlan tagging
To apply vlan tagging the Broadcom vlanctl kernel module is used. This sets up tagging devices connected to the specified interfaces.
These tagging devices apply filter rules and tagging actions similar to iptables/ebtables functionality.
The "real" interfaces is enslaved to the tagging device, which in turn is enslaved to the bridge.
## Implementation
### Vlan tagging
Vlan tagging is handled in a platform specific script (**/lib/wifi/multiap**) which is used to create tagging devices and apply tagging rules according to the specification.
Some examples of use:
```
/lib/wifi/multiap ts create fh wl0 10 # create a tagging device for FH iface wl0 with vlan id 10
/lib/wifi/multiap ts create bh wl2 1 2 # create a tagging device for BH iface wl2 with vlan 1 and profile 2
/lib/wifi/multiap ts create eth lei 1 3 br-map br-lan # create a tagging device for LEI iface lei with vlan 1, default pcp 3, Multi-AP bridge "br-map" and local bridge "br-lan"
/lib/wifi/multiap ts populate eth lei 10 # apply LEI specific rules for Secondary Network with vlan id 10 on iface lei
/lib/wifi/multiap ts delete wl0 # remove tagging device for iface wl0
```
### Map Agent
In order for a Map Agent to apply vlan tagging on the *Primary Network*, it must receive a **Default 802.1Q Settings TLV** containing the Primary Vlan ID.
This can be received in any of three ways:
- in a **AP-Autoconfiguration WSC** message
- in a **Multi-AP Policy Config Request** message
- as a Multi-AP IE subelement in **(Re-)Association Response** frames
To apply tagging on *Secondary Networks*, it must receive a **Traffic Separation Policy TLV** containing at least one SSID to Vlan ID mapping.
This can be received in either of:
- a **AP-Autoconfiguration WSC** message
- a **Multi-AP Policy Config Request** message
If the Traffic Separation feature is enabled in the Map Agent, it will monitor these trigger conditions and apply the tagging rules using the script when any of the trigger conditions is fulfilled.
## Configuration
The configuration governing the Traffic Separation (vlan tag numbering) comes from the map-controller.
### Map Agent
Primary Vlan ID and Default PCP value is set via the controller global section, primary_vid '0' means
Traffic Separation feature is disabled.
To enable the Traffic Separation feature:
```
config agent 'agent'
...
option vlan_segregation '1'
```
After Map Agent is restarted, the Traffic Separation setup will be done (and the *al_bridge* option will have been updated).
NOTE: This needs to be set on each Map Agent separately.
### Map Controller
The configuration governing the Traffic Separation (vlan tag numbering) comes from the Map Controller.
Primary Vlan ID and Default PCP value is set via the controller global section:
```
config controller 'controller'
option enabled '1'
......@@ -22,144 +107,161 @@ config controller 'controller'
option primary_vid '1'
option primary_pcp '2'
```
Each *ap* section specifies which Vlan ID it belongs to by the *vid* option:
Each ap specifies which Vlan ID it belongs to:
```
config ap
option band '5'
option ssid 'MAP-EC6C9A79FC4E-5GHz'
option encryption 'sae-mixed'
option vid '1' # Primary VID
option vid '1'
option type 'fronthaul'
option key 'FPaY-7teN-hTHa-pgdT'
option network 'lan'
config ap
option band '2'
option ssid 'MAP-EC6C9A79FC4E-2.4GHz'
option encryption 'sae-mixed'
option vid '1' # Primary VID
option vid '1'
option type 'fronthaul'
option key 'FPaY-7teN-hTHa-pgdT'
option network 'lan'
config ap
option band '5'
option ssid 'My-Guest-Network'
option encryption 'sae-mixed'
option vid '50' # Example guest VID 50
option vid '10'
option type 'fronthaul'
option key 'FPaY-7teN-hTHa-pgdT'
option network 'lan'
config ap
option band '5'
option ssid 'Another-Guest-Network'
option encryption 'sae-mixed'
option vid '20' # Example guest VID 20
option vid '20'
option type 'fronthaul'
option key 'FPaY-7teN-hTHa-pgdT'
option network 'lan'
```
## Implementation
In order for map-agent to apply vlan tagging on the *Primary Network*, it must receive a **Default 802.1Q Settings TLV** containing the Primary Vlan ID.
This can be received in any of three ways:
- in a **AP-Autoconfiguration WSC** message from the map-controller
- in a **Multi-AP Policy Config Request** message from the map-controller
- as a Multi-AP IE subelement in **(Re-)Association Response** frames
### ieee1905d
To apply tagging on *Secondary Networks*, it must receive a **Traffic Separation Policy TLV** containing at least one SSID to Vlan ID mapping.
This can be received in either of the following CMDUs from map-controller:
- a **AP-Autoconfiguration WSC** message
- a **Multi-AP Policy Config Request** message
The ieee1905d config specifies which bridge ieee1905 packets are expected to be received on. This should point to the CPU bridge, which is the default (br-lan).
### Bridge <-> wl MAC conflict
If no wl base MAC is specified in nvram parameters, bridge and wl macs will end up in conflict in the multi-bridge environment.
This can be mitigated by setting a wl MAC base in */data/.kernel_nvram.setting* that will not conflict with any bridge MAC.
An example:
```
root@iopsys:~# grep -i mac /data/.kernel_nvram.setting
1:macaddr=ec:6c:9a:79:fc:60
2:macaddr=ec:6c:9a:79:fc:70
root@iopsys:~# ip l sh br-lan
21: br-lan: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether ec:6c:9a:79:fc:4f brd ff:ff:ff:ff:ff:ff
```
## Other issues worth noting
### ebtables
In the dual bridge setup, ieee1905 packets are expected to be forwarded to the local bridge. This requires an ACCEPT rule in ebtables. In order for ieee1905d service to pick up the packets, it requires a DROP rule in ebtables.
These rules are set up by ieee1905d and mapagent automatically.
### EAPOL and the ASSOC-IE
hostapd manages the BSS side of a wifi connection and wpa_supplicant manages the STA side of a wifi connection.
For a STA to connect to a BSS a 4-way handshake needs to take place. This is achieved using EAPOL traffic between wpa_supplicant and hostapd.
According to specification, EAPOL traffic over a backhaul is to be tagged with the primary Vlan ID when Traffic Separation is in effect.
To avoid the need to modify these services to use tag devices for rx/tx, Broadcom wifi driver has included a feature to enable tagging of EAPOL in driver.
To use this feature one needs to set the bBSS and bSTA interfaces to Profile 2 and set a Primary Vlan ID on the bBSS.
This will trigger wifi driver to tag EAPOL using PVID, and also make PVID available from the driver on the bSTA side.
For any BH iface we can then do:
```
wl vlan_mode 0 &> /dev/null # make sure this is OFF, else driver won't handle vlan
wl -i $iface down &> /dev/null
wl -i $iface map_profile $profile &> /dev/null # only has effect on profile 2
wl -i $iface map_8021q_settings $vid &> /dev/null # can only be set on bBSS (read-only on bSTA)
wl -i $iface up &> /dev/null
```
This is also used to enable tagging on a repeater connecting to a AP that already has tagging enabled as it can fetch the PVID from the driver after association.
#### Simplified Backhaul
Since the tagging of EAPOL is handled by the driver, and since we currently only support Profile 2 BH, we may simplify our solution by removing the tagging devices from the BH devices (since this is in effect a no-op).
### Secondary networks
The specification makes clear that Secondary traffic going out on the Logical Ethernet Interface should retain its tag, while Primary traffic is to be untagged.
The specification also makes clear that traffic originating from outside the Multi-AP network is to be tagged or untagged prior to entering the Multi-AP network.
The implementation of this is left outside of the scope of the specification.
The implication is that any services that are to be made available to Secondary networks, (such as DHCP etc), are to be tagged prior to entering the Multi-AP network.
Also, any traffic between a Secondary network and WAN will need to be tagged/untagged outside of the scope of the Multi-AP network.
#### DHCP
To provide DHCP service on secondary networks, we create **sink** devices (in practice, a bridge) connected to the lan bridge for each Secondary network. These will do untagging of Secondary VIDs for the benefit of the DHCP service running on the **sink** device. The return traffic is then re-tagged with the Secondary VID and forwarded back to the Multi-AP network.
```
┌───┐ ┌───┐
┌──┤Tag├──┤FH │
│ └───┘ └───┘
bSTA │
┌───┐ ┌───┐ ┌───────┐ │ ┌───┐ ┌───┐
│BH ├──┤Tag├────┤bridge ├───┼──┤Tag├──┤FH │
└───┘ └───┘ └───┬───┘ │ └───┘ └───┘
│ │
┌─┴─┐ │ ┌───┐ ┌───┐
│Tag│ └──┤Tag├──┤BH │
└─┬─┘ └───┘ └───┘
│ bBSS
┌─┴─┐
DHCP │LEI│
┌──────┐ ┌───┐ └─┬─┘
│ sink ├──┤Tag├─┐ │ Agent/Controller
└──────┘ └───┘ │ ┌───┴───┐ ┌─────┐
├──┤bridge ├──────┤ CPU │
┌──────┐ ┌───┐ │ └┬─────┬┘ └─────┘
│ sink ├──┤Tag├─┘ │ │
└──────┘ └───┘ ┌─┴─┐ ┌─┴─┐
│Eth│ │Eth│
└───┘ └───┘
```
#### WAN
The above **sink** device can also be used to access WAN via NAT. If this interface is added to the *lan* zone of the firewall rules, it will get NATed just like *lan* traffic.
```
config zone
option name 'lan'
list network 'lan'
list network 'sink'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
```
This is added automatically when Secondary networks are getting set up.
## Future improvements
When Map Agent receive proper Traffic Separation policy config it will reconfigure */etc/config/network* to enable
vlan filtering on *al_bridge* (default br-lan) and configure vlan for Ethernet ports that were already bridged
to *al_bridge* and create *sink* veth interfaces that allow network layer 3 (IP, IPv6, DHCP etc.) access to the vlan networks.
```
config device 'br_lan'
option name 'br-lan'
config device 'br_lan'
option type 'bridge'
list ports 'eth2'
list ports 'eth3'
list ports 'eth4'
option macaddr '44:D4:37:71:BE:32'
option vlan_filtering '1'
```
Individual vlan ids for ports are configured using *bridge-vlan* network config entries.
Ports having *:t* appended will keep the vlan id tag for ingress end egress traffic
(802.1q frames will be sent out and received on the port). List port entries without
*:t* will add a tag for ingress and remove on egress traffic, which is proper
for *sink* interfaces and Ethernet interfaces for primary network.
```
config bridge-vlan
option device 'br-lan'
option vlan '1'
list ports 'eth2'
list ports 'eth3'
list ports 'eth4'
list ports 'sink_peer1'
config bridge-vlan
option device 'br-lan'
option vlan '50'
list ports 'eth2:t'
list ports 'eth3:t'
list ports 'eth4:t'
list ports 'sink_peer50'
```
By convention vlan *vid* network is configured to be 192.168.*vid*.0/24 ip network.
```
config interface 'vlan50'
option device 'sink50'
option is_lan '1'
option proto 'static'
option ipaddr '192.168.50.1'
option netmask '255.255.255.0'
```
Specific vlan configuration can be seen by *bridge vlan* command and example
output can look like this:
```
root@iopsys:~# bridge vlan
port vlan-id
eth2 1 PVID Egress Untagged
20
50
eth3 1 PVID Egress Untagged
20
50
eth4 1 PVID Egress Untagged
20
50
wl0 1 PVID Egress Untagged
wl1 1 PVID Egress Untagged
sink_peer1 1 PVID Egress Untagged
br-lan 1
20
50
wl1.1 1 PVID Egress Untagged
wl1.2 20 PVID Egress Untagged
wl0.1 1 PVID Egress Untagged
wl0.2 50 PVID Egress Untagged
sink_peer50 50 PVID Egress Untagged
sink_peer20 20 PVID Egress Untagged
```
PVID Egress Untagged entries will add/remove vlan id tag on for incoming/outgoing frames
on that port. Vlan id listed without PVID Egress Untagged mean that particular
vlan tag is accepted on the port, non listed vlan tags are dropped.
In example above *eth2* will:
* Accept 802.1q frames with VIDs 20 and 50
* Change untagged incoming ethernet frames to 802.1q with vid 1
* Remove tags for outgoing frames
For wireless port *wl0.2*:
* Transfer untagged traffic to vid 50.
Apart from some bugfixes (see TODO document), some design changes may be considered:
- consider using linux vlans or bridge vlans
- may not provide the filtering capabilities of brcm driver vlans, but maybe this can be designed around
- redefine border of MAP-segment
- currently anything going to CPU or eth is treated as LEI traffic, and Secondary traffic destined for specific use (DHCP, WAN) is treated separately
- this could be changed such that any MAP related devices are to be placed in br-map (any MAP-aware eth is placed in br-map as a LEI device) and all traffic going to CPU would be deemed outside of MAP segment and untagged
- this in turn can be done with one tag device per VID, where bridge port learning handles return tagging - can be done with either brcm tag device or linux tagging
- this would mean that no specific handling needs to be done for secondary networks, as they would appear as untagged br-lan traffic
- stricter rules on tag devices
- currently the defaults for TX and RX rules are used, which are DROP on missed RX filters and ACCEPT on missed TX filters
- this should be sufficient considering br-map is ingressed from all possible ports by tagging devices only, meaning no untagged traffic should appear within br-map
- there should however be no harm in stricter rules, making TX DROP by default on any missed filters
- profile 1 backhaul support
- profile 1 backhaul support is currently disabled in the script, but could be enabled in the future if required
- there is currently no logic governing the type of backhaul detected - all backhauls are assumed to be profile 2
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment