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

Fri, 10 Feb 2017 01:13:43 -0800 

Srikanth,
I looked at the flows from your previous email, and I can see that the packets were indeed being sent to the SF. 


So you know in the future, here are the interesting flows that get the 
packets to the SF:


This is the classifier flow:

Notice the classification is tcp, tp_src=2000, tp_dst=80 and that the 
actions are push_nsh, set the NSH NSP=7 (load:0x7->NXM_NX_NSP[0..23]) 
and set the NSH NSI=255 (load:0xff->NXM_NX_NSI[])

Then, resubmit(,0) sends the packet back to table=0 so that SFC can take it.

   cookie=0x1110010000070255, duration=327.102s, table=11, n_packets=7,
   n_bytes=518,
   
tcp,reg0=0x1,tp_src=2000,tp_dst=80actions=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:0x7->NXM_NX_NSP[0..23],load:0xff->NXM_NX_NSI[],load:0x7b7b7b03->NXM_NX_TUN_IPV4_DST[],
   load:0x7->NXM_NX_TUN_ID[0..31],resubmit(,0)



This is the SFC flow in table 0 called the TransportIngress table, it 
sends the packet to the SFC NextHop table (152)


   cookie=0x14, duration=337.663s, table=0, n_packets=7, n_bytes=518,
   priority=250,nsp=7 actions=goto_table:152


This is the SFC NextHop table:

This sets the NextHop to be the IP of the SF, namely 123.123.123.03 
(0x7b7b7b03) and then sends the packet to the SFC TransportEgress table


   cookie=0x14, duration=337.691s, table=152, n_packets=7, n_bytes=518,
   priority=550,nsi=255,nsp=7
   actions=load:0x7b7b7b03->NXM_NX_TUN_IPV4_DST[],goto_table:158


This is the SFC TransportEgress table:

This prepares the packet for egress and sends it out to OpenFlow port 2 
(vxgpe)


   cookie=0xba5eba1100000101, duration=337.673s, table=158,
   n_packets=7, n_bytes=518, priority=650,nsi=255,nsp=7
   
actions=move:NXM_NX_NSH_MDTYPE[]->NXM_NX_NSH_MDTYPE[],move:NXM_NX_NSH_NP[]->NXM_NX_NSH_NP[],move:NXM_NX_NSH_C1[]->NXM_NX_NSH_C1[],
   
move:NXM_NX_NSH_C2[]->NXM_NX_NSH_C2[],move:NXM_NX_TUN_ID[0..31]->NXM_NX_TUN_ID[0..31],load:0x4->NXM_NX_TUN_GPE_NP[],output:2



Notice the workaround section here [0]. This is necessary since 
OpenStack doesnt terminate VXLAN tunnels in the SF, but instead in the 
br-int bridge. We need the VXLAN+NSH packets to go all the way to the SF 
VM. I thought this workaround section should have been setup properly by 
the OPNFV installer, but it looks like you had to complete it.



As for your classification question: You may indeed need to create 
several classification rules. If you want all traffic from the client to 
enter the Service Chain, you may consider just specifying 
src_ip=<clientVM> IP. That wont catch the ICMP traffic, but I wonder if 
you really need to send this to the SF VM. If you do, then add another 
classification rule.


Regards,

Brady


[0] 
http://artifacts.opnfv.org/sfc/colorado/docs/design/index.html#document-architecture



On 10/02/17 09:02, Srikanth Lingala wrote:


Hi,


Finally, I am able to receive VxLAN packets to SFC VM. The issue is 
that , a route is missing in the OVS tunnel routing table (ovs-appctl 
ovs/route/show). In my compute node, it’s not allowing to add a route 
until br-int has some IP in the same subnet. So, I gave an IP address 
to br-int, which added the route to OVS tunnel routing table. But, in 
x86 Compute, If a route is added on br-int, it’s directly reflecting 
in OVS tunnel routing table. I need to debug this issue.


Anyways, Thanks Brady and Sam for your help.


I want some help on SFC Classifier. Currently, I am using the 
following classifier:


{"source_port": 2000, "protocol": 6, "dest_port": 80}


The above classifies the TCP traffic which matches the source port as 
‘2000’ and destination port as ‘80’ to SFC VM. Now, If I want to 
classify all the traffic like TCP/UDP/ICMP …etc with entire port 
ranges, to SFC VM, what should be classifier attributes? Is that 
possible with single classifier?


Regards,

Srikanth.


*From:*[email protected] 
[mailto:[email protected]] *On Behalf Of 
*Srikanth Lingala

*Sent:* Wednesday, February 08, 2017 11:30 PM

*To:* Sam Hague <[email protected]>; Brady Allen Johnson 
<[email protected]>
*Cc:* [email protected]; 
[email protected]; Rozet, Tim <[email protected]>; Ferenc 
Cserepkei <[email protected]>; Gorja Gorja 
<[email protected]>
*Subject:* Re: [sfc-dev] [SFC] ODL SFC with single compute node and 
OVS 2.6.1 NSH patches


Hi Sam/Brady,


Somehow, I resolved the table id issue by restarting Opendaylight in 
Controller node. Now SFC flows are created across tables 152 -158.



But, still not able to receive VxLAN packets at SFC vNF, when I 
execute the curl request from Client to Server.



In the following pastebin location, new flows and br-int bridge 
details are described.


http://pastebin.com/CMjK1yrT

Please help me to identify the issue.

Thanks and Regards,

Srikanth.


