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 | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Unnamed Law:
        If it happens, it must be possible.

_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

Reply via email to