modified on 12 sty 2010 at 09:10 ••• 4 251 views

Przeciekanie tras VRF

Z MikroTik Wiki

Wymagane pakiety: routing-test, mpls-test, RouterOS wersja 3.25+

Spis treści

Opis

W sieci MPLS z wieloma klientami może okazać się przydatna funkcja przeciekania tras między VRF. Klasycznym wykorzystaniem tej funkcji jest przeciekanie łącz/sieci do zarządzania VRF, lub przydzielaniem adresu zarządzającego do routerów CE jako adresu /32. Innym wykorzystaniem byłoby przeciekanie publicznych adresów IP do oddzielnych VRF, aby mogły być obsługiwane przez inny router niż adresy LAN. Należy przefiltrować wyciekanie tras aby upewnić się, że przeciekają tylko adresy nie nachodzące na siebie. Ważne jest upewnienie się, że VRF nie ma dostępu do tras do innych VRF. Realizuje się to poprzez filtry routingu i filtrowania wychodzących tras VRF dodanych w RouterOS wersji 3.25.

Diagram przykładowy

Image:Leaking-routes.png

W tym przykładzie mamy dwóch klientów VRF jak i zarządzanie VRF. Zakładamy, że każdy klient VRF potencjalnie będzie mieć nachodzące na siebie adresy IP. Jednakże adresy łącz nie nachodzą na siebie. VRF są zagregowane w routerze PE1, a punktem wyjściowym sieci jest PE2, w do którego podłączony jest także system zarządzania siecią. Systemem zarządzającym może być The Dude lub inne oprogramowanie NMS.


Konfiguracja VRF

Najpierw spójrzmy jak skonfigurowane są VRF na PE1:

/ip route vrf add routing-mark=red route-distinguisher=111:500 import-route-targets=111:500,111:999 export-route-targets=111:500 interfaces=ether1.500
/ip route vrf add routing-mark=green route-distinguisher=111:600 import-route-targets=111:600,111:999 export-route-targets=111:600 interfaces=ether1.600

Powyższe polecenia określają, że trasy poznane z czerwoengo VRF będą w tym PE oznaczone przez BGP extended community 111:500 i eksportowane z tym samym numerem. VRF importuje trasy z numerami 111:500 i 111:999. 111:999 będą importowane aby dla routera był osiągalny zarządzający VRF. To samo dotyczy zielonego VRF.

/routing bgp instance vrf add instance=default routing-mark=red redistribute-connected=yes redistribute-ospf=yes redistribute-static=yes out-filter=red-out
/routing bgp instance vrf add instance=default routing-mark=green redistribute-connected=yes redistribute-ospf=yes redistribute-static=yes out-filter=green-out

Tu nie dzieje się nic niezwykłego, tylko określono, że każdy VRf będzie używał filtru wyjściowego.

Zarządzający VRF będzie skonfigurowany na PE2 jak poniżej:

/ip route vrf add routing-mark=management route-distinguisher=111:999 import-route-targets=111:999,111:1000 export-route-targets=111:999 interfaces=ether1.999
/routing bgp instance vrf add instance=default routing-mark=management

Czerwony i zielony VRF będą skonfigurowane ze standardowymi ustawieniami. Zauważ dodatkową community którą importuje zarządzajćcy VRF. Używana jest, aby trasy klienta były trzymane oddzielnie z community, które eksportuje zarządzająct VRF.

Filtry routingu

Na PE1 ustawimy filtry red-out i green-out:

/routing filter add chain=red-out match-chain=connected-in append-route-targets=111:1000 action=passthrough
/routing filter add chain=green-out match-chain=connected-in append-route-targets=111:1000 action=passthrough

Filtry dopasowują wszystkie trasy pewnego typu w VRF (np adresy łącz) i przydzielają im numery 111:1000. Na PE2 te trasy będą importowane do zarządzającego VRF.

W zasadzie obydwa filtry są takie same, ale wierz mi, lepiej jest mieć oddzielne łańcuchy od samego początku, niż rekonfigurować wszystko, gdy musisz zastosować dodatkowe reguły dla jednego VRF.

Konfiguracja z zarządzaniem pętlą zwrotną

Powyższa konfiguracja zakłada, że Twoje adresy łącz są unikalne. Jeśli nie są, możesz uzyskać taki sam efekt poprzez dodanie interfejsu pętli zwrotnej (np. mostek bez członków). Dystrybuuj adres /32 do wszystkich routerów CE, którymi chcesz zarządzać. Polecane jest użycie publicznych adresów IP lub adresów, które jesteś pewien, że żaden z klientów nie będzie używać - np. 198.18.0.0/15. Następnie musisz dopasowywać sieć za pomocą filtrów routingu,.