At the moment bgpd will fall back to IPv4 unicast if there was no match in
the multiprotocol capabilities between local and remote peer.
This is not correct, if the router expects a certain AFI/SAFI for the
session then it should not fall back to IPv4 unicast.
An example is when bgpd uses IPv6 unicast for a session but the remote
side sends back IPv4 unicast. In that case the session would unexpectedly
fall back to IPv4 unicast.
The right behaviour in that case to estabilsh the connection but no
UPDATEs are exchanged since there is no matching AFI/SAFI pair.
This diff implements this. This is based on the fact that p->capa.ann.mp
(the capabilities we announced) will have something set if a multiprotocol
capability was inserted in the OPEN message. If nothing is set in
p->capa.ann.mp then the OPEN message did not include a multiprotocol
capability and the system needs to fall back to AF_INET since that is the
default.
This should help with systems that have silly defaults and annouce only IPv4
unicast on IPv6 sessions.
--
:wq Claudio
Index: session.c
===================================================================
RCS file: /cvs/src/usr.sbin/bgpd/session.c,v
retrieving revision 1.412
diff -u -p -r1.412 session.c
--- session.c 27 Apr 2021 09:12:23 -0000 1.412
+++ session.c 27 Apr 2021 15:13:19 -0000
@@ -2557,11 +2557,12 @@ capa_neg_calc(struct peer *p)
/* MP: both side must announce capability */
for (i = 0; i < AID_MAX; i++) {
- if (p->capa.ann.mp[i] && p->capa.peer.mp[i]) {
+ if (p->capa.ann.mp[i] && p->capa.peer.mp[i])
p->capa.neg.mp[i] = 1;
- hasmp = 1;
- } else
+ else
p->capa.neg.mp[i] = 0;
+ if (p->capa.ann.mp[i])
+ hasmp = 1;
}
/* if no MP capability present default to IPv4 unicast mode */
if (!hasmp)
