Re: [opnfv-tech-discuss] [Yardstick] Testcase stuck at "Creating stack state: CREATE_IN_PROGRESS"

[Srikanth Lingala]

Thanks Trinath…
I am able to fix the heat stack issue, by creating external network in 
OpenStack Controller node.
But, I am facing one more issue while connecting to VM through SSH, via 
Floating IP.
I am getting the below logs, while connecting to VM:

2017-10-16 18:50:33,483 [DEBUG] yardstick.ssh.athena ssh.py:371 Ssh is still 
unavailable: SSHError("Exception  was raised during 
connect. Exception value is: timeout('timed out',)",)
2017-10-16 18:50:35,485 [DEBUG] yardstick.ssh.athena ssh.py:371 Ssh is still 
unavailable: SSHError("Exception  was raised during 
connect. Exception value is: timeout('timed out',)",)
2017-10-16 18:50:37,487 [DEBUG] yardstick.ssh.athena ssh.py:371 Ssh is still 
unavailable: SSHError("Exception  was raised during 
connect. Exception value is: timeout('timed out',)",)
Process Duration-Ping-1452:
Traceback (most recent call last):
  File "/usr/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
self.run()
  File "/usr/lib/python2.7/multiprocessing/process.py", line 114, in run
self._target(*self._args, **self._kwargs)
  File "/home/opnfv/repos/yardstick/yardstick/benchmark/runners/duration.py", 
line 51, in _worker_process
benchmark = cls(scenario_cfg, context_cfg)
  File 
"/home/opnfv/repos/yardstick/yardstick/benchmark/scenarios/networking/ping.py", 
line 47, in __init__
self.connection.wait(timeout=600)
  File "/home/opnfv/repos/yardstick/yardstick/ssh.py", line 374, in wait
raise SSHTimeout("Timeout waiting for '%s'", self.host)
SSHTimeout: ("Timeout waiting for '%s'", u'172.16.0.138')
2017-10-16 18:50:38,534 [ERROR] yardstick.benchmark.core.task task.py:277 
Scenario NO.1: "Ping" ERROR!
2017-10-16 18:50:38,535 [ERROR] yardstick.benchmark.core.task task.py:128 
Testcase: "opnfv_yardstick_tc002" FAILED!!!
Traceback (most recent call last):
  File "/home/opnfv/repos/yardstick/yardstick/benchmark/core/task.py", line 
124, in start
data = self._run(scenarios, run_in_parallel, args.output_file)
  File "/home/opnfv/repos/yardstick/yardstick/benchmark/core/task.py", line 
279, in _run
"{0} runner status {1}".format(runner.__execution_type__, status))
RuntimeError: Duration runner status 1

Regards,
Srikanth.

From: Trinath Somanchi [mailto:trinath.soman...@gmail.com]
Sent: Monday, October 16, 2017 9:42 PM
To: Srikanth Lingala <srikanth.ling...@nxp.com>
Cc: opnfv-tech-discuss@lists.opnfv.org; opnfv-us...@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [Yardstick] Testcase stuck at "Creating stack 
state: CREATE_IN_PROGRESS"

Hi Srikanth-

Can you verify the heat logs ?

/Trinath

On 16-Oct-2017 9:26 PM, "Srikanth Lingala" 
<srikanth.ling...@nxp.com<mailto:srikanth.ling...@nxp.com>> wrote:
Hi,
I am trying to execute an OPNFV testcase with Yardstick.
I downloaded yardstick docker and able to run the docker container.
I wanted to run the usecase “opnfv_yardstick_tc002.yaml” from the repository. I 
executed the below command in yardstick docker VM:

#> yardstick -d task start 
/home/opnfv/repos/yardstick/tests/opnfv/test_cases/opnfv_yardstick_tc002.yaml

But, starting the usecase, I am keep getting the following message and not 
coming out from the above command:

2017-10-16 15:48:34,066 [DEBUG] yardstick.orchestrator.heat heat.py:622 
Creating stack state: CREATE_IN_PROGRESS

Following is the total output:

https://pastebin.com/G1t5jRKN

Can anyone help me to resolve the issue?

Thanks and Regards,
Srikanth.

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org<mailto: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

[opnfv-tech-discuss] [Yardstick] Testcase stuck at "Creating stack state: CREATE_IN_PROGRESS"

[Srikanth Lingala]

Hi,
I am trying to execute an OPNFV testcase with Yardstick.
I downloaded yardstick docker and able to run the docker container.
I wanted to run the usecase "opnfv_yardstick_tc002.yaml" from the repository. I 
executed the below command in yardstick docker VM:

#> yardstick -d task start 
/home/opnfv/repos/yardstick/tests/opnfv/test_cases/opnfv_yardstick_tc002.yaml

But, starting the usecase, I am keep getting the following message and not 
coming out from the above command:

2017-10-16 15:48:34,066 [DEBUG] yardstick.orchestrator.heat heat.py:622 
Creating stack state: CREATE_IN_PROGRESS

Following is the total output:

https://pastebin.com/G1t5jRKN

Can anyone help me to resolve the issue?

Thanks and Regards,
Srikanth.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] OPNFV Danube 3.0: Issue with two SFC's

[Srikanth Lingala]

Hi Manuel,
I am able to run the usecase ‘sfc_two_chains_SSH_and_HTTP.py’. The issue is 
with the sequence of executing commands.
First SFC Classifier flows are not adding in Compute Node, if we have two 
active Service Function Chains. So, I created SFC1 and added required 
classifiers with that chain. And then, I created another chain SFC2, and added 
classifiers with SFC2. I don’t know whether that’s a BUG in ODL/tacker or not. 
With that sequence, I am able to run the usecase successfully.

Thanks for all the help.

Regards,
Srikanth.



From: Manuel Buil [mailto:mb...@suse.com]
Sent: Monday, September 25, 2017 1:25 PM
To: Srikanth Lingala <srikanth.ling...@nxp.com>; 
sfc-...@lists.opendaylight.org; opnfv-tech-discuss@lists.opnfv.org; 
opnfv-us...@lists.opnfv.org
Cc: Gorja Gorja <prasad.go...@nxp.com>
Subject: Re: [opnfv-tech-discuss] OPNFV Danube 3.0: Issue with two SFC's

Hey Srikanth,

You are not getting any classification rule because it can't find an RSP, which 
means it was not able to create the chain. There is something fishy going on 
and it should not be there if you do a complete restart of ODL. To completely 
restart ODL, you must stop it, remove the directories: snapshot, instances and 
journal. Then, you should restart the OVSs (removing their conf.db database). 
If you are using neutron v2, you must also restart neutron completely (database 
included) because it keeps a journal and what breaks ODL, will again be 
executed as soon as neutron detects that ODL is up.

Regards,
Manuel

On Fri, 2017-09-22 at 12:57 +0000, Srikanth Lingala wrote:
Hi Manuel,
I started ODL cleanly. But, I observe the same issue. SFC Classifier flows are 
adding, only when we have single Chain.
I wonder how functests are passing with the SFC usecase 
‘sfc_two_chains_SSH_and_HTTP.py’ in different OPNFV labs.

And also, now after cleaning up ODL, SFC flows are NOT adding with table id 150 
– 158. Those SFC flows are adding to table id 10.
I observe no ERROR logs in ODL, but few WARNING logs.

Following are the ODL logs:
While creating first chain ‘mychain1’: tacker sfc-create --name mychain1 
--chain testVNF1
https://pastebin.com/JXDgitXD

While creating second chain ‘mychain2’: tacker sfc-create --name mychain2 
--chain testVNF2
https://pastebin.com/CYaxYvtZ

While creating first classifier ‘myclass1’: tacker sfc-classifier-create --name 
myclass1 --chain mychain1 --match source_port=0,dest_port=80,protocol=6
https://pastebin.com/Ly4Y2aSb
Here, Classifier flow is NOT adding with tcp and dest_port=80.

While creating first classifier ‘myclass2’: tacker sfc-classifier-create --name 
myclass2 --chain mychain2 --match source_port=0,dest_port=22,protocol=6
https://pastebin.com/iJJ2me1Y
Here, Classifier flow is adding with tcp and dest_port=22.

Regards,
Srikanth.

From: Manuel Buil [mailto:mb...@suse.com]
Sent: Friday, September 22, 2017 4:50 PM
To: Srikanth Lingala 
<srikanth.ling...@nxp.com<mailto:srikanth.ling...@nxp.com>>; 
sfc-...@lists.opendaylight.org<mailto:sfc-...@lists.opendaylight.org>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>; 
opnfv-us...@lists.opnfv.org<mailto:opnfv-us...@lists.opnfv.org>
Cc: Gorja Gorja <prasad.go...@nxp.com<mailto:prasad.go...@nxp.com>>
Subject: Re: [opnfv-tech-discuss] OPNFV Danube 3.0: Issue with two SFC's

Yes. You need to stop it, remove instances/ journal/ and snapshots/ and start 
it with bin/start clean. If I remember well, ODL Boron had an issue when 
restarting it and connecting old OVS, so you might need to restart also the OVS 
switches before starting ODL again.

Regards,
Manuel

On Fri, 2017-09-22 at 10:30 +, Srikanth Lingala wrote:
Hi Manuel,
So, If I restart the ODL and then add SFC and SFC Classifiers may fix this 
issue?

Regards,
Srikanth.

From: Manuel Buil [mailto:mb...@suse.com]
Sent: Friday, September 22, 2017 3:52 PM
To: Srikanth Lingala 
<srikanth.ling...@nxp.com<mailto:srikanth.ling...@nxp.com>>; 
sfc-...@lists.opendaylight.org<mailto:sfc-...@lists.opendaylight.org>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>; 
opnfv-us...@lists.opnfv.org<mailto:opnfv-us...@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] OPNFV Danube 3.0: Issue with two SFC's

