Filters for decentralised networking

[Nico Schottelius]

Hello everyone,

I was wondering how you typically handle announcing
a decentralised infrastructure to its upstreams / the Internet and how
you handle receiving your own routes again on other upstreams.

The scenario is as follows:

CUSTOMER
PEERINGS 1     ------ AS P6 --- CUSTOMER PEERINGS 2
 |            /
 |           /
AS P5 ---- AS P10 --- UPSTREAM 1
 | \      /     \
 |   AS P7---\   \
 |------------ AS P15 --- UPSTREAM 2
                   \ ---- UPSTREAM 3
                   \ ---- UPSTREAM 4


So essentialy the different AS are somewhat connected internally (*) (not
full mesh due to physical constraints) and the objective is to
announce all internal and all customer peerings to all upstreams.


Do you

a) use sophisticated filters including path length / specific ASN
   entries to announce to upstreams?

   One particular issue this approach is that the path lengths vary a
   bit, depending on where you are and where the upstream is and whether
   it's a customer announced route or an internally (*) announced one.

b) use a separate routing table that you announce fully to the
   upstreams?
c) do something completely differently?

And what is your approach to prevent receiving and re-announcing
your own (*) routes from upstreams? From my perspective sometimes it might
be better to use the upstream for internal routes, if the internal
network has trouble, but re-announcing it to the outside is certainly
not wanted.

Looking forward to read how you solve this in your setups!

Best regards,

Nico

(*) With "own" and "internal" I do not refer to iBGP, as the network
consists of multiple AS, all carrying an individual ASN
themselves. While they are all controlled by us, they are using eBGP
between the different locations.


--
Sustainable and modern Infrastructures by ungleich.ch