Peering/Transit eBGP sessions -pet or cattle?

Sun Feb 16 11:41:29 UTC 2020

On 10/Feb/20 14:37, adamv0025 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200216/19ae1a67/attachment.html>