Hello Srikanth,

Danube is using ODL Boron which had some issues when removing the 
classification rules. Unfortunately, those rules are not correctly removed and 
that creates a small mess which results in problems when creating new rules. 
You should not see this problem if you have a clean ODL but if you have created 
several classifiers and tried to remove them, you might see it.

Do you see any error in ODL logs when creating the classifier

Regards,
Manuel

On Fri, 2017-09-22 at 07:28 +, Srikanth Lingala wrote:
Hi,
I am using OPNFV Danube 3.0. I deployed one Openstack Controller with ODL & 
Tacker and Openstack Compute through Fuel.
I am trying 

[opnfv-tech-discuss] VxLAN workaround for OPNFV Danube 3.0

[Srikanth Lingala]

Hi,
I am trying to implement SFC with Opendaylight is OPNFV Danube 3.0 release.
Is "VxLAN Workaround in Compute node" still required in OPNFV Danube 3.0 
release also? Or ODL will take care of it.
Anyone please confirm.

Regards,
Srikanth.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] OPNFV Danube 3.0: Issue with two SFC's

[Srikanth Lingala]

Hi Manuel,
I started ODL cleanly. But, I observe the same issue. SFC Classifier flows are 
adding, only when we have single Chain.
I wonder how functests are passing with the SFC usecase 
‘sfc_two_chains_SSH_and_HTTP.py’ in different OPNFV labs.

And also, now after cleaning up ODL, SFC flows are NOT adding with table id 150 
– 158. Those SFC flows are adding to table id 10.
I observe no ERROR logs in ODL, but few WARNING logs.

Following are the ODL logs:
While creating first chain ‘mychain1’: tacker sfc-create --name mychain1 
--chain testVNF1
https://pastebin.com/JXDgitXD

While creating second chain ‘mychain2’: tacker sfc-create --name mychain2 
--chain testVNF2
https://pastebin.com/CYaxYvtZ

While creating first classifier ‘myclass1’: tacker sfc-classifier-create --name 
myclass1 --chain mychain1 --match source_port=0,dest_port=80,protocol=6
https://pastebin.com/Ly4Y2aSb
Here, Classifier flow is NOT adding with tcp and dest_port=80.

While creating first classifier ‘myclass2’: tacker sfc-classifier-create --name 
myclass2 --chain mychain2 --match source_port=0,dest_port=22,protocol=6
https://pastebin.com/iJJ2me1Y
Here, Classifier flow is adding with tcp and dest_port=22.

Regards,
Srikanth.

From: Manuel Buil [mailto:mb...@suse.com]
Sent: Friday, September 22, 2017 4:50 PM
To: Srikanth Lingala <srikanth.ling...@nxp.com>; 
sfc-...@lists.opendaylight.org; opnfv-tech-discuss@lists.opnfv.org; 
opnfv-us...@lists.opnfv.org
Cc: Gorja Gorja <prasad.go...@nxp.com>
Subject: Re: [opnfv-tech-discuss] OPNFV Danube 3.0: Issue with two SFC's

Yes. You need to stop it, remove instances/ journal/ and snapshots/ and start 
it with bin/start clean. If I remember well, ODL Boron had an issue when 
restarting it and connecting old OVS, so you might need to restart also the OVS 
switches before starting ODL again.

Regards,
Manuel

On Fri, 2017-09-22 at 10:30 +0000, Srikanth Lingala wrote:
Hi Manuel,
So, If I restart the ODL and then add SFC and SFC Classifiers may fix this 
issue?

Regards,
Srikanth.

From: Manuel Buil [mailto:mb...@suse.com]
Sent: Friday, September 22, 2017 3:52 PM
To: Srikanth Lingala 
<srikanth.ling...@nxp.com<mailto:srikanth.ling...@nxp.com>>; 
sfc-...@lists.opendaylight.org<mailto:sfc-...@lists.opendaylight.org>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>; 
opnfv-us...@lists.opnfv.org<mailto:opnfv-us...@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] OPNFV Danube 3.0: Issue with two SFC's

Hello Srikanth,

Danube is using ODL Boron which had some issues when removing the 
classification rules. Unfortunately, those rules are not correctly removed and 
that creates a small mess which results in problems when creating new rules. 
You should not see this problem if you have a clean ODL but if you have created 
several classifiers and tried to remove them, you might see it.

