Mailing List Archive: bgp collision avoidance

bgp collision avoidance - initial rough patch

Aug 26, 2003, 12:48 AM

Post #1 of 3 (932 views)

hi,

find attached an initial rough patch of my attempt to fix up
collision detection in Zebra/Quagga bgpd.

it:

- adds fd_local and fd_accept to struct peer
- changes fd to a pointer in struct peer
- removes the creation of a 'dummy' peer for remote initiated
connections
- changes bgp_collision_detect to:
- only check state OpenConfirm peers
- compare the BGP of the existing peer to the ID given (which
came from the open)
- close the offending socket - not send a NOTIFY (is it valid
to send a NOTIFY? peer must surely be in state OpenSent or
OpenConfirm?)
- update the peer fd pointer if needed and set the read
thread
- removes the code that has to copy dummy to real peer in event of a
collision in bgp_open_receive
- removes the code in bgp_accept to create a dummy peer.

its a rough initial patch, does appear to work with some brief
testing between 2 bgpd's (one with patch, one without), in principle
is simpler, but needs review and heavy testing.

also, at present the bgpd FSM simply logs and ignores many events
which should really result in sessions being shutdown and returned to
idle.

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
I haven't lost my mind -- it's backed up on tape somewhere.

Re: bgp collision avoidance - initial rough patch [ In reply to ]

john at jlc

Aug 28, 2003, 10:46 AM

Post #2 of 3 (895 views)

Permalink

Paul Jakma <paul@clubi.ie> wrote:
>
> find attached an initial rough patch of my attempt to fix up
> collision detection in Zebra/Quagga bgpd.
>
> it:
>
> - adds fd_local and fd_accept to struct peer
> - changes fd to a pointer in struct peer
> - removes the creation of a 'dummy' peer for remote initiated
> connections
> - changes bgp_collision_detect to:
> - only check state OpenConfirm peers
> - compare the BGP of the existing peer to the ID given (which
> came from the open)
> - close the offending socket - not send a NOTIFY (is it valid
> to send a NOTIFY? peer must surely be in state OpenSent or
> OpenConfirm?)

I must recommend some caution here.

If we reach this situation under authenticated TCP-MD5, we can be
reasonably sure the other host has lost its prior mind. But I don't
recall TCP-MD5 is even available as an option in quagga.

Under unauthenticated TCP, we're considerably less sure that the
message we receive accurately reflects the state of our peer.

Thus I'd tend to keep the full baggage of the NOTIFY.

(Note that, by my understanding, the new TCP connection will be
distinct from the old one; the NOTIFY will be sent on the old one,
assuming it is -- on our end -- in a state capable of sending one.
If the other end has indeed forgotten it, regular timeouts should
work.)

--
John Leslie <john@jlc.net>

Re: bgp collision avoidance - initial rough patch [ In reply to ]

paul at clubi

Aug 28, 2003, 6:44 PM

Post #3 of 3 (889 views)

Permalink

On Thu, 28 Aug 2003, John Leslie wrote:

> I must recommend some caution here.
>
> If we reach this situation under authenticated TCP-MD5, we can
> be reasonably sure the other host has lost its prior mind. But I
> don't recall TCP-MD5 is even available as an option in quagga.

it isnt, it wont be, least not on most platforms. (though, patches
for platforms which support TCP-MD5 option, eg OpenBSD, would be
accepted).

> Under unauthenticated TCP, we're considerably less sure that the
> message we receive accurately reflects the state of our peer.

indeed, but this is outside the remit of BGP really.

> Thus I'd tend to keep the full baggage of the NOTIFY.

Why? The close of the connection in itself should raise an event on
the peer.

> (Note that, by my understanding, the new TCP connection will be
> distinct from the old one; the NOTIFY will be sent on the old one,

It would be sent on the connection which is to be discarded.

> assuming it is -- on our end -- in a state capable of sending one.
> If the other end has indeed forgotten it, regular timeouts should
> work.)

NOTIFY is not a 'valid' event on any connection on which collision
avoidance needs to be done. When c.av. is done neither side should
have progressed past OpenConfirm.

Though, yes, that patch needs testing.

> --
> John Leslie <john@jlc.net>

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Crazee Edeee, his prices are INSANE!!!

Mailing List Archive

Mailing List Archive

Attached Files: