SDN/NFV Experts Exchange Blog

rss

Take the maximum advantage of your SDN/NFV setup


Test Cases for Network Services Virtualization (NSV) at Open User Networking Group 2015 Spring

This blog presents the verification process of NEC’s ProgrammableFlow SDN solution to meet ONUG NSV Working Group Top 10 requirements.

From NSV’s angle, the NEC SDN solution provides NSV’s orchestration with dynamic traffic steering on demand as a network platform infrastructure. The key values from the NEC SDN solution are as follows:

·     Flexible policy setting for traffic steering through various appliances and network provisioning from the centralized control point

·     End-to-end traffic visibility

·     Enabling agile network with NEC’s SDN solution for mission critical applications

·     Openness to integrate with 3rd party tools to configure/provision network from NEC SDN

Network Service Virtualization (NSV) Working Group Top 10 Requirements

1.   Ability to co-exist with legacy network equipment and to work in a hybrid network composed of classical physical network services and virtualized network services.

2.   Provide the capability to load, execute, and move services across standard platforms from multiple vendors.

3.   Support an interface to decouple virtualized service instances from the underlying infrastructure.

4.   Support the provisioning of forwarding paths between service nodes from multiple vendors.

5.   Provide the necessary mechanisms to allow virtualized network services to be scaled with SLA requirements via different supported mechanisms: e.g. on-demand scaling, automatic scaling, etc.

6.   Support open and standard APIs for all applicable functions provided to other authorized entities (e.g. CMS, service instances, 3rd parties, etc.).

7.   Support standard mechanisms to preserve system state, to preserve state integrity, and to replicate state between different platforms.

8.   Provide mechanisms for the network operator to control and verify the configuration of the virtualized services and the elements that virtualize the hardware resource.

9.   Access to functionality via exposed APIs at all layers shall be protected using standard security mechanisms appropriate for that layer wherever applicable for authentication, authorization, data encryption, data confidentiality, and data integrity.

10.  Ability to detect the failure of service instance(s) and/or network reachability to that service instance(s) and take action in a way that meets the fault detection and remediation time objective of that service.

1

Overall test configuration is described in the below diagram. 

Some traffic comes from legacy/traditional network side to get to the servers in OpenFlow switch fabric and other traffic flows within OpenFlow switch fabric.

To simulate both traffic patterns, “Ixia Client Tool_1” is in the legacy side and “Ixia Client Tool_2” is in OpenFlow switch fabric to send the traffic to “Ixia HTTP Server” in OpenFlow switch fabric. Testing was performed with Ixia tools to simulate 100 simultaneous user traffic to access HTTP server. Validation of conditions to pass or fail on most test cases was that the Ixia test tool reports less than 0.1% packet loss, or less than 0.1% TCP retransmissions or TCP resets. In our case, no packet loss with 100 user traffic to meet that criteria.

There are multi-vendor OpenFlow switches in this test configuration including NEC, Dell, and NoviFlow switches. ProgrammableFlow SDN Controller defines network virtualization via CLI/WebGUI/RestAPIs and enables service chaining to allow traffic to go through various appliances such as Radware DDoS, Riverbed WAN Optimizer, and F5 load balancer.

The “Firewall” to connect both legacy and OpenFlow switch fabric with 2 NICs in this test configuration was CentOS Linux server to simulate simple L2/transparent mode firewall.

3rd party tools could be any network monitoring tools to send RestAPIs to the controller in order to set network definition or get network information. In this test configuration, Zabbix was used as 3rd party tool to collect network bandwidth from the specific switch port in OpenFlow switch fabric as a demo. 

NEC ProgrammableFlow Controller(PFC) , NEC ProgrammableFlow Switches(PF5240, PF5820) ,DELL OpenFlow Switch S4810, NoviFlow were used In this test configuration as shown in the below diagram.

 

2

Ixia Test Criteria

 

descarga

Requirement 1: Ability to co-exist with legacy network equipment and to work in a hybrid network composed of classical physical network services and virtualized network services.