Do you see any error in ODL logs when creating the classifier

Regards,
Manuel

On Fri, 2017-09-22 at 07:28 +, Srikanth Lingala wrote:
Hi,
I am using OPNFV Danube 3.0. I deployed one Openstack Controller with ODL & 
Tacker and Openstack Compute through Fuel.
I am trying to execute the usecase: sfc_two_chains_SSH_and_HTTP
When I create two chains, Classifier flow is missing in the compute node.
I executed below commands:

#> tacker vnfd-create --vnfd-file test-vnfd-1.yaml
#> tacker vnfd-create --vnfd-file test-vnfd-2.yaml
#> tacker vnf-create --name testVNF1 --vnfd-name test-vnfd-1
#> tacker vnf-create --name testVNF2 --vnfd-name test-vnfd-2
#> tacker sfc-create --name mychain1 --chain testVNF1
#> tacker sfc-create --name mychain2 --chain testVNF2
#> tacker sfc-classifier-create --name myclass1 --chain mychain1 --match 
source_port=0,dest_port=80,protocol=6

When I execute the above command, I am not able to see classifier flow in the 
compute node. The flow should be something similar to below:
# ovs-ofctl dump-flows br-int -O Openflow13 | grep tcp
cookie=0x1110010005970255, duration=121.077s, table=11, n_packets=0, n_bytes=0, 
tcp,reg0=0x1,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:0x255->NXM_NX_NSP[0..23],load:0xff->NXM_NX_NSI[],load:0x7b7b7b05->NXM_NX_TUN_IPV4_DST[],load:0x255->NXM_NX_TUN_ID[0..31],resubmit(,0)

The above flow is not adding. But, when I tried the same with single Chain, I 
am able to see the above flow.

Is there any issue with two chains?

Regards,
Srikanth.

___

opnfv-tech-discuss mailing list

opnfv-tech-discuss@lists.opnfv.org<mailto: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

Re: [opnfv-tech-discuss] OPNFV Danube 3.0: Issue with two SFC's

[Srikanth Lingala]

Hi Manuel,
So, If I restart the ODL and then add SFC and SFC Classifiers may fix this 
issue?

Regards,
Srikanth.

From: Manuel Buil [mailto:mb...@suse.com]
Sent: Friday, September 22, 2017 3:52 PM
To: Srikanth Lingala <srikanth.ling...@nxp.com>; 
sfc-...@lists.opendaylight.org; opnfv-tech-discuss@lists.opnfv.org; 
opnfv-us...@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] OPNFV Danube 3.0: Issue with two SFC's

Hello Srikanth,

Danube is using ODL Boron which had some issues when removing the 
classification rules. Unfortunately, those rules are not correctly removed and 
that creates a small mess which results in problems when creating new rules. 
You should not see this problem if you have a clean ODL but if you have created 
several classifiers and tried to remove them, you might see it.

Do you see any error in ODL logs when creating the classifier

Regards,
Manuel

On Fri, 2017-09-22 at 07:28 +, Srikanth Lingala wrote:
Hi,
I am using OPNFV Danube 3.0. I deployed one Openstack Controller with ODL & 
Tacker and Openstack Compute through Fuel.
I am trying to execute the usecase: sfc_two_chains_SSH_and_HTTP
When I create two chains, Classifier flow is missing in the compute node.
I executed below commands:

#> tacker vnfd-create --vnfd-file test-vnfd-1.yaml
#> tacker vnfd-create --vnfd-file test-vnfd-2.yaml
#> tacker vnf-create --name testVNF1 --vnfd-name test-vnfd-1
#> tacker vnf-create --name testVNF2 --vnfd-name test-vnfd-2
#> tacker sfc-create --name mychain1 --chain testVNF1
#> tacker sfc-create --name mychain2 --chain testVNF2
#> tacker sfc-classifier-create --name myclass1 --chain mychain1 --match 
source_port=0,dest_port=80,protocol=6

When I execute the above command, I am not able to see classifier flow in the 
compute node. The flow should be something similar to below:
# ovs-ofctl dump-flows br-int -O Openflow13 | grep tcp
cookie=0x1110010005970255, duration=121.077s, table=11, n_packets=0, n_bytes=0, 
tcp,reg0=0x1,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:0x255->NXM_NX_NSP[0..23],load:0xff->NXM_NX_NSI[],load:0x7b7b7b05->NXM_NX_TUN_IPV4_DST[],load:0x255->NXM_NX_TUN_ID[0..31],resubmit(,0)

The above flow is not adding. But, when I tried the same with single Chain, I 
am able to see the above flow.

Is there any issue with two chains?

Regards,
Srikanth.

___

opnfv-tech-discuss mailing list

opnfv-tech-discuss@lists.opnfv.org<mailto: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

[opnfv-tech-discuss] OPNFV Danube 3.0: Issue with two SFC's

[Srikanth Lingala]

Hi,
I am using OPNFV Danube 3.0. I deployed one Openstack Controller with ODL & 
Tacker and Openstack Compute through Fuel.
I am trying to execute the usecase: sfc_two_chains_SSH_and_HTTP
When I create two chains, Classifier flow is missing in the compute node.
I executed below commands:

#> tacker vnfd-create --vnfd-file test-vnfd-1.yaml
#> tacker vnfd-create --vnfd-file test-vnfd-2.yaml
#> tacker vnf-create --name testVNF1 --vnfd-name test-vnfd-1
#> tacker vnf-create --name testVNF2 --vnfd-name test-vnfd-2
#> tacker sfc-create --name mychain1 --chain testVNF1
#> tacker sfc-create --name mychain2 --chain testVNF2
#> tacker sfc-classifier-create --name myclass1 --chain mychain1 --match 
source_port=0,dest_port=80,protocol=6

When I execute the above command, I am not able to see classifier flow in the 
compute node. The flow should be something similar to below:
# ovs-ofctl dump-flows br-int -O Openflow13 | grep tcp
cookie=0x1110010005970255, duration=121.077s, table=11, n_packets=0, n_bytes=0, 
tcp,reg0=0x1,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:0x255->NXM_NX_NSP[0..23],load:0xff->NXM_NX_NSI[],load:0x7b7b7b05->NXM_NX_TUN_IPV4_DST[],load:0x255->NXM_NX_TUN_ID[0..31],resubmit(,0)

The above flow is not adding. But, when I tried the same with single Chain, I 
am able to see the above flow.

Is there any issue with two chains?

Regards,
Srikanth.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [Pharos] Pharos lab for ARM band

[Srikanth Lingala]

OK...So, If I apply some patches to Fuel and rebuild Fuel ISO, can I deploy 
with mixed (x86 and aarch64) targets in Pharos POD?
If so, can you please point me to those patches?

Regards,
Srikanth.

From: Alexandru Avadanii [mailto:alexandru.avada...@enea.com]
Sent: Friday, September 08, 2017 5:54 PM
To: Srikanth Lingala <srikanth.ling...@nxp.com>; opnfv-us...@lists.opnfv.org; 
opnfv-tech-discuss@lists.opnfv.org
Cc: svc-armband <svc-armb...@enea.com>; Bob Monkman <bob.monk...@arm.com>; Shai 
Tsur <shai.t...@arm.com>; Gorja Gorja <prasad.go...@nxp.com>; Trinath Somanchi 
<trinath.soman...@nxp.com>; Veera.reddy B <veer...@nxp.com>
Subject: RE: [Pharos] Pharos lab for ARM band

