Kolega próbuje wdrożyć aktywny / pasywny internet multihoming. Projekt wymaga wysłania społeczności (wymienionych poniżej) do pasywnego dostawcy w celu zmniejszenia lokalnych preferencji w zdalnych AS dla reklamowanych tras. Dokumentacja wielokrotnie stwierdza, że wspólnoty są przeznaczone do użytku klientów i nie jesteśmy klientem tych dostawców. Sądzę, że umożliwienie szerokiemu internetowi zmiany lokalnych preferencji stanowi ogromne zagrożenie bezpieczeństwa. Czy miałoby to szansę na śnieżkę w piekle, by faktycznie działało?
1273:70 cable and wireless plc local pref 70
2828:1507 xo local pref 70
3356:70 level3 local pref 70
3549:100 global crossing local pref 100
4323:80 twtelecom local pref 80
1299:50 teliasonera local pref 50
Odpowiedzi:
Jest mało prawdopodobne (ale nie niemożliwe), aby społeczności, które oznaczyłeś na swoich trasach, rozprzestrzeniły się poza twój górny odcinek. Większość dostawców usunie społeczności przed ponowną weryfikacją tras w górę / w dół.
Jeśli chcesz wpływać na wiele zdalnych AS w ten sposób, musisz użyć AS_PATH poprzedzającego. Przygotuj 2-3 razy dostawcę zapasowego / pasywnego, a wtedy większość / cały ruch popłynie twoją aktywną ścieżką, dopóki nie zawiedzie. Następnie ruch powinien zostać przesunięty na pasywną ścieżkę, gdy nieudana trasa zostanie wycofana.
źródło
Dostawca powinien mieć filtr przychodzący, aby upewnić się, że społeczności te są akceptowane tylko od klientów. Jeśli nie, to jest to problem dostawców.
Niektórzy dostawcy Tier1 akceptują tego rodzaju społeczności z dowolnego miejsca. Jest to oparte na RFC 1998: http://tools.ietf.org/html/rfc1998.html
źródło
Najlepsze, co zwykle możesz zrobić, to szukać społeczności u swojego dostawcy, które pozwalają wskazać dopłaty dla każdego dostawcy. Zakłada się, że Twój dostawca ma takie społeczności i relacje równorzędne, aby to działało. Przygotowywanie własnych ogłoszeń dla twojego partnera nie miałoby żadnych zmian w górę od twojego dostawcy. Chociaż ta metoda nie zmienia localpref jednego AS usuniętego od twojego dostawcy, ma podobny wpływ na to, że ta ścieżka z powrotem do ciebie jest mniej pożądana. Istnieje wyjątek od wpływania na localpref upstream, który opiszę na dole, chociaż prawdopodobnie jest to przypadek skrajny.
Niektórzy dostawcy, tacy jak XO [AS2828], umożliwiają reklamowanie prefiksów w taki sposób, że dostawca ogłasza trasy z określonymi dopłatami dla niektórych z nich.
Na przykład XO akceptuje:
2828:1108przygotowuje jeden raz dla AT&T przygotowuje2828:1207dwa razy dla Level32828:1303trzy razy wcześniej dla SprintW Savvis społeczność przygotowuje się
3561:30151do AT&T.Dostawcy ci zwykle mają społeczności wskazujące dobrze znane społeczności NO_EXPORT lub NO_ADVERTISE dla określonych partnerów.
Jeden dostawca poziomu 2, jaki znam, InterNAP, jest w stanie wpłynąć na localpref upstream, ponieważ kupuje tranzyt, więc jest klientem poziomu 1. Mają społeczności, z których możesz skorzystać, gdy próbują je przełożyć na określone społeczności poziomu 1 dla twoich reklam upstream, które ustawiają localpref na wartości równorzędne, średnie lub wysokie. Zobacz http://www.onesc.net/communities/as6993/Internap-Customer-Guide-1.3.pdf .
Przykładowe referencje:
Społeczności XO, które zmieniają ogłoszenia klientów na niektórych partnerów w AS2828 Border Savvis Przygotowują
atrybuty społeczności
Nie mam powiązań z dostawcami wykorzystanymi w przykładach innych niż bezpośrednie doświadczenie jako klient.
źródło