koniec wykładu VIII
przykład data client office + firewall depot management mapa z google map
POP points of presence SP data client POP POP office depot POP POP management
VPN warstwy 2 (VPLL, VPLS) i 3 (VPRN) SP SP
tunele MPLS (iv) VLL Virtual Leased Lines VPLS Virtual LAN Segments VPRN Virtual Private Routed Networks
tunele MPLS (iv) VLL Virtual Leased Lines VPLS Virtual LAN Segments VPRN Virtual Private Routed Networks
tunele MPLS (iv) VLL Virtual Leased Lines VPLS Virtual LAN Segments VPRN Virtual Private Routed Networks
drogi pakietów w sieci SP (backbone) data client office A management depot B
wirtualne łącza data client office A management depot B
selektywne rozgłaszanie podsieci data client PE 1 via PE3 PE 2 office A via PE2 PE 5 via PE3 PE 3 management PE 4 depot B
przykład - podsumowanie tylko routery brzegowe wiedzą o VPN ach (skalowalność) routery wewnętrzne kierują ruch na podstawie przynależności do wirtualnego łącza IP/IP, Generic Routing Encapsulation (GRE) tunnels, Layer 2 Tunneling Protocol (L2TP), IPSec, Multiprotocol Label Switching (MPLS). routery brzegowe selektywnie rozgłaszają dostępność podsieci w jednym VPN adresy muszą być unikatowe
RFC 4364 - abstract This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes.
wybrane dokumenty RFC VPRN (BGP/MPLS) VPN RFC4364 BGP/MPLS IP Virtual Private Networks 2006 RFC4026 Provider Provisioned VPN Terminology 2005 RFC4031 Service Requirements for Layer 3 Provider Provisioned VPNs (PPVPNs) 2005 RFC2917 A Core MPLS IP VPN Architecture 2000 sygnalizacja/routing/zarządzanie RFC4760 Multiprotocol Extensions for BGP-4 2007 RFC4577 OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) 2006 RFC4684 Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs) 2006 RFC4382 MPLS/BGP Layer 3 Virtual Private Network (VPN) MIB 2006
attachement circuits ingress/egress PE - provider edge P - provider CE - customer edge PE P PE VPN A site CE attachement circuit ATM (VCI/VPI) Ethernet (VLAN, IP źródła) FrameRelay (DLCI) inne PPP, GRE, L2TP, IPSec P P P CE PE P P VPN B site CE PE PE ingress attachement circuit, określa (w PE) drogę pakietu w sieci SP (VPN/Internet)
wirtualne łącza w sieci SP ( route circuits ) 198.3.97.64/25 VPN A,B site VPN A site PE PE CE CE 198.3.97.64/25 PE VPN B site VPN B site PE VPN A site 198.3.97.0/25
VRF - Virtual Routing (and) Forwarding (tables) VPN A,B site VPN A site CE CE VPN B site VPN B site VPN A site zawsze jest też default forwarding table!
przekazywanie (forwarding) pakietów w routerach PE praktycznie zawsze (ingress, egress) attachement circuit związany jest z jednym VRF w PE (ingress, egress) route cicuit związany jest z jednym VRF w każdym z pary PE przekazywanie pakietu z ingress attachement circuit lub ingress route circuit wybór VRF wybór najlepszego wiersza w VRF wysłanie pakietu do egrees attachement circuit egress route circuit
skąd się biorą? VRF konfigurowane w PE przy dołączeniu site a zawartość VRF prefiksy sieci dostępnych w PE poprzez egress attachement circuits rozgłaszane przez CE (RIP, OSPF, BGP) wpisane statycznie prefiksy sieci dostępnych w innych PE (należacych do danej VPN) rozgłaszane przez inne PE (BGP) route circuit każde rozgłoszenie BGP(me) o dostępności podsieci (PE->PE) przenosi etykietę MPLS (dla dedykowanej LSP) dla route circuit
rozgłaszanie w backbone jakiego protokołu routingowego użyć? BGP, multiprotocol extensions wielobok zupełny (ibgp) pomiędzy routerami PE jak uniknąć porównywania rozgłoszeń dotyczących różnych VPN? każdy rozgłaszany przez PE adres podsieci rozbudowywany jest o unikatowy route distinguisher (RD) [8 oktetów] każdy SP ma swoją pule RD (prefiks) jak stwierdzić, że rozgłoszenie powinno trafić do określonych VRF? route target [8 oktetów] z każdym rozgłoszeniem propagowana jest lista route targets każdy VRF ma listę route targets, które go dotyczą jeżeli niepusta część wspólna, BGP wprowadza rozgłoszenie (wg. standardowych zasad) do danego VRF
PE dostaje rozgłoszenie o dostępności podsieci (static, OSPF) tworzy wpis w odpowiednim (odpowiednich) VRF konwertuje adres podsieci do VPN-IP4 (dodaje RD) rozgłasza dostępność via BGP innym (zainteresowanym) routerom rozgloszenie zawiera: NLRI, NEXT-HOP (adresy VPN-IP4) route targets etykieta MPLS router wybiera najlepszą drogę dla danego adresu VPN-IPV4 zapamiętuje interfejs i etykietę mpls (wejście do route circuit) redukuje adres do IPv4 i instaluje go w jednym/wielu VRF (niekoniecznie) informuje CE od dostępności podsieci w ramach VPN a
a co z naszym przykładem? data client office + firewall depot konfigurujemy attachement circuits (client, data, office, management, depot) definiujemy 2 routetargets data_intranet i data_extranet management do VRF w lokalizacji klienta przypisujemy routetarget data_extranet do pozostałych VRF przypisujemu routetarget data_intranet rozgłaszamy pdsieć w lokalizacji data z nexthop firewall i routetarget data_extranet rozgłaszamy podsieć w lokalizacji data z nexthop data i routetarget data_intranet mapa z google map
rozmiar tablic forwardowania mpls w routerach P P 1 PE 2 P 2 PE 1 PE 3 P 3 tunel MPLS (igre, L2TP, IPSec) pomiędzy każdą parą routerów PE każdy route circuit wstawiamy do odpowiedniego tunelu tablice forwardowania mpls w routerach P zawierają tylko przełączenia etykiet dla tuneli UFF.
koniec wykładu IX