Hi,
That is correct, everything is now AArch64 in our PODs.

BR,
Alex


From: Srikanth Lingala [mailto:srikanth.ling...@nxp.com]
Sent: Friday, September 08, 2017 11:48 AM
To: Alexandru Avadanii; 
opnfv-us...@lists.opnfv.org<mailto:opnfv-us...@lists.opnfv.org>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Cc: svc-armband; Bob Monkman; Shai Tsur; Gorja Gorja; Trinath Somanchi; 
Veera.reddy B
Subject: RE: [Pharos] Pharos lab for ARM band

Hi Alex,
Thanks for the details.
I viewed the following link for reference:
https://wiki.opnfv.org/display/pharos/Enea+Hosting<https://url10.mailanyone.net/v1/?m=1dqExj-0005uE-41=57e1b682=2_90BZQ1-RysgNt1AmHMojKH2LHu4JvrSPemJS6YkprgFmG8q-jJlEMYA4CZikrc8-R03obAumDs803BItktKdmDIr3C55G2KVSIp_QGTTHWTA1S4Vmt7WW_Wt4-85FzF9FhIOGOnJhGAYMKmfMkJQcvEi-WMB2SRG5EgU0mktznhy_1bVqcjJdS7vnkfeqilYivXeMCcCUFvI8dqUMVXEnwBEhNp13pdCNYfv7j0SdWJUxpJyWjFSnUzj-BIW8GPXN4uCWspaUrKqm12rIBwA>

So, in the current ENEA Pharos lab, you are using ARM based machines as OS 
Controller nodes, Compute nodes and even Jump Host node. Not using any hybrid 
POD (with combination of x86 and ARM machines as nodes). Right?

Regards,
Srikanth.

From: Alexandru Avadanii [mailto:alexandru.avada...@enea.com]
Sent: Friday, September 08, 2017 12:49 AM
To: Srikanth Lingala 
<srikanth.ling...@nxp.com<mailto:srikanth.ling...@nxp.com>>; 
opnfv-us...@lists.opnfv.org<mailto:opnfv-us...@lists.opnfv.org>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Cc: svc-armband <svc-armb...@enea.com<mailto:svc-armb...@enea.com>>; Bob 
Monkman <bob.monk...@arm.com<mailto:bob.monk...@arm.com>>; Shai Tsur 
<shai.t...@arm.com<mailto:shai.t...@arm.com>>
Subject: RE: [Pharos] Pharos lab for ARM band

Hi, Srikanth,
I'm glad to hear about new AArch64 hardware joining OPNFV.

First, note that Pharos specs require 5 nodes, which depending on the scenario 
can be used as 3 controllers + 2 computes, or 1 controller + computes.
This makes it hard to mix x86 and ARM targets in a Pharos POD. Therefore, this 
is not supported by OPNFV Danube 3.0 Fuel - it is not impossible, but it is out 
of our current scope.
To add some complexity to that, we have the additional jump server host, which 
used to be x86 up to and including the Danube release cycle; starting with the 
E release, Armband only support all-AArch64 PODs, including the jump host.

Also note that the old Fuel (used up to and including Danube) was replaced by 
the new Fuel, based on Mirantis Cloud Platform (MCP), which on its own means a 
lot of changes in the way we build and provision the OS images (bootstrap and 
final image) on the AArch64 nodes.
Starting with the E release, there is no more bootstrap building, all images 
(Ubuntu Xenial) are fetched from official Ubuntu Cloud Archive (UCA) repos and 
used as-is.

As for old bootstrap building, x86 instructions still apply [1], with only one 
extra arg required (--target_arch=arm64).

To summarize, I recommend looking into the current Armband/Fuel codebase 
(master branch) and prepare for using MCP-based Fuel instead of the old Danube 
codebase.
To add a lab in OPNFV, you will need 6 x AArch64 nodes (5 for the cluster and 
one for the jump host).

BR,
Alex

[1] 
https://docs.openstack.org/fuel-docs/latest/userdocs/fuel-install-guide/bootstrap/bootstrap_troubleshoot.html<https://url10.mailanyone.net/v1/?m=1dqExj-0005uE-41=57e1b682=QqYvZQC5560IPDtsPgdMeQQDvqEpjhyR0UZGIV7tunq-se0YCPSP6xxlDi9wG8__VazhOirYCoOetNpYw1zYeVUU37jndntzaFMWxDK0HxyAEOvTwQl303qQJvW6LiI8hQo73oBlWlaey0VdRgzt7zED7ggGAfYlAsO5lMGp6UZ5CsDVKOIeaGKcbe1PnBDPosO4fGpAlbKl6cmGI1CprYwKNm_6AYpz6bmcm_MH4EKvW1XJaTuuS38IKy1jzAmK8WOxuBjAGH_cWNfuJ3wQEUFMbstHAMFo2n_rquR2YBeNiJrobkN_nfbhospqyjqXdMTXG6-Lr2oVJhzFw-DnLg>


