I see no reason for it to be able to do so, in fact I would expect it to be optimized for the exact opposite - a routing table with less than a hundred routes.
Stuffing a DFZ table into a Windows box is… not something you do. Neither Microsoft nor Windows admins would really even consider it a viable idea.
The real question is: how does it fail? In the best case, it just drops a little bit of networking performance due to lookups taking a tiny amount of time on each packet. In the worst case, not only do the lookups take forever, but it might also cause overall lockups and "hard" degradation due to cascade effects from the network stack spinning to its death on each single packet.
But considering Windows servers are used as VPN endpoints, and those need to support at least some 4-digit route table sizes, it can't be entirely bad. My expectation would be just mediocre network performance without huge overall disruption.
Hey, can you point me to where you were finding this? I'd very much like to try it out this weekend and that might help - I've got a personal ASN and carrier link I can exchange the actual internet table on. The only thing I could find was people receiving the "full route tables" of a private cloud instance not the net.
The question is about the FIB side of the equation. It’s not an anti-windows remark it’s just a question since I’ve never done full tables on Windows and I don’t know it to be a supported use case. The BGP feature in Server versions is intended for cloud gateway not internet. Even the Linux kernel takes some parameter tuning to gracefully receive a full table without complaints. It’s a million routes in systems which typically have less than 10 after all.
Supporting BGP and supporting BGP with a DFZ full table are not the same thing. And achieving a particular packet/line rate in either of those scenarios is yet another.
Maybe check your own knowledge base, background and perspective before calling something shitposting?