Hi Chaoyi, I didn't consider Ronghui's environment which I have no idea about.
> That's why Zhiyuan proposed hacking way to do it. Considering such a limited situation, I understood this solution is for particular situation which is not usual for cascaded stack environment. Is it same of what you are implying in your message? I would like to avoid any misunderstanding between members as much as possible. Cheers, Shinobu On Wed, May 4, 2016 at 10:25 AM, joehuang <joehu...@huawei.com> wrote: > Hi, Shinobu, > > I think Zhiyuan's suggestion is mainly for Ronghui's environment, for his > environment has very limited network infterfaces, it's difficult to > experiment N-S feature. It would be recommended to use VMs for setting up > Tricircle test bed with two bottom pods, so it's much more easier to manage > networking plane for different purpose. But Ronghui's machine also have very > limited vCPU and memory, so booting serveral VMs to establish the tricircle > and two bottom pods test bed also not possible. That's why Zhiyuan proposed > hacking way to do it. > > Best Regards > Chaoyi Huang ( joehuang ) > > ________________________________________ > From: Shinobu Kinjo [shinobu...@gmail.com] > Sent: 04 May 2016 6:58 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [tricircle] Easy Way to Test Tricircle > North-South L3 Networking > > Vega, > > On Tue, May 3, 2016 at 5:49 PM, Vega Cai <luckyveg...@gmail.com> wrote: >> Hi all, >> >> Just would like to share a way to test Tricircle north-south L3 networking >> without requiring the third interface. >> >> In the Tricircle readme, it is said that you need to add an interface in >> your host to br-ext bridge. One interface to access the host, one interface >> for east-west networking and one interface for north-south networking, so >> all together three interfaces are required. >> >> What if your host only have two interfaces? Here is another deployment >> choice. >> >> First, change your external network type to flat type. If you are using the >> DevStack script provided by Tricircle, do the following changes in node2 >> local.conf then run DevStack in node2. >> >> (1) change Q_ML2_PLUGIN_VLAN_TYPE_OPTIONS >> from (network_vlan_ranges=bridge:2001:3000,extern:3001:4000) >> to (network_vlan_ranges=bridge:2001:3000) >> (since we going to use flat external network, no need to configure VLAN >> range for extern) >> (2) add PHYSICAL_NETWORK=extern >> (3) keep OVS_BRIDGE_MAPPINGS=bridge:br-bridge,extern:br-ext > > Good point. > >> >> Second, specify flat type when creating external network. >> >> curl -X POST http://127.0.0.1:9696/v2.0/networks >> -H "Content-Type: application/json" \ >> -H "X-Auth-Token: $token" \ >> -d '{"network": {"name": "ext-net", "admin_state_up": true, >> "router:external": true, "provider:network_type": "flat", >> "provider:physical_network": "extern", "availability_zone_hints": >> ["Pod2"]}}' > > Understood. > >> >> Third, configure IP address of br-ext. >> >> sudo ifconfig br-ext 163.3.124.1 netmask 255.255.255.0 >> >> Here 163.3.124.1 is your external network gateway IP, set net mask >> according to your CIDR. >> >> After the above steps, you can access your VM via floating IP in node2. Also >> your VM can ping the external gateway. >> >> Would like your VM to access the Internet?(Of course node2 should be able to >> access the Internet) Two more steps to follow: >> (1) Enable packet forward in node2 >> >> sudo bash >> echo 1 >/proc/sys/net/ipv4/ip_forward >> >> (2) Configure SNAT in node2 >> >> sudo iptables -t nat -I POSTROUTING -s 163.3.124.0/24 -o eth1 -j SNAT >> --to-source 10.250.201.21 >> >> 163.3.124.0/24 is your external network CIDR, eth1 is the interface >> associated with your default route in node2 and 10.250.201.21 is the IP of >> eth1. > > I would like to avoid this kind of hackery way as much as possible. > I would like to see your further recommendation so that we easily and > quickly build cascaded stack system including top. > >> >> Hope this information helps. >> >> BR >> Zhiyuan >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Email: > shin...@linux.com > GitHub: > shinobu-x > Blog: > Life with Distributed Computational System based on OpenSource > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Email: shin...@linux.com shin...@redhat.com __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
