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