modified on 11 sty 2010 at 11:40 ••• 9 830 views

Wirtualny Routing i Forwarding

Z MikroTik Wiki

Wymagane pakiety: routing-test, mpls-test

Spis treści

Opis

RouterOS 3.x pozwala na utworzenie wielu wirtualnych instancji routujacych i forwardujących na pojedynczym routerze. Jest funkcja użyteczna dla MPLLS VPN opartego o BGP. W przeciwieństwie do BGP VPLS, które jest technologią warstwy 2 modelu OSI, BGP VRF VPN pracuje na warstwie trzeciej, ponieważ wymienia prefiksy IP pomiędzy routerami. VRF rozwiązuje ten problem poprzez nadpisywanie prefiksów IP i zapewnianie prywatności (poprzez oddzielny routing dla różnych VPN).

Konfiguracja potrzebna do stworzenia VRF znajduje się w menu /ip route vrf. Możesz dodać nowe trasy do VRF poprzez określenie atrybutu routing-mark. Trasy z interfejsów należących do VRF zostaną automatycznie umieszczone w odpowiedniej tablicy routingu.

Technicznie, VRF oparty jest o politykę routingu. Jest dokładnie jedna tablica polityki routingu na każdy aktywny VRF. Istniejąca obsługa polityki routingu w MT RouterOS nie jest zmieniana; ale z drugiej strony nie ma możliwości posiadania polityki routingu wewnątrz VRF. Głównymi różnicami pomiędzy tablicami VRF a prostą polityką routingu są:

  • Trasy w tablicach VRF domyślnie resolvują następne skoki ze swoich tablic rotingu, podczas gdy trasy polityk zawsze używają głównej tablicy routingu. Atrybut trasy tylko do odczytu gateway-table wyświetla informację o tym, która tablica jest używana dla poszczególnej trasy (wartością domyślną jest main).
  • Inne jest wyszukiwanie trasy. Dla polityki routingu: po zakończeniu wyszukiwania trasy w tablicy polityki routingu i nie znalezieniu żadnej, następuje przeszukiwanie głównej tablicy routingu. Dla VRF: po zakończeniu przeszukiwania i nie znalezieniu trasy w tablicy VRF, wyszukiwanie jest nieudane ze zwracanym błedem "network unreachable". (Możesz zmienić takie zachowanie własnymi regułami wyszukiwania)

Możesz użyć wieloprotokołowego BGP z rodziną adresów VPNv4 aby dystrybuować trasy z tablic routingu VRF - nie tylko do innych routerów, ale także do innych tablic routingu wewnątrz routera. Najpierw ustaw rozróżnianie tras dla VRF. Można to zrobić w /ip route vrf. Zazwyczaj będzie to odnośnik jeden-do-jednego pomiędzy rożróżniaczem trasy a VRF, ale nie jest to jedyna opcja. Umieszczanie trasy w tablicach VRF jest kontrolowane przez atrybut BGP extended communities. Skonfiguruj listy importu i eksportu w /ip route vrf, import-route-targets i export-route-targets. Lista docelowa eksportu trasy dla VRF powinna zawierać przynajmniej jeden rozróżniacz trasy dla tego VRF. Następnie ustaw listę VRF dla każdej instancji BGP biorącej udział w routingu VRF.

Po ustawieniu list VRF dla instancji BGP, rozróżniacza trasy i eksportu tras, można utworzyć trasy aktywnej rodziny adresów VPNv4, w zależności od ustawień redystrybucji BGP. Instalowane są w oddzielnych tablicach routingu i jeśli obecne, widoczne są w /routing bgp vpnv4-route. Te tak zwane trasy VPNv4 mają prefiks składający się z rozróżniacza trasy i prefiksu sieci IPv4. W ten sposób nadpisuje się prefiksy IPv4 dystrybuowane w BGP.

Trasa VPNv4 będzie dystrybuowana tylko jeśli posiada poprawną etykietę MPLS. Musisz zainstalować pakiet mpls-test i ustawić odpowiedni zakres etykiet. (Domyślna konfiguracja ma odpowiedni zakres etykiet.)

Przykłady

