Arnoud Vermeer wrote:
Hi,
I found a bug while working on a route server implementation based on
OpenBGPD. I have a IPv6 session from OpenBGPD 4.4 (on OpenBSD 4.4,
routeertnix) to Quagga 0.99.5 (laborantix).
Hello Arnoud,
I'm running a native IPv6 session from OpenBGPD 4.4 to a Foundry of some
sort operated by my transit, so my experience below is not a duplicate
of your test, but I've included it for whatever it's worth.
I have multiple IPv4 peers, and multiple IPv6 peers in the setup. When I
start the BGP daemon, everything starts up nicely. All sessions come up.
Same here.
When I clear a IPv6 peering session, the connection shifts to the
Idle state. When I look in the log, I can see it connect and establish a
connection, but break as soon as a mistery update gets send out.
<<snip>>
Here is where I don't match your experience:
$ bgpctl sho nei 2001:470:1:53::1
BGP neighbor is 2001:470:1:53::1, remote AS 6939
Description: Hurricane_rtr0_v6
BGP version 4, remote router-id 216.218.252.162
BGP state = Established, up for 04w3d02h
Last read 00:00:10, holdtime 90s, keepalive interval 30s
Neighbor capabilities:
Multiprotocol extensions: IPv6 Unicast
Route Refresh
Message statistics:
Sent Received
Opens 1 1
Notifications 0 0
Updates 1 109606
Keepalives 86391 72742
Route Refresh 1 0
Total 86394 182349
Update statistics:
Sent Received
Updates 1 99044
Withdraws 0 22196
Local host: 2001:470:1:53::2, Local port: 179
Remote host: 2001:470:1:53::1, Remote port: 8028
$ bgpctl nei 2001:470:1:53::1 clear
request processed
$ bgpctl sho nei 2001:470:1:53::1
BGP neighbor is 2001:470:1:53::1, remote AS 6939
Description: Hurricane_rtr0_v6
BGP version 4, remote router-id 216.218.252.162
BGP state = Idle, down for 00:00:03
Last read 00:00:04, holdtime 240s, keepalive interval 80s
Message statistics:
Sent Received
Opens 1 1
Notifications 1 0
Updates 1 109632
Keepalives 86391 72742
Route Refresh 1 0
Total 86395 182375
Update statistics:
Sent Received
Updates 0 0
Withdraws 0 0
Last error: Cease
$ bgpctl sho nei 2001:470:1:53::1
BGP neighbor is 2001:470:1:53::1, remote AS 6939
Description: Hurricane_rtr0_v6
BGP version 4, remote router-id 216.218.252.162
BGP state = Active, down for 00:00:09
Last read 00:00:10, holdtime 240s, keepalive interval 80s
Message statistics:
Sent Received
Opens 1 1
Notifications 1 0
Updates 1 109632
Keepalives 86391 72742
Route Refresh 1 0
Total 86395 182375
Update statistics:
Sent Received
Updates 0 0
Withdraws 0 0
Local host: 2001:470:1:53::2, Local port: 179
Remote host: 2001:470:1:53::1, Remote port: 8028
$ bgpctl sho nei 2001:470:1:53::1
BGP neighbor is 2001:470:1:53::1, remote AS 6939
Description: Hurricane_rtr0_v6
BGP version 4, remote router-id 216.218.252.162
BGP state = Established, up for 00:00:08
Last read 00:00:08, holdtime 90s, keepalive interval 30s
Neighbor capabilities:
Multiprotocol extensions: IPv6 Unicast
Route Refresh
Message statistics:
Sent Received
Opens 2 2
Notifications 1 0
Updates 2 110178
Keepalives 86392 72743
Route Refresh 1 0
Total 86398 182923
Update statistics:
Sent Received
Updates 1 731
Withdraws 0 0
Local host: 2001:470:1:53::2, Local port: 179
Remote host: 2001:470:1:53::1, Remote port: 8119
$ uname -a
OpenBSD earth.raapid.net 4.4 GENERIC#1021 i386
$ bgpctl sho rib mem
RDE memory statistics
272868 IPv4 network entries using 8.3M of memory
1566 IPv6 network entries using 67.3K of memory
275328 prefix entries using 8.4M of memory
47567 BGP path attribute entries using 3.6M of memory
43683 BGP AS-PATH attribute entries using 1.6M of memory,
and holding 47567 references
4696 BGP attributes entries using 110K of memory
and holding 9090 references
4695 BGP attributes using 36.7K of memory
RIB using 22.2M of memory
When the NOTIFICATION is received, the peer is set back to the state
Idle, where the process starts again. The only way to break the cicle is
to restart the entire OpenBGPD daemon.
The only time I've had a session get "hung down" is once or twice when
running 4.3 and having made several bgpd.conf changes and issuing
"bgpctl reload" several times -- I believe it was regarding changing an
MD5 secret but I can't remember for sure. Either way, I eventually
restarted bgpd at that time and the sessions came right up, and I
haven't seen that behavior occur again after I upgraded to 4.4, but YMMV.
Cheers,
Tico
