On Wed, Feb 8, 2017 at 7:44 AM, Srikanth Lingala <srikanth.ling...@nxp.com>
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 <srikanth.ling...@nxp.com>
> *Cc:* Brady Allen Johnson <brady.allen.john...@ericsson.com>;
> sfc-...@lists.opendaylight.org; opnfv-tech-discuss@lists.opnfv.org; Gorja
> Gorja <prasad.go...@nxp.com>; Rozet, Tim <tro...@redhat.com>; Ferenc
> Cserepkei <ferenc.cserep...@ericsson.com>
> *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{getExternalIdKey=opendaylight-iid, getExternalIdValue=/network-to
> pology:network-topology/network-topology:topology[network-
> topology:topology-id='ovsdb:1']/network-topology:node[
> network-topology:node-id='ovsdb://uuid/7e64138d-8a76-4f1
> 6-a6d8-35095922bf60/bridge/br-int']/network-topology:termina
> tion-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.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=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=[PortExtern
> alIds{getExternalIdKey=opendaylight-iid, getExternalIdValue=/network-to
> pology:network-topology/network-topology:topology[network-
> topology:topology-id='ovsdb:1']/network-topology:node[
> network-topology:node-id='ovsdb://uuid/7e64138d-8a76-4f1
> 6-a6d8-35095922bf60/bridge/br-int']/network-topology:termina
> tion-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.u
> rn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.OvsdbBrid
> geAugmentation=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=
> 'ovsdb://uuid/7e64138d-8a76-4f16-a6d8-35095922bf60/bridge/br-int'],
> augmentations={}}], getBridgeName=OvsdbBridgeName [_value=br-int],
> getBridgeOpenflowNodeRef=KeyedInstanceIdentifier{targetType=interface
> org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yang.netw
> ork.topology.rev131021.network.topology.topology.Node, path=[
> org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yan
> g.network.topology.rev131021.NetworkTopology,
> org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yang.netw
> ork.topology.rev131021.network.topology.Topology[key=TopologyKey
> [_topologyId=Uri [_value=ovsdb:1]]], org.opendaylight.yang.gen.v1.u
> rn.tbd.params.xml.ns.yang.network.topology.rev131021.network
> .topology.topology.Node[key=NodeKey [_nodeId=Uri
> [_value=ovsdb://uuid/7e64138d-8a76-4f16-a6d8-35095922bf60]]]]},
> getBridgeOtherConfigs=[BridgeOtherConfigs{getBridgeOtherConfigKey=hwaddr,
> getBridgeOtherConfigValue=ac:ad:fe:4b:69:43, augmentations={}},
> BridgeOtherConfigs{getBridgeOtherConfigKey=disable-in-band,
> getBridgeOtherConfigValue=true, augmentations={}}], getBridgeUuid=Uuid
> [_value=22adf6f1-28d7-4098-a0f7-df732d3e1f9f],
> getControllerEntry=[ControllerEntry{getControllerUuid=Uuid
> [_value=9eb78a2f-e62f-4ae1-8c6f-21c3ac901d51], getTarget=Uri [_value=tcp:
> 192.168.0.3:6653], isIsConnected=true, augmentations={}}],
> getDatapathId=DatapathId [_value=00:00:ac:ad:fe:4b:69:43],
> getDatapathType=class org.opendaylight.yang.gen.v1.u
> rn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.DatapathTypeSystem,
> getFailMode=class org.opendaylight.yang.gen.v1.u
> rn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.OvsdbFailModeSecure,
> getManagedBy=OvsdbNodeRef [_value=KeyedInstanceIdentifier{targetType=interface
> org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yang.netw
> ork.topology.rev131021.network.topology.topology.Node, path=[
> org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yan
> g.network.topology.rev131021.NetworkTopology,
> org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yang.netw
> ork.topology.rev131021.network.topology.Topology[key=TopologyKey
> [_topologyId=Uri [_value=ovsdb:1]]], org.opendaylight.yang.gen.v1.u
> rn.tbd.params.xml.ns.yang.network.topology.rev131021.network
> .topology.topology.Node[key=NodeKey [_nodeId=Uri
> [_value=ovsdb://uuid/7e64138d-8a76-4f16-a6d8-35095922bf60]]]]}],
> getProtocolEntry=[ProtocolEntry{getProtocol=class
> org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.
> yang.ovsdb.rev150105.OvsdbBridgeProtocolOpenflow13, augmentations={}}]}}}
>
>
>
> One thing I am not able to understand is that ODL is trying to get RSP
> ‘Path-mychain-Path-114’, which is not there. When I check the RSP in the
> DLUX SFC UI, I saw the RSP as ‘Path-mychain-Path-140’. Am I missing
> anything here?
>
> This and the logs above match what Brady suspected - the chain isn't being
> built or the wrong one being requested. in the workflow you build the
> chain, then add the classifier. Those are the awarnings you see form
> netvirt - it can't get the RSP. The other warning is not finding the vxgpe
> port, which also added during the chain creation.
>
> Seems like I recall a bug at some point where the wrong chain name was
> used. Can't remember if that was from the tacker side or something else.
> Maybe Brady can remember.
>
>
>
> Regards,
>
> Srikanth.
>
>
>
> *From:* Srikanth Lingala
> *Sent:* Tuesday, February 07, 2017 9:50 PM
> *To:* 'Brady Allen Johnson' <brady.allen.john...@ericsson.com>;
> sfc-...@lists.opendaylight.org; opnfv-tech-discuss@lists.opnfv.org
> *Cc:* Ferenc Cserepkei <ferenc.cserep...@ericsson.com>; Manuel Buil <
> manuel.b...@ericsson.com>; Rozet, Tim <tro...@redhat.com>; Veera.Reddy B <
> veer...@nxp.com>; Gorja Gorja <prasad.go...@nxp.com>
> *Subject:* RE: [SFC] ODL SFC with single compute node and OVS 2.6.1 NSH
> patches
>
>
>
> Hi Brady,
>
> While adding SFC and SFC Classifier, I can’t see any valid errors in
> karaf.log. Anyways, I am pasting WARN and ERROR logs of sfc in the below
> link:
>
> Karaf warning messages:
>
> http://pastebin.com/PCa4QFft
>
>
>
> Karaf error messages:
>
> http://pastebin.com/34CmBjZW
>
>
>
> But, some of the karaf logs are old ones also.
>
>
>
> And also, I observer below errors at Openvswitch log
> (/var/log/openvswitch/ovs-vswitchd2.log):
>
>
>
> 2017-02-06T18:34:59.555Z|00110|netdev_vport|WARN|vxgpe: unknown vxlan
> argument 'nsp'
>
> 2017-02-06T18:34:59.555Z|00111|netdev_vport|WARN|vxgpe: unknown vxlan
> argument 'nshc2'
>
> 2017-02-06T18:34:59.555Z|00112|netdev_vport|WARN|vxgpe: unknown vxlan
> argument 'nshc3'
>
> 2017-02-06T18:34:59.555Z|00113|netdev_vport|WARN|vxgpe: unknown vxlan
> argument 'nshc4'
>
> 2017-02-06T18:34:59.556Z|00114|netdev_vport|WARN|vxgpe: unknown vxlan
> argument 'nsi'
>
> 2017-02-06T18:34:59.556Z|00115|netdev_vport|WARN|vxgpe: unknown vxlan
> argument 'nshc1'
>
> 2017-02-06T18:34:59.556Z|00116|netdev_linux|WARN|br-int: removing
> policing failed: Operation not supported
>
> 2017-02-06T18:34:59.556Z|00117|netdev_linux|WARN|br-phy1: removing
> policing failed: Operation not supported
>
> 2017-02-06T18:36:15.772Z|00001|ofproto_dpif_xlate(pmd9)|ERR|over max
> translation depth 64: tcp,in_port=4,vlan_tci=0x0000,
> dl_src=fa:16:3e:f1:08:d3,dl_dst=fa:16:3e:03:7c:6a,nw_src=123
> .123.123.5,nw_dst=123.123.123.4,nw_tos=0,nw_ecn=0,nw_ttl=64,
> tp_src=2000,tp_dst=80,tcp_flags=syn
>
> 2017-02-06T18:36:17.029Z|00001|ofproto_dpif_xlate(revalidator10)|ERR|over
> max translation depth 64: tcp,in_port=4,vlan_tci=0x0000,
> dl_src=fa:16:3e:f1:08:d3,dl_dst=fa:16:3e:03:7c:6a,nw_src=123
> .123.123.5,nw_dst=123.123.123.4,nw_tos=0,nw_ecn=0,nw_ttl=64,
> tp_src=2000,tp_dst=80,tcp_flags=syn
>
> 2017-02-06T18:36:46.820Z|00002|ofproto_dpif_xlate(pmd9)|ERR|over max
> translation depth 64: tcp,in_port=4,vlan_tci=0x0000,
> dl_src=fa:16:3e:f1:08:d3,dl_dst=fa:16:3e:03:7c:6a,nw_src=123
> .123.123.5,nw_dst=123.123.123.4,nw_tos=0,nw_ecn=0,nw_ttl=64,
> tp_src=2000,tp_dst=80,tcp_flags=syn
>
> 2017-02-06T18:37:18.884Z|00003|ofproto_dpif_xlate(pmd9)|ERR|over max
> translation depth 64: tcp,in_port=4,vlan_tci=0x0000,
> dl_src=fa:16:3e:f1:08:d3,dl_dst=fa:16:3e:03:7c:6a,nw_src=123
> .123.123.5,nw_dst=123.123.123.4,nw_tos=0,nw_ecn=0,nw_ttl=64,
> tp_src=2000,tp_dst=80,tcp_flags=syn
>
> 2017-02-06T18:37:19.580Z|00002|ofproto_dpif_xlate(revalidator10)|ERR|over
> max translation depth 64: tcp,in_port=4,vlan_tci=0x0000,
> dl_src=fa:16:3e:f1:08:d3,dl_dst=fa:16:3e:03:7c:6a,nw_src=123
> .123.123.5,nw_dst=123.123.123.4,nw_tos=0,nw_ecn=0,nw_ttl=64,
> tp_src=2000,tp_dst=80,tcp_flags=syn
>
>
>
> Does the above error messages are anything to do with the adding of SFC
> flows in the compute node?
>
>
>
> Regards,
>
> Srikanth.
>
>
>
> *From:* Brady Allen Johnson [mailto:brady.allen.john...@ericsson.com
> <brady.allen.john...@ericsson.com>]
> *Sent:* Tuesday, February 07, 2017 3:55 PM
> *To:* Srikanth Lingala <srikanth.ling...@nxp.com>;
> sfc-...@lists.opendaylight.org; opnfv-tech-discuss@lists.opnfv.org
> *Cc:* Ferenc Cserepkei <ferenc.cserep...@ericsson.com>; Manuel Buil <
> manuel.b...@ericsson.com>; Rozet, Tim <tro...@redhat.com>; Veera.Reddy B <
> veer...@nxp.com>; Gorja Gorja <prasad.go...@nxp.com>
> *Subject:* [SFC] ODL SFC with single compute node and OVS 2.6.1 NSH
> patches
>
>
>
>
> Srikanth,
>
> The reason wget works and doesnt send packets to the VM is because your
> classification rule (pasted below) matches on srcPort=2000 and dstPort=80,
> but you dont specify the srcPort with wget, so the packets dont match
> classification, and subsequently dont get sent to SFC (hence they dont go
> the VNF VM). The packets go directly from the client to the server.
>
> This is your classification flow:
>
> cookie=0x1110010000510255, duration=1268.611s, table=11, n_packets=896,
> n_bytes=66304, tcp,reg0=0x1,tp_src=2000,tp_dst=80
> actions=move:NXM_NX_TUN_ID[0..31]->NXM_NX_NSH_C2[],push_nsh,
> load:0x1->NXM_NX_NSH_MDTYPE[],load:0x3->NXM_NX_NSH_NP[],load
> :0xc0a8001a->NXM_NX_NSH_C1[],load:0x33->NXM_NX_NSP[0..23],
> load:0xff->NXM_NX_NSI[],load:0x7b7b7b03->NXM_NX_TUN_IPV4_DST
> [],load:0x33->NXM_NX_TUN_ID[0..31],resubmit(,0)
>
>
> Looking at the flows in more detail, I dont see the SFC flows, which is
> why the packets dont go to the VNF VM when you use curl. When SFC is used
> with Netvirt for OPNFV (which is what you're doing here) the SFC flows
> should be in tables 0 and tables 152-158. The largest table I see here is
> 111. Netvirt is working correctly, and sending the packets to SFC, but the
> SFC flows dont exist.
>
> Can you check the ODL logs to see if something failed in SFC. The ODL logs
> are usually in /opt/opendaylight/data/logs/karaf.log* Just do this grep
> to see what happened:
>
> grep -i sfc /opt/opendaylight/data/logs/karaf.log*
>
>
> Regards,
>
> Brady
>
> On 07/02/17 09:24, Srikanth Lingala wrote:
>
> Hi,
>
> My setup includes:
>
> · One Openstack Controller with ODL (of course with SFC) which is
> deployed through OPNFV Colorado 3.0
>
> · One aarch64 Compute Node (OpenStack Mitaka), which is attached
> to the above OS Controller
>
>
>
> I downloaded OVS 2.6.1 from OVS git hub and applied NSH patches from below
> URL:
>
>
>
> https://github.com/yyang13/ovs_nsh_patches/tree/master/v2.6.1
>
>
>
> I am able to create the SFC attributes like VNFD, VNF, Chain, and
> Classifier through Tim Rozet SFC walkthrough (
> https://github.com/trozet/sfc-random/blob/master/tacker_sfc
> _apex_walkthrough.txt). And also, I launched VNF, http_server and
> http_client VM’s on the same compute node.
>
> All the related NSH flows are added to the bridge ‘br-int’ in the compute
> node without fail.
>
>
>
> But, when I execute the command ‘*curl --local-port 2000 123.123.123.4*’
> from the http_client VM, I am getting the below error message:
>
>
>
> *curl: (7) Failed to connect to 123.123.123.4 port 80: Connection timed
> out*
>
>
>
> When I execute the command ‘*wget 123.123.123.4*’ from the http_client
> VM, I am getting the 200 OK response.
>
> But, in both the cases, no VxLAN packets are coming at the tacker VNF VM
> (using vxlan_tool.py).
>
>
>
> OVS bridges and flows details of Compute Node are given at the below link:
>
> http://pastebin.com/MEN7dk8n
>
>
>
> Can anyone give me some clue, to debug the issue.
>
>
>
> I also want to know, whether anyone one are succeeded while executing SFC
> across compute node through ODL and OVS 2.6.1 with NSH patches from Yang.
>
> Thanks for the help.
>
>
>
> Regards,
>
> Srikanth.
>
>
>
>
> _______________________________________________
> 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
