WIXLIB

KTH/CSC, BGP-MPLS VPN lab, rev: 1.4KTHNOCBGP-MPLS VPN labJuniper versionGroup ture

KTHNOC, BGP-MPLS VPN lab, rev: 1.4Table of Contents1 Goals.32 Groups.33 Preparations.33.1Preparation questions.34 Overview.45 Part 1: The Backbone.76 Part 2: L3VPN.87 Part 3: L2VPN.97.1CE configuration.97.2PE configuration.108 Cleanup.119 References.11Appendix A: Netmaps.122

KTHNOC, BGP-MPLS VPN lab, rev: 1.41GoalsThis lab gives an overview of BGP-MPLS provider-based VPNs inthe Juniper environment. It handles both L2VPN (virtual privatewire service) and L3VPN.The scenario is the operation of a backbone network configuredwith MP-BGP, MPLS and RSVP with a set of customers connectedto this network. Each customer have several sites, representingtheir branch-offices. The backbone offers VPN services to thecustomers, where some customers require L2VPN and someL3VPN.When the lab is finished, you will understand how L2VPN andL3VPN work, and you will understand how all protocols worktogether.2GroupsThe lab includes a common backbone, and the customer sites aredistributed among several routers. But the lab can be partitionedinto three groups. However, since most of the steps of the lab isbased on the whole network it is important to continuouslycooperate with the other groups.The lab requires 20 routers. Each group configures six routers.3PreparationsBefore you begin this lab, it is essential that you understand BGPMPLS provider-based VPNs. Read through lecture notes andrelevant book chapters, for example Chapter 10 of [2] and Chapter15 of [4].The commands used in this lab are best looked up in the JunOSreference manuals[3].The KTHNOC reference manual[5] can be useful to setup basicIGP, MPLS and RSVP.3.1 Preparation questionsPreparation questions that should be answered before you come tothe lab:3

KTHNOC, BGP-MPLS VPN lab, rev: 1.4What is the difference between overlay(customer-based) and peerto-peer(provider-provisioned) VPNs?What is a CE?What is a PE?What is the purpose of the route distinguisher?What is the benefit of using type 1 route distinguisher (compared tousing type 0)?What is the route target used for?If you configure a full mesh VPN with default import and exportroute target rules, what command in JunOS can you use instead ofimport/export rules?4OverviewThe lab consists of a backbone as shown in the Figure 1 below. Thebackbone is a redundant backbone consisting of six border routers,also called PE routers, and two core routers (RTB3 and RTB4), alsocalled P routers. The whole backbone runs an IGP, as well as RSVPand MPLS. The border routers also run BGP, the core routers donot.4

KTHNOC, BGP-MPLS VPN lab, rev: 1.4BackboneRTC1RTC2RTB4RTB1RTB3RTB2RTC3RTC4Figure 1: The MPLS/IGP/BGP backboneThe core is designed to be resilient. Any link or router should notbe a single-point of failure. (Except the customer interfaces). Studythe figure and make sure that you can find at least two waysbetween each pair of border routers.The border routers are connected to two customer sites each asshown in Figure 2.5

KTHNOC, BGP-MPLS VPN lab, rev: 1.4BackboneCore:Border:Sites:Group 1Group 2Group 3Figure 2: CE routers and groupsThese site routers (CEs) represent customer networks. Since wehave a limited number of routers, the customer sites all constituteone router only.The group partitioning is shown in the figure as well. Every grouphas four CE:s and two PE:s. The two P routers are pre-configured.BackboneCore:Border:Sites:RED BLUE YELGREENRED BLUE YELGREENRED BLUE YELGREENFigure 3: VPNs6

