Open Stack

The internal VLAD ID is indeed limited to 4096 but this internal tag number is used to isolate different neutron subnets, not tenants. 

A tenant could create 10 neutron networks each with its own subnet and then start 10 instances each attached to a separate net/subnet. If these instances would be scheduled on the same compute node then they would all use different internal VLAN IDs (locally unique to that node).

 

Basically, you're right that there is a built-in limitation of 4096 instances attached to 4096 different Neutron net/subnets on a compute node, but it's not realistic to actually start that many instances on a compute node.

 

George

 

 

________________________________

From: BYEONG-GI KIM [mailto:kimbyeonggi at gmail.com] 
Sent: Wednesday, September 17, 2014 8:47 PM
To: openstack at lists.openstack.org
Subject: [Openstack] Question about VXLAN support

 

Hello.

 

I have a question about the VXLAN support on OpenStack.

 

As far as I know, the OVS operates like the below:

 

1. A tag number is created to identify each tenant, and it is used between br-int and br-tun. Furthermore the tag number is identified as a VLAN ID (I checked it via tcpdump).

 

2. After the packet arrived at br-tun, it is encapsulated and VNI (VXLAN Network Identifier) is attached. The binding information between the VLAN ID (tag number) and the VNI is stored in OVSDB. 

 

If the operation is correct, it seems that the number of tenants which can be created is still limited to about 4000, which is the supported range of VLAN, because the tag number is used to identify each tenant at the inside of br-int regardless of the supported range of VNI. 

 

If more than 5000 tenants are created in a Compute Node, how could be these identified after the packet arrived at br-int? In the theory, the 4500th tenant should have 4500 tag number but the tag number is presented as VLAN ID so that it cannot be assigned over 4096.

 

Any advice and comment would really be appreciated.

 

Best regards

 

Byeong-Gi KIM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140917/95d59f9d/attachment.html>