[SFC-139] getPortNumberFromNode is not correctly calculating the port number from the port name Created: 15/Feb/16  Updated: 19/Oct/17  Resolved: 17/Feb/16

Status: Resolved
Project: sfc
Component/s: General
Affects Version/s: unspecified
Fix Version/s: None

Type: Bug
Reporter: Brady Johnson Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 5354
Priority: Highest

 Description   

The port name that is set in the SF, as follows is not correctly being converted to the port number:

{
"service-functions": {
"service-function": [
{
"name": "sf1",
"type": "http-header-enrichment",
"nsh-aware": true,
"ip-mgmt-address": "10.0.0.10",
"sf-data-plane-locator": [
{
"name": "sf1-dpl",
"ip": "10.0.0.10",
"port": 6633,
"transport": "service-locator:vxlan-gpe",
"service-function-forwarder": "sff1",
"service-function-ovs:ovs-port" :

{"port-id" : "tap-port-1"}

<== This is the field that should be converted
}
]
}
]
}
}

 Comments   
Comment by Brady Johnson [ 15/Feb/16 ]

This is blocking OPNFV SFC from working correctly.

Comment by A H [ 15/Feb/16 ]

Hi Brady Johnson, what is the ETA for an available patch?

Comment by Brady Johnson [ 15/Feb/16 ]

Here is the patch in stable/beryllium:

https://git.opendaylight.org/gerrit/#/c/34707/

Waiting for results of manual OPNFV SFC testing with NetVirt classifier and Tacker VnfMgr. This should be finished in the next hour or so.

Comment by A H [ 15/Feb/16 ]

To better assess the impact of this patch, please help us identify:

Severity: Could you elaborate on the severity of this bug? Is this a BLOCKER such that we cannot release Beryllium without it? Is there a workaround such that we can write a release note and fix in Beryllium SR1?
Testing: Could you also elaborate on the testing of this patch? How extensively has this patch been tested? Did you do any manual/local testing? Is it covered by any unit tests or system tests?
Impact: Does this fix impact any dependent projects?

Comment by Brady Johnson [ 15/Feb/16 ]

Severity:
The severity was set to major since it caused traffic loss for OPNFV SFC. That is, packets could not be sent to/from SFs. The failure caused 2 very important flows to not be written. There is no a workaround available, so the situation was quite bad.

Testing:
The testing performed was manual, and was performed in an OPNFV environment. The OpenStack Tacker Vnf Mgr was used to bring up VMs for SFs and to configure SFC. ODL NetVirt was used as an SFC classifier. To test, packets were injected into a chain, and verified that they were sent where expected, and received by the intended destination.

Impact:
As previously mentioned, this bug impacted the downstream OPNFV SFC project.

Comment by A H [ 17/Feb/16 ]

Have we been able to verify the fix for this bug?

Comment by Brady Johnson [ 17/Feb/16 ]

This bug was verified manually by Sam Hague as mentioned in Comment 5. The fix worked correctly as expected.

Generated at Wed Feb 07 20:38:44 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.