Re: [j-nsp] BGP full mesh or route reflector

--b1=_FPwY7YAZfXmAHciBikWzf5s3004Nk2Ph9rurJmU8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Friday, 5 December 2025 at 13:35, Johan Borch via juniper-nsp <juniper-n=
[email protected]> wrote:
> Hi!
>
> In an SR/MP-BGP underlay, will it have a significant impact on device
> performance if we use a full iBGP mesh instead of route reflectors or oth=
er
> drawbacks? Let=E2=80=99s say we will end up with around 100 PE routers. T=
hese
> routers will not carry an excessive number of prefixes (no full tables).
> We can ignore the configuration part as configuration is auto-generated.

Hi Johan,

There are also a lot of variables to consider. But it can work for sure. To=
 provide you with some data points of working setups...

Based on your description, if you're running a private MPLS network with on=
ly internal/private routes it's fine, 100 PEs in full mesh is fine. I've ru=
n a 100 PE network using Cisco ME3600s/ME3800s, in a full iBGP mesh, no pub=
lic routing, just a fully private MPLS network providing private L3 VPNs, w=
ith maybe 1000 routes.

That's going back some years (Cisco ME3600/3800!) and they had/have tiny li=
ttle single core PPC CPUs (if my memory is correct). CPU usage was consiste=
ntly low though due to low route scale and minimal route churn. Also ran fu=
ll mesh RSVP back then, also fine due to such low scale and low churn.

Later I remember running a similar sized network, again full mesh, with ASR=
9001s, quad-core PPCs. Absolutely rubbish CPUs by today's standards, but wh=
en you have so few routes and so little churn, it's no problem.

At my currently employer we run an ISP/carrier network, with 9M paths in BG=
P RIB. This is also nearly 100 PEs with a full iBGP mesh. We wanted to depl=
oy this network with RRs from day 1, but we run everything in EVPN and we w=
anted to use ORR, and we had to wait for our vendor to support ORR for EVPN=
. They implemented it, and our migration to virtual RRs using EVPN ORR is n=
early done now (all PE > RR iBGP sessions up, RR > RR sessions up), last st=
ep is to remove the band aid which makes the PE -> RR BGP sessions less pre=
ferable and start stripping away the iBGP full mesh.

But up until now, the devices have been fine. It's 2026 (just about), route=
rs these days have 64GBs of RAM and a 6 core / 12 thread AMD Ryzen at > 3Gh=
z. They eat BGP routes for breakfast (we're an Arista shop, these are 7280R=
3 "-A" models).

With the number of paths we have rapidly increasing, and the number of PEs =
also rapidly increasing, in this case, this isn't going to scale for long, =
and we knew from day one we'd need to get to RRs, so RRs were always planne=
d, we just had to wait for vendor support. But it's been fine until now. In=
 the previous networks I mentioned, RRs were never planned due to low route=
 scale and low route churn, and they were also fine.

Also considering some other factors; I have worked on networks handling eme=
rgency call routing, air traffic control, and other sensitive traffic. With=
 a full iBGP mesh, convergence is at it's quickest (depending on the update=
 groups); interface goes on router A, it informs router B directly, immedia=
tely. With RRs, a withdraw is processed as fast as your slowest RR because =
all RRs need to withdraw the route before the PE finally drops the route. O=
n the current network I work, due to the large geographical scale (and exha=
usting the number of ORR groups our vendor supports) we have multiple RR gr=
oups peered together, and with millions of paths, convergence won't be fast=
.

There are always pros and cons, just gotta find the gotchas (or turn your p=
ager off!).