NEC SDN approach to meet this requirement:

1. Service chaining being done in OpenFlow network by CLI/GUI/RestAPIs to the controller, both physical and virtual machines (clients) are located at OpenFlow and legacy network. Traditional/legacy network and OpenFlow network are connected via MCLAG (Multi Chassis Link AGgregation).

2. Firewall (services) in legacy network is inline with OpenFlow network.

NEC SDN provides seamless and transparent traffic flow between legacy network and OpenFlow network where end points (either physical or virtual service instances) are located by using network virtualization and service insertion as a part of traffic steering.

NEC showed 2 types of test scenario for this requirement:

“Test case 1” is to demonstrate co-existence of classical network and virtualized network services, the following is the detail test steps:

1)Enable service chaining with FW and LB in OpenFlow network

2)Generate traffic for 1~2 minutes from 100 active clients in the legacy network (Ixia) to the http server in OpenFlow network

3)From NEC SDN management GUI (Web browser GUI) , check the end-to-end traffic and confirm traffic traverses via firewall and load balancer

4)Check any packet loss

 

4

“Test case 2” is to demonstrate network services in legacy/classic network , the following is the detail test steps:

1)Generate traffic for 1~2 minutes from 100 active clients in the legacy network (Ixia) to the http server in OpenFlow network

2)From NEC SDN management GUI (Web browser GUI) , check the end-to-end traffic and confirm traffic comes in via FW port in the legacy network

3)Check any packet loss 

6

Validation conditions (Pass/Fail):

•The test tool reports less than 0.1% packet loss, or less than 0.1% TCP retransmissions or TCP resets.

Results:

There was no packet loss during both test cases. The demos for this testing are shown from here, test 1 and test 2.

Applicable use case:

In case of Campus/Enterprise Network, your backbone/core network can be built with OpenFlow switch fabric to connect data sensitive organizational or financial data severs which need authorized access.

Client traffic could come from legacy/traditional network devices through LAN or WAN. Client traffic can go through any authenticator (Radius, LDAP/AD) and firewalls before accessing the campus core network. To enforce further security layer, ProgrammableFlow Controller/OpenFlow switch fabric can steer the traffic to appropriate VTNs(Virtual Tenant Network), MAC/IP/Port basis additional filtering path, and chained service path in order to provide much finer granular security level of network access in OpenFlow switch fabric. More details about Campus/Enterprise Network with OpenFlow switch fabric integration is shown from this link

Requirement 2: Provide the capability to load, execute and move services across standard platforms from multiple vendors

NEC SDN approach to meet this requirement:

ProgrammableFlow Controller can work with different virtualization platforms (different hypervisors, H/W) for networking. We will run the test of virtualized NEC ProgrammableFlow Controller on ESXi hypervisor and on KVM hypervisor to simulate virtualized services being on the different hypervisors.

NEC showed the following test scenario for this requirement:

1) Generate traffic for 1 minute from 100 active clients to the http server on Ixia and check the packet loss

(Switches are connected to ESXi based ProgrammableFlow Controller for this test case)

2) Stop the traffic

3) Generate traffic for 1 minute from 100 active clients to the http server on Ixia and check the packet loss

(Switches are connected to KVM based ProgrammableFlow Controller for this test case)

4) Stop the traffic

 

7

Validation conditions (Pass/Fail):

•The test tool reports less than 0.1% packet loss, or less than 0.1% TCP retransmissions or TCP resets.

Results:

There was no packet loss during the step1) and 3) testing. The demo for this testing is shown from this link.

Applicable use case:

ProgrammableFlow Controller can work on virtual environment, however, this solution is for only proof-of-concept level not for the production level due to performance and scalability issues on the virtual environment limitation.

Requirement 3 and 7 were shown together with one test case.

Requirement 3: Support an interface to decouple virtualized service instances from the underlying infrastructure.

Requirement 7: Support standard mechanisms to preserve system state, to preserve state integrity, and to replicate state between different platforms.

