This is added automatically when Secondary networks are getting set up.
This is added automatically when Secondary networks are getting set up.
## Future improvements
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
