Thanks Marco. Things are lot clearer now. Really appreciate it! BR, Viswa
<http://www.verizon.com> Viswanath Kumar Skand Priya Architect SDN, Cloud Services & Orchestration On Fri, Aug 25, 2017 at 6:52 PM, PLATANIA, MARCO (MARCO) < [email protected]> wrote: > Kumar, Bharath, > > > > VPP is the vLB. VPP has many plugins, so you can configure it to play > different roles. In the vLB/vDNS use case, we use VPP as packet generator > (VM1) and vLB (VM2). In the vFW use case, we use it as packet generator > (VM1) and vFW (VM2). For the vLB scenario, nslookups directed to the vLB > are captured by VPP and sent over to one of the existing vDNSs. > > > > Regarding the discovery service that vLB and vDNS use, I’m not aware of > any VPP discovery service, so we implemented our own. > > > > Lately, we found that the vLB use case used in release-1.0.0 didn’t work > in some OpenStack labs, due to VPP config issues (use cases for > release-1.0.0 supported Rackspace only). We are now using the latest VPP > (1707). The vLB use case architecture changed a little: while for > release-1.0.0 we only had vLB and vDNS, the current release adds a packet > generator VM as part of the VNF. Please use this one because is more stable. > > > > To test it, you can log into the packet generator VM and run nslookups > like: > > > > nslookup host1.dnsdemo.onap.org vLB_IP_ADDRESS > > > > The vLB_IP_ADDRESS is the IP address towards the private network that > connects vLB and packet generator. If you are using the latest template in > Gerrit (https://gerrit.onap.org/r/gitweb?p=demo.git;a=tree;f=heat/vLB;h= > e69c2fadce8452da7840b3177c7e2ad694bf1959;hb=refs/heads/master > <https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_gitweb-3Fp-3Ddemo.git-3Ba-3Dtree-3Bf-3Dheat_vLB-3Bh-3De69c2fadce8452da7840b3177c7e2ad694bf1959-3Bhb-3Drefs_heads_master&d=DwMGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=9F3pNUkzjE-2v1eTClkRVTaKybM-QdOEEflZQ1UA1C3bK3Y3fLmJGlCViaBBmZar&m=uoAmj6rWZhjoYOy2zSY3sd7HYL_ZZEhkc7FN7wjUPWo&s=TloTt-q3dAfXaQGAf2_gAPO-ucMFJIxWcwF8mXIV-tY&e=> > ), that address is set to 192.168.9.111. > > > > Thanks, > > Marco > > > > > > *From: *"Kumar Skand Priya, Viswanath V" <viswanath.kumarskandpriya@ > verizon.com> > *Date: *Friday, August 25, 2017 at 4:27 AM > *To: *bharath thiruveedula <[email protected]> > *Cc: *"PLATANIA, MARCO (MARCO)" <[email protected]>, " > [email protected]" <[email protected]>, Josef > Reisinger <[email protected]> > *Subject: *Re: [E] [onap-discuss] vLB/vDNS Queries > > > > Hi Marco, > > I would like to rephrase one of Bharath’s question : > > Assuming vLB and vDNS are in same private network, why do we need VPP in > middle? Can clients directly contact vLB inorder to reach vDNS, which then > gets scaled based on policy? > > BR, > Viswa > > On Friday, August 25, 2017, bharath thiruveedula <[email protected]> > wrote: > > Hi Marco, > > > > Marco, thanks a lot for your reply! > > > > 1) You are right, the vFW/vLB VNFs have multiple vNICs, one of > these attached to the public network. We tested them successfully in 3-4 > different vanilla OpenStack environments (Liberty and Mitaka versions) plus > Rackspace. It may be that your OpenStack configuration doesn’t > > > > allow you to attach vNICs directly to public networks, but this feature > can be enabled (although I can’t help here, sorry for that) > > > > Oh, but I think it is not recommended by openstack to directly attach > the interface to external network. I am aware that using floating-ip is > not valid in SDC, so that's why we took this approach. Not sure why SDC > team invalidates using floating ip in heat template. > > 2) The v_lb_init.sh script allows VPP to take over eth0 and eth1 > in the vLB VM. This doesn’t mean that you can’t reach the VM. It’s true > that PING and SSH don’t work, but VPP will accept nslookup requests on eth0 > from an external VM and use eth1 to forward those requests to one or more > vDNS. We didn’t test the vLB with floating IPs though. I remember that the > configuration currently in place couldn’t work straight away with floating > IPs, so for the moment we abandoned that path. As for the vDNS not > connected to the vLB, try to see if Java is downloaded and installed > correctly, and if dnsmembership.sh and dns_client.sh in vLB and vDNS VMs, > respectively, are running. These scripts launch a service that vLB and vDNS > use to discover each other via the ONAP OAM network. > > > > Yeah floating IP approach is not working, I have tested vDNS using > nslookup directly to DNS IP, it works. Bu > > t through vLB is not redirecting. I will test nslookup from the external > VM in the same network of vLB. Can you give information on dnsmembership.sh > and dns_client.sh, as why we need discovery here, does VPP take care of > that? > > Best Regards > > Bharath T > > ________________________________ > > From: PLATANIA, MARCO (MARCO) <[email protected]> > > Sent: Thursday, August 24, 2017 10:03 PM > > To: bharath thiruveedula; [email protected]; Josef Reisinger > > Subject: Re: [onap-discuss] vLB/vDNS Queries > > > > > > Bharath, > > > > > > > > 1) You are right, the vFW/vLB VNFs have multiple vNICs, one of > these attached to the public network. We tested them successfully in 3-4 > different vanilla OpenStack environments (Liberty and Mitaka versions) plus > Rackspace. It may be that your OpenStack configuration doesn’t allow you to > attach vNICs directly to public networks, but this feature can be enabled > (although I can’t help here, sorry for that) > > > > 2) The v_lb_init.sh script allows VPP to take over eth0 and eth1 > in the vLB VM. This doesn’t mean that you can’t reach the VM. It’s true > that PING and SSH don’t work, but VPP will accept nslookup requests on eth0 > from an external VM and use eth1 to forward those requests to one or more > vDNS. We didn’t test the vLB with floating IPs though. I remember that the > configuration currently in place couldn’t work straight away with floating > IPs, so for the moment we abandoned that path. As for the vDNS not > connected to the vLB, try to see if Java is downloaded and installed > correctly, and if dnsmembership.sh and dns_client.sh in vLB and vDNS VMs, > respectively, are running. These scripts launch a service that vLB and vDNS > use to discover each other via the ONAP OAM network. > > > > 3) The vFW/vLB demos work in ONAP release 1.0.0, in Rackspace. The > ONAP code currently in the master branch is supposed to support vFW/vLB > demos in vanilla OpenStack, although the code is being tested right now. > Some issue is preventing the closed loop to work correctly. If you want to > test the closed loop in OpenStack, you may consider to install ONAP 1.0.0 > plus DCAE 1.1.0 and MSO 1.1.0 in O > > -- > > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=KgFIQiUJzSC0gUhJaQxg8eC3w16GC3sKgWIcs4iIee0&m=_oTHH6MG0bXoH3fRJZF542GoHdbff1wk826wqtD8dp8&s=YyPnAWxQPPzfjJlpQ3ujuSrywrBWW2KZGIoPXkiOMoM&e=> > > > > Viswanath Kumar Skand Priya > > Architect > > SDN, Cloud Services & Orchestration > > > > > >
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