KTHNOC, BGP-MPLS VPN lab, rev: 1.4Figure 3 above shows the VPNs. There four VPNs: RED, BLUE, YELand GREEN. Each VPN involves three sites, one in each group.The RED and BLUE VPNs are L2VPN, that is, they areinterconnected by pseudowires.The YEL and GREEN VPNs are L3VPNs, that is, they areinterconnected by routing.More detailed netmaps are given in Appendix A.5Part 1: The BackboneThe two P routers are already configured. Each group should nowconfigure two border routers/PEs according to netmaps 1-3 inAppendix A.When configuring the backbone, be careful not to configure anydynamic routing protocols on the customer interfaces. Be also verythorough since errors may take a long while to debug in thissomewhat complex network.First, configure all network interfaces, loopback interfaces androuter-ids as shown in the netmap. All addresses are in the192.168.0.0/16 range.Second, all routers should run an IGP. Configure OSPF and verifythat all routers can ping/traceroute all other routers.Third, the network should run RSVP and MPLS. Configure RSVPand MPLS for all partaking interfaces (ie to the core and to yourpeer border router) and enable family MPLS on these interfaces aswell.Enable icmp-tunneling for MPLS (so that you can traceroute).Fourth, setup two LSPs (full mesh) to the other border routers.Set up full mesh between the routers that are necessary (ie RTC1RTB1-RTC3 and RTC2-RTB2-RTC4). Use the label-switched-pathcommand to setup the LSP. Use the no-cspf option to disableautomatic constraint-based routing.Verify that the LSPs are up. You can do this in several ways. Oneway is to check RSVP sessions.Another way is by looking in the inet.3 routing table where RSVPadds its routes by default. Why does RSVP add its routes in inet.3and not in inet.0?7

KTHNOC, BGP-MPLS VPN lab, rev: 1.4Finally set up iBGP. You should use loopback peering and youshould setup a full mesh between all border routers. Since we shallrun MP-BGP, you should enable two extra address families: l2vpnsignalling (for L2VPN) and inet-vpn unicast (for L3VPN)Verify that the whole backbone works. This is mainly done byexamining that the LSPs are in place so that the BGP tables use theLSPs for transit traffic.Resiliency: Deactivate a backbone interface (where there is an LSPsignalled). Study how long it takes before the LSP is reinstalledusing an alternate route. Approximately how long does it take?Which protocols are involved?Milestone 1: Show a working backbone.Signature:Keep and save the configuration. It will be used as a basis for boththe L3VPN and L2VPN parts below.6Part 2: L3VPNYou shall now create the YEL and GREEN VPNs.Start with configuring the CE routers. You should use the last twonetmaps in Appendix A, L3VPN #3 and #4.Configure the interfaces and the extra /24 network. Let eBGP bethe PE-CE routing protocol for L3VPN#3 and RIP be the PE-CErouting protocol for L3VPN#4. Export this /24 to the PE-CE routingprotocol.Now configure the PE:s. Create a new routing-instance for eachcustomer. The instance type of the routing instance is “vrf”. Definewhich interface the VRF attaches, and set the route distinguisherusing the RD assigned in the netmap.Ensure that networks are announced properly from CE:s to PE:s,and from PE:s to CE:s.8

KTHNOC, BGP-MPLS VPN lab, rev: 1.4You should also create rules for the route target. Create vrf importand export rules for fully meshed VPNs. Ensure that you export theroutes from your customer inet.0 tables – both the /24 customernetwork and the /30 link network (both are necessary if you wantyour traceroute to work). A simpler way than to use vrf-import andvrf-export is to use the vrf-target command.Set also the vrf-table-label command.Verify that the routing tables look reasonable. Focus first on thecustomer inet.0 table. After that look at the bgp.l3vpn.0 table toensure that the VPN routes are exported and imported as theyshould.Verify that the VPN works by pinging and trace-routing betweenthe customer sites. Also, try to ping with a large MTU (1500) toverify that all packets sizes work. Check that the routing tablescontain the remote networks.Examine the state of the routers. Write down the name of allrouting tables. (There should be at least six) and explain thepurpose of each table:You may have to wait for some other group before demonstratingthe milestone.But you should at least show a working VPN to one other neighbourin both L3VPN#3 (YELLOW) and L3VPN#4(GREEN).Milestone 2: Show a working L3VPN.Signature:Remember to keep the configuration (and save it to disc). Youshould keep the configuration so that the other groups can use yoursites, and save it if you break for the day (you cannot assume thatthe same configuration will be there next day).7Part 3: L2VPNContinue with the L2VPN setup as shown in the L2VPN #1 and #2in Appendix A. These are the VPNs shown as red and blue in Figure9