From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Srikanth 
Lingala
Sent: Thursday, September 07, 2017 8:35 PM
To: opnfv-us...@lists.opnfv.org<mailto:opnfv-us...@lists.opnfv.org>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: [opnfv-tech-discuss] [

Re: [opnfv-tech-discuss] [Pharos] Pharos lab for ARM band

[Srikanth Lingala]

Hi Alex,
Thanks for the details.
I viewed the following link for reference:
https://wiki.opnfv.org/display/pharos/Enea+Hosting

So, in the current ENEA Pharos lab, you are using ARM based machines as OS 
Controller nodes, Compute nodes and even Jump Host node. Not using any hybrid 
POD (with combination of x86 and ARM machines as nodes). Right?

Regards,
Srikanth.

From: Alexandru Avadanii [mailto:alexandru.avada...@enea.com]
Sent: Friday, September 08, 2017 12:49 AM
To: Srikanth Lingala <srikanth.ling...@nxp.com>; opnfv-us...@lists.opnfv.org; 
opnfv-tech-discuss@lists.opnfv.org
Cc: svc-armband <svc-armb...@enea.com>; Bob Monkman <bob.monk...@arm.com>; Shai 
Tsur <shai.t...@arm.com>
Subject: RE: [Pharos] Pharos lab for ARM band

Hi, Srikanth,
I'm glad to hear about new AArch64 hardware joining OPNFV.

First, note that Pharos specs require 5 nodes, which depending on the scenario 
can be used as 3 controllers + 2 computes, or 1 controller + computes.
This makes it hard to mix x86 and ARM targets in a Pharos POD. Therefore, this 
is not supported by OPNFV Danube 3.0 Fuel - it is not impossible, but it is out 
of our current scope.
To add some complexity to that, we have the additional jump server host, which 
used to be x86 up to and including the Danube release cycle; starting with the 
E release, Armband only support all-AArch64 PODs, including the jump host.

Also note that the old Fuel (used up to and including Danube) was replaced by 
the new Fuel, based on Mirantis Cloud Platform (MCP), which on its own means a 
lot of changes in the way we build and provision the OS images (bootstrap and 
final image) on the AArch64 nodes.
Starting with the E release, there is no more bootstrap building, all images 
(Ubuntu Xenial) are fetched from official Ubuntu Cloud Archive (UCA) repos and 
used as-is.

As for old bootstrap building, x86 instructions still apply [1], with only one 
extra arg required (--target_arch=arm64).

To summarize, I recommend looking into the current Armband/Fuel codebase 
(master branch) and prepare for using MCP-based Fuel instead of the old Danube 
codebase.
To add a lab in OPNFV, you will need 6 x AArch64 nodes (5 for the cluster and 
one for the jump host).

BR,
Alex

[1] 
https://docs.openstack.org/fuel-docs/latest/userdocs/fuel-install-guide/bootstrap/bootstrap_troubleshoot.html


From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Srikanth 
Lingala
Sent: Thursday, September 07, 2017 8:35 PM
To: opnfv-us...@lists.opnfv.org<mailto:opnfv-us...@lists.opnfv.org>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: [opnfv-tech-discuss] [Pharos] Pharos lab for ARM band

Hi,
We want to setup Pharos lab for ARM band machines. For that, I am using OPNFV 
Danube 3.0 release (Fuel ISO).
Is it possible to deploy an OpenStack setup with x86 machine as OS Controller 
and ARM machine as OS Compute node?
And also, can anyone give me some reference links to build a bootstrap image 
(for Fuel deployment) for baremetal ARM machines?

Regards,
Srikanth.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [Pharos] Pharos lab for ARM band

[Srikanth Lingala]

Hi,
We want to setup Pharos lab for ARM band machines. For that, I am using OPNFV 
Danube 3.0 release (Fuel ISO).
Is it possible to deploy an OpenStack setup with x86 machine as OS Controller 
and ARM machine as OS Compute node?
And also, can anyone give me some reference links to build a bootstrap image 
(for Fuel deployment) for baremetal ARM machines?

Regards,
Srikanth.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] OPNFV Danube - Fuel Deployment failing

[Srikanth Lingala]

Hi,
I am using OPNFV Danube release. I downloaded Fuel ISO from the below location:
http://artifacts.opnfv.org/fuel/danube/opnfv-danube.3.0.iso

And, I am trying to deploy OpenStack deployment with One OpenStack Controller 
and OpenStack Compute.
In the 'Connectivity Check' of Fuel Network Settings, I am getting the 
following error:

Verification failed.
Repo availability verification using public network failed on following nodes 
Untitled (e8:00).
Following repos are not available - http://archive.ubuntu.com/ubuntu/.
Check your public network settings and availability of the repositories from 
public network. Please examine nailgun and astute logs for additional details.

But, both the Controller and Compute nodes, are able to connect to internet.
When I check the nailgun logs, I found the following:

2017-08-30 05:33:51

INFO

