Hello, Yes I’ve seen it. Docker file is not updated with this 0.8 image version this is normal ?
I’ve updated my patch with some corrections. Regards, FR De : Alec Hothan (ahothan) [mailto:ahot...@cisco.com] Envoyé : mercredi 29 mai 2019 20:37 À : MENGUY Francois Regis TGI/OLN Cc : opnfv-tech-discuss@lists.opnfv.org Objet : Re: [opnfv-tech-discuss] #nfvbench L3 traffic use case Forgot to mention that you will need to rebase your changes as there were a few commits getting in lately - one being multiqueue support which might be of interest to you. https://gerrit.opnfv.org/gerrit/#/c/67966/ Note that this one brings in a new test VM image (0.8) as we had to add support for multiqueue in the testpmd or vpp app running in the VM. I have also bumped up the version tag to 3.3.0 so that we can get a new docker image with upgraded built-in VM image. Thanks Alec From: "Alec Hothan (ahothan)" <ahot...@cisco.com> Date: Wednesday, May 29, 2019 at 11:17 AM To: "francoisregis.men...@orange.com" <francoisregis.men...@orange.com> Cc: "opnfv-tech-discuss@lists.opnfv.org" <opnfv-tech-discuss@lists.opnfv.org> Subject: Re: [opnfv-tech-discuss] #nfvbench L3 traffic use case Hi Francois, The packet passing traffic verification code checks that we receive at least one packet from each VNF on each port. This check is done by getting the packet src MAC and comparing against the VNF MAC in local list (otherwise obtained from Openstack API or from a config). This works for the case of VLAN. In the case of VxLAN, TRex will receive a fully encapsulated packet where the outer header is the VxLAN UDP header and the inner packet is the packet coming from the VNF. So the outer header src MAC is going to be the MAC of the vswitch port – not of the VNF. Scapy will be able to extract the src mac but it will be for the outer header while what we want to get is the src mac in the inner header (scapy is not smart enough to distinguish vxlan packet). That is why we have to use the binary extraction at preset offset to read the src MAC from the inner packet if vxlan is used. Thanks Alec From: <opnfv-tech-discuss@lists.opnfv.org> on behalf of "François-Régis MENGUY via Lists.Opnfv.Org" <francoisregis.menguy=orange....@lists.opnfv.org> Reply-To: "francoisregis.men...@orange.com" <francoisregis.men...@orange.com> Date: Wednesday, May 29, 2019 at 2:01 AM To: "Alec Hothan (ahothan)" <ahot...@cisco.com> Cc: "opnfv-tech-discuss@lists.opnfv.org" <opnfv-tech-discuss@lists.opnfv.org> Subject: Re: [opnfv-tech-discuss] #nfvbench L3 traffic use case Hello Alec, I am working on taking account your comments but I have one question about retrieving source mac address in end-to-end connectivity check. I used Scapy library to identify source mac address from packet received by traffic generator and for VLAN use case no need to use binary block and choose the good offset. Scapy Ether class no need to specify some offset and seems transparent to Ethernet encapsulation. I was not able to test VXLAN use case on our platform but I hope Scapy is also able to retrieve mac source address in this case. Have you the possibility to test this part on your side ? or do you prefer to keep using binary packet and offset as before ? Regards, Francois Regis Menguy De : Alec Hothan (ahothan) [mailto:ahot...@cisco.com] Envoyé : jeudi 23 mai 2019 22:30 À : MENGUY Francois Regis TGI/OLN Cc : opnfv-tech-discuss@lists.opnfv.org Objet : Re: #nfvbench L3 traffic use case Hi Francois, Just a general follow up on the feature patchset review, I think it would be great to extend support for an L3 router on the packet path, that would work independently of how the devices in the packet path are brought up (either by nfvbench using PVP/PVVP or externally with EXT chains). This basically splits the code into several parts: • the part that handles traffic on the packet path (including ARP, IP addresses…) which works with any mode (EXT, PVP, PVVP) • the part that creates/reuses devices (openstack case only: PVP. PVVP): neutron routers, extra networks… We can limit this first version of the feature to single-chain/VLAN and see later whether there is interest in extending to multi-chaining and to VxLAN. Perhaps add some description on why this feature can be useful or what kind of problems/requirements it will address. Thanks Alec _________________________________________________________________________________________________________________________ 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.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#23205): https://lists.opnfv.org/g/opnfv-tech-discuss/message/23205 Mute This Topic: https://lists.opnfv.org/mt/31735294/21656 Mute #nfvbench: https://lists.opnfv.org/mk?hashtag=nfvbench&subid=2783016 Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
