On 10/Feb/20 14:37, adamv0025@netconsultings.com wrote:

The “cattle” case:
Or would you instead rely on small-ish non-redundant HW at your internet edge rather than trying to enhance MTBF with big chassis full of redundant HW?

Is this cause eventually the MTBF figure for a particular transit/peering eBGP session boils down to the MTBF of the single card or even single optical module hosting the link, (and creating bundles over separate cards -well you can never be quite sure how the setup looks like on the other end of that connection)?

Or is it because the effects of a smaller/non-resilient border edge device failure is not that bad in your particular (maybe horizontally scaled) setup?

This, for us.

We pick up transit and peering in multiple cities around the world. The cute boxes at the time were the MX80 and ASR9001. These have since run out of steam for us, and in many sites, our best option was the MX480, as there was no other high-performance, non-redundant device that made sense to us.

However, just months after upgrading to the MX480, the MX204 launched. So now, we focus on the MX204 for peering and transit.

It's so massively distributed that it doesn't make sense to aggregate multiple exchange points or transit providers in a single location. And if a device in one location were to fail, there is sufficient coverage across the backbone to pick up the slack. We also use separate devices for transit and peering.

Of course, transit providers (and some exchange points) don't really enjoy this model with us, as they'd like to sell us a multi-site contract, which doesn't make any sense to us.

Mark.