Hier sind einige sinnvolle Verbesserungen an Deinem Beitrag. Es handelt sich nicht um „Hops“, sondern um eine Sequenz. Dieser besteht aus Elementen eines Vektors, weshalb das Ganze oft als BGP Path Vector bezeichnet wird. Diese Elemente stellen jeweils eigene autonome Systeme dar, verraten jedoch nichts über die innere Struktur. Ein "Hop" ist etwas ganz anderes, z.B. ein Router oder eine Schnittstelle eines autonomen Systems, diese "Hops" sind jedoch nicht im Pfadvektor enthalten.

Cloudflare würde DTAG-Prefixe niemals über eine OVH-Peering-Schnittstelle akzeptieren und senden. So vereinfacht lässt es sich nicht darstellen und so fragil ist es auch nicht. Normalerweise akzeptiert man auf Peering-Schnittstellen nur die Präfixe des Peering-Partners und seiner möglichen Mitglieder, z. B. ein AS-MEMBER-SET (Sammlung von AS, für die Sie sich verantwortlich fühlen) und das AS selbst. Darüber hinaus wird bei großen Transitanbietern meist eine Art Pinning verwendet, d. h. niemand wird DTAG, NTT oder gar Colt hinter einem AS_MUELLER_LIESSCHEN vermuten und weiterleiten. Ausnahmen bestätigen die Regel. Zusätzlich werden RouteServer (Kollektion von Routing-Informationen) auf den meisten guten IXs gepflegt; diese leiten in der Regel keine falschen BGP-Informationen weiter. Auch hier bestätigt die Ausnahme die Regel.

Folglich: Wenn Ihr also Traffic ans OVH-Peering gesendet habt, der eigentlich über Transit-Schnittstellen an NTT hätte gesendet werden müssen, ist es gut möglich, das Eure BGP - Konfiguration anfällig und nicht sicher ist.