Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Nobody answer and I figured out how to do it, so I'm going to answer. Maybe is useful to somebody in the future.

I had to make a whole new approach to the problem and this was my way to do it:

Changes at OS level

I won't use VLAN at the interfaces level, but I will do it at bridge level, so em1.90 won't exists at all. so:

# cd /etc/sysconfig/network-scripts/
# cat ifcfg-em1
DEVICE="em1"
ONBOOT=yes
OVS_BRIDGE=br-salida
TYPE=OVSPort
DEVICETYPE="ovs"

# cat ifcfg-br-salida
DEVICE=br-salida
BOOTPROTO=none
ONBOOT=yes
TYPE=OVSBridge
DEVICETYPE="ovs"
IPADDR="192.168.70.14"
NETMASK="255.255.255.0"
DNS1="192.168.10.7"
GATEWAY=”192.168.70.1”

# cat ifcfg-br-salida.90
BOOTPROTO="none"
DEVICE="br-salida.90"
ONBOOT="yes"
IPADDR="192.168.90.14"
PREFIX="24"
DNS1="192.168.10.7"
VLAN=yes 
NOZEROCONF=yes
USERCTL=no

Reboot.

At this point, 192.168.70.14 should be answering, but 192.168.90.14 not. So, thanks to http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.simple.html I did this:

We create a table called "RioBlanco" and we will configure that everything that come from 192.168.90.14 has to be assosiated to this table (rule) and goes to 192.168.90.1 (route):

# echo 200 RioBlanco >> /etc/iproute2/rt_tables
# ip rule add from 192.168.90.14 table RioBlanco
# ip rule ls
0:      from all lookup local
32765:  from 192.168.90.14 lookup RioBlanco
32766:  from all lookup main
32767:  from all lookup default
# ip route add default via 192.168.90.1 dev br-salida.90 table RioBlanco
# ip route flush cache

Now both IP are responding. This changes are not persistent. To make them persisten, we have to do this:

Rule:

# cat /etc/sysconfig/network-scripts/rule-br-salida
from 192.168.90.14 table RioBlanco

Route:

# cat /etc/sysconfig/network-scripts/route-br-salida
default via 192.168.90.1 dev br-salida.90 table RioBlanco

Changes at Openstack level

changes in /etc/neutron/plugins/ml2/ml2_conf.ini:

[ml2]
type_drivers = flat,vlan,vxlan
tenant_network_types = vlan,vxlan
mechanism_drivers =openvswitch
[ml2_type_vlan]
network_vlan_ranges = fisico-vlan:90:90

Now we had to link the physical bridge (br-salida) with the interface we configured in Openstack (fisico-vlan). This has to be don in /etc/neutron/plugins/ml2/openvswitch_agent.ini:

bridge_mappings =fisico-vlan:br-salida

Now, we have to be sure of this in /etc/neutron/l3_agent.ini:

external_network_bridge =
gateway_external_network_id =

You can achieve this when you install with packstack with answer file, with this options:

CONFIG_NEUTRON_ML2_TYPE_DRIVERS=vxlan,vlan
CONFIG_NEUTRON_ML2_TENANT_NETWORK_TYPES=vxlan,vlan
CONFIG_NEUTRON_ML2_MECHANISM_DRIVERS=openvswitch
CONFIG_NEUTRON_ML2_VLAN_RANGES=fisico-vlan:90:90
CONFIG_NEUTRON_L3_EXT_BRIDGE=
CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS=fisico-vlan:br-salida

Reboot. After the reboot, finally:

~(keystone_admin]# neutron net-create externa_vlan90 --shared --provider:network_type vlan --provider:segmentation_id 90 --provider:physical_network fisico-vlan --router:external

~(keystone_admin]# neutron subnet-create --name sub-externa_vlan90 --gateway 192.168.90.1  --allocation-pool start=192.168.90.25,end=192.168.90.35 externa_vlan90 192.168.90.0/24

