Hello, Valentin, Thank you very much for the clear expectation.
There is some challenge to put net3 directly between R1 and R2. If R1 and R2 are centralized routers, then ext-net1 is the external network for R1, and net3 could be router-interface-add to R1. Because R1 and R2 are centralized routers, it's possible to setup vxlan tunnel between R1 and R2 node, for the vxlan endpoints of R1 and R2 are fixed and limited. But if R1 or R2 is DVR(distributed virtual router), then R1/R2 will be presented in many compute nodes, if net3 is attached to both R1 and R2, then almost all compute nodes will be involved to setup the tunnel for R1/R2, there are too many management messages for the tunnelig setup, and hard to manage so many point to point tunneling for R1/R2. To reduce the tunneling endpoints between DVR routers, we have to use the centralized node for the DVR, which is used for north-south traffic, so net3 should be only setup in the centralized node of DVR. But in Neutron networking mode, a router can only be attached to one external network, and only external network is determined in centralized node. If we want to support a general mode for east-west traffic between networks in different OpenStack, we have to address DVR and one external network constraint. We understand the requirement to have north-south path in each OpenStack, while at the same to east-west traffic should also be enabled for networks. One spec has been prepared (and code will be available soon) to fulfill this demand: https://review.openstack.org/#/c/448359/3/specs/pike/l3-networking-multi-NS-with-EW-enabled.rst +-----------------------+ +----------------------+ | ext-net1 | | ext-net2 | | +---+---+ | | +--+---+ | |RegionOne | | | RegionTwo | | | +---+---+ | | +----+--+ | | | R1 | | | | R2 | | | +--+----+ | | +--+----+ | | | net1 | | net2 | | | +---+--+---+-+ | | ++-----+--+---+ | | | | | | | | | | +---------+-+ | | | | +--+--------+ | | | Instance1 | | | | | | Instance2 | | | +-----------+ | | | | +-----------+ | | +----+--+ | bridge-net | +-+-----+ | | | R3(1) +--------------------+ R3(2) | | | +-------+ | | +-------+ | +-----------------------+ +----------------------+ Figure.1 Multiple external networks with east-west networking Instance1 and Instance2 still only have one network interface. But we introduce a logical router R3(1), R3(2) and bridge-net for east-west traffic between OpenStack clouds, that means cross OpenStack cloud traffic will totally separated from traffic inside one OpenStack cloud and north-south traffic. bridge-net is the external network of R3(1) and R3(2). The traffic will goes out like this: Now, north-south traffic of Instance1 and Instance2 work like follows:: Instance1 -> net1 -> R1 -> ext-net1 Instance2 -> net2 -> R2 -> ext-net2 Only one hop for north-south traffic. East-west traffic between Instance1 and Instance2 work like follows:: Instance1 <-> net1 <-> R3(1) <-> bridge-net <-> R3(2) <-> net2 <-> Instance2 Two hops for cross OpenStack east-west traffic. Of course Tricircle can help to realize this topology with networking automation: The logical topology in central Neutron where Tricircle plugin will work look like as follows: ext-net1 ext-net2 +-------+ +--+---+ | | +---+---+ +----+--+ | R1 | | R2 | +--+----+ +--+----+ | net1 net2 | +---+--+---++ ++-----+--+---+ | | | | +---------+-+ | | +--+--------+ | Instance1 | | | | Instance2 | +-----------+ | | +-----------+ +-+----+--+ | R3 | +---------+ Figure.2 Logical topology in central Neutron It's easy to create a such topology with the help of Tricircle. For more detail, you can refer to the spec: https://review.openstack.org/#/c/448359/3/specs/pike/l3-networking-multi-NS-with-EW-enabled.rst Please note that R1 R2 and R3 are only logical routers, the total traffic handled by router R1, R2 and R3 for the instances are same as the topology you provided. We can prioritize this feature in Tricricle, so that it can be available to be used in the PoC in OPNFV Beijing Summit. Currently one video conference APP is planned to be used in the PoC, would you support to deploy clearwater vIMS VMs in the PoC environments? After the multi-site PoC environment is ready, it's easy to bring a new VNF to the multi-site clouds. We can discuss this in multi-site weekly meeting if you are interested in join the PoC. Best Regards Chaoyi Huang (joehuang) ________________________________ From: valentin.bouc...@orange.com [valentin.bouc...@orange.com] Sent: 27 March 2017 17:45 To: joehuang; Soni, Anand Kumar via opnfv-tech-discuss; Morales, Victor; Meimei Subject: RE:答复:[opnfv-tech-discuss] VNF to demonstrate VNF high availability across VIM Hi Chaoyi, Each clearwater vm can have 1 interface (signaling + management) or 2 interfaces (1 for signaling and 1 for management). See clearwater documentation => Link.<http://clearwater.readthedocs.io/en/stable/Multiple_Network_Support.html> Currently, We have only tested clearwater multisite deployement with 1 interface per VM. For this configuration, the "North South Networking via Multiple External Networks" Tricircle network scenario is interesting. But changes would have to be made to bring it closer to the needs. +-----------------+ +-----------------+ | RegionOne | | RegionTwo | | | | | | ext_net1 | | ext_net2 | | +-----+-----+ | | +-----+-----+ | | | | | | | | | | | | | | +--+--+ | | +--+--+ | | | | | net3 | | | | | | R1 |-------------------| R2 | | | | | | | | | | | +--+--+ | | +--+--+ | | | | | | | | | | | | | | +---+-+-+ | | +---+-+-+ | | net1 | | | net2 | | | | | | | | | +--------+--+ | | +--------+--+ | | | Instance1 | | | | Instance2 | | | +-----------+ | | +-----------+ | | | | | +-----------------+ +-----------------+ I think the way is to put a network between R1 and R2 instead of instance1 and instance2. Thereby, Instance1 can communicate to instance2 with his net1 ip trough the net3 network. But, also with the external componants (like sip client etc.) with a floating ip on ext_net1 or 2. BR, Valentin Boucher ________________________________ De : joehuang [joehu...@huawei.com] Envoyé : jeudi 23 mars 2017 14:53 À : BOUCHER Valentin IMT/OLN; Soni, Anand Kumar via opnfv-tech-discuss; Morales, Victor; Meimei Objet : RE: 答复:[opnfv-tech-discuss] VNF to demonstrate VNF high availability across VIM Hi Valentin, The networking topology is very clear from the picture. If we want to make vIMS clearwater as close as to the production deployment in OpenStack multisite environment, what's the better networking proposal, for example, how many interfaces for one VM, i.e, how many network planes, how to process the north-south traffic, is SNAT/FIP needed? Would like to check whether Tricircle networking automation can fulfill the demands for vIMS clearwater multi-site deployment. Tricircle already supports several typical networking topology in https://docs.openstack.org/developer/tricircle/networking-guide.html#networking-scenario ( please note that VxLAN based bridge network between routers, VxLAN based cross OpenStack L2 network will be released in pike-1 by the end of next week ) And one more typical topology is expected to be released in pike-2: L3 networking to support multiple north-south with east-west enabled: https://review.openstack.org/#/c/448359/ Best Regards Chaoyi Huang (joehuang) ________________________________ From: valentin.bouc...@orange.com [valentin.bouc...@orange.com] Sent: 23 March 2017 0:03 To: joehuang; Soni, Anand Kumar via opnfv-tech-discuss; Morales, Victor; Meimei Subject: RE:答复:[opnfv-tech-discuss] VNF to demonstrate VNF high availability across VIM Hello, Chaoyi, Oh ok, no problem. ~12 VMs with 2 Go and 1 VM with 4 Go per site VNF networking: * Only one network interface on each VM * Communication between each local site network must be allowed without any NAT/PAT or floating ip. * So, Each local VM must be able to communicate with the remote VM with his local ip. * For the moment we use a openvpn tunnel to do that and the openvpn vms acts as router between local and remote networks (see the picture in attachment). The goal is to replace openvpn tunnel with a better solution like bgp-mpls or other thing. BR, Valentin ________________________________ De : joehuang [joehu...@huawei.com] Envoyé : jeudi 16 mars 2017 14:17 À : BOUCHER Valentin IMT/OLN; Soni, Anand Kumar via opnfv-tech-discuss; Morales, Victor; Meimei Objet : 答复:[opnfv-tech-discuss] VNF to demonstrate VNF high availability across VIM Hello, Valentin, Very pleased to know the practice, and very keen to discuss about it in more detail f2f. But unfortuntealy I am not able to attend the plugfest in Paris, could you please provide reference material especial VNF's networking topology, and then find a way for more detail disucssion. BR Chaoyi Huang(joehuang) Sent from HUAWEI AnyOffice 发件人：valentin.bouc...@orange.com 收件人：黄朝意,Soni, Anand Kumar via opnfv-tech-discuss,Morales, Victor,梅玫 时间：2017-03-16 19:04:22 主题:RE:[opnfv-tech-discuss] VNF to demonstrate VNF high availability across VIM Hello, Last summer, In Orange Labs, we implemented vIMS ClearWater on a multi-site environment. We used the single site implementation with Cloudify orchestrator and updated this to support multi-site environment. As presented by Metaswitch<http://clearwater.readthedocs.io/en/stable/Geographic_redundancy.html>, vIMS Clearwater can support currently 2 sites deployment. However, our implementation only works on 2 separate OpenStack platforms because we had no multisite platform at hand. So, the network between those sites is based on a OpenVPN tunnel. The multisite mechanism works but It would be nice to be able to integrate this on a real multisite platform. Since OPNFV/Brahmaputra release, the deployment of this vIMS was included in functest project but for the moment, it only support one site. I would attend the next OPNFV/Plugfest in Paris and it could be a great opportunity to improve this test-case using your multi-site solution. Best Regards, Valentin Boucher ________________________________ De : opnfv-tech-discuss-boun...@lists.opnfv.org [opnfv-tech-discuss-boun...@lists.opnfv.org] de la part de joehuang [joehu...@huawei.com] Envoyé : jeudi 16 mars 2017 03:44 À : opnfv-tech-discuss; victor.mora...@intel.com; Meimei Objet : [opnfv-tech-discuss] VNF to demonstrate VNF high availability across VIM Hello, In multisite, we have one use cases ever discussed: a VNF (telecom application) should, be able to realize high availability deployment across OpenStack instances. For more detail of such an use cases, you can refer to https://git.opnfv.org/multisite/tree/docs/requirements/VNF_high_availability_across_VIM.rst Now, it's time to bring it into reality. After Tricircle provides cross OpenStack L2/L3 networking automation capability based on VxLAN, we'd like to have a demo in OPNFV Beijing summit to show how a VNF can run in 2 OpenStack instances and achieve high availability regardless how much nine, planned or unplanned downtime of an OpenStack cloud would be. The VNF will work in cluster, active/active or active/standby mode, and it was deployed into two OpenStack instances, overlay VxLAN network will provide network plane for session/or other data replication between VNF parts, and also provide the VIP for VNF to provide service, if the VNF is running in active/standby, the standby VNF can take over the VIP and continue to provide service after the master or the openstack cloud is failed. If you are interested in such an use case, please join us, help would be appreciated: 1. Provide or integrate sample VNF which is able to be deployed into multiple OpenStack instances to reach cloud level redundancy/failure escape. 2. Joint demo in Beijing OPNFV summit. 3. Build multi-site general infrastructure in E-release for CI/Functest/3rd party service, to provide general multi-region environment for services like Tricircle/Kingbird/Domino/Tacker which deal with multi-region functionalities. Best Regards Chaoyi Huang (joehuang) _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