[1576] Casting message to Nailgun: 
{"method"=>"check_repositories_with_setup_resp", "args"=> 
{"task_uuid"=>"97a9f809-2142-4338-9621-f3417defebc6", "status"=>"ready", 
"progress"=>100, "nodes"=> 
[{:out=>{"failed_urls"=>["http://archive.ubuntu.com/ubuntu/"]}, :err=> 
"Unexpected failure.\nTraceback (most recent call last):\n File 
\"/usr/lib/python2.7/dist-packages/url_access_checker/network.py\", line 218, 
in manage_network\n yield\n File 
\"/usr/lib/python2.7/dist-packages/url_access_checker/commands.py\", line 76, 
in take_action\n CheckUrlsWithSetup, self).take_action(pa)\n File 
\"/usr/lib/python2.7/dist-packages/url_access_checker/commands.py\", line 57, 
in take_action\n raise e\nUrlNotAvailable: {\"failed_urls\": 
[\"http://archive.ubuntu.com/ubuntu/\"]}\n2017-08-30 05:33:50 ERROR (network) 
Unexpected failure.\nTraceback (most recent call last):\n File 
\"/usr/lib/python2.7/dist-packages/url_access_checker/network.py\", line 218, 
in manage_network\n yield\n File 
\"/usr/lib/python2.7/dist-packages/url_access_checker/commands.py\", line 76, 
in take_action\n CheckUrlsWithSetup, self).take_action(pa)\n File 
\"/usr/lib/python2.7/dist-packages/url_access_checker/commands.py\", line 57, 
in take_action\n raise e\nUrlNotAvailable: {\"failed_urls\": 
[\"http://archive.ubuntu.com/ubuntu/\"]}\n{\"failed_urls\": 
[\"http://archive.ubuntu.com/ubuntu/\"]}\n2017-08-30 05:33:50 ERROR (app) 
{\"failed_urls\": [\"http://archive.ubuntu.com/ubuntu/\"]}\n;, :status=>1, 
:uid=>"4"}]}}


Even, I checked the URL with the command 'urlaccesscheck check 
http://archive.ubuntu.com/ubuntu/'. And, the command is fine.
Anyone facing similar issue?

Regards,
Srikanth.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] Regarding vxlan_tool.py in SFC vNF

[Srikanth Lingala]

Hi,
I am working on ODL SFC. I am able to execute the basic SFC usecase.
But, I just want to understand, what vxlan_tool.py does in SFC vNF. Is it 
forward packets to next vNF based on NSH header?
Can anyone please let me know, what are the specific tasks, which are handled 
by vxlan_tool.py?

Regards,
Srikanth.
___
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-dev] [SFC] ODL SFC with multiple compute nodes

[Srikanth Lingala]

Brady,
On which interface, you want me do tcpdump in the compute node.
As br-int is OVS port, we can’t see packets on that.

Regards,
Srikanth.

From: Brady Allen Johnson [mailto:brady.allen.john...@ericsson.com]
Sent: Thursday, March 02, 2017 9:18 PM
To: opnfv-tech-discuss@lists.opnfv.org; Srikanth Lingala 
<srikanth.ling...@nxp.com>; sfc-...@lists.opendaylight.org
Subject: Re: [sfc-dev] [SFC] ODL SFC with multiple compute nodes

Srikanth,

We experienced a similar problem lately in OPNFV SFC when using multiple 
compute hosts. The situation was that the packets returning from an SF entered 
the SFF on the XVLAN-GPE port, and then the packets need to go to an SFF on a 
different compute host, and they do so on a normal VXLAN tunnel, which is 
obviously on a different port than the VXLAN-GPE port. The problem is that when 
the packets "transition" from the VXLAN-GPE tunnel to the VXLAN tunnel, the UDP 
port number in the packet was not correctly updated, and it was still 6633 from 
VXLAN-GPE and got dropped by the VXLAN port.

Can you do a tcpdump on the first compute host to see if you are experiencing 
the same problem?

I believe this was fixed, but I cant remember where the solution is. Hopefully 
Yi Yang can provide details about this.

Regards,

Brady


-Original Message-
From: Brady Allen Johnson 
<brady.allen.john...@ericsson.com<mailto:brady%20allen%20johnson%20%3cbrady.allen.john...@ericsson.com%3e>>
To: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org> 
<opnfv-tech-discuss@lists.opnfv.org<mailto:%22opnfv-tech-disc...@lists.opnfv.org%22%20%3copnfv-tech-disc...@lists.opnfv.org%3e>>,
 srikanth.ling...@nxp.com<mailto:srikanth.ling...@nxp.com> 
<srikanth.ling...@nxp.com<mailto:%22srikanth.ling...@nxp.com%22%20%3csrikanth.ling...@nxp.com%3e>>,
 sfc-...@lists.opendaylight.org<mailto:sfc-...@lists.opendaylight.org> 
<sfc-...@lists.opendaylight.org<mailto:%22sfc-...@lists.opendaylight.org%22%20%3csfc-...@lists.opendaylight.org%3e>>
Subject: [sfc-dev] [SFC] ODL SFC with multiple compute nodes
Date: Thu, 2 Mar 2017 13:42:16 +

Since this is more of an issue with OPNFV SFC than ODL SFC, I will add that 
mail list.

Regards,

Brady


-Original Message-
From: Srikanth Lingala 
<srikanth.ling...@nxp.com<mailto:srikanth%20lingala%20%3csrikanth.ling...@nxp.com%3e>>
To: sfc-...@lists.opendaylight.org<mailto:sfc-...@lists.opendaylight.org> 
<sfc-...@lists.opendaylight.org<mailto:%22sfc-...@lists.opendaylight.org%22%20%3csfc-...@lists.opendaylight.org%3e>>
Subject: [sfc-dev] ODL SFC with multiple compute nodes
Date: Thu, 2 Mar 2017 08:41:27 +

PS: Sorry, If I am resending the mail to the sfc-dev mailing list. As I can’t 
find the mail in the mailing list, I am resending it.

Hi,
I am able to run SFC usecase successfully with single Compute Node.
Now, I am trying SFC usecase across multiple computes with Opendaylight, 
Openstack and OVS with NSH patches by Yi Yang. For that, I deployed a Openstack 
setup with OPNFV Colorado 3.0.
My setup includes:

· One Openstack Controller with ODL controller and tacker

· Two Compute Nodes

For validating SFC usecase, I am using tacker. Following are the sequence of 
commands to configure SFC attributes, in my usecase:

neutron net-create net_mgmt --provider:network_type=vxlan 
--provider:segmentation_id 1005
neutron subnet-create net_mgmt 123.123.123.0/24
tacker vnfd-create --vnfd-file /root/sfc-random/test-vnfd-1.yaml
tacker vnfd-create --vnfd-file /root/sfc-random/test-vnfd-2.yaml
tacker vnf-create --name testVNF1 --vnfd-name test-vnfd-1 (SFC VM1 on Compute 1)
tacker vnf-create --name testVNF2 --vnfd-name test-vnfd-2 (SFC VM2 on Compute 2)
nova boot --flavor custom --image SFC-VM --nic net-id=$(neutron net-list | awk 
'/ net_mgmt / {print $2}') --availability-zone compute1 http_server 
(http_server VM on Compute 2)
nova boot --flavor custom --image SFC-VM --nic net-id=$(neutron net-list | awk 
'/ net_mgmt / {print $2}') --availability-zone compute2 http_client 
(http_client VM on Compute 1)
tacker sfc-create --name mychain --chain testVNF1,testVNF2
tacker sfc-classifier-create --name myclass --chain mychain --match 
source_port=2000,dest_port=80,protocol=6


All the above commands are successful. SFC flows are added in the respective 
compute nodes.
Flows on Compute Node1:
http://pastebin.com/R1ZkvpHt

Flows on Compute Node2:
http://pastebin.com/WcCLeQTH

Here comes the issue….

I am able to see packets on SFC Flows in Compute Node1. And also, I am able to 
see VxLAN packets (vxlan_tool.py) on SFC VM launched on Compute Node 1.
But, I am not able to see any packets on SFC flows in Compute Node 2. 
Obviously, not getting VxLAN packets on SFC VM in Compute Node2.
I think packets are not getting from ‘vxgpe’ port in Compute Node1 to Compute 
Node 2. When I execute the command ovs-appctl ofproto/tr

[opnfv-tech-discuss] ODL SFC with multiple compute nodes

[Srikanth Lingala]

Hi guys,
I am able to run SFC usecase successfully with single Compute Node.
Now, I am trying SFC usecase across multiple computes with Opendaylight, 
Openstack and OVS with NSH patches by Yi Yang. For that, I deployed a Openstack 
setup with OPNFV Colorado 3.0.
My setup includes:

* One Openstack Controller with ODL controller and tacker

* Two Compute Nodes

For validating SFC usecase, I am using tacker. Following are the sequence of 
commands to configure SFC attributes, in my usecase:

neutron net-create net_mgmt --provider:network_type=vxlan 
--provider:segmentation_id 1005
neutron subnet-create net_mgmt 123.123.123.0/24
tacker vnfd-create --vnfd-file /root/sfc-random/test-vnfd-1.yaml
tacker vnfd-create --vnfd-file /root/sfc-random/test-vnfd-2.yaml
tacker vnf-create --name testVNF1 --vnfd-name test-vnfd-1 (SFC VM1 on Compute 1)
tacker vnf-create --name testVNF2 --vnfd-name test-vnfd-2 (SFC VM2 on Compute 2)
nova boot --flavor custom --image SFC-VM --nic net-id=$(neutron net-list | awk 
'/ net_mgmt / {print $2}') --availability-zone compute1 http_server 
(http_server VM on Compute 2)
nova boot --flavor custom --image SFC-VM --nic net-id=$(neutron net-list | awk 
'/ net_mgmt / {print $2}') --availability-zone compute2 http_client 
(http_client VM on Compute 1)
tacker sfc-create --name mychain --chain testVNF1,testVNF2
tacker sfc-classifier-create --name myclass --chain mychain --match 
source_port=2000,dest_port=80,protocol=6


All the above commands are successful. SFC flows are added in the respective 
compute nodes.
Flows on Compute Node1:
http://pastebin.com/R1ZkvpHt

Flows on Compute Node2:
http://pastebin.com/WcCLeQTH

Here comes the issue

I am able to see packets on SFC Flows in Compute Node1. And also, I am able to 
see VxLAN packets (vxlan_tool.py) on SFC VM launched on Compute Node 1.
But, I am not able to see any packets on SFC flows in Compute Node 2. 
Obviously, not getting VxLAN packets on SFC VM in Compute Node2.
I think packets are not getting from 'vxgpe' port in Compute Node1 to Compute 
Node 2. When I execute the command ovs-appctl ofproto/trace on br-int of 
Compute Node1, I got the following trace information:
Here, vxgpe port number is 1. So, I gave flow trace for in_port as '1'.

Compute_Node1#> ovs-appctl ofproto/trace br-int nsi=254,nsp=35,in_port=1
Bridge: br-int
Flow: 
in_port=1,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x

Rule: table=0 cookie=0x14 priority=250,nsp=35
OpenFlow actions=goto_table:152

Resubmitted flow: 
in_port=1,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x
Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 
reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 
reg14=0x0 reg15=0x0
Resubmitted  odp: drop
Resubmitted megaflow: 
recirc_id=0,nsi=254,nsp=35,in_port=1,dl_type=0x
Rule: table=152 cookie=0x14 priority=550,nsi=254,nsp=35
OpenFlow actions=load:0xc0a8001a->NXM_NX_TUN_IPV4_DST[],goto_table:158

Resubmitted flow: 
tun_src=0.0.0.0,tun_dst=192.168.0.26,tun_ipv6_src=::,tun_ipv6_dst=::,tun_gbp_id=0,tun_gbp_flags=0,tun_gpe_np=0,tun_gpe_flags=0,tun_tos=0,tun_ttl=0,tun_flags=0,in_port=1,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x
Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 
reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 
reg13=0x0 reg14=0x0 reg15=0x0
Resubmitted  odp: drop
Resubmitted megaflow: 
recirc_id=0,nsi=254,nsp=35,tun_dst=0.0.0.0,in_port=1,dl_type=0x
Rule: table=158 cookie=0xba5eba110101 
priority=655,nsi=254,nsp=35,in_port=1
OpenFlow 
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[],IN_PORT
output to native tunnel
native tunnel routing failed

Final flow: 
tun_src=0.0.0.0,tun_dst=192.168.0.26,tun_ipv6_src=::,tun_ipv6_dst=::,tun_gbp_id=0,tun_gbp_flags=0,tun_gpe_np=0x4,tun_gpe_flags=0,tun_tos=0,tun_ttl=0,tun_flags=0,in_port=1,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x
Megaflow: 
recirc_id=0,nsi=254,nsh_mdtype=0,nsh_np=0,nsp=35,nshc1=0,nshc2=0,tun_id=0/0x,tun_dst=0.0.0.0,tun_gpe_np=0,in_port=1,dl_type=0x
Datapath actions: drop

Please help me to resolve the issue.

Regards,
Srikanth.


___
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-dev] [SFC] ODL SFC with single compute node and OVS 2.6.1 NSH patches

[Srikanth Lingala]

Brady,
Thanks for the detailed explanation.

Now, as basic SFC is working from Client -> SFC -> Server, I am trying to 
execute my actual usecase.
I have a public network with the subnet 172.16.0.0.
I assigned a public IP (Ex: 172.16.0.25) (neutron floating_ip in OpenStack) to 
Server VM. I want to remove Client VM from the usecase. Now, if I access the 
server VM from external machine (Ex: 172.16.0.12) (from Public Network) to 
Server VM through the command ‘curl --local-port 2000 172.16.0.25’, packets are 
not coming to SFC VM.
But, If access the Server VM from Client VM (Private Network), SFC packets are 
coming to SFC VM.
Do I need to add any SFC Classifier for the above requirement? Or Do I need to 
add any flows in the compute node?

Thanks & Regards,
Srikanth.

From: Brady Allen Johnson [mailto:brady.allen.john...@ericsson.com]
Sent: Friday, February 10, 2017 2:43 PM
To: Srikanth Lingala <srikanth.ling...@nxp.com>; Sam Hague <sha...@redhat.com>
Cc: opnfv-tech-discuss@lists.opnfv.org; sfc-...@lists.opendaylight.org; Rozet, 
Tim <tro...@redhat.com>; Ferenc Cserepkei <ferenc.cserep...@ericsson.com>; 
Gorja Gorja <prasad.go...@nxp.com>; Veera.Reddy B <veer...@nxp.com>
Subject: Re: [sfc-dev] [SFC] ODL SFC with single compute node and OVS 2.6.1 NSH 
patches

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=0x111001070255, duration=327.102s, table=11, n_packets=7, 
n_bytes=518, 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: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=0xba5eba110101, 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= 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 destinatio

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

[Srikanth Lingala]

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: sfc-dev-boun...@lists.opendaylight.org 
[mailto:sfc-dev-boun...@lists.opendaylight.org] On Behalf Of Srikanth Lingala
Sent: Wednesday, February 08, 2017 11:30 PM
To: Sam Hague <sha...@redhat.com>; Brady Allen Johnson 
<brady.allen.john...@ericsson.com>
Cc: opnfv-tech-discuss@lists.opnfv.org; sfc-...@lists.opendaylight.org; Rozet, 
Tim <tro...@redhat.com>; Ferenc Cserepkei <ferenc.cserep...@ericsson.com>; 
Gorja Gorja <prasad.go...@nxp.com>
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: 
sfc-dev-boun...@lists.opendaylight.org<mailto:sfc-dev-boun...@lists.opendaylight.org>
 [mailto:sfc-dev-boun...@lists.opendaylight.org] On Behalf Of Srikanth Lingala
Sent: Wednesday, February 08, 2017 9:34 PM
To: Sam Hague <sha...@redhat.com<mailto:sha...@redhat.com>>
Cc: sfc-...@lists.opendaylight.org<mailto:sfc-...@lists.opendaylight.org>; 
Ferenc Cserepkei 
<ferenc.cserep...@ericsson.com<mailto:ferenc.cserep...@ericsson.com>>; Gorja 
Gorja <prasad.go...@nxp.com<mailto:prasad.go...@nxp.com>>; Rozet, Tim 
<tro...@redhat.com<mailto:tro...@redhat.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
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:sha...@redhat.com]
Sent: Wednesday, February 08, 2017 6:47 PM
To: Srikanth Lingala <srikanth.ling...@nxp.com<mailto:srikanth.ling...@nxp.com>>
Cc: Brady Allen Johnson 
<brady.allen.john...@ericsson.com<mailto:brady.allen.john...@ericsson.com>>; 
sfc-...@lists.opendaylight.org<mailto:sfc-...@lists.opendaylight.org>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>; 
Gorja Gorja <prasad.go...@nxp.com<mailto:prasad.go...@nxp.com>>; Rozet, Tim 
<tro...@redhat.com<mailto:tro...@redhat.com>>; Ferenc Cserepkei 
<ferenc.cserep...@ericsson.com<mailto:ferenc.cserep...@ericsson.com>>; 
Veera.Reddy B <veer...@nxp.com<mailto:veer...@nxp.com>>
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 
<srikanth.ling...@nxp.com<mailto: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-r

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

