Re: [opnfv-tech-discuss] [sfc-dev] [SFC] ODL SFC with single compute node and OVS 2.6.1 NSH patches

2017-02-08 Thread Sam Hague 
On Wed, Feb 8, 2017 at 7:44 AM, Srikanth Lingala 
wrote:

> Hi Brady,
>
> One more observation is that SFC flows you are talking about, like table
> 152 – 158 are added in table 2 – 10 in my compute node.
>
Did you do the step to move the SFC and NetVirt flows to the proper table
offset? Not sure if tacker does that for you, otherwise do it manually: Use
your odl IP in the below commands:

curl -u admin:admin -H 'Content-type: application/json' -X PUT -d
{"netvirt-providers-config":{"table-offset":1}}
http://192.168.0.2:8181/restconf/config/netvirt-providers-config:netvirt-providers-config
curl -u admin:admin -H 'Content-type: application/json' -X PUT -d
'{"sfc-of-renderer-config":{"sfc-of-table-offset":"150","sfc-of-app-egress-table-offset":"11"}}'
http://192.168.0.2:8181/restconf/config/sfc-of-renderer:sfc-of-renderer-config

You can check the flows in the below paste link:
>
> http://pastebin.com/MEN7dk8n
>
> It seems some of the flows are missing. I am not able to understand why
> table numbers are changed in my compute node. With the same ODL controller,
> SFC worked fine with x86 compute node. Then, I attached my aarch64 compute
> node with OVS 2.6.1 patches (with DPDK), which is giving issues.
>
> Do I need to do anything different?
>
>
>
> Thanks for the help.
>
>
>
> Regards,
>
> Srikanth.
>
>
>
> *From:* Sam Hague [mailto:sha...@redhat.com]
> *Sent:* Tuesday, February 07, 2017 11:22 PM
> *To:* Srikanth Lingala 
> *Cc:* Brady Allen Johnson ;
> sfc-...@lists.opendaylight.org; opnfv-tech-discuss@lists.opnfv.org; Gorja
> Gorja ; Rozet, Tim ; Ferenc
> Cserepkei 
> *Subject:* Re: [sfc-dev] [SFC] ODL SFC with single compute node and OVS
> 2.6.1 NSH patches
>
>
>
>
>
>
>
> On Tue, Feb 7, 2017 at 12:23 PM, Srikanth Lingala <
> srikanth.ling...@nxp.com> wrote:
>
> Hi Brady,
>
> One small update.
>
> While creating SFC Classifier, in the karaf logs, I found the following
> WARNING messages:
>
>
>
> 2017-02-06 20:48:47,977 | WARN  | NV-SfcDTL-1  |
> NetvirtSfcWorkaroundOF13Provider | 295 - 
> org.opendaylight.netvirt.openstack.net-virt-sfc-impl
> - 1.3.0.Boron | Failed to get renderedServicePatch for entry:
> Ace{getActions=Actions{augmentations={interface
> org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.
> yang.netvirt.sfc.acl.rev150105.RedirectToSfc=RedirectToSfc{
> getRspName=Path-mychain-Path-114, isRenderRsp=false}}},
> getMatches=Matches{getAceType=AceIp{getDestinationPortRange=
> DestinationPortRange{getLowerPort=PortNumber [_value=80],
> getUpperPort=PortNumber [_value=80], augmentations={}}, getProtocol=6,
> getSourcePortRange=SourcePortRange{getLowerPort=PortNumber [_value=2000],
> getUpperPort=PortNumber [_value=2000], augmentations={}},
> augmentations={}}, augmentations={}}, getRuleName=myclass, augmentations={}}
>
>
>
> 2017-02-06 20:48:53,252 | WARN  | NV-SfcDTL-1  |
> NetvirtSfcWorkaroundOF13Provider | 295 - 
> org.opendaylight.netvirt.openstack.net-virt-sfc-impl
> - 1.3.0.Boron | handleRenderedServicePath: Could not identify gpe vtep
> vxgpe -> OF (0) on Node{getNodeId=Uri [_value=ovsdb://uuid/7e64138d-
> 8a76-4f16-a6d8-35095922bf60/bridge/br-int], 
> getTerminationPoint=[TerminationPoint{getTpId=Uri
> [_value=br-int], augmentations={interface org.opendaylight.yang.gen.v1.u
> rn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.OvsdbTerm
> inationPointAugmentation=OvsdbTerminationPointAugmentation{getIfindex=35,
> getIngressPolicingBurst=0, getIngressPolicingRate=0, getInterfaceType=class
> org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.
> yang.ovsdb.rev150105.InterfaceTypeInternal, getInterfaceUuid=Uuid
> [_value=c4d8822d-a58c-4e9a-b02c-4d1a12cd1a9a], getName=br-int,
> getOfport=65534, getPortUuid=Uuid 
> [_value=963afdf4-b908-46d6-b153-32d6b30e5f85]}}},
> TerminationPoint{getTpId=Uri [_value=vxlan-192.168.2.26],
> augmentations={interface org.opendaylight.yang.gen.v1.u
> rn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.OvsdbTerm
> inationPointAugmentation=OvsdbTerminationPointAugmentation{getIfindex=0,
> getIngressPolicingBurst=0, getIngressPolicingRate=0, getInterfaceType=class
> org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.
> yang.ovsdb.rev150105.InterfaceTypeVxlan, getInterfaceUuid=Uuid
> [_value=fa8eca30-cba1-494c-a039-8019eac50c87],
> getName=vxlan-192.168.2.26, getOfport=6, 
> getOptions=[Options{getOption=local_ip,
> getValue=192.168.2.1, augmentations={}}, Options{getOption=remote_ip,
> getValue=192.168.2.26, augmentations={}}, Options{getOption=key,
> getValue=flow, augmentations={}}], getPortExternalIds=[PortExtern
> alIds

Re: [opnfv-tech-discuss] [sfc-dev] [SFC] ODL SFC with single compute node and OVS 2.6.1 NSH patches

2017-02-07 Thread Sam Hague 
On Tue, Feb 7, 2017 at 12:23 PM, Srikanth Lingala 
wrote:

> Hi Brady,
>
> One small update.
>
> While creating SFC Classifier, in the karaf logs, I found the following
> WARNING messages:
>
>
>
> 2017-02-06 20:48:47,977 | WARN  | NV-SfcDTL-1  |
> NetvirtSfcWorkaroundOF13Provider | 295 - 
> org.opendaylight.netvirt.openstack.net-virt-sfc-impl
> - 1.3.0.Boron | Failed to get renderedServicePatch for entry:
> Ace{getActions=Actions{augmentations={interface
> org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.
> ns.yang.netvirt.sfc.acl.rev150105.RedirectToSfc=
> RedirectToSfc{getRspName=Path-mychain-Path-114, isRenderRsp=false}}},
> getMatches=Matches{getAceType=AceIp{getDestinationPortRange=
> DestinationPortRange{getLowerPort=PortNumber [_value=80],
> getUpperPort=PortNumber [_value=80], augmentations={}}, getProtocol=6,
> getSourcePortRange=SourcePortRange{getLowerPort=PortNumber [_value=2000],
> getUpperPort=PortNumber [_value=2000], augmentations={}},
> augmentations={}}, augmentations={}}, getRuleName=myclass, augmentations={}}
>
>
>
> 2017-02-06 20:48:53,252 | WARN  | NV-SfcDTL-1  |
> NetvirtSfcWorkaroundOF13Provider | 295 - 
> org.opendaylight.netvirt.openstack.net-virt-sfc-impl
> - 1.3.0.Boron | handleRenderedServicePath: Could not identify gpe vtep
> vxgpe -> OF (0) on Node{getNodeId=Uri [_value=ovsdb://uuid/7e64138d-
> 8a76-4f16-a6d8-35095922bf60/bridge/br-int], 
> getTerminationPoint=[TerminationPoint{getTpId=Uri
> [_value=br-int], augmentations={interface org.opendaylight.yang.gen.v1.
> urn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.
> OvsdbTerminationPointAugmentation=OvsdbTerminationPointAugmentation{getIfindex=35,
> getIngressPolicingBurst=0, getIngressPolicingRate=0, getInterfaceType=class
> org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.
> ns.yang.ovsdb.rev150105.InterfaceTypeInternal, getInterfaceUuid=Uuid
> [_value=c4d8822d-a58c-4e9a-b02c-4d1a12cd1a9a], getName=br-int,
> getOfport=65534, getPortUuid=Uuid 
> [_value=963afdf4-b908-46d6-b153-32d6b30e5f85]}}},
> TerminationPoint{getTpId=Uri [_value=vxlan-192.168.2.26],
> augmentations={interface org.opendaylight.yang.gen.v1.
> urn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.
> OvsdbTerminationPointAugmentation=OvsdbTerminationPointAugmentation{getIfindex=0,
> getIngressPolicingBurst=0, getIngressPolicingRate=0, getInterfaceType=class
> org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.
> ns.yang.ovsdb.rev150105.InterfaceTypeVxlan, getInterfaceUuid=Uuid
> [_value=fa8eca30-cba1-494c-a039-8019eac50c87],
> getName=vxlan-192.168.2.26, getOfport=6, 
> getOptions=[Options{getOption=local_ip,
> getValue=192.168.2.1, augmentations={}}, Options{getOption=remote_ip,
> getValue=192.168.2.26, augmentations={}}, Options{getOption=key,
> getValue=flow, augmentations={}}], getPortExternalIds=[PortExternalIds{
> getExternalIdKey=opendaylight-iid, getExternalIdValue=/network-
> topology:network-topology/network-topology:topology[
> network-topology:topology-id='ovsdb:1']/network-topology:
> node[network-topology:node-id='ovsdb://uuid/7e64138d-8a76-
> 4f16-a6d8-35095922bf60/bridge/br-int']/network-topology:
> termination-point[network-topology:tp-id='vxlan-192.168.2.26'],
> augmentations={}}], getPortUuid=Uuid 
> [_value=e91778e6-e44f-49bb-a8da-180a8b5e1a93]}}},
> TerminationPoint{getTpId=Uri [_value=vxlan-192.168.2.2],
> augmentations={interface org.opendaylight.yang.gen.v1.
> urn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.
> OvsdbTerminationPointAugmentation=OvsdbTerminationPointAugmentation{getIfindex=0,
> getIngressPolicingBurst=0, getIngressPolicingRate=0, getInterfaceType=class
> org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.
> ns.yang.ovsdb.rev150105.InterfaceTypeVxlan, getInterfaceUuid=Uuid
> [_value=4b8ff9cf-8a55-43fa-9a4a-6aeba7e0e0cd], getName=vxlan-192.168.2.2,
> getOfport=1, getOptions=[Options{getOption=local_ip,
> getValue=192.168.2.1, augmentations={}}, Options{getOption=remote_ip,
> getValue=192.168.2.2, augmentations={}}, Options{getOption=key,
> getValue=flow, augmentations={}}], getPortExternalIds=[PortExternalIds{
> getExternalIdKey=opendaylight-iid, getExternalIdValue=/network-
> topology:network-topology/network-topology:topology[
> network-topology:topology-id='ovsdb:1']/network-topology:
> node[network-topology:node-id='ovsdb://uuid/7e64138d-8a76-
> 4f16-a6d8-35095922bf60/bridge/br-int']/network-topology:
> termination-point[network-topology:tp-id='vxlan-192.168.2.2'],
> augmentations={}}], getPortUuid=Uuid 
> [_value=be986ca9-c1a4-427b-a729-6f5d7675317e]}}}],
> augmentations={interface org.opendaylight.yang.gen.v1.
> urn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.
> OvsdbBridgeAugmentation=OvsdbBridgeAugmentation{getBridgeExternalIds=[
> BridgeExternalIds{getBridgeExternalIdKey=opendaylight-iid,
> getBridgeExternalIdValue=/network-topology:network-
> topology/network-topology:topology[network-topology:
> topology-id='ovsdb:1']/network-topology:node[network-
> topology:node-id=

Re: [opnfv-tech-discuss] [sfc-dev] [SFC] [SDNVPN] ETSI NFV Plugtest - Netvirt outcome

2017-02-02 Thread Sam Hague 
Adding Aswin and Venkat.

On Feb 2, 2017 4:37 AM, "Juan Manuel Fernandez" <
juan.manuel.fernan...@ericsson.com> wrote:

> Hi,
>
>
>
> Some of the people working for OPNFV in Madrid are involved in the ETSI
> NFV Plugtest where interoperability among different MANO orchestrators,
> NFVis and VNFs is being tested. There we have brought an OPNFV Colorado
> environment configured to deploy Service Chaining (including Openstack +
> Openstack Tacker + ODL Boron), however most of the requirements are related
> to basic connectivity to be provided by ODL as a Neutron backend. In our
> case, and given we are using SFC module the Neutron back-end is old
> Netvirt, since integration with new Netvirt is not finished.
>
>
>
> I don’t know how the final results of the Plugtest will be published by
> ETSI, but in general I would say tests have gone quite well for OPNFV, but
> we have found some issues we have not been able to solve and we wonder if
> you guys are thinking on solving them (or are already solved) in new
> Netvirt or maybe we have done something wrong and not taken something into
> account:
>
>
>
> 1.   Attach to flat provider network:
>
>
>
> We are not completely sure, whether this is provided by ODL, but it seems
> not to be provided by Networking ODL in Openstack yet. Please, see the
> following proposed change in Networking ODL (not approved yet):
> https://review.openstack.org/#/c/425246/
>
>
>
> 2.   Some VNFs were working as a pure bump in the wire, re-injecting
> traffic received from a user, including a MAC/IP different than the VM’s
> (i.e. not doing MAC re-writing). In these situations, Openstack port
> security was preventing from what it is considering an anti-spoofing
> attack. In that sense we considered three different options:
>
>
>
> -  Disable completely port security in
> /etc/neutron/plugins/ml2/ml2_conf.ini, by setting port_security_enabled
> to false. This solution is too wide and unsecure, so we did not apply it.
> On the other hand, we already had some other VMs running with security
> groups associated, so we were not sure if that might be a problem.
>
> -  Disable port security in the network to be used.
> Unfortunately, this possibility that is available from Mitaka (included in
> August) was not still available in the Mirantis Openstack version (
> https://review.openstack.org/#/c/306470/) we were using, but *we wonder
> if this is supported by ODL-Netvirt (old and new).* The neutron command
> would be the following:
>
> o   neutron net-create  *--port_security_enabled=False*
>
> -  Finally, the last option we saw, was disabling port security
> and security groups in each and every port. The VM is attached to a network
> without disabling security groups, but as a next step, port security is
> disabled in the port using the following commands:
>
> o   neutron port-update --no-security-groups PORT_ID
>
> o   neutron port-update  --port-security-enabled=False
>
> This option was crashing in ODL throwing a java exception, is that
> supported in new Netvirt?
>
>
>
>  So, to sum up, are you aware of these issues in old Netvirt? Are they
> really issues? Is there a workaround? And the most important thing, in case
> they are real issues, are they already solved in new netvirt or will they
> be solved?
>
>
>
> My apologies if you have received this e-mail twice, I already sent it
> some minutes ago, but I’m not sure if was properly sent
>
>
>
> Thanks and best regards,
>
>
>
> Juanma
>
>
>
> [image: Ericsson] 
>
> *JUAN MANUEL FERNANDEZ *
> SDN System Engineer
>
>
> *Ericsson*
> Via de los Poblados 13
> 28043, Spain
> Phone +34 913392408 <+34%20913%2039%2024%2008>
> Mobile +34 618837205 <+34%20618%2083%2072%2005>
> Office 8402408
> juan.manuel.fernan...@ericsson.com
> www.ericsson.com
>
>
>
>
>
> Legal entity: Ericsson España, S.A., registered office in Madrid. This
> Communication is Confidential. We only send and receive email on the basis
> of the terms set out at www.ericsson.com/email_disclaimer
>
>
>
> ___
> sfc-dev mailing list
> sfc-...@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/sfc-dev
>
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [SFC] Nominating Manuel Buil as committer

2016-09-22 Thread Sam Hague 
+1

On Thu, Sep 22, 2016 at 10:46 AM, Paul Quinn (paulq) 
wrote:

> +1
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss