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

Copyright (c) 2015-2017 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 which talks to single controller in three node cluster configuration. Test suite checks changes of the the example-ipv4-topology on all nodes. RIB is not examined.

singlepeer_pc_shm_300kroutes: pc - prefix counting shm - shard monitoring (during the process of prefix advertizing)

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.

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 BGP application peer

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

Test suite performs basic BGP performance test cases for BGP application peer. BGP application peer introduces routes - using restconf - in two steps: 1. introduces the 100000 number of routes in one POST request 2. POSTs the rest of routes (up to the 180000 number) one by one Test suite checks that the prefixes are propagated to IPv4 topology and announced to BGP peer via updates. Test case where the BGP peer is disconnected and reconnected and all routes are deleted by BGP application peer are performed as well. Brief description how to configure BGP application peer and how to use restconf application peer interface: https://wiki.opendaylight.org/view/BGP_LS_PCEP:User_Guide#BGP_Application_Peer https://wiki.opendaylight.org/view/BGP_LS_PCEP:Programmer_Guide#BGP http://docs.opendaylight.org/en/stable-boron/user-guide/bgp-user-guide.html#bgp-peering http://docs.opendaylight.org/en/stable-boron/user-guide/bgp-user-guide.html#application-peer-configuration

Reported bugs: Bug 4689 - Not a reasonable duration of 1M prefix introduction from BGP application peer via restconf Bug 4791 - BGPSessionImpl: Failed to send message Update logged even all UPDATE mesages received by iBGP peer

BGP performance of ingesting from many iBGP peers, data change counter 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 processes as iBGP peers. This is analogue of single peer performance suite, which uses many peers. Each peer is of ibgp type, and they contribute to the same example-bgp-rib, and thus to the same single example-ipv4-topology. 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.

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 (manypeers_changecount.robot) to get better precision.

ODL distinguishes peers by their IP addresses. Currently, this suite requires python utils to be started on ODL System, to guarantee IP address block is available for them to bind to. TODO: Figure out how to use Docker and docker IP pool available in RelEng.

Currently, 127.0.0.1 is hardcoded as the first peer address to use. TODO: Figure out how to make it configurable. As peer IP adresses are set incrementally, we need ipaddr to be used in Robot somehow.

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: Is there a need for version of this suite where ODL connects to pers? Note that configuring ODL is slow, which may affect measured performance singificantly. Advanced TODO: Give manager ability to start pushing on trigger long after connections are established.

BGP performance of ingesting from many iBGP peers, data change counter is used.

Copyright (c) 2018 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 processes as iBGP peers. This is analogue of single peer performance suite, which uses many peers. Each peer is of ibgp type, and they contribute to the same example-bgp-rib, and thus to the same single example-ipv4-topology. 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. Use the other version of the suite (manypeers_prefixcount.robot) if the feature does not work.

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.

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.

ODL distinguishes peers by their IP addresses. Currently, this suite requires python utils to be started on ODL System, to guarantee IP address block is available for them to bind to. TODO: Figure out how to use Docker and docker IP pool available in RelEng.

Currently, 127.0.0.1 is hardcoded as the first peer address to use. TODO: Figure out how to make it configurable. As peer IP adresses are set incrementally, we need ipaddr to be used in Robot somehow.

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: Is there a need for version of this suite where ODL connects to pers? Note that configuring ODL is slow, which may affect measured performance singificantly. Advanced TODO: Give manager ability to start pushing on trigger long after connections are established.

Set tell-based protocol usage

Copyright (c) 2016 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

Suite stops all odl nodes, un-comment usage of tell-based protocol in config file (means make it true) and starts all nodes again.

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

Copyright (c) 2015-2017 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 which talks to single controller in three node cluster configuration. Test suite checks changes of the the example-ipv4-topology on all nodes. RIB is not examined.

singlepeer_pc_shm_300kroutes: pc - prefix counting shm - shard monitoring (during the process of prefix advertizing)

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.

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.