You should be advertising /32's and /128's. From the hypervisor to the TOR, then the TOR aggregates if possible and advertises to a spine. At least, that's wha

You should be advertising /32's and /128's. From the hypervisor to the TOR, then the TOR aggregates if possible and advertises to a spine. At least, that's what you do if you use Calico and want to be able to use hypervisor migration when using it with OpenStack. Just make sure your TOR's can handle the amount of routes necessary, have a default route from the hypervisor to the internet, and from the TOR to the spine, and have the spine advertise a 0's route. So now the spine is the only place where you need beefier routers that can support more than the TOR's in terms of routes. With some intelligence in the IPAM solution your host will get a /26 (or a /64) and will advertise that entire range, and only a single /32 is advertised if the VM/container moves to another hypervisor host (to support things like live-migration). That being said, most TOR's can handle quite a large amount of routes these days. When I was at a telco we had some gear that did up to 128k routes, so splitting between IPv4/IPv6 we had 64k routes each. Which is plenty, even for larger clusters.