There is nothing wrong with your setup. L3 routing is done by the network node. L3 is already blocked by security groups. The vlans provide L2 isolation. Essentially we handle this with convention, as in tell your tenants not to open up their firewalls if they don't want to be accessed by other tenants.
for example: nova secgroup-add-rule default tcp 22 22 192.168.0.0/24 # or some other restricted range instead of: nova secgroup-add-rule default tcp 22 22 0.0.0.0/0 People seem to expect l3 traffic to be totally blocked between tenants. I'm not totally convinced that is good behavior, but it should be possible to produce a patch that will do this. In fact I've put together a potential version here: https://review.openstack.org/#/c/20362/ Unless I've messed something up, with this patch, you should be able to set: bridge_forward_inteface=xxx # where xxx is your public_interface And get the behavior you expect. Vish On Jan 23, 2013, at 2:27 PM, Ronivon Costa <ronivon.co...@gmail.com> wrote: > Hello, > > > I have just installed Folsom in a physical server, and the tenants can also > ping and ssh into each others instances. > I think there is something wrong with my setup. > > Below I provide some info from the deployment. > Any tip will be very much appreciated. > > Thanks. > Roni > > > nova-manage network list > id IPv4 IPv6 start address DNS1 > DNS2 VlanID project uuid > 1 10.0.0.0/24 None 10.0.0.3 None > None 100 c0561ee64e6c40b2aea3bdcf47916f18 > c417baf7-f989-49d9-973d-f6f2b51a2d5c > 2 10.0.1.0/24 None 10.0.1.3 None > None 101 36ae086d927f49039cedfcb046463876 > 4bff308a-7990-46a4-952b-772d4953cb10 > > > -- > > brctl show > > bridge name bridge id STP enabled interfaces > br100 8000.fa163e7b7397 no vlan100 > > vnet0 > br101 8000.fa163e7baec0 no vlan101 > vnet1 > > ------- > > br100 Link encap:Ethernet HWaddr fa:16:3e:7b:73:97 > inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0 > inet6 addr: fe80::b016:8dff:fefa:43db/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:531 errors:0 dropped:0 overruns:0 frame:0 > TX packets:803 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:66890 (66.8 KB) TX bytes:90421 (90.4 KB) > > br101 Link encap:Ethernet HWaddr fa:16:3e:7b:ae:c0 > inet addr:10.0.1.1 Bcast:10.0.1.255 Mask:255.255.255.0 > inet6 addr: fe80::c41:bbff:fed4:354b/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:422 errors:0 dropped:0 overruns:0 frame:0 > TX packets:574 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:65212 (65.2 KB) TX bytes:69840 (69.8 KB) > > dummy0 Link encap:Ethernet HWaddr 02:dc:e1:5c:aa:5e > inet6 addr: fe80::dc:e1ff:fe5c:aa5e/64 Scope:Link > UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:169 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 B) TX bytes:23932 (23.9 KB) > > dummy1 Link encap:Ethernet HWaddr 72:2d:2b:59:a2:d1 > BROADCAST NOARP MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > > dummy2 Link encap:Ethernet HWaddr 72:6f:28:d7:e8:cd > BROADCAST NOARP MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > > eth0 Link encap:Ethernet HWaddr 00:1a:92:08:1f:47 > inet addr:10.100.200.126 Bcast:10.100.200.255 Mask:255.255.255.0 > inet6 addr: fe80::21a:92ff:fe08:1f47/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:210280 errors:1 dropped:0 overruns:0 frame:1 > TX packets:20752 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:310541700 (310.5 MB) TX bytes:1983489 (1.9 MB) > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:91449 errors:0 dropped:0 overruns:0 frame:0 > TX packets:91449 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:600766448 (600.7 MB) TX bytes:600766448 (600.7 MB) > > vlan100 Link encap:Ethernet HWaddr fa:16:3e:7b:73:97 > inet6 addr: fe80::f816:3eff:fe7b:7397/64 Scope:Link > UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:71 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 B) TX bytes:11025 (11.0 KB) > > vlan101 Link encap:Ethernet HWaddr fa:16:3e:7b:ae:c0 > inet6 addr: fe80::f816:3eff:fe7b:aec0/64 Scope:Link > UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:95 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 B) TX bytes:12033 (12.0 KB) > > vnet0 Link encap:Ethernet HWaddr fe:16:3e:7b:0b:14 > inet6 addr: fe80::fc16:3eff:fe7b:b14/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:531 errors:0 dropped:0 overruns:0 frame:0 > TX packets:764 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:74324 (74.3 KB) TX bytes:84372 (84.3 KB) > > vnet1 Link encap:Ethernet HWaddr fe:16:3e:5c:99:18 > inet6 addr: fe80::fc16:3eff:fe5c:9918/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:422 errors:0 dropped:0 overruns:0 frame:0 > TX packets:520 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:71120 (71.1 KB) TX bytes:63161 (63.1 KB) > > wlan0 Link encap:Ethernet HWaddr 00:24:01:12:c8:6b > BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > > > On 21 January 2013 11:15, Kevin Jackson <ke...@linuxservices.co.uk> wrote: > Hi Roni, > VirtualBox should honour the VLAN tagging, but it seems its related to the > driver type used: e1000 strips the VLAN tag it seems. I don't recall having > this issue, but if I get time I'll be happy to spin an environment up and > have a play. > > See this post: http://humbledown.org/virtualbox-intel-vlan-tag-stripping.xhtml > > Regards, > Kev > > > On 20 January 2013 15:32, Ronivon Costa <ronivon.co...@gmail.com> wrote: > Hello, > > I am playing with Openstack and VlanManager in a Virtualbox machine. Is it > tenant isolation supposed to work in this setup? > > I have several tenants, and the instances for them have landed on different > subnets (11.0.1.x, 11.0.2.x, 11.0.3.x, etc). > > It is possible to ping and ssh other tenant instances from any tenant! > > Is this the correct behaviour for a virtualized deployement ? > > Cheers, > Roni > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > > > > -- > Kevin Jackson > @itarchitectkev > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