After all this, Openstack is ready to work with this new network that is using VLAN tag (90), so in Horizon, we can:

  • create a new internal network (with a sub net on it)
  • Create a router that has this internal network and uses the new external network just created (externa_vlan90) as gateway
  • Launch an instance in this environment, and associate a floating IP from this new pool

That's it.

Nobody answer and I figured out how to do it, so I'm going to answer. Maybe is useful to somebody in the future.

I had to make a whole new approach to the problem and this was my way to do it:

Changes at OS level

I won't use VLAN at the interfaces level, but I will do it at bridge level, so em1.90 won't exists at all. so:

# cd /etc/sysconfig/network-scripts/
# cat ifcfg-em1
DEVICE="em1"
ONBOOT=yes
OVS_BRIDGE=br-salida
TYPE=OVSPort
DEVICETYPE="ovs"

# cat ifcfg-br-salida
DEVICE=br-salida
BOOTPROTO=none
ONBOOT=yes
TYPE=OVSBridge
DEVICETYPE="ovs"
IPADDR="192.168.70.14"
NETMASK="255.255.255.0"
DNS1="192.168.10.7"
GATEWAY=”192.168.70.1”

# cat ifcfg-br-salida.90
BOOTPROTO="none"
DEVICE="br-salida.90"
ONBOOT="yes"
IPADDR="192.168.90.14"
PREFIX="24"
DNS1="192.168.10.7"
VLAN=yes 
NOZEROCONF=yes
USERCTL=no

Reboot.

At this point, 192.168.70.14 should be answering, but 192.168.90.14 not. So, thanks to http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.simple.html I did this:

We create a table called "RioBlanco" and we will configure that everything that come from 192.168.90.14 has to be assosiated to this table (rule) and goes to 192.168.90.1 (route):

# echo 200 RioBlanco >> /etc/iproute2/rt_tables
# ip rule add from 192.168.90.14 table RioBlanco
# ip rule ls
0:      from all lookup local
32765:  from 192.168.90.14 lookup RioBlanco
32766:  from all lookup main
32767:  from all lookup default
# ip route add default via 192.168.90.1 dev br-salida.90 table RioBlanco
# ip route flush cache

Now both IP are responding. This changes are not persistent. To make them persisten, we have to do this:

Rule:

# cat /etc/sysconfig/network-scripts/rule-br-salida
from 192.168.90.14 table RioBlanco

Route:

# cat /etc/sysconfig/network-scripts/route-br-salida
default via 192.168.90.1 dev br-salida.90 table RioBlanco

Changes at Openstack level

changes in /etc/neutron/plugins/ml2/ml2_conf.ini:

[ml2]
type_drivers = flat,vlan,vxlan
tenant_network_types = vlan,vxlan
mechanism_drivers =openvswitch
[ml2_type_vlan]
network_vlan_ranges = fisico-vlan:90:90

Now we had to link the physical bridge (br-salida) with the interface we configured in Openstack (fisico-vlan). This has to be don in /etc/neutron/plugins/ml2/openvswitch_agent.ini:

bridge_mappings =fisico-vlan:br-salida

Now, we have to be sure of this in /etc/neutron/l3_agent.ini:

external_network_bridge =
gateway_external_network_id =

You can achieve this when you install with packstack with answer file, with this options:

CONFIG_NEUTRON_ML2_TYPE_DRIVERS=vxlan,vlan
CONFIG_NEUTRON_ML2_TENANT_NETWORK_TYPES=vxlan,vlan
CONFIG_NEUTRON_ML2_MECHANISM_DRIVERS=openvswitch
CONFIG_NEUTRON_ML2_VLAN_RANGES=fisico-vlan:90:90
CONFIG_NEUTRON_L3_EXT_BRIDGE=
CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS=fisico-vlan:br-salida

Reboot. After the reboot, finally:

~(keystone_admin]# neutron net-create externa_vlan90 --shared --provider:network_type vlan --provider:segmentation_id 90 --provider:physical_network fisico-vlan --router:external

