Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Temp. ID: TE-Q-2.02.02-E-08 V 1.0 Experiences with Implementing MPLS/VPN Services Philip Bridge Nextra (Schweiz) AG 18.10.2000 Some Paraphrases • ‘For the first time in the history of the Internet the transmission people are giving the network people more bandwidth than they know what to do with’ – Peter Lothberg • ‘If you aren’t scared, you don’t understand’ – 5/25/2017 Mike O’Dell Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 2 MPLS-based VPN IP Backbone Layer-2 Switching 5/25/2017 ‘Private’ Internet Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 IP Routing 3 MPLS Label Switch Router (LSR) Provider Edge Router (PE) 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 4 MPLS • IP Routing creates consistent, network-wide Routing Tables LSR IP Routing Protocol (OSPF, IS-IS) PE 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 5 MPLS • Label Distribution Protocol runs in parallel to IP routing • LSRs use LDP to swap IP Route-to-Label bindings • Creates Label Forwarding Tables Label Distribution Protocol 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 6 MPLS • LDP & IP Routing create Label Switch Paths between PE routers Local Remote label label IP prefix o/p interface 3 5 3.3.3.3 C X 3 10.0/16 A Local Remote label label 5 X IP prefix o/p interface 3.3.3.3 A 2) I reach 3.3.3.3 via int C, label 5 Local Remote label label IP prefix o/p interface X 3 3.3.3.3 F X 3 10.0/16 A LSP C 3.3.3.3 A F 4) I reach 3.3.3.3 via int F, label 3 5/25/2017 3) To reach 3.3.3.3 via me use label 3 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 1) To reach 3.3.3.3 via me use label 5 7 MPLS • PE routers ‘encapsulate’ IP packet with Label header • Works an any layer-2 (Ethernet, WAN link, ATM…) Local Remote label label Local Remote label label o/p interface IP prefix 3 5 3.3.3.3 C X 3 10.0/16 A o/p interface IP prefix X 3 3.3.3.3 F X 3 10.0/16 A Local Remote label label 5 5 X IP prefix o/p interface 3.3.3.3 A 3.3.3.3 C 3.3.3.3 A Label IP DA IP Data 3 3.3.3.3 IP Packet F 3.3.3.3 5/25/2017 IP Packet Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 8 MPLS • Normal IP ‘connectionless’ routing builds layer-2 LSP ‘circuits’! • LSPs take same path that would be taken by IP-based forwarding 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 9 MPLS & Network Scalability • LDP & OSPF IP routing build LSPs between PE routers 2) To reach 3.3.3.3 via me use label 3 1) To reach 3.3.3.3 via me use label 5 3) I reach 3.3.3.3 via int F, label 3 C A 3.3.3.3 F 2.2.2.2 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 10 MPLS & Network Scalability • PE-PE LSPs used to build BGP session between PE routers • Core LSRs do not have any BGP routing LSP between BGP endpoints C A F BGP Session 3.3.3.3 2.2.2.2 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 11 MPLS & Network Scalability • BGP tells each PE which remote PE for each external route • Recursive lookup in the routing table to find a route to the remote PE • Route to the remote PE is actually a LSP LSP between BGP endpoints 5) BGP neighbor 3.3.3.3 has a route to 10.0/16... C A 10.0/16 F 6) …so to reach 10.0/16 I use int F, label 3 5/25/2017 BGP Session 3.3.3.3 2.2.2.2 4) BGP: I have a route to 10.0/16 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 12 MPLS & Network Scalability • BGP route exchange between PEs, no BGP in Core • LSPs only established between BGP session endpoints • A few LSPs carry 1000’s of Edge routes between PEs • Complex routing can be ‘pushed out’ of the Core to the Edges 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 13 MPLS & VPNs • BGP Edge Routes are hidden from the Core • IP addresses of data packets are hidden from the Core • Overlapping ‘address families’ can share the Core…VPNs! 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 14 Virtual Routers • PE-PE BGP hides Customer routes from Core • MPLS hides IP addresses of packets from Core • But routes and and addresses are still visible in PE routing table! B C F BGP Session 3.3.3.3 A 10.0/16 10.0/16 2.2.2.2 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 15 Virtual Routers • Solution is to assign a ‘Virtual Router to each Customer port • Routing Tables in Virtual Routers are invisible to each other • Cisco name: Virtual Routing and Forwarding Instance (VRF) B C F BGP Session 3.3.3.3 A 10.0/16 10.0/16 2.2.2.2 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 16 Layer 2 Labels • Extend BGP to carry L2 labels and routes • PE uses 2nd Level Label (L2) to distinguish between VPNs 1) BGP:To reach 10.0/16 via me use L2 10 2) BGP: To reach 10.0/16 via me use L2 12 3) To reach 10.0/16 via 3.3.3.3 I use L2 10 4) To reach Next Hop 3.3.3.3 I use int F, L1 label 3 B C F BGP Session 3.3.3.3 A 10.0/16 10.0/16 2.2.2.2 5) …so to reach 10.0/16 I use int F, L1 label 3, L2 label 10 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 17 Layer 2 Labels • 1st Level Label gets packets to correct destination PE • Destination PE strips 1st Level Label (L1) from incoming packets • Destination PE uses 2nd Level Label (L2) to forward incoming packets t 1) Packets arriving with L2 10 are for red VRF 2) Packets arriving with L2 12 are for blue VRF B C F BGP Session 3.3.3.3 A 10.0/16 10.0/16 2.2.2.2 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 18 VPN Forwarding • Packet arrives on interface E = red VRF • PE looks up route to 10.0.0.1 in VRF Routing Table • BGP route from 3.3.3.3 gives L2 = 10 • Recursive lookup on Next Hop 3.3.3.3 gives L1 = 3 • Packet label switched through Core to 3.3.3.3 • L1 removed • L2 tells PE router to treat packet according to red VRF • L2 removed, packet forwarded out of interface A 3 10 10.0.0.1 IP Packet C L1 L2 IP DA IP Data 3 10 10.0.0.1 IP Packet 10 10.0.0.1 IP Packet 3.3.3.3 A F 10.0.0.1 IP Packet E 10 5/25/2017 10.0.0.1 IP Packet 10.0.0.1 IP Packet Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 19 MPLS & VPNs • • • • MPLS VPNs are like ‘Private Internets’ Internet protocols work within the VPN Easy to understand - similar to Frame-Relay Compliments Tunnel-based (IPSec) VPNs 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 20 IP Backbone Sharing ‘Private Internet’ IP Backbone ‘Private’ Internet 5/25/2017 ‘Private’ Internet Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 21 Frame Relay Comparison 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 22 Frame Relay Comparison ‘Private’ Internet 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 23 MPLS & VPNs • Customers A and B want their own VPNs, and an ExtraNet • Customer A wants to connect his VPN to the Internet • Customer B does not trust security of Customer A... Internet Service VPN-B Extra Net VPN-A 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 24 Experience with MPLS VPNs • • • • • • Customer VPNs in service for >1 year. Several dozen VPNs Sizes between 2 and dozens of sites Average size of ca. 10 sites. 50:50 mixture of managed/unmanaged CPE Many VPNs have fixed and Dial-Up Access 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 25 Experience with MPLS VPNs • Many VPNs are combined with Internet Access Service, and a large proportion of these with managed Firewall services. • From the Customer perspective, an MPLS VPN ‘looks’ different from a classical IP network. This has to be explained. – strange traceroutes – discontiguous routing domains 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 26 Experience with MPLS VPNs • MPLS labels increase the length of a packet. Can be a problem with Ethernet equipment from some vendors. Was a big problem for us at the beginning. Is still a problem for IPsec VPNs • Equipment vendor MPLS/VPN implementations are reliable. Still some small bugs and missing features, but nothing that can’t be worked around 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 27 Experience with MPLS VPNs • MPLS/VPN is a very powerful paradigm for building an infrastructure that can deliver rich set of Services very flexibly and very rapidly • It is a simple concept, but there are so many implementation possibilities that complexity can (very) easily can get out of control 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 28 Experience with MPLS VPNs • Tools to properly manage VPNs are still lagging way behind the network functionality • Available tools restrict the ability of a Service Provider to innovate and develop solutions that are unique • GUIs for provisioning are OK, but the real problem is fault resolution…about 5-10 times more difficult to resolve problems than normal IP-based ISP networks 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 29 Experience with MPLS VPNs • It is crucial to impose a structured, modular Service model onto the VPN architecture from the beginning – Helps Salesmen and Customers to understand what can and cannot be done – Helps implementation team to configure the solution – Helps NOC to trouble-shoot – Reduces load on 3rd level pre-sales & support 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 30 Next Challenges • Integration of MPLS/VPN and DiffServ QoS • Multi-provider/Multi-AS extension of MPLS/VPN based Services • Traffic Engineering 5/25/2017 Doc ID: TE-Q-1.01.06-E-17 / Version 1.0 / Release: 28.10.1999 31 Thank You! Temp. ID: TE-Q-2.02.02-E-08 V 1.0 http://www.swinog.ch/swinog1/presentations.html [email protected]