quick bit of context so my question makes sense:
I've been asked to plan out some subnets and routing for a new IP range we've just been allocated. The range will be used to customer's equipment (on IPs allocated out of this range) to peering providers.
</context>
Every routing example I've seen appears to revolve around one central "Core" router, which connects to all the other networks and routers. This would leave me with a setup looking something like this
Full diagram at http://www.gliffy.com/go/publish/6360724
To me, this would seem to have a few disadvantages, namely a single point of failure, and wasting 2 IPs for each additional connection. That lead me to come up with this:
Full diagram at http://www.gliffy.com/go/publish/6360825
In theory, this makes better use of the IP ranges, and has fewer single points of failure. Can anybody suggest why the first set-up seems preferable, even with it's seemingly obvious faults?
Thanks!
Best Answer
With your "one big /24" solution, each client router will need to make a decision of which upstream peering router to send traffic to, so they would either need to carry full internet routes or use some other (e.g. policy-based) method to make a decision.
With your "one big core router" solution, each client router simply needs to have a default route pointing to the one big core router, which in turn will make the upstream routing decision.
Of course, I wouldn't recommend having just "one big core router", but would prefer to see "two big core routers" instead. Each client router can then be dual-homed to those two big core routers, providing the necessary redundancy (both for connectivity and routing) when there is a core router failure.