Najprostsza konfiguracja MPLS VPN

Image:l3vpn-simple.png

W tym przykładzie stworzony jest już podstawowy szkielet MPLS (składający się z dwóch routerów brzegowych providera PE1 i PE2) oraz skonfigurowany tak, aby przekazywał ruch pomiędzy routerami brzegowymi klienta CE1 i CE2, należącymi do VPN cust-one.


CE1 Router

/ip address add address=10.1.1.1/24 interface=ether1
# use static routing
/ip route add dst-address=10.3.3.0/24 gateway=10.1.1.2

CE2 Router

/ip address add address=10.3.3.4/24 interface=ether1
/ip route add dst-address=10.1.1.0/24 gateway=10.3.3.3

PE1 Router

/interface bridge add name=lobridge
/ip address add address=10.1.1.2/24 interface=ether1
/ip address add address=10.2.2.2/24 interface=ether2
/ip address add address=10.5.5.2/32 interface=lobridge
/ip route vrf add disabled=no routing-mark=cust-one route-distinguisher=1.1.1.1:111 \
    export-route-targets=1.1.1.1:111 import-route-targets=1.1.1.1:111 interfaces=ether1
/mpls ldp set enabled=yes transport-address=10.5.5.2
/mpls ldp interface add interface=ether2
/routing bgp instance set default as=65000
/routing bgp instance vrf add instance=default routing-mark=cust-one redistribute-connected=yes
/routing bgp peer add remote-address=10.5.5.3 remote-as=65000 address-families=vpnv4 \
    update-source=lobridge
 # add route to the remote BGP peer's loopback address
/ip route add dst-address=10.5.5.3/32 gateway=10.2.2.3

PE2 Router (Cisco)

ip vrf cust-one
 rd 1.1.1.1:111
 route-target export 1.1.1.1:111
 route-target import 1.1.1.1:111
 exit

interface Loopback0
 ip address 10.5.5.3 255.255.255.255

mpls ldp router-id Loopback0 force
mpls label protocol ldp

interface FastEthernet0/0
 ip address 10.2.2.3 255.255.255.0
 mpls ip

interface FastEthernet1/0
 ip vrf forwarding cust-one
 ip address 10.3.3.3 255.255.255.0

router bgp 65000
 neighbor 10.5.5.2 remote-as 65000
 neighbor 10.5.5.2 update-source Loopback0
 address-family vpnv4
  neighbor 10.5.5.2 activate
  neighbor 10.5.5.2 send-community both
  exit-address-family
 address-family ipv4 vrf cust-one
  redistribute connected
  exit-address-family

ip route 10.5.5.2 255.255.255.255 10.2.2.2

Efekt końcowy

Sprawdzenie czy działa redystrybucja trasy VPNv4:

[admin@PE1] > /routing bgp vpnv4-route print detail
Flags: L - label present
 0 L route-distinguisher=1.1.1.1:111 dst-address=10.3.3.0/24 gateway=10.5.5.3
     interface=ether2 in-label=17 out-label=17 bgp-local-pref=100 bgp-med=0
     bgp-origin=incomplete bgp-ext-communities="RT:1.1.1.1:111"

 1 L route-distinguisher=1.1.1.1:111 dst-address=10.1.1.0/24 interface=ether1
     in-label=16 bgp-ext-communities="RT:1.1.1.1:111"

Sprawdzenie czy 10.3.3.0 jest umieszczony na liście tras IP, w tablicy tras cust-one:

[admin@PE1] > /ip route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADC  10.1.1.0/24         10.1.1.2         ether1             0
 1 ADb  10.3.3.0/24                         10.5.5.3 recursi... 20
 2 ADC  10.2.2.0/24         10.2.2.2         ether2             0
 3 ADC  10.5.5.2/32         10.5.5.2         lobridge           0
 4 A S  10.5.5.3/32                         10.2.2.3 reachab... 1

