On 27 June 2019 16:31:27 BST, Mark Tinka <mark.ti...@seacom.mu> wrote: > > >On 27/Jun/19 14:48, James Bensley wrote: > >> That to me is a simple scenario, and it can be mapped with a >> dependency tree. But in my experience, and maybe it's just me, things >> are usually a lot more complicated than this. The root cause is >> probably a bad design introducing too much complexity, which is >> another vote for smaller PEs from me. With more service dedicated PEs >> one can reduce or remove the possibility of piling multiple services >> and more complexity onto the same PE(s). > >Which is one of the reasons we - painfully to the bean counters - >insist >that routers are deployed for function. > >We won't run peering and transit services on the same router. > >We won't run SP and Enterprise on the same router as Broadband. > >We won't run supporting services (DNS, RADIUS, WWW, FTP, Portals, NMS, >e.t.c.) on the same router where we terminate customers. > >This level of distribution, although quite costly initially, means you >reduce the inter-dependency of services at a hardware level, and can >safely keep things apart so that when bits fail, you aren't committing >other services to the same fate. > >Mark.
Agreed. This is worked well for me over time. It's costly in the initial capex out-lay but these boxes will have different upgrade/capacity increase times and price points, so over time everything spreads out. Massive iron upgrades require biblical business cases and epic battles to get the funds approved. Periodic small to medium PE upgrades are nicer on the annual budget and the forecasting. Cheers, James.
