From c7aa8abd8788c3607ad0131f02e892cf92221e40 Mon Sep 17 00:00:00 2001 From: Dmitrij Tejblum Date: Fri, 14 Jan 2011 18:27:05 +0300 Subject: bgpd: fix handling of "Unsupported Capability" * bgp_packet.c: (bgp_notify_receive) justify the difference between BGP_NOTIFY_OPEN_UNSUP_PARAM and BGP_NOTIFY_OPEN_UNSUP_CAPBL cases, as it is explained in RFC5492, page 3, paragraph 1. "Unsupported Capability" error does not mean, that the peer doesn't support capabilities advertisement -- quite the opposite (if the peer would not support capabilities advertisement, the code would be "Unsupported Optional Parameter"). Thus there is no reason to mark the peer as one non-supporting capabilities advertisement. Example: suppose the peer is in fact IPv6-only, but we didn't configure anything address-family specific for it. Then, the peer would refuse the session with "Unsupported Capability" code. If we internally set the peer as non-supporting capabilities advertisement after that, we will not be able to establish the session with it ever, even with a fixed configuration -- IPv6-only BGP session cannot be established without capabilities. In practice an edge case would be seen as the same IPv6 peer working with its "neighbor" block read from bgpd.conf, but not working, when slowly input in "conf t" mode. --- bgpd/bgp_packet.c | 6 ------ 1 file changed, 6 deletions(-) (limited to 'bgpd/bgp_packet.c') diff --git a/bgpd/bgp_packet.c b/bgpd/bgp_packet.c index a5f9552c..9102add7 100644 --- a/bgpd/bgp_packet.c +++ b/bgpd/bgp_packet.c @@ -1885,12 +1885,6 @@ bgp_notify_receive (struct peer *peer, bgp_size_t size) bgp_notify.subcode == BGP_NOTIFY_OPEN_UNSUP_PARAM ) UNSET_FLAG (peer->sflags, PEER_STATUS_CAPABILITY_OPEN); - /* Also apply to Unsupported Capability until remote router support - capability. */ - if (bgp_notify.code == BGP_NOTIFY_OPEN_ERR && - bgp_notify.subcode == BGP_NOTIFY_OPEN_UNSUP_CAPBL) - UNSET_FLAG (peer->sflags, PEER_STATUS_CAPABILITY_OPEN); - BGP_EVENT_ADD (peer, Receive_NOTIFICATION_message); } -- cgit v1.2.1