KTHNOC, BGP-MPLS VPN lab, rev: 1.43 above. You should be able to use the same backbone as forL3VPN, and the L3VPNs may co-exist with the L2VPNs.7.1 CE configurationIn these VPNs, we need to create pseudo-wires between each CE.Since it is full mesh, every CE needs to be connected by twopseudo-wires. But since we do not have more than one physicalinterface (eg fe-0/0/0), we need to create virtual links on thephysical Ethernet. This is done by creating VLANs.On the CE and PE, create two VLANs on the interconnectingEthernet link. This is made by configuring vlan-tagging on the toplevel, and then creating one unit for each VLAN. In each unitconfigure a vlan-id as used in Appendix 2. Within the unit, alsoconfigure an address.Example of one VLAN configured on fe-0/0/0interfaces{fe 0/0/0 {vlan tagging;unit 935 {vlan id 935;family inet {address 193.2.4.5/24}}}}No further configuration is necessary on the CE:s.7.2 PE configurationThe PE configuration is more elaborate. First, the accessinterfaces should be configured with matching VLANs from thecustomer. Encapsulation vlan-ccc should also be configured on thephysical interface, which determines how the encapsulation withinthe pseudo-wire is achieved. No IP address should be configured onthe customer interface. Why not?Then, a routing instance for each L2VPN is created as follows:1. The routing instance is of type l2vpn2. The route distinguisher is assigned. Use loopback address:VPN number as before.3. Use full mesh vrf targets (vrf-target command using 65001:#)4. Define the sites (below)10

KTHNOC, BGP-MPLS VPN lab, rev: 1.4The sites and their interconnection is made within the protocoll2vpn clause. It is essentially made by virtually interconnecting theL2VPN sites manually. First the local site is defined and anidentifier is assigned to it. Then, the pseudo-wires to the remotesides are defined. It is recommended to use the naming proposedby the netmap in Appendix A, that is, use the last number in therouter-id as site number.Ensure that you have a working setup. It should be possible to pingbetween the CE:s.Examine the state of the routers. Write down the name of allrouting tables. How do they differ from L3VPN?Milestone 3: Show a working L2VPN.Signature:8CleanupTo reset the machines to their initial state, follow the followingsteps for all routers.1.9Reset the configuration by loading (using override) the root/labconf configuration.References[1] KTHNOC Router lab Introduction - Juniper version[2] White. McPehrson and Sangli, “Practical BGP”, Addison-Wesley[3] JunOS 8.2 routing configuration s/junos82/swconfig82-routing/html[4] Garrett, “JunOS Cookbook”, O'Reilly[5] KTHNOC Router lab Reference - Juniper version11

KTHNOC, BGP-MPLS VPN lab, rev: 1.4Appendix A: NetmapsNETMAP Topology VPN, Site DRTB40.128/32ASN: 65001IP subnets: 192.168.X.Yfe .1/00/0fe 0/0/1.1fe 0/0/0 .1RTC10.1/32fe 0/0/0fe 0/0/0D10.129/32fe 0/0/1 .11.0/30fe 1/0/0 .2RTB34.0/30/11/0fe .2/300.2.fe 2/0/0 .1.3.0/30fe .21/0fe 1/0/1 .2/0fe 2/0/0 .2.5.0/30fe 0/0/0fe 0/0/1fe 0/0/0D2fe 0/0/0D3RTC20.2/32fe 0/0/1fe 0/0/0D4KTHNOC netmap topology l2pvn.odp rev 1.012

KTHNOC, BGP-MPLS VPN lab, rev: 1.4NETMAP Topology VPN, Site ARTB40.128/32ASN: 65001IP subnets: 192.168.X.Yfe .11/0/1fe0/0 1/.1fe 1/0/0 .1RTB10.3/32fe 0/0/0fe 0/0/0A10.129/32fe 1/0/1 .17.0/30fe 1/0/0 .2RTB310.0/30/11/0fe .2/300.8fe 2/0/0 .1.9.0/30fe .21/0fe 1/0/1 .2/0fe 2/0/0 .2.11.0/30fe 0/0/0fe 0/0/1fe 0/0/0A2fe 0/0/0A3RTB20.4/32fe 0/0/1fe 0/0/0A4KTHNOC netmap topology l2pvn.odp rev 1.013