Przyjrzyjmy się trasom IP w cust-one VRF. Prefiks IP 10.1.1.0/24 jest połączoną trasą należącą do interfejsu, który został ustawiony jako należący do cust-one VRF. Prefiks IP 10.3.3.0/24 jest rozgłaszan przez BGP jako trasa VPNv4 z PE2 i jest zaimportowana w tablicy routingu VRF, ponieważ import-route-targets jest zgodny z atrybutem BGP extended communities z którym był rozgłaszany.

[admin@PE1] /ip route> print detail where routing-mark=cust-one
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
 0 ADC  dst-address=10.1.1.0/24 pref-src=10.1.1.2 gateway=ether1 distance=0 scope=10
        routing-mark=cust-one

 1 ADb  dst-address=10.3.3.0/24 gateway=10.5.5.3 recursive via 10.2.2.3 ether2
        distance=20 scope=40 target-scope=30 routing-mark=cust-one
        bgp-local-pref=100 bgp-origin=incomplete
        bgp-ext-communities="RT:1.1.1.1:111"

To samo dla Cisco:

PE2#show ip bgp vpnv4 all
BGP table version is 5, local router ID is 10.5.5.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1.1.1.1:111 (default for vrf cust-one)
*>i10.1.1.0/24      10.5.5.2                      100      0 ?
*> 10.3.3.0/24      0.0.0.0                  0         32768 ?

PE2#show ip route vrf cust-one

Routing Table: cust-one
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 1 subnets
B       10.1.1.0 [200/0] via 10.5.5.2, 00:05:33
     10.0.0.0/24 is subnetted, 1 subnets
C       10.3.3.0 is directly connected, FastEthernet1/0

Powinieneś móc pingować CE2 z CE1 i na odwrót.

[admin@CE1] > /ping 10.3.3.4
10.3.3.4 64 byte ping: ttl=62 time=18 ms
10.3.3.4 64 byte ping: ttl=62 time=13 ms
10.3.3.4 64 byte ping: ttl=62 time=13 ms
10.3.3.4 64 byte ping: ttl=62 time=14 ms
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 13/14.5/18 ms

Bardziej skomplikowana konfiguracja (modyfikacja poprzedniego przykładu)

Image:l3vpn-two-customers.png

W tym przykładzie są dwaj klienci: cust-one i cust-two.

W takim razie należy ustawić dwa VPN, odpowiednio cust-one i cust-two i wymieniać między nimi trasy.

Nie jest to najbardziej typowa konfiguracja, ponieważ trasy zazwyczaj nie są wymieniane pomiędzy różnymi klientami. Domyślnie nie powinno się mieć dostępu z jednej strony VRF do innej strony VRF w innym VPN.(Jest to "prywatny" aspekt VPN.) Oddzielny routing jest sposobem zapewnienia prywatności; jest również wymagane rozwiązanie problemu nadpisywania prefiksów sieci IP. Wymiana trasy jest w bezpośrednim konflikcjie z tymi dwoma wymaganiami, ale czasami zachodzi potrzeba jej stosowania (np. rozwiązanie tymczasowe, gdy dwaj klienci migrują do pojedynczej sieci).

CE1 Router, cust-one

/ip route add dst-address=10.4.4.0/24 gateway=10.1.1.2

CE2 Router, cust-one

/ip route add dst-address=10.4.4.0/24 gateway=10.3.3.3

CE1 Router, cust-two

/ip address add address=10.4.4.5 interface=ether1
/ip route add dst-address=10.1.1.0/24 gateway=10.3.3.3
/ip route add dst-address=10.3.3.0/24 gateway=10.3.3.3

PE1 Router

# zamień stary VRF tym:
/ip route vrf add disabled=no routing-mark=cust-one route-distinguisher=1.1.1.1:111 \
    export-route-targets=1.1.1.1:111 import-route-targets=1.1.1.1:111,2.2.2.2:222 interfaces=ether1

PE2 Router (Cisco)

ip vrf cust-one
 rd 1.1.1.1:111
 route-target export 1.1.1.1:111
 route-target import 1.1.1.1:111
 route-target import 2.2.2.2:222
 exit

ip vrf cust-two
 rd 2.2.2.2:222
 route-target export 2.2.2.2:222
 route-target import 1.1.1.1:111
 route-target import 2.2.2.2:222
 exit