NEC SDN approach to meet this requirement:

NEC SDN enables network virtualization and provide various interfaces such as CLI/GUI/RestAPIs to configure network definition with virtualized service instances. When virtualized service instances are moved around among physical servers from an orchestration tool such as vCenter, there is no configuration change on ProgrammableFlow Controller for network, PFC will detect the network change automatically. Therefore, virtualized service instances are not coupled from the underlying infrastructure, it can be moved to any physical machines at any time without any network configuration change in NEC ProgrammableFlow Controller and switches.

NEC showed the following test scenario for this requirement:

VMs are simulating Virtualized Service Instances (Firewalls, Load balancers, WAN Optimizer, etc)

1) Generate traffic from Ixia 100 active client to Ixia HTTP server via FW virtualized service on ESXi hypervisor for 1 minute

2) Move the FW virtualized service VM from one ESXi host to another ESXi host via vCenter

3) Check traffic paths from NEC SDN management GUI (Web browser GUI) for physical NW and see if migrated VM is shown on the different switch port and new traffic flows via migrated VM

4) See if traffic resumes after migration

· Firewall service VM migration is performed via vCenter of VMWare

· Automatic route change after migration in OpenFlow switch fabric, no configuration change in OpenFlow enabled switches or logical network definition in NEC ProgrammableFlow Controller during firewall service VM migration

 

8

Validation conditions (Pass/Fail):

•Forwarding path verification from NEC SDN management GUI (Web browser GUI) between Ixia client and server via FW virtualized service VM before migration

•During the migration period, which should be less than 20s, TCP connections may be lost, but then re-established and continue running normally afterwards

•Forwarding path verification from NEC SDN management GUI (Web browser GUI) between Ixia client and server via FW virtualized service VM after migration

Result:

VM migration via vCenter of VMWare took around 7 seconds. Traffic immediately resumed after migration was complete.

Applicable use case:

Virtual machines no matter what they are virtual service instances or specific virtual applications and physical machines such as either physical appliances or servers can move around in OpenFlow switch fabric without concerning silo infrastructure or changing switch configuration after deploying OpenFlow switch fabric with NEC ProgrammableFlow Controller. OpenFlow switch fabric has “better scalability of flat L2 segment” than legacy/traditional networks which has physical silo boundary and also provides transparent VM/PM migration with the controller’s automatic route changes.

 

9

Requirement 4: Support the provisioning of forwarding paths between service nodes from multiple vendors.

NEC SDN approach to meet this requirement:

NEC SDN supports the provisioning of end-to-end traffic, no matter where service nodes/clients/servers are located in the network. Network visibility via GUI/CLI/RestAPIs enables the provisioning of forwarding paths at a packet level. The controller maps physical topology of service nodes from multiple vendors within OpenFlow switch fabric. If one forwarding path goes down, the controller reroutes to the alternative path, at the same time SNMP traps and alarms are generated by the controller so that your network monitoring tools can capture. Also, OpenFlow switch fabric has port-group feature for automatic link failover in microsecond level.

NEC showed the following test scenario for this requirement:

1) Generate Traffic from Ixia with 100 active clients and keep running for 1 minute while doing the following steps

2) Run CLI or Web API scripts to add each service node one by one (F5 LB, RiverBed WAN optimizer, Radware FW)

3) Check forwarding paths from NEC SDN management GUI (Web browser GUI) to see if packets are properly forwarded to all service nodes that got added

4) Run CLI or Web API scripts to delete each service node one by one (F5 LB, RiverBed WAN optimizer, Radware FW)

5) Check forwarding paths from NEC SDN management GUI (Web browser GUI) to see if packets are no longer forwarded to all service nodes that got deleted

 

10

Validation conditions (Pass/Fail):

•The test tool reports less than 0.1% packet loss, or less than 0.1% TCP retransmissions or TCP resets.

•Forwarding path verification from NEC SDN management GUI(Web browser GUI)

Result:

There was no packet loss during the test and GUI showed the proper forwarding path. The demo for this testing is captured here.