[Srikanth Lingala]

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:sha...@redhat.com]
Sent: Wednesday, February 08, 2017 6:47 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>; Veera.Reddy B <veer...@nxp.com>
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 
<srikanth.ling...@nxp.com<mailto: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<mailto:sha...@redhat.com>]
Sent: Tuesday, February 07, 2017 11:22 PM
To: Srikanth Lingala <srikanth.ling...@nxp.com<mailto:srikanth.ling...@nxp.com>>
Cc: Brady Allen Johnson 
<brady.allen.john...@ericsson.com<mailto:brady.allen.john...@ericsson.com>>; 
sfc-...@lists.opendaylight.org<mailto:sfc-...@lists.opendaylight.org>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>; 
Gorja Gorja <prasad.go...@nxp.com<mailto:prasad.go...@nxp.com>>; Rozet, Tim 
<tro...@redhat.com<mailto:tro...@redhat.com>>; Ferenc Cserepkei 
<ferenc.cserep...@ericsson.com<mailto: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<mailto: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.urn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.OvsdbTerminationPointAugmentation=OvsdbTerminationPointAugmentation{getIfindex=35,

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

[Srikanth Lingala]

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. 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<mailto: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.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={}}, Optio

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

[Srikanth Lingala]

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|1|ofproto_dpif_xlate(pmd9)|ERR|over max 
translation depth 64: 
tcp,in_port=4,vlan_tci=0x,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|1|ofproto_dpif_xlate(revalidator10)|ERR|over max 
translation depth 64: 
tcp,in_port=4,vlan_tci=0x,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|2|ofproto_dpif_xlate(pmd9)|ERR|over max 
translation depth 64: 
tcp,in_port=4,vlan_tci=0x,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|3|ofproto_dpif_xlate(pmd9)|ERR|over max 
translation depth 64: 
tcp,in_port=4,vlan_tci=0x,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|2|ofproto_dpif_xlate(revalidator10)|ERR|over max 
translation depth 64: 
tcp,in_port=4,vlan_tci=0x,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]
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=0x111001510255, 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

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