interface FastEthernet2/0
 ip vrf forwarding cust-two
 ip address 10.4.4.3 255.255.255.0

router bgp 65000
 address-family ipv4 vrf cust-two
  redistribute connected
  exit-address-family

Wariant: zamiana Cisco na drugi MT

Konfiguracja PE2 Mikrotik

/interface bridge add name=lobridge
/ip address
 add address=10.2.2.3/24 interface=ether1
 add address=10.3.3.3/24 interface=ether2
 add address=10.4.4.3/24 interface=ether3
 add address=10.5.5.3/32 interface=lobridge
/ip route vrf
 add disabled=no routing-mark=cust-one route-distinguisher=1.1.1.1:111 \
     export-route-targets=1.1.1.1:111 import-route-targets=1.1.1.1:111,2.2.2.2:222 \
     interfaces=ether2
 add disabled=no routing-mark=cust-two route-distinguisher=2.2.2.2:222 \
    export-route-targets=2.2.2.2:222 import-route-targets=1.1.1.1:111,2.2.2.2:222 \
    interfaces=ether3
/mpls ldp set enabled=yes transport-address=10.5.5.3
/mpls ldp interface add interface=ether1
/routing bgp instance set default as=65000
/routing bgp instance vrf add instance=default routing-mark=cust-one redistribute-connected=yes
/routing bgp instance vrf add instance=default routing-mark=cust-two redistribute-connected=yes
/routing bgp peer add remote-address=10.5.5.2 remote-as=65000 address-families=vpnv4 \
    update-source=lobridge
 # add route to the remote BGP peer's loopback address
/ip route add dst-address=10.5.5.2/32 gateway=10.2.2.2

Efekt końcowy

Wynik /ip route print jest teraz wystarczająco interesujący aby poświęcić mu uwagę.

[admin@PE2] /ip route> print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADb  10.1.1.0/24                        10.5.5.2 recurs... 20
 1 ADC  10.3.3.0/24        10.3.3.3        ether2             0
 2 ADb  10.4.4.0/24                                           20
 3 ADb  10.1.1.0/24                        10.5.5.2 recurs... 20
 4 ADb  10.3.3.0/24                                           20
 5 ADC  10.4.4.0/24        10.4.4.3        ether3             0
 6 ADC  10.2.2.0/24        10.2.2.3        ether1             0
 7 A S  10.5.5.2/32                        10.2.2.2 reacha... 1
 8 ADC  10.5.5.3/32        10.5.5.3        lobridge           0

Trasa 10.1.1.0/23 została odebrana od zdalnego peera BGP i umieszczona w obu tablicach routingu VRF.

Trasy 10.3.3.0/24 i 10.4.4.0/24 są również umieszczone w obu tablicach VRF. Każda jest połączoną trasą w jednej tablicy i trasą BGP w drugiej. Nie ma to nic wspólnego z byciem rozgłaszanym przez BGP. Są po prostu rozgłaszane do lokalnej tablicy tras PVNv4 i są lokalnie reimportowane. Route-targets w importowaniu i eksportowaniu określa, w których tablicach mają się znaleźć.

Można to wydedukować z ich atrybutów - nie mają zwyczajnych atrybutów BGP. (Trasa 10.4.4.0/24.)
[admin@PE2] /ip route> print detail where routing-mark=cust-one
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
 0 ADb  dst-address=10.1.1.0/24 gateway=10.5.5.2 recursive via 10.2.2.2 ether1
        distance=20 scope=40 target-scope=30 routing-mark=cust-one
        bgp-local-pref=100 bgp-origin=incomplete
        bgp-ext-communities="RT:1.1.1.1:111"

 1 ADC  dst-address=10.3.3.0/24 pref-src=10.3.3.3 gateway=ether2 distance=0 scope=10
        routing-mark=cust-one

 2 ADb  dst-address=10.4.4.0/24 distance=20 scope=40 target-scope=10
        routing-mark=cust-one bgp-ext-communities="RT:2.2.2.2:222"

Odwołania

RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)

MPLS Fundamentals, chapter 7, Luc De Ghein, Cisco Press 2006