~(keystone_admin]# neutron subnet-create --name sub-externa_vlan90 --gateway 192.168.90.1  --allocation-pool start=192.168.90.25,end=192.168.90.35 externa_vlan90 192.168.90.0/24

After all this, Openstack is ready to work with this new network that is using VLAN tag (90), so in Horizon, we can:

  • create a new internal network (with a sub net on it)
  • Create a router that has this internal network and uses the new external network just created (externa_vlan90) as gateway
  • Launch an instance in this environment, and associate a floating IP from this new pool

That's it.

UPDATE

@andrew.shvartz asked for this:

# ovs-ofctl dump-flows br-salida | grep NORMAL
 cookie=0x87f2e5150ed1a394, duration=79193.730s, table=0, n_packets=44401, n_bytes=3777718, idle_age=2956, hard_age=65534, priority=4,in_port=1,dl_vlan=1 actions=mod_vlan_vid:90,NORMAL
 cookie=0x87f2e5150ed1a394, duration=80338.782s, table=0, n_packets=552789, n_bytes=407772490, idle_age=0, hard_age=65534, priority=0 actions=NORMAL
# ovs-ofctl dump-flows br-salida | grep NORMAL
 cookie=0x87f2e5150ed1a394, duration=79194.703s, table=0, n_packets=44401, n_bytes=3777718, idle_age=2957, hard_age=65534, priority=4,in_port=1,dl_vlan=1 actions=mod_vlan_vid:90,NORMAL
 cookie=0x87f2e5150ed1a394, duration=80339.755s, table=0, n_packets=552800, n_bytes=407773946, idle_age=0, hard_age=65534, priority=0 actions=NORMAL
# ovs-ofctl dump-flows br-salida | grep NORMAL
 cookie=0x87f2e5150ed1a394, duration=79195.579s, table=0, n_packets=44401, n_bytes=3777718, idle_age=2958, hard_age=65534, priority=4,in_port=1,dl_vlan=1 actions=mod_vlan_vid:90,NORMAL
 cookie=0x87f2e5150ed1a394, duration=80340.631s, table=0, n_packets=552813, n_bytes=407775522, idle_age=0, hard_age=65534, priority=0 actions=NORMAL
# ovs-ofctl dump-flows br-salida | grep NORMAL
 cookie=0x87f2e5150ed1a394, duration=79196.281s, table=0, n_packets=44401, n_bytes=3777718, idle_age=2959, hard_age=65534, priority=4,in_port=1,dl_vlan=1 actions=mod_vlan_vid:90,NORMAL
 cookie=0x87f2e5150ed1a394, duration=80341.333s, table=0, n_packets=552822, n_bytes=407776858, idle_age=0, hard_age=65534, priority=0 actions=NORMAL
# ovs-ofctl dump-flows br-salida | grep NORMAL
 cookie=0x87f2e5150ed1a394, duration=79196.897s, table=0, n_packets=44401, n_bytes=3777718, idle_age=2960, hard_age=65534, priority=4,in_port=1,dl_vlan=1 actions=mod_vlan_vid:90,NORMAL
 cookie=0x87f2e5150ed1a394, duration=80341.949s, table=0, n_packets=552829, n_bytes=407777926, idle_age=0, hard_age=65534, priority=0 actions=NORMAL
# ovs-ofctl dump-flows br-int | grep dl_vlan=90
 cookie=0x8294a4ca2fd6ec57, duration=79204.002s, table=0, n_packets=65851, n_bytes=78387142, idle_age=2967, hard_age=65534, priority=3,in_port=1,dl_vlan=90 actions=mod_vlan_vid:1,NORMAL
# ip -details link show br-salida
9: br-salida: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT
link/ether b8:ca:3a:60:80:c0 brd ff:ff:ff:ff:ff:ff promiscuity 1
openvswitch addrgenmode eui64

