Ask Your Question

In GRE why the VLAN tag is stripped out before sending it in tunnel rather than sending the VLAN tagged Packet?

asked 2014-06-09 01:49:16 -0500

swarvanusg gravatar image

updated 2014-06-09 01:53:44 -0500

In neutron if we are using ‘ML2’ plugin with ‘GRE’ type driver, then normally in ‘br-tun’ the tenant specific VLAN tag is stripped out and corresponding GRE key/ID is applied before sending data towards tunnel. As I understand there are different mapping within GRE key and VLAN ID in different OpenStack Node. Now GRE is capable of encapsulating (L2 over L3) packets.

My questions are:

Q1. Does GRE tunnel is capable of encapsulating the VLAN tagged packet within L3?

Q2. If it is capable of doing so, why the VLAN is stripped out before sending it in GRE tunnel?

edit retag flag offensive close merge delete


@dbaxps: Thanks for the answer. One thing i can't understand that what you actually mean by 'context'. In OpenStack i assume that the 'context' is the switch specific configuration (rules and action) in a specific node. The Mapping between GRE key and VLAN id is configured in a particular Node (compute/network) context, which is private/local to the node. Lats say for a specific tenant the mapping is:

Node1(VALN ID) Node1(GRE KEY) Node2(GRE KEY) Node2(VLAN ID)

'1' <=M=> '101' <====TUNNEL=====> '101' <=M=> '3'

*M : Local Mapping

If I say there is a global mapping schema, by which I mean a tenant actually specified by a single VLAN id universally (whole OpenStack deployment). In that case I don't need to strip out the GRE, I'm just passing the encapsulated VLAN tagged packet from one node to another. Where I may use GRE key ...(more)

swarvanusg gravatar imageswarvanusg ( 2014-06-09 08:01:33 -0500 )edit

1 answer

Sort by » oldest newest most voted

answered 2014-06-09 04:01:26 -0500

dbaxps gravatar image

updated 2014-06-09 18:22:08 -0500

smaffulli gravatar image

Tunnels are end to end entities, mostly global in nature "Push a packet in at one end and it pops out the other". Tags on the other hand are used as indicators in the packet that is used to pass context from one switch to another.

The expectation is that tunnels when setup allow packets to get forwarded as is across the network. Tags on the other hand may cause packet changes frequently as context information gets passed around. Hence, I would guess answer is no.


Across compute nodes we use the GRE tunnel ID. As discussed previously, each tenant network is provisioned both a GRE tunnel ID and a locally significant VLAN tag. That means that incoming traffic with a GRE tunnel ID is converted to the correct local VLAN tag as can be seen in table 2. The message is then forwarded to br-int already VLAN tagged and the appropriate check can be made.

edit flag offensive delete link more


I can understand how it is done in the current design. My question is not how it is done, but I want know why? I'm just trying to understand if there is any design constraints if I don't strip down the VLAN tag and pass the packet as it is the next node using GRE. I want to know why the current design is chosen, why there is a local mapping for GRE ID and VLAN tag, rather than using a fixed VLAN tag across all node for tenant.

swarvanusg gravatar imageswarvanusg ( 2014-06-09 22:47:53 -0500 )edit

Maybe it would be reasonable to address this question to ? or raise up another question, because the one was asked is answered.

dbaxps gravatar imagedbaxps ( 2014-06-09 23:38:37 -0500 )edit

Thanks for the assist :) @dbaxps

swarvanusg gravatar imageswarvanusg ( 2014-06-10 04:50:50 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools


Asked: 2014-06-09 01:49:16 -0500

Seen: 1,008 times

Last updated: Jun 09 '14