On Wed, 14 Sep 2016, Paul Jakma wrote:
However, that doesn't mean a collision is impossible - it's just
dependent on timing and can happen every now and then. The test needs
to be prepared for a retry. Either the test itself should run again,
or the wrapper around the test should try again if the fail was due to
connection collision. ??
Oh, the other thing you could do is have one side be passive. E.g.
configure Quagga to have the test case peer as passive, and have the
test case connect; or have the test-case only listen and just wait for
Quagga to connect.
That might be worthwhile to ensure collision issues don't come into
non-CD unit tests?
Then, to test CD at least /somewhat/, have two tests:
1: Test just passively listens, and waits for connection to come in from
RUT. Then there's a number of combinations of things to test. Such as
perhaps:
- Wait for the open to be received on the received, inbound connection
and then connect out to the RUT and send OPEN, then see what happens &
flag clear spec violations.
- Connect out to the RUT, wait for OPEN on the inbound && for outbound
to connect, then send OPEN on outbound, then see what happens & flag
clear spec violations.
- Connect out to RUT, wait for outbound to succeed and immediately send
OPEN, then wait for OPENs, see what happens, etc.
Repeat these for RUT having the higher BGP router-ID, and the test
having the higher.
regards,
--
Paul Jakma | [email protected] | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Unnamed Law:
If it happens, it must be possible.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