Nobody answer and I figured out how to do it, so I'm going to answer. Maybe is useful to somebody in the future.

I had to make a whole new approach to the problem and this was my way to do it:

Changes at OS level

I won't use VLAN at the interfaces level, but I will do it at bridge level, so em1.90 won't exists at all. so:

# cd /etc/sysconfig/network-scripts/
# cat ifcfg-em1
DEVICE="em1"
ONBOOT=yes
OVS_BRIDGE=br-salida
TYPE=OVSPort
DEVICETYPE="ovs"

# cat ifcfg-br-salida
DEVICE=br-salida
BOOTPROTO=none
ONBOOT=yes
TYPE=OVSBridge
DEVICETYPE="ovs"
IPADDR="192.168.70.14"
NETMASK="255.255.255.0"
DNS1="192.168.10.7"
GATEWAY=”192.168.70.1”

# cat ifcfg-br-salida.90
BOOTPROTO="none"
DEVICE="br-salida.90"
ONBOOT="yes"
IPADDR="192.168.90.14"
PREFIX="24"
DNS1="192.168.10.7"
VLAN=yes 
NOZEROCONF=yes
USERCTL=no

Reboot.

At this point, 192.168.70.14 should be answering, but 192.168.90.14 not. So, thanks to http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.simple.html I did this:

We create a table called "RioBlanco" and we will configure that everything that come from 192.168.90.14 has to be assosiated to this table (rule) and goes to 192.168.90.1 (route):

# echo 200 RioBlanco >> /etc/iproute2/rt_tables
# ip rule add from 192.168.90.14 table RioBlanco
# ip rule ls
0:      from all lookup local
32765:  from 192.168.90.14 lookup RioBlanco
32766:  from all lookup main
32767:  from all lookup default
# ip route add default via 192.168.90.1 dev br-salida.90 table RioBlanco
# ip route flush cache

Now both IP are responding. This changes are not persistent. To make them persisten, we have to do this:

Rule:

# cat /etc/sysconfig/network-scripts/rule-br-salida
from 192.168.90.14 table RioBlanco

Route:

# cat /etc/sysconfig/network-scripts/route-br-salida
default via 192.168.90.1 dev br-salida.90 table RioBlanco

Changes at Openstack level

changes in /etc/neutron/plugins/ml2/ml2_conf.ini:

[ml2]
type_drivers = flat,vlan,vxlan
tenant_network_types = vlan,vxlan
mechanism_drivers =openvswitch
[ml2_type_vlan]
network_vlan_ranges = fisico-vlan:90:90

Now we had to link the physical bridge (br-salida) with the interface we configured in Openstack (fisico-vlan). This has to be don in /etc/neutron/plugins/ml2/openvswitch_agent.ini:

bridge_mappings =fisico-vlan:br-salida

Now, we have to be sure of this in /etc/neutron/l3_agent.ini:

external_network_bridge =
gateway_external_network_id =

You can achieve this when you install with packstack with answer file, with this options:

CONFIG_NEUTRON_ML2_TYPE_DRIVERS=vxlan,vlan
CONFIG_NEUTRON_ML2_TENANT_NETWORK_TYPES=vxlan,vlan
CONFIG_NEUTRON_ML2_MECHANISM_DRIVERS=openvswitch
CONFIG_NEUTRON_ML2_VLAN_RANGES=fisico-vlan:90:90
CONFIG_NEUTRON_L3_EXT_BRIDGE=
CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS=fisico-vlan:br-salida

Reboot. After the reboot, finally:

~(keystone_admin]# neutron net-create externa_vlan90 --shared --provider:network_type vlan --provider:segmentation_id 90 --provider:physical_network fisico-vlan --router:external

~(keystone_admin]# neutron subnet-create --name sub-externa_vlan90 --gateway 192.168.90.1  --allocation-pool start=192.168.90.25,end=192.168.90.35 externa_vlan90 192.168.90.0/24

