diff options
author | spiritus72 <billmorrissonjr@gmail.com> | 2018-06-21 14:13:36 +0100 |
---|---|---|
committer | spiritus72 <billmorrissonjr@gmail.com> | 2018-06-28 08:45:55 +0100 |
commit | fc443788ab537a007083ac8ff16deb0277c8bcc8 (patch) | |
tree | f035720d5b0dce072fb900dcc85ca22faa84d6d4 | |
parent | 60e21cbdbe94e32060369304b0502fe5b03af2c4 (diff) |
Fix Update README.tests
When looking at the different testcases in the functest directory
TEST SYMMETRIC is outdated and TEST DELETION is missing in the README.
This patch is an update to README.tests for the latest changes that
have been done the to those two testcases.
Change-Id: I54fceac85f45212ed45efca1a6f30d4ba092e0c1
Signed-off-by: spiritus72 <billmorrissonjr@gmail.com>
-rw-r--r-- | sfc/tests/functest/README.tests | 37 |
1 files changed, 29 insertions, 8 deletions
diff --git a/sfc/tests/functest/README.tests b/sfc/tests/functest/README.tests index d4e3df3e..f39d8888 100644 --- a/sfc/tests/functest/README.tests +++ b/sfc/tests/functest/README.tests @@ -34,15 +34,36 @@ will be running a firewall that blocks the traffic in a specific port (e.g. 33333). A symmetric service chain routing the traffic throught this SF will be created as well. -1st check: The client is able to reach the server using a source port different -from the one that the firewall blocks (e.g 22222), and the response gets back -to the client. +1st check: The client is able to reach the server and the response gets back +to the client. Here the firewall is running without blocking any port. -2nd check: The client is able to reach the server using the source port that -the firewall blocks, but responses back from the server are blocked, as the -symmetric service chain makes them go through the firewall that blocks on the -destination port initially used as source port by the client (e.g. 33333). +2nd check: The client is not able to reach the server as the firewall +is configured to block traffic on port 80, and the request from the client +is blocked, as the symmetric service chain makes them go through the firewall. -If the client is able to receive the response, it would be a symptom of the +If the client is able to reach the server, it would be a symptom of the +symmetric chain not working, as traffic would be flowing from client to server +directly without traversing the SF. + +3rd check: The client is able to reach the server, as the firewall +is configured to block traffic on port 22222, and the response from the server +is blocked. + +If the server is able to reach the client, it would be a symptom of the symmetric chain not working, as traffic would be flowing from server to client directly without traversing the SF. + +4th check: The client is able to reach the server and the response gets back +to the client. Like in 1st check to verify test ends with same config +as at the beginning. + + +## TEST DELETION - sfc_chain_deletion ## + +One client and one server are created using nova. Then a SF is created using tacker. +A service chain which routes the traffic through this SF will be created as well. +After that the chain is deleted and re-created. + +vxlan_tool is started in the SF and HTTP traffic is sent from the client to the server. +If it works, the vxlan_tool is modified to block HTTP traffic. +It is tried again and it should fail because packets are dropped.
\ No newline at end of file |