[Srikanth Lingala]

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.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] SFC with OPNFV Colorado

[Srikanth Lingala]

Hi,
I deployed OS controller and single OS Compute through OPNFV Colorado 2.0.
I installed SFC Tacker on OS Controller. [https://github.com/trozet/tacker]
I created SFC attributes like vnfd, vnf and sfc from sfc-tacker.
I am able to see the respective SFC related attributes like Service Function, 
Service Function Forwarder, Service Function Path, ACL and Service Function 
Classifier in ODL using DLUX GUI.
I am able to see NSH flows in the Compute Node. OVS flows information is shown 
in the below link:

http://pastebin.com/aG7qMpt0

When I create a SFC Classifier, I am able to see the related flows in the OVS, 
but not able to getting packets to the vNF deployed in the SFC.
Please let me know, where I am missing the context here.

Regards,
Srikanth.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] Opendaylight - Switches are not connected in the topology page of DLUX UI

[Srikanth Lingala]

Hi,
I have deployed One Openstack Controller with ODL Controller and One Openstack 
Compute Node through Fuel 9 community build.
In the both hosts, I am able to see VxLAN tunnel ports for 'br-int' bridge.
When I saw the Topology page in the DLUX UI 
(http://:8181/index.html#/topology),
 I am able to see two Openflow switches.
But, connection between these switches is not showing. I am able to PING the 
Controller and Compute machine from one another. Because of this, VM's are not 
pinging through VxLAN tunnels. Can anyone give me a hint, where could be the 
issue?

Following are the 'ovs-vsctl' details in both controller and compute node:
http://pastebin.com/jCxvmv2R

Regards,
Srikanth.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] Opendaylight - Switches are not connected in the topology page of DLUX UI

[Srikanth Lingala]

Hi,
I have deployed One Openstack Controller with ODL Controller and One Openstack 
Compute Node through Fuel 9 community build.
In the both hosts, I am able to see VxLAN tunnel ports for 'br-int' bridge. 
But, when I saw the Topology page in the DLUX UI 
(http://:8181/index.html#/topology), I am able to see two 
Openflow switches. But, connection between these switches is not showing. I am 
able to PING the Controller and Compute machine from one another. Because of 
this, VM's are not pinging through VxLAN tunnels. Can anyone give me a hint, 
where could be the issue?
Following are the OVS details:
Openstack Controller:
root@node-9:~# ovs-vsctl show
1960cd46-cc88-41b9-a2cb-2306b9f6feac
Manager "tcp:192.168.0.4:6640"
is_connected: true
Bridge br-int
Controller "tcp:192.168.0.4:6653"
is_connected: true
fail_mode: secure
Port br-int
Interface br-int
type: internal
Port "vxlan-192.168.2.1"
Interface "vxlan-192.168.2.1"
type: vxlan
options: {key=flow, local_ip="192.168.2.2", 
remote_ip="192.168.2.1"}
Port "tap0ef6e861-0d"
Interface "tap0ef6e861-0d"
type: internal
Bridge br-ex
Port br-ex
Interface br-ex
type: internal
Port "p_aec4d661-0"
Interface "p_aec4d661-0"
type: internal
ovs_version: "2.4.1"

root@node-9:~# ovs-vsctl list Open_vSwitch .
_uuid   : 1960cd46-cc88-41b9-a2cb-2306b9f6feac
bridges : [5457b0d3-e9e7-4e7e-9661-1cf1a0afcf62, 
9a4e1bd6-d283-4048-9995-b41933a83772]
cur_cfg : 356
datapath_types  : [netdev, system]
db_version  : "7.12.1"
external_ids: {system-id="40fe6786-0a57-4b35-ab70-dd18c29c7d67"}
iface_types : [geneve, gre, "gre64", internal, ipsec_gre, 
"ipsec_gre64", lisp, patch, stt, system, tap, vxlan]
manager_options : [df08aebc-4e94-47cd-81ce-8e82d7e93cae]
next_cfg: 356
other_config: {local_ip="192.168.2.2", 
provider_mappings="br-ex:p_aec4d661-0"}
ovs_version : "2.4.1"
ssl : []
statistics  : {}
system_type : Ubuntu
system_version  : "14.04-trusty"
Openstack Compute:
root@node-10:~# ovs-vsctl show
79f1fefc-5f30-40d6-980e-b745b111567b
Manager "tcp:192.168.0.4:6640"
is_connected: true
Bridge br-int
Controller "tcp:192.168.0.4:6653"
is_connected: true
fail_mode: secure
Port br-int
Interface br-int
type: internal
Port "vxlan-192.168.2.2"
Interface "vxlan-192.168.2.2"
type: vxlan
options: {key=flow, local_ip="192.168.2.1", 
remote_ip="192.168.2.2"}
ovs_version: "2.4.1"

root@node-10:~# ovs-vsctl list Open_vSwitch .
_uuid   : 79f1fefc-5f30-40d6-980e-b745b111567b
bridges : [2a74c39b-fc71-4820-a5a9-08c5382879c3]
cur_cfg : 5
datapath_types  : [netdev, system]
db_version  : "7.12.1"
external_ids: {system-id="e594dee5-6c5d-44f8-bb66-d79f46e8558b"}
iface_types : [geneve, gre, "gre64", internal, ipsec_gre, 
"ipsec_gre64", lisp, patch, stt, system, tap, vxlan]
manager_options : [7ccef49d-ad29-4712-8764-0101eacf2d44]
next_cfg: 5
other_config: {local_ip="192.168.2.1"}
ovs_version : "2.4.1"
ssl : []
statistics  : {}
system_type : Ubuntu
system_version  : "14.04-trusty"
Regards, Srikanth.

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