*From:*[email protected] 
<mailto:[email protected]> 
[mailto:[email protected]] *On Behalf Of 
*Srikanth Lingala

*Sent:* Wednesday, February 08, 2017 9:34 PM
*To:* Sam Hague <[email protected] <mailto:[email protected]>>

*Cc:* [email protected] 
<mailto:[email protected]>; Ferenc Cserepkei 
<[email protected] 
<mailto:[email protected]>>; Gorja Gorja 
<[email protected] <mailto:[email protected]>>; Rozet, Tim 
<[email protected] <mailto:[email protected]>>; 
[email protected] 
<mailto:[email protected]>
*Subject:* Re: [sfc-dev] [SFC] ODL SFC with single compute node and 
OVS 2.6.1 NSH patches


Hi Sam,

I already had the same configuration in the ODL.


root@node-15:~# curl -u admin:admin 
http://192.168.0.2:8181/restconf/config/netvirt-providers-config:netvirt-providers-config


{"netvirt-providers-config":{"table-offset":1}}


root@node-15:~# curl -u admin:admin 
http://192.168.0.2:8181/restconf/config/sfc-of-renderer:sfc-of-renderer-config/


{"sfc-of-renderer-config":{"sfc-of-table-offset":150,"sfc-of-app-egress-table-offset":11}}

Regards,

Srikanth.

*From:*Sam Hague [mailto:[email protected]]
*Sent:* Wednesday, February 08, 2017 6:47 PM

*To:* Srikanth Lingala <[email protected] 
<mailto:[email protected]>>
*Cc:* Brady Allen Johnson <[email protected] 
<mailto:[email protected]>>; 
[email protected] 
<mailto:[email protected]>; 
[email protected] 
<mailto:[email protected]>; Gorja Gorja 
<[email protected] <mailto:[email protected]>>; Rozet, Tim 
<[email protected] <mailto:[email protected]>>; Ferenc Cserepkei 
<[email protected] 
<mailto:[email protected]>>; Veera.Reddy B 
<[email protected] <mailto:[email protected]>>
*Subject:* Re: [sfc-dev] [SFC] ODL SFC with single compute node and 
OVS 2.6.1 NSH patches



On Wed, Feb 8, 2017 at 7:44 AM, Srikanth Lingala 
<[email protected] <mailto:[email protected]>> 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:[email protected]
    <mailto:[email protected]>]
    *Sent:* Tuesday, February 07, 2017 11:22 PM
    *To:* Srikanth Lingala <[email protected]
    <mailto:[email protected]>>
    *Cc:* Brady Allen Johnson <[email protected]
    <mailto:[email protected]>>;
    [email protected]
    <mailto:[email protected]>;
    [email protected]
    <mailto:[email protected]>; Gorja Gorja
    <[email protected] <mailto:[email protected]>>; Rozet, Tim
    <[email protected] <mailto:[email protected]>>; Ferenc Cserepkei
    <[email protected] <mailto:[email protected]>>
    *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
    <[email protected] <mailto:[email protected]>> 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='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.network.topology.rev131021.network.topology.topology.Node,
        path=[org.opendaylight.yang.ge
        
<http://org.opendaylight.yang.ge>n.v1.urn.tbd.params.xml.ns.yang.network.topology.rev131021.NetworkTopology,
        
org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yang.network.topology.rev131021.network.topology.Topology[key=TopologyKey
        [_topologyId=Uri [_value=ovsdb:1]]],
        
org.opendaylight.yang.gen.v1.urn.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 <http://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.urn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.DatapathTypeSystem,
        getFailMode=class
        
org.opendaylight.yang.gen.v1.urn.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.network.topology.rev131021.network.topology.topology.Node,
        path=[org.opendaylight.yang.ge
        
<http://org.opendaylight.yang.ge>n.v1.urn.tbd.params.xml.ns.yang.network.topology.rev131021.NetworkTopology,
        
org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yang.network.topology.rev131021.network.topology.Topology[key=TopologyKey
        [_topologyId=Uri [_value=ovsdb:1]]],
        
org.opendaylight.yang.gen.v1.urn.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' <[email protected]
        <mailto:[email protected]>>;
        [email protected]
        <mailto:[email protected]>;
        [email protected]
        <mailto:[email protected]>
        *Cc:* Ferenc Cserepkei <[email protected]
        <mailto:[email protected]>>; Manuel Buil
        <[email protected] <mailto:[email protected]>>;
        Rozet, Tim <[email protected] <mailto:[email protected]>>;
        Veera.Reddy B <[email protected] <mailto:[email protected]>>;
        Gorja Gorja <[email protected] <mailto:[email protected]>>
        *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:[email protected]]
        *Sent:* Tuesday, February 07, 2017 3:55 PM
        *To:* Srikanth Lingala <[email protected]
        <mailto:[email protected]>>;
        [email protected]
        <mailto:[email protected]>;
        [email protected]
        <mailto:[email protected]>
        *Cc:* Ferenc Cserepkei <[email protected]
        <mailto:[email protected]>>; Manuel Buil
        <[email protected] <mailto:[email protected]>>;
        Rozet, Tim <[email protected] <mailto:[email protected]>>;
        Veera.Reddy B <[email protected] <mailto:[email protected]>>;
        Gorja Gorja <[email protected] <mailto:[email protected]>>
        *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
        [email protected]
        <mailto:[email protected]>
        https://lists.opendaylight.org/mailman/listinfo/sfc-dev




_______________________________________________
sfc-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/sfc-dev























					Reply via email to