[SOLVED] How to use UCI to configure VLANs on a large installation?


#1

I am running a large (500+) openwrt site. Things work smoothly, but our configuration software was hacked together four years ago and it is showing its age. Basically we edit the /etc/config files, but could not get the vlans we needed, so we do this configuration on the /etc/rc.local.

We would like to have less points to tweak when making changes, so we decided to create an UCI file and put our customization in it. That is working fine. But creating vlans still eludes us, so you may be able to help.

We have 4 vlans on Ethernet (we use the blue wan port which on some of our routers is PoE).

200, untagged
203 tagged
203.5 tagged
205 tagged

we create vlans on rc.local

vconfig add eth0 203
ifconfig vlan203 up

vconfig add vlan203 5
ifconfig vlan5 up

vconfig add eth0 205
ifconfig vlan205 up

The network bridges between the SSIDs and VLANs are defined in /etc/config/network

config interface 'lan'
   option ifname 'eth0'
   option type 'bridge'
   option proto 'dhcp'
   option hostname      'ap0604'

config interface 'cadastro'
   option type 'bridge'
   option proto 'none'
   option ifname 'vlan5'

config interface 'visitante'
   option type 'bridge'
   option proto 'none'
   option ifname 'vlan203'

config interface 'dados'
   option type 'bridge'
   option proto 'none'
   option ifname 'vlan205'

The SSIDs are defined in /etc/config/wireless

config wifi-iface
   option device 'radio1'
   option network 'dados'
   option mode 'ap'
   option ssid 'eduroam'
   option encryption 'wpa2'
   option key 'xxx'
   option server 'zzz'
   option port '1812'

config wifi-iface
   option device 'radio1'
   option mode 'ap'
   option encryption 'none'
   option network 'cadastro'
   option ssid 'WifiUFF'

config wifi-iface
   option device 'radio1'
   option mode 'ap'
   option ssid 'VisitantesUFF'
   option network 'visitante'
   option encryption 'wpa2'
   option key 'yyy'
   option server 'yyy'
   option port '1812'

config wifi-iface
   option device 'radio1'
   option network 'dados'
   option mode 'ap'
   option ssid 'ap0604'
   option encryption 'wpa2'
   option key 'xxx'
   option server 'xxx'
   option port '1812'

The question is, is there a way to configure the vlans inside the /etc/config/network file, or should I just create a new /etc/config file and new rc.d script to run it?

--luiz

PS

This is other thread, but

On the newer (LEDE - TP Link TP-WR849N) we use ip link to create the VLANS

ip link add link eth0 eth0.203 type vlan id 203
ip link add link eth0.203 eth0.203.5 type vlan id 5

But due to a bug on the switch we had to use veth - the switch would not accept tagged and untagged vlans on the same port (it would tag our single untagged vlan).

It may make using /etc/config/network even harder.



Where is the switch option menú on OpenWrt 18.06.1?
#2

Yes, you can configure the VLANs in /etc/config/network

I recently updated the wiki which should be accessible once the DNS issues are resolved. Search on "/etc/config/network"

In short, the switch configuration can be done in /etc/config/network, as is the bridging of interfaces.

Hardware switch configuration is limited by the number of distinct VLANs that the switch and driver support. As an example from an Archer C7:

jeff@office:~$ swconfig dev switch0 help
switch0: ag71xx-mdio.0(Atheros AR8327), ports: 7 (cpu @ 0), vlans: 128
     --switch
	Attribute 1 (int): enable_vlan (Enable VLAN mode)
[...]

VLAN tags outside of that range (0-127 in the Archer C7 case) need vid on the switch and pvid on the port configured. I think of the vlan config parameter as a "table entry" that happens to default vid and pvid to its value.

As an example:

config switch_vlan
        option device 'switch0'
        option vlan '3'
        option vid '1000'
        option ports '6t 1t 2 3 4 5'
# LAN 4
config switch_port
        option device 'switch0'
        option port '5'
        option pvid '3'
        option enable_eee '1'

#3

Yes, there is a way to configure VLANs inside the UCI...in fact, I never knew the method you describe above existed.

You are looking for the config switch_vlan section of /etc/config/network. The following example places VLAN 3 on the CPU (port 0) and on ports 2 and 3 untagged, and port 4 tagged:

config switch_vlan                                                              
        option device 'switch0'                                          
        option vlan '3'                                                         
        option vid '3'                                                          
        option ports '0t 2 3 4t'

The following creates a network on VLAN 3:

config interface 'network2'                                                     
        option proto 'static'                                            
        option type 'bridge'                                                                                             
        option ifname 'eth0.3'                                                  
        option netmask '255.255.255.0'
        option ipaddr '192.168.xxx.1'

See:

https://wiki.openwrt.org/doc/uci/network

and

https://openwrt.org/docs/guide-user/base-system/basic-networking

You may wish to look into Cucumber Tony: https://ct-networks.io/

The Server is Open Source, as well as the OpenWRT agent (SocketMan), so you don't have to purchase the service from them.


#4

Jeff, thank you for the quick response!

So to see if I understood correctly:

I will create 4 vlans (e.g. 3,4,5,6) and associate each one with one vid (200, 203, 203.5, 205) in 4 config switch vlan blocks

There will be only two port, blue and CPU (5 and 6, I think, in most APs), tagged/untagged depending on the vlan and tagged on the CPU port.

example:

config switch_vlan
        option device 'switch0'
        option vlan '5'
        option vid '203.5'
        option ports '6t 5t'

Then for each vlan I need a config switch_port block, with the pvid of the vlan

example:

