Claudio Jeker(cje...@diehard.n-r-g.com) on 2021.04.28 12:40:46 +0200: > 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.
reads ok benno@ > -- > :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) >