diff options
| -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 |