Subject: problem in collision strategy?

From: [email-masked]
Date: Thu, 12 Sep 2002 16:36:40 +0200

hi,

recently we encountered a race condition  with  the collision
detection strategy, which i would like to bring the the attention of the
people working on the new BGP draft for BGP.

The root of the problem seems to be  related in the interface between
the TCP layer and BGP layer: when is an event received by the TCP handled
by the BGP?

The situation is described below. It sounds pretty strange, however
it did occur! It took about 100 attempts and sometimes much more to get
out of it.  And as  far as I can see, nothing happened outside
of the current state machine description, i.e. the currewnt BGP state machine
allowed this to happen.

Regrads,

Hans De Vleeschouwer.

(in the scenario below time progresses downwards)

+---------------+
+---------------+

! BGP speaker A !
! BGP speaker B !

! 10.10.10.10   !------------------+ 10.10.11.11
!

!
!
!
!

+---------------+
+---------------+

!
Setup TCP connection 1!

!===============================>!

!
!

BGP speaker 1 initiates a TCP connection towards speaker2

This action is successfull.

!   OPEN
for connection 1        !

!===============================>!

Speaker 1 being informed that the TCP is up, sends an OPEN

message for the connection he initiated. The OPEN message

is NOT yet treated by speaker 2. (probably speaker 2 is not

yet aware of the connection because he did not check the TCP

events ).

The states in BGP are:

Connection 1: Open Sent
Connection 1: idle?

!   Setup TCP
connection 2        !

!<================================!

!
!

At this stage, speaker 2 also sets up a TCP connection to speaker
A

(this happens before the BGP application of speaker 2 is

aware of the connection of speaker 1).

!
OPEN for connection 2     !

!================================>!

Now BGP speaker 1, being informed of a new connection immediatelly

sends an OPEN message. On Speaker 2 we have either a slow TCP,
a slow BGP

or a slow link in between (actually it was a test tool, so I do
not know

really).but in any case it seems that the BGP states now became:

The states in BGP are:

Connection 1: Open Sent
Connection 1: idle?

Connection 1: Open Sent
Connection 2: idle?

!
OPEN for connection 1      !

!<==================================!

!
!

!
KEEPALIVE for connection 1 !

!==================================>!

BGP speaker 2 'wakes up' and responds to connection 1. BGP speaker
1

who is reacting alert, sends a KEEPALIVE for connection 1

The states in BGP are:

Connection 1: Open confirm
Connection 1: see below

COnnection 1: Open Sent
Connection 2: ?

AT this stage, the collision detection mechanism starts in BGP

speaker 1. Since BGP speaker 2 has the highest id, speaker 1 decides

to tear down his original TCP connection (connection 1).

!   KEEPALIVE for
connection 1   !

!<===============================!

Connection 1: gone

COnnection 2 : Open Sent

In the mean time BGP speaker 2, not being aware of the fact that

speaker 1 closed the connection 1 wakes up again, and receives
the

keealive from speaker 1 , sends back a keepalive and bring the

connection 1 in establsihed state.(note that on this keepalive
will be

lost, as the connection is closed.

Connection 1: established

Also at this moment, BGP speaker 2 notices that connection 2 is
up

and sends an OPEN mesage for connection 2, and trasitions to OPEN
SENT

Connection 2: OPEN sent.

!
OPEN for connection 2        !

!<====================================!

BGP speaker 2 then treats the OPEN mesage from speaker 1 (which
arrived

quite some time ago, but was not treated until now).

for connection 2.

This triggers the collision detection in speaker 2. As he still

believes that connection 1 is established, he decides to close
the connection 2

The end result is that both connection are cleared.

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Thu, 12 Sep 2002 17:41:48 -0400

This is described in Sue's FSM spec under section.
 
2.4.2 Collision Detect Processing in Established state
 
If Hans implements the config option, the race condition will go away.
 
Ben

-----Original Message-----
From: Tom Petch [mailto:[email-masked]]
Sent: Thursday, September 12, 2002 2:06 PM
To: [email-masked]; BGP mailing list
Subject: Re: problem in collision strategy?

Interesting, fascinating even.
 
The two ends should implement the same Connection collision detection and
arrive at the same conclusion.  The way I read it, both should retain the
(TCP) connection initiated by the BGP speaker with the higher value of BGP
Identifier; assuming that that is speaker 2, then 
This triggers the collision detection in speaker 2. As he still 
believes that connection 1 is established, he decides to close the
connection 2 
 
is in error; speaker 2 should close the first connection just as speaker one
has done.
 
Tom Petch, Network Consultant
[email-masked] <mailto:[email-masked]> 

-----Original Message-----
From: [email-masked]
<mailto:[email-masked]>  < [email-masked]
<mailto:[email-masked]> >
To: BGP mailing list < [email-masked] <mailto:[email-masked]> >
Date: 12 September 2002 15:38
Subject: problem in collision strategy?

<snip>

+---------------+                  +---------------+ 
! BGP speaker A !                  ! BGP speaker B ! 
! 10.10.10.10   !------------------+ 10.10.11.11   ! 
!               !                  !               ! 
+---------------+                  +---------------+ 
         !          Setup TCP connection 1! 
         !===============================>! 
         !                                ! 

         !   OPEN for connection 1        ! 
         !===============================>! 

The states in BGP are: 
 Connection 1: Open Sent           Connection 1: idle? 

        !   Setup TCP connection 2        ! 
        !<================================! 
        !                                 ! 

At this stage, speaker 2 also sets up a TCP connection to speaker A 
(this happens before the BGP application of speaker 2 is 
aware of the connection of speaker 1). 

        !       OPEN for connection 2     ! 
        !================================>! 

Now BGP speaker 1, being informed of a new connection immediatelly 
sends an OPEN message. On Speaker 2 we have either a slow TCP, a slow BGP 
or a slow link in between (actually it was a test tool, so I do not know 
really).but in any case it seems that the BGP states now became: 

The states in BGP are: 
 Connection 1: Open Sent           Connection 1: idle? 
 Connection 1: Open Sent           Connection 2: idle? 

       !        OPEN for connection 1      ! 
       !<==================================! 
       !                                   ! 
       !        KEEPALIVE for connection 1 ! 
       !==================================>! 

BGP speaker 2 'wakes up' and responds to connection 1. BGP speaker 1 
who is reacting alert, sends a KEEPALIVE for connection 1 
The states in BGP are: 
 Connection 1: Open confirm        Connection 1: see below 
 COnnection 1: Open Sent           Connection 2: ? 

       !   KEEPALIVE for connection 1   ! 
       !<===============================! 
  Connection 1: gone 
  COnnection 2 : Open Sent 

In the mean time BGP speaker 2, not being aware of the fact that 
speaker 1 closed the connection 1 wakes up again, and receives the 
keealive from speaker 1 , sends back a keepalive and bring the 
connection 1 in establsihed state.(note that on this keepalive will be 
lost, as the connection is closed. 
                                   Connection 1: established 

Also at this moment, BGP speaker 2 notices that connection 2 is up 
and sends an OPEN mesage for connection 2, and trasitions to OPEN SENT 
                                   Connection 2: OPEN sent. 

      !        OPEN for connection 2        ! 
      !<====================================! 

BGP speaker 2 then treats the OPEN mesage from speaker 1 (which arrived 
quite some time ago, but was not treated until now). 
for connection 2. 

This triggers the collision detection in speaker 2. As he still 
believes that connection 1 is established, he decides to close the
connection 2