BGP performance of ingesting from 1 iBGP peer, data change counter is used.

Copyright (c) 2015 Cisco Systems, Inc. and others. All rights reserved.

This program and the accompanying materials are made available under the terms of the Eclipse Public License v1.0 which accompanies this distribution, and is available at http://www.eclipse.org/legal/epl-v10.html

This suite uses play.py as single iBGP peer. The suite only looks at example-ipv4-topology, so RIB is not examined.

This suite requires odl-bgpcep-data-change-counter to be installed so make sure it is added to "install-features" of any jobs that are going to invoke it.

The suite consists of two halves, differing on which side initiates BGP connection. Data change counter is a lightweight way to detect "work is being done". WaitUtils provide a nice Keyword to wait for stability, but it needs initial value, that is why Store_Change_Count appears just before work-inducing action. The time for Wait_For_Stable_* cases to finish is the main performance metric. After waiting for stability is done, full check on number of prefixes present is performed.

Brief description how to configure BGP peer can be found here: https://wiki.opendaylight.org/view/BGP_LS_PCEP:User_Guide#BGP_Peer http://docs.opendaylight.org/en/stable-boron/user-guide/bgp-user-guide.html#bgp-peering

TODO: Currently, if a bug causes zero increase of data changes, affected test cases will wait for max time. Reconsider. If zero increase is allowed as stable, higher number of repetitions should be required.

Additionally this test suite is not compatible with Helium and Hydrogen releases as they don't include data change counter feature. Use the other version of the suite (singlepeer_prefixcount.robot) to test them.

BGP performance of ingesting from 1 iBGP peer, data change counter is NOT used.

Copyright (c) 2015 Cisco Systems, Inc. and others. All rights reserved.

This program and the accompanying materials are made available under the terms of the Eclipse Public License v1.0 which accompanies this distribution, and is available at http://www.eclipse.org/legal/epl-v10.html

This suite uses play.py as single iBGP peer. The suite only looks at example-ipv4-topology, so RIB is not examined.

The suite consists of two halves, differing on which side initiates BGP connection. State of "work is being done" is detected by increasing value of prefixes in topology. The time for Wait_For_Stable_* cases to finish is the main performance metric. After waiting for stability is done, full check on number of prefixes present is performed.

Brief description how to configure BGP peer can be found here: https://wiki.opendaylight.org/view/BGP_LS_PCEP:User_Guide#BGP_Peer http://docs.opendaylight.org/en/stable-boron/user-guide/bgp-user-guide.html#bgp-peering

TODO: Currently, if a bug causes prefix count to remain at zero, affected test cases will wait for max time. Reconsider. If zero is allowed as stable, higher period or repetitions would be required.

The prefix counting is quite heavyweight and may induce large variation in time. Try the other version of the suite (singlepeer_changecount.robot) to get better precision.