Mailing List Archive

[Bug 19] from time to time bgpd session go idle
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.quagga.net/show_bug.cgi?id=19





------- Additional Comments From cristian_dimache@rtanet.ro 2005-06-08 11:31 -------
sh thread cpu
Runtime(ms) Invoked Avg uSecs Max uSecs Type Thread
151.977 633 240 5000 R bgp_read
0.999 13 76 999 R zclient_read
0.000 6 0 0 R vtysh_accept
4.999 7 714 2000 R bgp_accept
2.000 13 153 1000 T bgp_connect_timer
39.994 637 62 21996 E bgp_event
341.945 49 6978 282957 R vtysh_read
0.000 56 0 0 T bgp_keepalive_timer
0.000 1 0 0 E zlookup_connect
1.999 118 16 1999 T bgp_routeadv_timer
0.000 1 0 0 E zclient_connect
181.973 28 6499 8998 T bgp_scan
1.000 1 1000 1000 R vty_accept
6.999 52 134 1000 W vty_flush
2.000 51 39 1000 R vty_read
17.998 221 81 2000 W bgp_write
1.000 116 8 1000 T bgp_import
0.000 4 0 0 T bgp_start_timer
754.883 2007 376 282957 RWTEX TOTAL





------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 19] from time to time bgpd session go idle [ In reply to ]
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.quagga.net/show_bug.cgi?id=19





------- Additional Comments From paul@dishone.st 2005-06-08 11:52 -------
Does the problem go away if one of the peers is set to 'passive'?



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 19] from time to time bgpd session go idle [ In reply to ]
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.quagga.net/show_bug.cgi?id=19





------- Additional Comments From cristian_dimache@rtanet.ro 2005-06-08 21:44 -------
Yes, it dows go away if one peer (the one that does not accept connections on
179, logically) is set to passive.
Maybe the problem is in listening on more than two interfaces...I have three bgp
peers, on three sepparate interfaces...the third interface works only as passive...



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 19] from time to time bgpd session go idle [ In reply to ]
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.quagga.net/show_bug.cgi?id=19





------- Additional Comments From paul@dishone.st 2005-06-08 22:00 -------
Ok, I know the problem so.

It's down to perennial problems around the BGP 'dummy peer' for FSM for accepted
connections. We need to clean this up at some stage and seperate per-connection
state from peer state. At the moment we have 1 connection per peer and we hack
up a 'dummy peer' for accepted connections, which we delete once the connection
gets past OpenSent. This makes our collision detection and FSM fragile I think.
FSM should be per /connection/, and a peer can have multiple connections going
(well, two - pre-Established).

Further, we don't have a backoff timer for sending Open's, plus, iirc, we will
immediately send an Open if we receive one (if we havn't yet). This tends to
have a latching effect and cause peers to synchronise their state machines and
exacerbate collision-detection problems.

I dont have a quick fix for this, other than to use 'passive' on one side. The
connection information needs to be fixed, which is a biggish job.




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.