Skip to content

fix Bug#3270: provider bridge residential domain deployment scenario

Rahul Thakur requested to merge 8021ad into iopsys

Descriptions and cause

During the implementation of the provider bridge deployment scenario, it came to light that netifd has an inherent restriction that the 8021ad vlan cannot be setup using the linux naming convention, that is, ethx.y.z

This restriction stems from the initial implementation: https://git.openwrt.org/?p=project/netifd.git;a=commit;h=59217785704fca27d2c7a19e279d27c384a452cd

I can understand that this restriction was introduced becuase netifd has ways on internally generating vlans in case the corresponding device section is not mentioned. So, if ethx.y is the ifname in the interface section and the corresponding device section with name ethx.y does not exist, it would create ethx.y. What is worth noting here is that at this junture, since the device section is not even consulted, netifd has no way of knowing the type of this vlan interface, hence, it assumes it to 8021q and sets up the vlans accordingly.

If this same naming convention is used, then if ethx.y.z is ifname in interface section then ethx.y is created first and then ethx.y.z on top of ethx.y, however, since netifd does not consult the device section, it creates both vlans as 8021q.

Solution

if device section for a vlan interface mentioned as ifname in interface section is present, then create vlan using the parameters mentioned in the corresponding device section. This should not break the traditional openwrt behaviour as well and hence, in my opinion is a more suited candidate to resolve bug #3270.

Merge request reports