config switch_port
        option device 'switch0'
        option port '5'
        option pvid '5'
        option enable_eee '1'

Should I use enable_eee ? I do not think it is active now.

I am assuming IEEE 802.1ad will work just by using the dot notation...

--schara


#5

Thank you lleachii, you provided the second part of the puzzle.

On the previous answer Jeff had not mentioned how to glue the vlans to the bridges (because our vlans now are named, we just use the interface name on the "option ifname". There is just one ambiguity in your answer because I do not know if it is the vlan number or the vid number you are referring to, but I guess it should be the vid, so in my case I would have

option ifname 'eth0.203.5'.

Assuming again IEEE 802.1ad works. It should, because we are using it. For the readers that want to do that, remember to lower the MTU on the link so the tag does not make the frame too big.

I will test on one AP and do a summary for the group. Thank you all.

S.


#6

the Q-in-Q stuff is the most confusing part. not sure if the UCI configs will parse that correctly, compared to you setting it up with "ip" commands. I'd test that out in a lab setting first.


#7

That is how LuCI set them up. Is there a reason your VLANs and VIDs numbered differently???


#8

Yes, this is a large installation (4 campi, 94 buildings) and the wired network is not under my administration. I needed some vlans and those were the vlan numbers given to me. When I needed more I started using Q-in-Q instead of bothering the IT guys to configure all the switches.

S.

PS. I should add the problem that the swiches only have support for a limited number of vlans. In my case many can only support 16 vlans:

root@OpenWrt:~# swconfig dev switch0 help
switch0: eth0(AR7240/AR9330 built-in switch), ports: 5 (cpu @ 0), vlans: 16
     --switch
        Attribute 1 (int): enable_vlan (Enable VLAN mode)
        Attribute 2 (none): apply (Activate changes in the hardware)
        Attribute 3 (none): reset (Reset the switch)
     --vlan
        Attribute 1 (int): vid (VLAN ID)
        Attribute 2 (ports): ports (VLAN port mapping)
     --port
        Attribute 1 (int): pvid (Primary VLAN ID)
        Attribute 2 (string): link (Get port link information)

So even if I wanted to use the same VLAN/VID I would not be able to.


#9

Rather than a complicated set of VLANs subject to complicated constraints on campus IT people's time, switch VLAN support, and tag vs number mappings, have you considered GRE tunneling between your routers? You might be able to create a more consistent and uniform design.


#10

It does appear that you're limited to a total of 16 VLANs from that output.

I've never tried to configure QinQ on OpenWRT. The kernel interface part of it is likely to be "happy" with the syntax. The UCI scripts are generally in /lib/netifd/ if you find a need to modify them. If you do, and aren't building your own images, remember to add them to /etc/sysupgrade.conf so that they are preserved over a flash.


Yes, the constraints of a single device's configuration (in this case the limited "default" numbering of VLANs) should not dictate an entire network's policies and topologies. Add a few lines to config on OpenWRT, or re-configure dozens of hosts, switches, routers, and firewalls? I'll add a couple lines of OpenWRT config please!

Tunneling doesn't really "solve" anything as it still needs to flow on its own VLAN in a "managed" environment. It additionally adds the complexities of routing and/or MTU management.


#11

Without knowing more about the network, it's hard to say, but the Q-in-Q stuff seems like the kind of thing that is designed to expand the network flexibility, and might need further expansion and become rather difficult to maintain in the long run.

GRE could potentially make things more flexible in terms of expansion within the limited vlans. But maybe not... Without details hard to say. I just thought I'd throw it out there for consideration in case it hadn't been considered but was deemed useful


#12

Makes sense, 802.11ad helps resolve the 4094 limit (or less) on VLANs in a trunking situation. I definitely can see where a sub-net admin might want to use it as well.

Thankfully, even with the proliferation of IoT devices, I haven't gotten there yet!


#13

Also Wireguard, and dumping the traffic into the desired VLAN on the far-end...the same principal applies as GRE.


#14

Wireguard would be perfect if you need the encryption, otherwise GRE will be much less CPU intensive, it just depends on what's needed.


#15

IP-in-IP tunnel as well, install kmod-ipip, and the ip tunnel mode is 'ipip'.

It is configured as an "Unmanaged" interface in UCI.


#16

Or OpenWISP project.


Any white-label WiFi cloud management software that supports OpenWRT?
#17

I enable Energy Efficient Ethernet as my OpenWRT boxes need to run on UPS power during power outages and all of my wired links are very short. Whether it makes any appreciable difference, I've never measured, but for the "cost" of a single line of config per port, I've got it in there.


#18

Well, it took me some time because I was busy with other matters. But I am reporting that it works. Below is the final /etc/config/network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config switch_vlan
        option device 'switch0'
        option vlan '7'
        option vid '203'
        option ports '0t 1t'

config switch_vlan
        option device 'switch0'
        option vlan '8'
        option vid '203.5'
        option ports '0t 1t'

config switch_vlan
        option device 'switch0'
        option vlan '9'
        option vid '205'
        option ports '0t 1t

'config interface 'lan'
        option ifname 'eth0'
        option type 'bridge'
        option proto 'dhcp'
        option hostname 'ap0604'
 
config interface 'cadastro'
        option type 'bridge'
        option proto 'none'
        option ifname 'eth0.203.5'
    
config interface 'visitante'
        option type 'bridge'
        option proto 'none'
        option ifname 'eth0.203'

config interface 'dados'
        option type 'bridge'
        option proto 'none'
        option ifname 'eth0.205'

There was no need to use the config port settings. QinQ worked fine.

I would like to thank everyone who helped.

S.