After all this, Openstack is ready to work with this new network that is using VLAN tag (90), so in Horizon, we can:

  • create a new internal network (with a sub net on it)
  • Create a router that has this internal network and uses the new external network just created (externa_vlan90) as gateway
  • Launch an instance in this environment, and associate a floating IP from this new pool

That's it.

UPDATE

@andrew.shvartz asked for this:

# ovs-ofctl dump-flows br-salida | grep NORMAL
 cookie=0x87f2e5150ed1a394, duration=79193.730s, table=0, n_packets=44401, n_bytes=3777718, idle_age=2956, hard_age=65534, priority=4,in_port=1,dl_vlan=1 actions=mod_vlan_vid:90,NORMAL
 cookie=0x87f2e5150ed1a394, duration=80338.782s, table=0, n_packets=552789, n_bytes=407772490, idle_age=0, hard_age=65534, priority=0 actions=NORMAL
# ovs-ofctl dump-flows br-salida | grep NORMAL
 cookie=0x87f2e5150ed1a394, duration=79194.703s, table=0, n_packets=44401, n_bytes=3777718, idle_age=2957, hard_age=65534, priority=4,in_port=1,dl_vlan=1 actions=mod_vlan_vid:90,NORMAL
 cookie=0x87f2e5150ed1a394, duration=80339.755s, table=0, n_packets=552800, n_bytes=407773946, idle_age=0, hard_age=65534, priority=0 actions=NORMAL
# ovs-ofctl dump-flows br-salida | grep NORMAL
 cookie=0x87f2e5150ed1a394, duration=79195.579s, table=0, n_packets=44401, n_bytes=3777718, idle_age=2958, hard_age=65534, priority=4,in_port=1,dl_vlan=1 actions=mod_vlan_vid:90,NORMAL
 cookie=0x87f2e5150ed1a394, duration=80340.631s, table=0, n_packets=552813, n_bytes=407775522, idle_age=0, hard_age=65534, priority=0 actions=NORMAL
# ovs-ofctl dump-flows br-salida | grep NORMAL
 cookie=0x87f2e5150ed1a394, duration=79196.281s, table=0, n_packets=44401, n_bytes=3777718, idle_age=2959, hard_age=65534, priority=4,in_port=1,dl_vlan=1 actions=mod_vlan_vid:90,NORMAL
 cookie=0x87f2e5150ed1a394, duration=80341.333s, table=0, n_packets=552822, n_bytes=407776858, idle_age=0, hard_age=65534, priority=0 actions=NORMAL
# ovs-ofctl dump-flows br-salida | grep NORMAL
 cookie=0x87f2e5150ed1a394, duration=79196.897s, table=0, n_packets=44401, n_bytes=3777718, idle_age=2960, hard_age=65534, priority=4,in_port=1,dl_vlan=1 actions=mod_vlan_vid:90,NORMAL
 cookie=0x87f2e5150ed1a394, duration=80341.949s, table=0, n_packets=552829, n_bytes=407777926, idle_age=0, hard_age=65534, priority=0 actions=NORMAL
# ovs-ofctl dump-flows br-int | grep dl_vlan=90
 cookie=0x8294a4ca2fd6ec57, duration=79204.002s, table=0, n_packets=65851, n_bytes=78387142, idle_age=2967, hard_age=65534, priority=3,in_port=1,dl_vlan=90 actions=mod_vlan_vid:1,NORMAL
# ip -details link show br-salida
9: br-salida: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT
link/ether b8:ca:3a:60:80:c0 brd ff:ff:ff:ff:ff:ff promiscuity 1
openvswitch addrgenmode eui64
# lsmod | grep 8021 8021q 29022 0 garp 14384 1 8021q mrp 18542 1 8021q # ip -details link show em1 4: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP mode DEFAULT qlen 1000 link/ether b8:ca:3a:60:80:c0 brd ff:ff:ff:ff:ff:ff promiscuity 1 addrgenmode none