Cheers,
James.
-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsG5BAEBCgBtBYJpcIB2CRCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0
aW9ucy5vcGVucGdwanMub3JnxT15AhT40hHyKYLX7KMqjtHuixVlCXI43DKy
iLEgdeQWIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAA680QAKqcD/c9XPW6qsNn
h1ZsgOfM0LsOh4xFhqkSE+zw5Fmzngj8h1OR9XuZR7/ytJZUJUEla/BJduzg
/mwYGUZodAwfpFaB5cDQRiBxg/E+D7j/wi0xo9nPGcskwkNNZZiZ+gy2Cujv
AXWAcM0YrtJKxDeW3iMQD6zy/7NFGtiB61b6B0ET9cv1g9modsXXpnKqG26e
pE1UGqlYfF5l6OpP/JclxRYLaPPahJJ8Rty3X7hoxmUNDqhPdDmyE7OcZUAa
S9wDZ6a0Ni0bfuMhwm0Y7ZkBZTLXWiJ/a0+2s1oNRIPV4modulCyTsgv3UYy
r/mwPat8HUwWApIY46+2W5dFVDjCYSE07vX409L2d9mQ78s78z2PQuJUGAQL
e7f+xS3+LO9XTNCK57Lub4wyDKwHbDrqT+d8WQlBNaQAtamuPyvGJxeGi8Pt
R+f9FJzbcTGUgcYHJOfRTMOneE4Jgh3w0o9PivNSHOlYTkfZ/4dLr0Pdg3xr
orhjx6PKUebnrd6Sk12zqRbVNchqiIsooivax9x5nGmXbR/w0xqceSmjwhqg
YPGVyhwxwZodcIQd/zxBrVz09ggUjVhd6kEyTNXR4qNQNY3aQEyqVuD0NXH7
xhAf1iieytLCH9LN608DRjDUBOzD+oBwZK9y/5zNswf6/DaBVdj2sYDVaL48
XT+lLj8Y
=3DxScD
-----END PGP SIGNATURE-----

--b1=_FPwY7YAZfXmAHciBikWzf5s3004Nk2Ph9rurJmU8
Content-Type: application/pgp-signature; name="publickey - [email protected] - 0x3E936359.asc.sig"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="publickey - [email protected] - 0x3E936359.asc.sig"

wsG5BAABCgBtBYJpcIB2CRCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0aW9ucy5vcGVucGdw
anMub3Jn503BwtBjOp7aR7MdlIvN96qiSjfLKZ+W4gTUkwr9wO0WIQQ+k2NZBObfK8Tl7sKoEx+i
gX+A+wAA8kUQAKYSaVgKQZ07gmphB0IXrEmtT9eD0kabaGyteo3fxVgzt6DeSIAmhmmRFrrF4bVy
opRT0q7D2C8HXZiUV8sqo3+WgRDvA4rRw4Fj1yIslZ7etiPEoTaBIRTUs5lrognZactAgmXLw9zw
cpc9FfXF80nx7ssQRR7dHuT/LpJJ/FQhtvNSXUpz3CNnshSofH2heVhwVQ/H7sQ+/1gHe84kBAd8
Yo4Qk0dxD9mttb8nk9b0hx3DA9OY0Gyo4QwIafY1MHvsFQOqqZEcLYmGQptGR4N6EKAzbeIfstud
el6fY4A6dmcmeR5d0sl/EYG8JWBic0jCIrgIvj3rXxwGeZmPaypx++eJMGEd89BHl2QJc1lH4APQ
y56PGlw3waylyESWPociKTpIpN/n2p0kSNi0E8ZChTebg7LSH86MP9lwFXYp1KoVQfkuTnRXhpxp
/XazBrdcVU5/7XSAcCGVsv+3OUcBfxRez4n3aPCdtwbO3HU2svQZtRpb8WA9h6ZD6hukkVUdsniA
Om9KBO6FD0TVLTsaK3+NE4lg1uPKdtjHrWXZI/5Xchufz6nILB4sEox027f98bjPeDDQDcyECsgY
GHANIB0AzyMuGhMyw5y9G2s898TvgoqZgJhZnQOikNZJxzBrp/EauYSNwaQkyLq0Be0kuiQajUNW
lrOH6ub9K4nA

--b1=_FPwY7YAZfXmAHciBikWzf5s3004Nk2Ph9rurJmU8
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KanVuaXBlci1u
c3AgbWFpbGluZyBsaXN0IGp1bmlwZXItbnNwQHB1Y2submV0aGVyLm5ldApodHRwczovL3B1Y2su
bmV0aGVyLm5ldC9tYWlsbWFuL2xpc3RpbmZvL2p1bmlwZXItbnNwCg==

--b1=_FPwY7YAZfXmAHciBikWzf5s3004Nk2Ph9rurJmU8--