Applicable use case:

More detail service chaining use cases are described at “Service Chaining” section in this blog series.

Requirement 6: Support open and standard APIs for all applicable functions provided to other authorized entities (e.g. CMS, service instances, 3rd parties, etc.).

NEC SDN approach to meet this requirement:

NEC SDN provides complete set of RestAPIs for integration with other applications used to operate network among end points and service instances.

NEC SDN has open and standard APIs (JSON, XML format) for 3rd party tools can call if they get authorized to access to the controller.

NEC showed the following test scenario for this requirement:

1) Generate traffic flow from 2 hosts across an SDN network topology

2) Access reporting tool (Open Source 3rd party tool) integrated with NEC WebAPI.

3) Demonstrate bandwidth reporting on Zabbix. Show how GUI on WebAPI client tool (Zabbix) allows polling of bandwidth statistics of each switch port (For example, port 11). Show how query can be done manually or how an interval time to poll automatically

4) See logs from Zabbix to see JSON format strings which were sent to NEC’s ProgrammableFlow Controller

5) Show API details from Zabbix to see how NEC Rest APIs are called from 3rd party application

6) Show full documentation of open and standard APIs of NEC ProgrammableFlow Controller (https://support.necam.com/SDN/pfv6/)

 

11

Validation conditions (Pass/Fail):

•Check the statistics report from Zabbix GUI

•Compare the JSON format string after calling APIs from Zabbix with open and standard APIs of NEC ProgrammableFlow Controller and verify APIs

Result:

The demo is shown from this link.

Applicable use case:

Network monitoring tools such as any SNMP client tool, syslog tool or OpenStack can be integrated with NEC SDN to set network definition or get network information via RestAPIs.

Requirement 9: Access to functionality via exposed APIs at all layers shall be protected using standard security mechanisms appropriate for that layer wherever applicable for authentication, authorization, data encryption, data confidentiality, and data integrity.

NEC SDN approach to meet this requirement:

NEC SDN RestAPIs support authentication with username/password creation, password being encrypted by MD5 and authorization based on each user’s permission level with roles. Data encryption is performed by OpenSSL. Show full documentation of open and standard APIs of NEC ProgrammableFlow Controller.

NEC showed the following test scenario for this requirement:

1) Authentication - execute Web Client program in Python script with wrong user name or password and see if the program gets rejected to access ProgrammableFlow Controller to set service chaining

                            Example: demo script

$ python nec-sdn-lab-service-chaining.py 10.0.1.20

Enter WebAPI Username: Administrator

Enter WebAPI Password: ******* <- wrong password

Authentication failure error message will be shown and the API request will get rejected to access the controller.

2)Authorization - execute Web Client program in Python script with certain ID who doesn’t have admin privilege and see if the Web Client program gets rejected to access ProgrammableFlow Controller.

$ python nec-sdn-lab-service-chaining.py 10.0.1.20

Enter WebAPI Username: jenny <- not enough privilege, non-admin user

Enter WebAPI Password: *******

Authorization failure error message will be shown and the API request will get rejected to access the controller.

3)Data encryption, confidentiality - Change Web Client program in Python script with HTTP connection rather than HTTPS (SSL/TLS) and see if the Web Client program gets rejected to access ProgrammableFlow Controller.

Data encryption, confidentiality failure error message will be shown and the API request will get rejected to access the controller.

4)Data integrity – Show ProgrammableFlow Controller network definition syntax after WebAPI gets executed by Web Client program in Python script and see if the syntax is consistent with ProgrammableFlow Controller network definition from ProgrammableFlow Controller GUI and executable immediately

Validation conditions (Pass/Fail):

•Verify the error message output from the client and verify the syntax on NEC ProgrammableFlow Controller.

Result:

The demo is shown from this link.

Applicable use case:

Your network is programmable on demand whenever it is necessary to change your network. CLI/RestAPIs enables programmability of your network. Also programmability leads network automation.

