[Solved]: Gretap tunnel with vlan 802.1q tagging

I am having success with my current gretap configuration, but it is limited due to the lack of vlan tag in the GRE encapsulated Ethernet header.

Could someone please advise how to change my configuration to include a vlan tag and one that can be different from the vlan tag of the outer Ethernet header?

Relevant configuration in /etc/config/network:

config device 'eth1.100'
        option type '802.1q'
        option vid '100'
        option name 'eth1.100'

config interface 'test'
	option ifname 'eth1.100'
	option proto 'static'
	option ipaddr ''
	option netmask ''
	option ipv6 '0'

config interface 'g30t'
        option proto 'gretap'
        option ipaddr ''
        option peeraddr ''

config interface 'g100c'
        option proto 'dhcp'
        option ifname '@g30t'
        option ipaddr ''
        option netmask ''

Your underlying transport will need to handle more than 1500 byte packets if bridging Ethernet-like interfaces. This can be handled with 802.11 links, as they support an MTU of 2304. This is a tunnel challenge, in general, as fragmentation of packets within the tunnel can't determine the sender of the "inner" packet that needs to get the ICMP fragmentation required message. Symptoms of this are that ping works, but ssh connections (that fill packets to their MTU) fail. If the bridge over the L2 GRE is "directly involved" then it confusingly works, apparently as the source/destination interface sees the reduced MTU of the bridge.

Also be careful with interface naming in UCI as gre4t-abcd.1234 is at the 15-character limit for interface names in the kernel.

From a previously running config of mine (the 172.16.1.NN/24 addresses are on the underlying 802.11s mesh interfaces that are configured elsewhere for a 2304 MTU):

# Give it plenty of MTU
# 14 Ethernet header
#  4 VLAN tag
#  4 Ethernet CRC
# 20 IPv4 delivery
#  8 GRE
#  4 GRE key
#  4 GRE sequence
# --
# 58 total

config interface 'gt98'
        option proto 'gretap'
        option mtu 1558
        option ipaddr ''
        option peeraddr ''
        option delegate '0'

# Multiple, similar declarations for the other tunnels follow
config interface 'vlanNNNN'
        option type 'bridge'
        option stp '1'
        option ifname 'eth1.NNNN @gt95.NNNN @gt96.NNNN @gt97.NNNN @gt98.NNNN'
        option proto 'static'
        option ipaddr ''
        option netmask ''
        option delegate '0'

Edit: I don't know why it needed to be @gt95.NNNN but, as I recall, it didn't seem to work with just gt95.NNNN

The approach I now use for setting the MTU of the underlying mesh I've documented at


(I previously "hooked" the netifd scripts to set the MTU directly, rather than using UCI configuration.)

That worked for me. I had tried using "option network 'eth1.NNNN'" in my g30t stanza unsuccessfully. I was hesitant to experiment too much with bridge/switch config, since these experiments can suck up a lot of time, so I appreciate the example you provided.

1 Like

Thank you qbdwlr0 and jeff for the details. Does your config use separate IP for DHCP interface and GRE tunnel?

I am new to GRE and have this scenario. My openWRT board has 3 LAN interfaces and 3 AP's. One of the 3 AP's is the hotspot SSID. All user traffic through this SSID should be tagged and go through a GRE tunnel to reach the GRE server. This GRE tunnel should be established with the WAN IP of my openWRT board. Thus, LAN/WLAN traffic will be tagged with VLAN A and hotspot SSID will be tagged with VLAN B. My questions are

  1. How to establish a GRE tunnel with WAN IP (the goal is that at an instant, board should have only one DHCP WAN IP).
  2. To send other traffic with VLAN A, I have erected wan.A. As GRE traffic also has to go through WAN, I want a outer VLAN tag with VLAN B. Is this acheivable?

Thanks much!

Yes, at least as I have it configured the tunnel end points are on a completely different subnet than those that the tunnel that connects them is bridged to.

I have a hard time this morning thinking of how/why one would bridge the subnet of the tunnel end point through the tunnel. Reminds me of a snake swallowing its tail or the like.

Before you go further in your implementation, you'll need to decide if you want to route or bridge traffic. I'm not sure what you mean by "GRE server" -- there isn't such a thing the way there is in a typical VPN. GRE is just a way of getting packets from one place to another -- a "wire replacement" sort of.

Perhaps best to open a new thread for your specific questions as they seem to go well beyond of getting 802.11q VLAN tagging to work with layer 2 GRE tunnels.

Thank you Jeff. Sorry for the delayed response.

Why I said GRE server is, it is the one who is going to give IP to the tunnel end point residing in my openWRT board. That is how my implementation is for now.

Your snake and its tail analogy helped me understand my question better. Now I have a WAN IP and a GRE tunnel IP, both of them in different subnets. Thank you once again!

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.