Requirement 10: Ability to detect the failure of service instance(s) and/or network reachability to that service instance(s) and take action in a way that meets the fault detection and remediation time objective of that service.

NEC SDN approach to meet this requirement:

NEC SDN automates detection and rerouting of network traffic upon either link failure or service instance unreachability.

1) NEC will show how port grouping can be applied for near instantaneous failover in the event of a network fault

2) ProgrammableFlow Controller will detect failure of service instance using the Network Monitor Function.

NEC showed the following test scenario for this requirement:

“Test case 1” is to simulate physical link failure.

1) Generate traffic from 100 active client(Ixia) to the server in OpenFlow network for 1 minute

2) Shut down a physical switch port in the route on the switch management console

3) Show that traffic is automatically redirected in spite of the link failure. Illustrate new route taken in NEC ProgrammableFlow Controller’s management GUI with logical/physical end-to-end traffic path

4) Measure packet drop in the test tool, confirm SLA objective attainment

 

12

“Test case 2” is to simulate service instance failure.

1) Shutdown the service instance

2) See if the traffic flows to other alternative service instance to continue the service without service disruption. Illustrate traffic flowing to new instance NEC ProgrammableFlow Controller’s management GUI with logical/physical end-to-end traffic path

3) Measure packet drop in the test tool, confirm SLA objective attainment

 

13

Validation conditions (Pass/Fail):

•For test case 1: The test tool reports less than 0.1% packet loss, or less than 0.1% TCP retransmissions or TCP resets

•For test case 2: Instance failure detection would take at least 6 seconds before traffic is rerouted by NEC ProgrammableFlow Controller. During the failure detection, which will be 6 seconds , TCP connections may be lost. However, then connections are re-established and will continue running normally afterwards. (health-interval + wait-time x failure-counts (in seconds) ) . Forwarding path verification from NEC SDN management GUI(Web browser GUI) between Ixia client and server via appliance services and end-to-end traffic resuming via rerouted paths after failure detection

Result:

•For test case 1: There was no packet loss during the test. The demo is shown from here.

•For test case 2: Drop showed during 6 seconds, but traffic resumed once the instance failure was detected by the controller. The demo is shown from here.

Applicable use case:

Physical link failure case enables seamless network services for mission critical applications or devices in OpenFlow switch fabric. Link conversion after the failure detection takes microsecond level of latency on the data plane of OpenFlow switch fabric, STP free.

Instance failure case enables physical and virtual appliance instance monitoring in your network and pre-program alternative service nodes (physical or virtual appliances) in case of the node failure.

NEC Presents at Tech Field Day Extra at ONUG Spring 2015

Full Event

Live Blogs

ONUG Spring 2015 Live Blog – Day2 from Ethan Banks on Networking Blog

“NEC Tech Field Day Event” section from Jason Edelman’s Blog

 

14








b i u quote


Save Comment
Showing 7 Comments
Avatar  equi 4 months agoReply

Thanks for the test case,I am a networking student and it will help me a lot.

Yes, that's correct. All devices on the diagram such as (HP, Meru, NoviFlow, Alcatel-lucent) can communicate with NEC's controller via OF1.0 or OF1.3.1. The diagram is based on the testing with those devices and NEC's controlle

Hi This is exactly what I was looking for. Thanks for sharing this great Information That is very interesting smile I love reading and I am always searching for informative information like this You are bookmarked.

Testing was performed with Ixia tools to simulate 100 simultaneous user traffic to access HTTP server. Validation of conditions to pass or fail on most test cases was that the Ixia test tool reports less than 0.1% packet loss, or less than 0.1% TCP retransmissions or TCP resets.

Nice post and it would be great for everyone, Thanks a lot for spreading this information here.

NEC Corporation of America (NEC), a main innovation integrator of cutting edge IT, interchanges and systems administration arrangements, today reported the fruitful finishing of ONUG's

Avatar  assignment help last yearReply

The ONUG tests intend to give evidence of ideas, highlight acceptance, and exhibitions to guarantee that the systems administration arrangements in the system overlays