6VPE. Overview. Juniper IPv6 lab exercise: 6VPE

Transcription

1 Lab 7 6VPE Overview In this lab, you will configure the infrastructure that will be used to support 6VPE. All these exercises assume you already have intermediate level of understanding of the JUNOS CLI You have been assigned a POD consisting of 4 devices: two PE routers and two CE routers. Make sure you understand which devices have been assigned to you. This lab guide takes as a configuration example POD A but this just a reference. Make sure you adapt your configurations to your assigned POD, following always the lab diagram. Note that your lab login (password lab123) grants you all permissions needed to complete this lab; however some restrictions have been made to prevent loss of connectivity to the devices. Please be careful, and have fun! In this lab you will: Station patching and configuration reset Configure the core IGP Configure MP-IBGP peering between communicating P-routers Configure CE routing options Create a VRF on your PE router Create and apply VRF (VPN) import and export policy Establish RSVP LSPs between communicating PE routers Configure static routing on the PE-CE interface Configure BGP routing on the PE-CE interface Enable pings originating from a multiaccess PE-CE interface Verify proper VPN operation by examining VRF tables, PE-PE BGP updates, and performing ping tests Please refer to the next page lab diagram to perform this exercise and chose the one that refers to your assigned POD: 1

2 Lab Diagram Lab 7: 6VPE L3VPNs Carrying IPv6 routes x.y/24 = Serial Interfaces x.y/32 = Loopback Interfaces 2001:10:0:a::b/64 = PE-CE Interfaces 2001:192:168:c::1/128 = CE Loopback Interfaces 2001:172:x:0-7/64 = CE Static Routes POD A VPN-A CE-A1 Denver: ::50::1 AS :172:16:0::/ :172:16:1::/ :172:16:2::/ :172:16:3::/64 VPN-B 2001:10:0:4::/64 :4::2 ge-0/0/1.0 ge-0/0/1.0 :4::1 ebgp Static Routes (Virtual Customer Networks) Tokyo-PE lo0: MPLS LSP / /24 se-1/0/1 se-1/0/1 Sydney-P se-1/0/0 se-1/0/0 lo0: ISIS Level 2 AS Provider Core MPLS LSP MP-BGP HongKong-PE lo0: :10:0:12::/64 :12::1 ge-0/0/1.0 ge-0/0/1.0 :12::2 ebgp VPN-A CE-A2 SaoPaulo :51::1 AS :172:16:4::/ :172:16:5::/ :172:16:6::/ :172:16:7::/64 POD B VPN-B CE-B1 Madrid :52::1 AS :172:16:0::/ :172:16:1::/ :172:16:2::/ :172:16:3::/ :10:0:6::/64 :6::2 ge-0/0/1.0 ebgp :6::1 Static Routes (Virtual Customer Networks) London-PE lo0: /24 se-1/0/0 se-2/0/ Sydney-P lo0: ISIS Level 2 AS Provider Core se-2/0/ /24 MP-BGP se-1/0/ Amsterdam-PE lo0: :10:0:14::/64 :14::1 ge-0/0/1.0 ge-0/0/1.0 :14::2 ebgp CE-B2 NewYork :53::1 AS :172:16:4::/ :172:16:5::/ :172:16:6::/ :172:16:7::/64 2

3 Lab 7: 6VPE L3VPNs Carrying IPv6 routes x.y/24 = Serial Interfaces x.y/32 = Loopback Interfaces 2001:10:0:a::b/64 = PE-CE Interfaces 2001:192:168:c::1/128 = CE Loopback Interfaces 2001:172:x:0-7/64 = CE Static Routes POD C VPN-C MPLS LSP VPN-C / /24 CE-C1 :8::2 ge-0/0/1.0 SanJosePE se-1/0/1 se-3/0/1 Sydney-P se-3/0/0 se-1/0/1 Montreal-PE :16::1 fe-0/0/1.0 Rome fe-0/0/1.0 :8::1 lo0: 7.2 lo0: lo0: ge-0/0/1.0 :16::2 :54:: ebgp ebgp AS AS MP-BGP 2001:172:16:0::/ :172:16:1::/ :172:16:2::/ :172:16:3::/ :10:0:8::/64 Static Routes (Virtual Customer Networks) ISIS Level 2 AS Provider Core 2001:10:0:16::/64 CE-C2 Barcelona :55::1 2001:172:16:4::/ :172:16:5::/ :172:16:6::/ :172:16:7::/64 3

4 Key Commands Key operational mode commands used in this lab include the following: configure show interfaces terse show isis adjacency show isis interface show bgp neighbor show bgp summary show route receive-protocol bgp show route advertising-protocol bgp show route summary show mpls lsp show route forwarding-table vpn vpn-name show route hidden detail show route protocol bgp detail show route table bgp.l3vpn-inet6.0 show route table inet.3 show route table inet6.3 show route table vpn-name Part 1: Patching and Configuration Reset Step 1.1 Familiarize yourself with the 6VPE topology described in the lab 7 diagram handout. You will configure a pair of PE and CE routers. Log into your PE and CE routers and go ahead and load the lab7-6vpe-start file that is located in the ipv6/ directory of your device. This will give us a working baseline configuration on the devices. lab@tokyo-pe> configure Entering configuration mode lab@tokyo-pe# load override ipv6/lab7-6vpe-start load complete Familiarize with the configuration just loaded. You will notice that there are inet and inet6 families configured on the interfaces with respective IPv4 addresses for the core facing interfaces and IPv6 addresses for the customer facing interfaces. There is not much more configured Once you are satisfied commit your configuration. lab@tokyo-pe# commit and-quit commit complete Now login into your CE assigned device and load the ipv6/lab7-6vpe-start file. This will give us back a working baseline configuration. 4

5 configure Entering configuration mode load override ipv6/lab7-6vpe-start load complete Familiarize with the configuration just loaded. Like in the PE case, you will notice that there is just inet family configured on the interfaces with respective IPv6 addresses. Nothing else really. Once you are satisfied with your inspection go ahead and commit your configuration. commit and-quit commit complete Part 2 Interface Addressing (PE and CE Routers) Step 2.1 Note The P-router (Sydney) has been preconfigured. For the moment you do not have to do anything with Sydney, just look You must add the family mpls to each of your PE core facing interfaces (se-1/0/x). You should also add the family iso to your interfaces to support the use of IS-IS routing in the core. Issue the following commands while at the [edit interfaces] hierarchy: [edit interfaces] lab@tokyo-pe# set interface-name unit 0 family mpls [edit interfaces] lab@tokyo-pe# set interface-name unit 0 family iso Step 2.2 Repeat these commands for each of your PE router s physical interfaces. Because interface support of mpls packets is required in all future labs, you should now enable the processing of labeled packets with the following command, entered at the [edit protocols] hierarchy on your PE router. Remember to disable the protocol on interface ge-0/0/0!! [edit protocols] lab@tokyo-pe# set mpls interface all [edit protocols] lab@tokyo-pe# set mpls interface ge-0/0/0 disable 5

6 Part 3 Configure Core And Core Facing IGP (IS-IS) Step 3.1 We will now configure the ISO NET on your PE router s loopback interface. Use the following table to obtain the correct NET value for your station. Router router-id Tokyo-PE HongKong-PE London-PE Amsterdam-PE SanJose-PE Montreal-PE Issue the following command while at the [edit interfaces] hierarchy to assign your router s ISO NET: [edit interfaces] lab@tokyo-pe# set lo0 unit 0 family iso address iso-net-address Step 3.2 Show your interface configuration to check your work. Commit your changes when you are satisfied that the information you entered is correct. [edit interfaces] lab@tokyo-pe# show ge-0/0/0 { description "MGMT INTERFACE - DO NOT DELETE"; unit 0 { family inet { address /16; ge-0/0/1 { description "to CE_A1-Denver"; unit 0 { family inet6 { address 2001:10:0:4::1/64; 6

7 se-1/0/1 { description "to Sydney-P"; unit 0 { family inet { address /24; family iso; family mpls; lo0 { unit 0 { family inet { address /32; family iso { address ; [edit interfaces] lab@tokyo-pe# commit commit complete Step 3.3 Verify correct interface addressing by pinging directly connected CE and P router interfaces. You should also use the operational mode show interfaces terse command to confirm that the proper addressing and protocol families have been configured on your CE and PE router interfaces. [edit interfaces] lab@tokyo-pe# run ping count 3 PING ( ): 56 data bytes 64 bytes from : icmp_seq=0 ttl=64 time=3.377 ms 64 bytes from : icmp_seq=1 ttl=64 time=2.624 ms 64 bytes from : icmp_seq=2 ttl=64 time=2.681 ms ping statistics packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.624/2.894/3.377/0.342 ms [edit interfaces] lab@tokyo-pe# run ping 2001:10:0:4::2 count 3 PING6(56= bytes) 2001:10:0:4::1 --> 2001:10:0:4::2 16 bytes from 2001:10:0:4::2, icmp_seq=0 hlim=64 time=9.461 ms 16 bytes from 2001:10:0:4::2, icmp_seq=1 hlim=64 time=8.432 ms 16 bytes from 2001:10:0:4::2, icmp_seq=2 hlim=64 time=6.269 ms 7

8 :10:0:4::2 ping6 statistics packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/std-dev = 6.269/8.054/9.461/1.330 ms lab@tokyo-pe# run show interfaces terse Interface Admin Link Proto Local Remote ge-0/0/0 up up ge-0/0/0.0 up up inet /16 gr-0/0/0 up up ip-0/0/0 up up lsq-0/0/0 up up lt-0/0/0 up up mt-0/0/0 up up sp-0/0/0 up up sp-0/0/0.0 up up inet sp-0/0/ up up inet > > 0/ > > 0/0 ge-0/0/1 up up ge-0/0/1.0 up up inet6 2001:10:0:4::1/64 fe80::21d:b5ff:fe0f:6301/64 ge-0/0/2 up up ge-0/0/3 up up se-1/0/0 up down se-1/0/1 up up se-1/0/1.0 up up inet /24 iso dsc up up gre up up ipip up up lo0 up up lo0.0 up up inet > 0/0 iso lo up up inet > 0/0 lo up up inet > 0/ > 0/ > 0/ > 0/ > 0/0 lo up up lsi up up mtun up up pimd up up pime up up pp0 up up ppd0 up up ppe0 up up st0 up up tap up up vlan up down 8

9 Step 3.4: IS-IS For IS-IS, we will configure a single Level 2 routing area. Enter the following command while at the [edit protocols isis] portion of the PE configuration hierarchy: lab@tokyo-pe# set protocols isis level 1 disable lab@tokyo-pe# set protocols isis interface se-1/0/1 lab@tokyo-pe# set protocols isis interface lo0 Repeat the same steps on your other PE device. Remember to not configure the PE-CE VRF interface here! Step 3.5: IS-IS Show your work, and commit changes when you are satisfied that IS-IS Level 2 has been correctly configured: lab@tokyo-pe# show protocols mpls { interface all; interface ge-0/0/0.0 { disable; isis { level 1 disable; interface se-1/0/1.0; interface lo0.0; lab@tokyo-pe# commit and-quit commit complete Exiting configuration mode lab@tokyo-pe> Step 3.6: IS-IS Verify that the IS-IS routing protocol is functioning correctly by tracing the route to the lo0 addresses of the other PE and P routers in the room. You might also want to issue IS-IS operational mode commands such as: lab@host> show isis adjacency lab@host> show isis interface lab@host> show route protocol isis lab@host> show isis database <detail extensive> lab@tokyo-pe> show isis hostname 9

10 IS-IS hostname database: System ID Hostname Type Tokyo-PE Static HongKong-PE Dynamic Sydney-P Dynamic show isis database IS-IS level 1 link-state database: 0 LSPs IS-IS level 2 link-state database: LSP ID Sequence Checksum Lifetime Attributes Tokyo-PE x4 0x L1 L2 HongKong-PE x3 0x L1 L2 Sydney-P x5bf 0x L1 L2 3 LSPs lab@tokyo-pe> traceroute traceroute to ( ), 30 hops max, 40 byte packets ( ) ms ms ms ( ) ms ms ms Part 4 View the Configuration of P Router Step 1 Telnet to a P router and view its configuration. The configuration should be similar to this example taken from Sydney: lab@tokyo-pe> telnet Trying Connected to Escape character is '^]'. Sydney-P (ttyp1) login: lab Password: --- JUNOS 11.4R9.4built :37:41 UTC lab@sydney-p> show configuration groups { ISIS { interfaces { <*-*> { unit 0 { family iso; family mpls; 10

11 system { host-name Sydney-P; root-authentication { encrypted-password "$1$KI99zGk6$MbYFuBbpLffu9tn2.sI7l1"; ## SECRET-DATA ssh-dsa "ssh-dss AAAAB3NzaC1kc3MAAACBAMQrfP2bZyBXJ6PC7XXZ+MzErI8Jl6jah5L4/O8BsfP2hC7EvRfNoX7MqbrtCX/9gUH9gCh VuBCB+ERULMdgRvM5uGhC/gs4UX+4dBbfBgKYYwgmisM8EoT25m7qI8ybpl2YZvHNznvO8h7kr4kpYuQEpKvgsTdH/J le4uqnjv7daaaafqdzaqa6qagbw3o/zvealcidj6p0dwaaaib1il+krwrxid8nppy+w4dwxeqav3bnobzpc4eyxqkbu COr80Q5YBlWXVBHx9elwBWZwj0SF4hLKHznExnLerVsMuTMA846RbQmSz62vM6kGM13HFonWeQvWia0TDr78+rOEgWF 2KHBSIxL51lmIDW8Gql9hJfD/Dr/NKP97w3L0wAAAIEAr3FkWU8XbYytQYEKxsIN9P1UQ1ERXB3G40YwqFO484SlyKy YCfaz+yNsaAJu2C8UebDIR3GieyNcOAKf3inCG8jQwjLvZskuZwrvlsz/xtcxSoAh9axJcdUfSJYMW/g+mD26JK1Cli w5rwp2nh9kurjxei7iredp4egnkm4i15o= configurator@server1.he"; ## SECRET-DATA login { user lab { uid 2000; class super-user; authentication { encrypted-password "$1$84J5Maes$cni5Hrazbd/IEHr/50oY30"; ## SECRET-DATA services { ftp; ssh; telnet; web-management { http; syslog { user * { any emergency; file messages { any any; authorization info; file interactive-commands { interactive-commands any; interfaces { apply-groups ISIS; ge-0/0/0 { apply-groups-except ISIS; description "MGMT INTERFACE - DO NOT DELETE"; unit 0 { family inet { 11

12 address /16; se-1/0/1 { description se-1/0/1.to; encapsulation ppp; serial-options { clocking-mode dce; clock-rate 8.0mhz; unit 0 { family inet { address /24; family inet6 { address 2001:10:0:30::1/64; se-2/0/0 { description se-1/0/0.lo; encapsulation ppp; serial-options { clocking-mode dce; clock-rate 8.0mhz; unit 0 { family inet { address /24; family inet6 { address 2001:10:0:31::1/64; se-2/0/1 { description se-1/0/0.am; encapsulation ppp; serial-options { clocking-mode dce; clock-rate 8.0mhz; unit 0 { family inet { address /24; family inet6 { address 2001:10:0:34::1/64; se-3/0/0 { description se-1/0/1.mo; 12

13 encapsulation ppp; serial-options { clocking-mode dce; clock-rate 8.0mhz; unit 0 { family inet { address /24; family inet6 { address 2001:10:0:35::1/64; se-3/0/1 { description se-1/0/1.sj; encapsulation ppp; serial-options { clocking-mode dce; clock-rate 8.0mhz; unit 0 { family inet { address /24; family iso; family inet6 { address 2001:10:0:32::1/64; lo0 { unit 0 { family inet { address /32; family iso { address ; family inet6 { address 2001:192:168:5::1/128; routing-options { autonomous-system 65412; protocols { mpls { interface all; interface ge-0/0/0.0 { disable; 13

14 bgp { group vpn { type internal; local-address ; passive; family inet { unicast; family inet-vpn { unicast; cluster ; neighbor ; neighbor ; neighbor ; neighbor ; neighbor ; neighbor ; group ibgp { type internal; local-address 2001:192:168:5::1; passive; neighbor 2001:192:168:8::1; neighbor 2001:192:168:12::1; neighbor 2001:192:168:24::1; neighbor 2001:192:168:21::1; neighbor 2001:192:168:28::1; neighbor 2001:192:168:16::1; isis { level 1 disable; interface ge-0/0/0.0 { disable; interface all; rsvp { interface ge-0/0/0.0 { disable; interface all; ospf { area { interface all; interface ge-0/0/0.0 { disable; ospf3 { 14

15 realm ipv4-unicast { area { interface all; interface ge-0/0/0.0 { disable; area { interface all; interface ge-0/0/0.0 { disable; ldp { interface ge-0/0/0.0 { disable; interface all; lab@sydney-p> exit Connection closed by foreign host. lab@tokyo-pe> Note that BGP is configured on the P router (for future usage as RR), and that MPLS and RSVP signaling has been enabled on all interfaces. Part 5 Configure PE-PE MP-IBGP Peering Session Step 5.1 Each pair of communicating PEs should now define a single MP-IBGP peering session to the remote PE router using loopback addresses as peering points. Issue the following commands while at the [edit protocols bgp] portion of the configuration hierarchy and make sure you enable families inet6-vpn unicast and inet unicast to the bgp group. Here is an example taken from the Tokyo router lab@tokyo-pe# edit protocols bgp [edit protocols bgp] lab@tokyo-pe# set group pe type internal local-address [edit protocols bgp] lab@tokyo-pe# set group pe family inet6-vpn unicast [edit protocols bgp] lab@tokyo-pe# set group pe family inet unicast 15

16 [edit protocols bgp] set group pe neighbor Step 5.2 Configure your PE router s autonomous system number. Enter the following command while at the [edit routing-options] portion of the configuration hierarchy: [edit protocols bgp] lab@tokyo-pe# top lab@tokyo-pe# set routing-options autonomous-system Step 5.3 Show your work, and commit changes when you are satisfied that your PE MP-IBGP peering session has been correctly configured. lab@tokyo-pe# show routing-options autonomous-system 65412; lab@tokyo-pe# show protocols bgp group pe { type internal; local-address ; family inet { unicast; family inet6-vpn { unicast; neighbor ; lab@tokyo-pe# commit and-quit commit complete Exiting configuration mode Step 5.4 Verify that the PE-PE MP-IBGP peering session has been correctly established. lab@tokyo-pe# run show bgp summary Groups: 1 Peers: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State #Active/Received/Accepted/Damped :58 16

17 Establ inet.0: 0/0/0/0 bgp.l3vpn-inet6.0: 0/0/0/0 run show bgp neighbor Peer: AS Local: AS Type: Internal State: Established Flags: <ImportEval Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: <Preference LocalAddress AddressFamily Rib-group Refresh> Address families configured: inet-unicast inet6-vpn-unicast Local Address: Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: Local ID: Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 BFD: disabled, down NLRI for restart configured on peer: inet-unicast inet6-vpn-unicast NLRI advertised by peer: inet-unicast inet6-vpn-unicast NLRI for this session: inet-unicast inet6-vpn-unicast Peer supports Refresh capability (2) Stale routes from peer are kept for: 300 Peer does not support Restarter functionality NLRI that restart is negotiated for: inet-unicast inet6-vpn-unicast NLRI of received end-of-rib markers: inet-unicast inet6-vpn-unicast NLRI of all end-of-rib markers sent: inet-unicast inet6-vpn-unicast Peer supports 4 byte AS extension (peer-as 65412) Peer does not support Addpath Table inet.0 Bit: RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Table bgp.l3vpn-inet6.0 RIB State: BGP restart is complete RIB State: VPN restart is complete Send state: not advertising Active prefixes: 0 Received prefixes: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Last traffic (seconds): Received 6 Sent 11 Checked 83 Input messages: Total 9 Updates 2 Refreshes 0 Octets 186 Output messages: Total 9 Updates 0 Refreshes 0 Octets 272 Output Queue[0]: 0 Output Queue[1]: 0 17

18 Does the MP-IBGP peering session show the correct NLRI families for the support of IPV4 VPNs? If both PE routers have their BGP configured correctly, the peering session should show the correct NLRI families. Look above in the output of the show bgp neighbors command. In the field marked NLRI for this session, it should show both inet-unicast and inet6-vpn-unicast Check your configuration if your MP-IBGP peering session indicates a state of Active, Idle, Connect, or Open. At this time no BGP routes should be sent or received over the PE peering session due to a lack of export policy. Verify this with the following operational mode commands: lab@tokyo-pe# run show route advertising-protocol bgp lab@tokyo-pe# run show route receive-protocol bgp inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) inet6.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) lab@tokyo-pe# run show route protocol bgp inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) inet6.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) Part 6 Configure CE Routing Options Note The 2001:172:x:x::/64 address ranges in this lab have been specifically allocated to demonstrate address overlap within VPNs A and VPNs B and D. This fact should be considered ad-hoc VPNs be formed with other teams. The loopback addresses are unique on all routers, and should be used to test connectivity within expanded VPNs. 18

19 Step 6.1 Define your CE station s 2001:172:x:x::/64 static routes only on your two assigned CE devices. On top of that, you will be configuring an additional static route on your CE that encompasses your loopback interface. Use a /64 prefix length and again a next-hop of receive. Please refer to the following table and diagram to configure your static routes on each router: Denver CE-A1 SaoPaulo CE-A2 Madrid CE-B1 New York CE-B2 2001:172:16:0::/ :172:16:1::/ :172:16:2::/ :172:16:3::/ :172:16:4::/ :172:16:5::/ :172:16:6::/ :172:16:7::/ :172:16:0::/ :172:16:1::/ :172:16:2::/ :172:16:3::/ :172:16:4::/ :172:16:5::/ :172:16:6::/ :172:16:7::/ :192:168:50::/ :192:168:51::/ :192:168:52::/ :192:168:53::/64 Rome CE-C1 Barcelona CE-C2 2001:172:16:0::/ :172:16:1::/ :172:16:2::/ :172:16:3::/ :172:16:4::/ :172:16:5::/ :172:16:6::/ :172:16:7::/ :192:168:54::/ :192:168:55::/64 Log into your CE router and begin configuring your autonomous system number as stated in the lab diagram at the [edit routing-options] portion of the hierarchy: lab@denver-ce_a1# edit routing-options [edit routing-options] lab@denver-ce_a1# set autonomous-system Now configure a static route that encompasses your CE s loopback interface. Ensure that all of your static routes are placed into the right routing table by specifying the rib inet6.0 command: [edit routing-options] lab@denver-ce_a1# set rib inet6.0 static route 2001:192:168:50::/64 receive Next, define the 2001:172:x:x::/64 static routes on your CE router. If desired, you can enter a single aggregate route for your CE s 2001:172:x:x::/64 address block. We are using receive as a nexthop in this case so that attempts to ping or trace routes to these prefixes will succeed. [edit routing-options] lab@denver-ce_a1# set rib inet6.0 static route 2001:172:16:0::/64 receive [edit routing-options] lab@denver-ce_a1# set rib inet6.0 static route 2001:172:16:0::/64 receive 19

20 [edit routing-options] set rib inet6.0 static route 2001:172:16:0::/64 receive [edit routing-options] set rib inet6.0 static route 2001:172:16:0::/64 receive Step 6.2 Verify the correct routing-options configuration on your CE router and commit the configuration. [edit routing-options] show rib inet6.0 { static { route 2001:172:16:0::/64 receive; route 2001:172:16:1::/64 receive; route 2001:172:16:2::/64 receive; route 2001:172:16:3::/64 receive; route 2001:192:168:50::/64 receive; autonomous-system 65000; [edit routing-options] lab@denver-ce_a1# commit and-quit commit complete Exiting configuration mode Repeat the same steps to configure the respective static routes in your other assigned CE router.. Part 7 Configure 6VPE using Static Routes on the CE Router Step 7.1 Configure two static routes on your CE device for each of the subnets associated with the remote CE. The example shown creates an aggregate for the remote CE s 2001:172:x:x::/62 routing block (individual /64s can also be used), and a /64 route that represents the remote CE s lo0 address. Both of these routes point to your PE as the next hop. The following commands are entered at the [edit routing-options] portion of the hierarchy on your CE router: [edit routing-options] lab@denver-ce_a1# edit rib inet6.0 [edit routing-options rib inet6.0] lab@denver-ce_a1# set static route 2001:172:16:4::/62 next-hop 2001:10:0:4::1 [edit routing-options rib inet6.0] lab@denver-ce_a1# set static route 2001:192:168:51::/64 next-hop 2001:10:0:4::1 20

21 [edit routing-options rib inet6.0] commit and-quit commit complete Exiting configuration mode Part 8: Create VRF on PE Router Step 8.1 Familiarize yourself with the overall lab topology using the lab diagram. Log into your PE router and park yourself at the [edit routing-instances vpn-name] portion of the hierarchy. Enter the following commands to create your VPN s VRF table. Initially, we will use static routing on the PE-CE link. VRF names are a purely local matter, but using different names can cause confusion if you should later find yourself issuing VPN-related commands on the other team s PE router. We recommend the use of vpn-a, vpn-b and vpn-c VRF table names. lab@tokyo-pe# edit routing-instances vpn-a lab@tokyo-pe# set instance-type vrf lab@tokyo-pe# set route-distinguisher :1 lab@tokyo-pe# set interface ge-0/0/1 Step 8.2 With the previous commands you created a VRF named vpn-name and assigned a Route Distinguisher (RD) that is based on the PE router s RID. The router s PE-CE interface has also been associated with the VRF. All routes forwarded over this interface will be bound to a VRF label as a single Forwarding Equivalency Class (FEC). We will now link the VRF table with an import and export policy: lab@tokyo-pe# set vrf-import vpna-import lab@tokyo-pe# set vrf-export vpna-export Step 8.3 The static routes associated with your CE will now be configured. Remember to do this under the context of rib vpn-a.inet6.0!! The example shown creates an aggregate for the CE s 2001:172:x:x::/62 routing block (individual /64s can also be used), and a /64 route that represents the CE s lo0 address which points to the CE as the next hop. 21

22 The following commands are entered at the [edit routing-instances vpn-name routingoptions] portion of the hierarchy: edit routing-options rib vpn-a.inet6.0 [edit routing-instances vpn-a routing-options rib vpn-a.inet6.0] set static route 2001:172:16:0::/62 next-hop 2001:10:0:4::2 [edit routing-instances vpn-a routing-options rib vpn-a.inet6.0] set static route 2001:192:168:50::/64 next-hop 2001:10:0:4::2 Step 8.4 Verify your VRF configuration. It should now look similar to this one taken from Tokyo-PE: [edit routing-instances vpn-a routing-options rib vpn-a.inet6.0] up 2 instructor@tokyo-pe# show instance-type vrf; interface ge-0/0/1.0; route-distinguisher :1; vrf-import vpna-import; ## 'vpna-import' is not defined vrf-export vpna-export; ## 'vpna-export' is not defined routing-options { rib vpn-a.inet6.0 { static { route 2001:172:16:0::/62 next-hop 2001:10:0:4::2; route 2001:192:168:50::/64 next-hop 2001:10:0:4::2; Note You will not be able to commit your configuration until you write the VRF import and export policy. Part 9: Create VPN Import and Export Policy Step 9.1 Before writing the VPN import and export policy, you will create the named BGP extended communities that will serve as your VPN s route target and site-of-origin (SoO) attributes. Consult the following table to determine the correct values for your assigned VPN s Target Community. 22

23 VPN: A B C Assigned Target Values: target:65412:100 target:65412:200 target:65412:300 Step 9.2 Position yourself at the [edit policy-options] portion of the hierarchy and create your named communities: lab@tokyo-pe# top lab@tokyo-pe# edit policy-options [edit policy-options] lab@tokyo-pe# set community vpna-target members target:65412:100 [edit policy-options] lab@tokyo-pe# set community vpna-origin members origin: :1 Step 9.3 Note Currently there is no best practice regarding how providers will actually assign the SOO attribute. In these labs, the SOO is set based upon the RID of the PE that is serving a particular site, with a unique integer value assigned to each VRF within that PE. In this case, we are using the number 1 as this is the first (and only) VRF currently defined in your PE. Write your VRF import policy. The VRF import policy filters routes received from other PE routers via MP-IBGP. Your policy will only accept routes tagged with the target of your particular VPN. Position yourself at the [edit policy-options policy-statement vpn-name-import] portion of the hierarchy and enter the following configuration statements: [edit policy-options] lab@tokyo-pe# edit policy-statement vpna-import [edit policy-options policy-statement vpna-import] lab@tokyo-pe# set term 1 from protocol bgp [edit policy-options policy-statement vpna-import] lab@tokyo-pe# set term 1 from community vpna-target [edit policy-options policy-statement vpna-import] lab@tokyo-pe# set term 1 then accept [edit policy-options policy-statement vpna-import] lab@tokyo-pe# set term 2 then reject Show your completed policy; it should be similar to this one taken from Tokyo-PE: 23

24 [edit policy-options policy-statement vpna-import] show term 1 { from { protocol bgp; community vpna-target; then accept; term 2 { then reject; Step 9.4 Now you will create a VRF export policy to control what routes are advertised via MP-IBGP to other PE routers. Ensure that you tag the exported routes with the correct target and SoO communities. Enter the following statements at the [edit policy-options policy-statement vpnname-export] portion of the hierarchy: [edit policy-options policy-statement vpna-import] lab@tokyo-pe# up [edit policy-options] lab@tokyo-pe# edit policy-statement vpna-export [edit policy-options policy-statement vpna-export] lab@tokyo-pe# set term 1 from protocol static [edit policy-options policy-statement vpna-export] lab@tokyo-pe# set term 1 then community add vpna-target [edit policy-options policy-statement vpna-export] lab@tokyo-pe# set term 1 then community add vpna-origin [edit policy-options policy-statement vpna-export] lab@tokyo-pe# set term 1 then accept [edit policy-options policy-statement vpna-export] lab@tokyo-pe# set term 2 then reject Step 9.5 Verify your export policy and commit your work. It should be similar to this example taken from Tokyo: [edit policy-options policy-statement vpna-export] lab@tokyo-pe# show term 1 { from protocol static; then { community add vpna-target; community add vpna-origin; accept; 24

25 term 2 { then reject; [edit policy-options policy-statement vpna-export] lab@tokyo-pe# commit and-quit commit complete Exiting configuration mode Note Follow the same steps and configure similarly your other PE device Step 9.6 To verify the functionality of the PE-CE VRF interface, issue the following operational mode command: lab@tokyo-pe> ping 2001:10:0:4::2 routing-instance vpn-a count 3 PING6(56= bytes) 2001:10:0:4::1 --> 2001:10:0:4::2 16 bytes from 2001:10:0:4::2, icmp_seq=0 hlim=64 time=6.986 ms 16 bytes from 2001:10:0:4::2, icmp_seq=1 hlim=64 time=6.237 ms 16 bytes from 2001:10:0:4::2, icmp_seq=2 hlim=64 time=3.686 ms :10:0:4::2 ping6 statistics packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/std-dev = 3.686/5.636/6.986/1.413 ms Are the pings successful? Step 9.7 The pings should be successful. Verify that your VRF table contains the correct directly connected, static, and BGP routes.your VRF table should now appear similar to this example taken from Tokyo. To examine your VRF, enter the following command: lab@tokyo-pe> show route table vpn-a.inet6.0 terse vpn-a.inet6.0: 8 destinations, 8 routes (6 active, 0 holddown, 2 hidden) + = Active Route, - = Last Active, * = Both A Destination P Prf Metric 1 Metric 2 Next hop AS path * 2001:10:0:4::/64 D 0 >ge-0/0/1.0 * 2001:10:0:4::1/128 L 0 Local * 2001:172:16::/62 S 5 >2001:10:0:4::2 2001:192:168:50::/64 * S 5 >2001:10:0:4::2 25

26 * fe80::/64 D 0 >ge-0/0/1.0 fe80::21d:b5ff:fe0f:6301/128 * L 0 Local Hypothesize as to why your VRF table does not display any routes from the remote PE. Are there any hidden routes? You should notice that hidden MP-BGP routes exist from the remote PE router. lab@tokyo-pe> show route table vpn-a.inet6.0 hidden vpn-a.inet6.0: 8 destinations, 8 routes (6 active, 0 holddown, 2 hidden) + = Active Route, - = Last Active, * = Both 2001:172:16:4::/62 [BGP/170] 00:11:44, localpref 100, from AS path: I Unusable 2001:192:168:51::/64 [BGP/170] 00:11:44, localpref 100, from AS path: I Unusable If you use the extensive switch and check the details for one of your hidden routes you will discover the reason it is hidden lab@tokyo-pe> show route hidden 2001:192:168:51::/64 extensive vpn-a.inet6.0: 8 destinations, 8 routes (6 active, 0 holddown, 2 hidden) 2001:192:168:51::/64 (1 entry, 0 announced) BGP Preference: 170/-101 Route Distinguisher: :1 Next hop type: Unusable Address: 0x8e71fe4 Next-hop reference count: 4 State: <Secondary Hidden Int Ext> Local AS: Peer AS: Age: 13:55 Task: BGP_ AS path: I Communities: target:65412:100 origin: :1 Import Accepted VPN Label: Localpref: 100 Router ID: Primary Routing Table bgp.l3vpn-inet6.0 26

27 Indirect next hops: 1 Protocol next hop: ::ffff: Push Indirect next hop: 0 - Note The next-hop ::ffff: in the example, is the IPv4-mapped representation of the IPv4 address of HongKong s loopback interface. The next hop is automatically converted by the router when an IPv6 route is transported over an IPv4 session. An IPv4-mapped address has its first 80 bits set to zero and the next 16 set to one, while its last 32 bits are filled with the IPv4 address. These addresses are commonly represented in the standard IPv6 format, but having the last 32 bits written in the customary dot-decimal notation of IPv4; for example, ::ffff: represents the IPv4 address What could be causing these routes to be hidden? How can you obtain more information regarding hidden routes? These hidden routes have an unusable next-hop indication. Use the show route hidden extensive command to obtain more information about these routes. This indication results from the absence of MPLS LSPs between PE routers. L3 VPN MP-BGP routes must resolve their next-hop through an LSP. At present the lack of established LSPs are causing these MP-BGP routes to be hidden. Note The unusable next hop indication results from the absence of MPLS LSPs between PE routers. Labeled IP V6 routes must point to an LSP that resolves to the advertised BGP next-hop. Further, this LSP must reside in the inet6.3 table routing table. At present, this table is empty due to the lack of established LSPs. We will resolve this situation in the next part. Enter the following command on your PE router: lab@tokyo-pe> show route table inet.3 lab@tokyo-pe> show route table inet6.3 27

28 Part 10: Establish LSPs Between Communicating PEs Step 10.1 First, we will enable RSVP signalling on all PE router interfaces. Enter the following command at the [edit protocols] hierarchy on your PE router: edit Entering configuration mode edit protocols [edit protocols] set rsvp interface all Step 10.2 Establish an RSVP-signalled LSP to your peer. Enter the following commands at the [edit protocols mpls] hierarchy on your PE router: [edit protocols] edit mpls [edit protocols mpls] set label-switched-path Tokyo-to-HongKong to no-cspf Verify that your configuration looks like this sample taken from Tokyo and commit your work: [edit protocols] show rsvp interface all; [edit protocols] show mpls label-switched-path Tokyo-to-HongKong { to ; no-cspf; interface all; interface ge-0/0/0 disable; [edit protocols] lab@tokyo-pe# commit and-quit commit complete Exiting configuration mode Note Follow the same steps and configure a similar LSP on your other PE device 28

29 Have both LSPs (between PEs) been established? Does the LSP appear in your inet.3 table now? Yes, the loopback address of the terminating point of your LSP has been installed into inet.3. RSVP, which is the protocol used in the lab to signal your LSPs, installs routes to the egress router s address in inet.3. lab@tokyo-pe> show mpls lsp Ingress LSP: 1 sessions To From State Rt P ActivePath LSPname Up 0 * Tokyo-to-HongKong Total 1 displayed, Up 1, Down 0 Egress LSP: 1 sessions To From State Rt Style Labelin Labelout LSPname Up 0 1 FF 3 - HongKong-to- Tokyo Total 1 displayed, Up 1, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0 lab@tokyo-pe> show route table inet.3 inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both /32 *[RSVP/7/1] 00:01:56, metric 20 > via se-1/0/1.0, label-switched-path Tokyo-to-HongKong Step 10.3 Has this newly configured LSP (and the correspondent entry on inet.3) fixed the problem so there are no hidden routes anymore in your vpn-a.inet6.0 table? No, routes from the remote PE remain hidden!! lab@tokyo-pe> show route table vpn-a.inet6.0 terse vpn-a.inet6.0: 8 destinations, 8 routes (6 active, 0 holddown, 2 hidden)+ = Active Route, - = Last Active, * = Both 29

30 A Destination P Prf Metric 1 Metric 2 Next hop AS path * 2001:10:0:4::/64 D 0 >ge-0/0/1.0 * 2001:10:0:4::1/128 L 0 Local * 2001:172:16::/62 S 5 >2001:10:0:4::2 2001:192:168:50::/64 * S 5 >2001:10:0:4::2 * fe80::/64 D 0 >ge-0/0/1.0 fe80::21d:b5ff:fe0f:6301/128 * L 0 Local lab@tokyo-pe> show route hidden extensive match "Protocol next hop:" Protocol next hop: ::ffff: Protocol next hop: ::ffff: Protocol next hop: ::ffff: Protocol next hop: ::ffff: Note Remember that those MP-BGP routes received from the remote PE still have a protocol next hop set to the IPv4-mapped address of the advertising PE. To resolve this next hop BGP through the LSP between Tokyo and HongKong, BGP would need to find a route for ::ffff: , in the equivalent inet.3 routing table for IPv6, pointing to the LSP. That is the inet6.3 table. At this point there is no such a route Part 11: Enable IPv6 Tunnelling over MPLS Step 11.1 Enable IPv6 tunnelling over your LSP and commit your configuration: lab@tokyo-pe> edit Entering configuration mode lab@tokyo-pe# set protocols mpls ipv6-tunneling lab@tokyo-pe# commit and-quit commit complete Exiting configuration mode What is the effect of this command? Enter the show route summary command. Are there any new routing tables? 30

31 When you enter the show route summary command look towards the bottom of the output. A new routing table called inet6.3 was created by the IPv6-tunneling command. lab@tokyo-pe> show route summary Autonomous system number: Router ID: inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) Direct: 3 routes, 3 active Local: 2 routes, 2 active IS-IS: 3 routes, 3 active inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) RSVP: 1 routes, 1 active iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) Direct: 1 routes, 1 active mpls.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) MPLS: 3 routes, 3 active VPN: 1 routes, 1 active inet6.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) RSVP: 1 routes, 1 active vpn-a.inet6.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) Direct: 2 routes, 2 active Local: 2 routes, 2 active BGP: 2 routes, 2 active Static: 2 routes, 2 active bgp.l3vpn-inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) BGP: 2 routes, 2 active This statement allows IPv6 routes to be resolved over an MPLS network by converting all routes stored in the inet.3 routing table to IPv4-mapped IPv6 addresses and then copying them into the inet6.3 routing table. This routing table can be used to resolve next hops for both inet6 and inet6- vpn routes. The routes are added to inet6.3. You can check the contents of inet6.3 by entering the show route table inet6.3 command. What routes do you see in there? inet6.3 contains IPv4-mapped representation of the loopback interfaces IPv4 addresses used to define the egress router for the different LSPs on your router. It is just a conversion from inet.3 to inet6.3 31

32 show route table inet6.3 inet6.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both ::ffff: /128 *[RSVP/7/1] 00:03:01, metric 20 > via se-1/0/1.0, label-switched-path Tokyo-to-HongKong Is BGP now able to resolve the next hop of the remote PE IPv6 routes using this routing table? Check the next hop of these routes and compare it with the entries in inet6.3 Now that inet6.3 exists, and is being populated with routes by RSVP, BGP should be able to use the LSPs to perform next-hop resolution for IPv6 routes. You should see no hidden routes any longer lab@tokyo-pe> show route table vpn-a.inet6.0 terse vpn-a.inet6.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both A Destination P Prf Metric 1 Metric 2 Next hop AS path * 2001:10:0:4::/64 D 0 >ge-0/0/1.0 * 2001:10:0:4::1/128 L 0 Local * 2001:172:16::/62 S 5 >2001:10:0:4::2 * 2001:172:16:4::/62 B >se-1/0/1.0 I 2001:192:168:50::/64 * S 5 >2001:10:0:4::2 2001:192:168:51::/64 * B >se-1/0/1.0 I * fe80::/64 D 0 >ge-0/0/1.0 fe80::21d:b5ff:fe0f:6301/128 * L 0 Local Looking good!!! It seems that now the IPv6 learned route uses the LSP for the fowarding! This is because the BGP next-hop of the route could be now resolved through inet6.3 Part 12: Verify Network Operation Step 12.1 Do you now have complete routing information for the remote CE location? 32

33 The routes advertised by the remote PE router should no longer be hidden. Your PE router should now have reachability to the remote CE router. How is your PE learning about the static routes defined on the remote PE? The routes learned from the remote PE router are learned using MP-BGP. Why are there two labels associated with the routes learned from the remote PE? Where does each label come from? Notice the output of the command below. There are two labels associated with this route a top and a bottom label. The bottom label (innermost) was learned using the MP-BGP advertisement, which maps to the remote VRF table for this VPN. The top label (outermost) is the label that was signaled by RSVP in relation to the MPLS LSP that exists between the PE routers. lab@tokyo-pe> show route table vpn-a 2001:192:168:51::/64 extensive vpn-a.inet6.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) 2001:192:168:51::/64 (1 entry, 1 announced) TSI: KRT in-kernel 2001:192:168:51::/64 -> {indirect(262142) *BGP Preference: 170/-101 Route Distinguisher: :1 Next hop type: Indirect Address: 0x9268b08 Next-hop reference count: 6 Source: Next hop type: Router, Next hop index: 590 Next hop: via se-1/0/1.0 weight 0x1, selected Label-switched-path Tokyo-to-HongKong Label operation: Push , Push (top) Label TTL action: prop-ttl, prop-ttl(top) Protocol next hop: ::ffff: Push Indirect next hop: 947c State: <Secondary Active Int Ext> Local AS: Peer AS: Age: 8:55 Metric2: 20 Task: BGP_ Announcement bits (1): 1-KRT AS path: I Communities: target:65412:100 origin: :1 Import Accepted VPN Label:

34 Localpref: 100 Router ID: Primary Routing Table bgp.l3vpn-inet6.0 Indirect next hops: 1 Protocol next hop: ::ffff: Metric: 20 Push Indirect next hop: Indirect path forwarding next hops: 1 Next hop type: Router Next hop: via se-1/0/1.0 weight 0x1 ::ffff: /128 Originating RIB: inet6.3 Metric: 20 Node path count: 1 Forwarding nexthops: 1 Nexthop: via se-1/0/1.0 Step 12.2 Determine what label your PE has assigned to the routes in your VRF: lab@tokyo-pe> show route advertising-protocol bgp detail vpn-a.inet6.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) * 2001:172:16::/62 (1 entry, 1 announced) BGP group pe type Internal Route Distinguisher: :1 VPN Label: Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [65412] I Communities: target:65412:100 origin: :1 * 2001:192:168:50::/64 (1 entry, 1 announced) BGP group pe type Internal Route Distinguisher: :1 VPN Label: Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [65412] I Communities: target:65412:100 origin: :1 What label is associated with the routes in your VRF? The output of the command above shows that Tokyo-PE has assigned a label of to the vpn-a VRF table. This label might differ from PE router to PE router. 34

35 You might want to take a few moments to issue the following commands and analyze the resulting output: lab@tokyo-pe> show route protocol bgp detail lab@tokyo-pe> show route forwarding-table vpn vpn-a lab@tokyo-pe> show rsvp session ingress detail lab@tokyo-pe> show route table bgp.l3vpn-inet6.0 Step 12.3 Verify proper CE-to-CE connectivity by logging into your CE router and generating pings targeted at the remote CE router s loopback address. lab@denver-ce_a1> ping 2001:192:168:51::1 count 3 PING6(56= bytes) 2001:10:0:4::2 --> 2001:192:168:51:: :192:168:51::1 ping6 statistics packets transmitted, 0 packets received, 100% packet loss Why do you think the pings are failing? The pings are failing because the source address of each of your ping packets happens to be the outgoing interface of your CE router. At this point, neither CE router has a route to the remote CE router s VRF interface. Reissue the ping command, but this time source the packet from the CE s lo0 interface: lab@denver-ce_a1> ping 2001:192:168:51::1 source 2001:192:168:50::1 count 3 PING6(56= bytes) 2001:192:168:50::1 --> 2001:192:168:51::1 16 bytes from 2001:192:168:51::1, icmp_seq=0 hlim=61 time=6.391 ms 16 bytes from 2001:192:168:51::1, icmp_seq=1 hlim=61 time=6.441 ms 16 bytes from 2001:192:168:51::1, icmp_seq=2 hlim=61 time=6.369 ms :192:168:51::1 ping6 statistics packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/std-dev = 6.369/6.400/6.441/0.030 ms Why do the pings succeed when sourced from your CE s loopback, but not when they originate from the PE-CE VRF interface? 35

36 Step 12.4 Because the remote CE router does have a static route to your loopback address but has not learned a route to you VRF interface, it can only reply to the echo-request messages sourced from your loopback address. Trace the route to the remote CE s loopback address: lab@denver-ce_a1> traceroute 2001:192:168:51::1 source 2001:192:168:50::1 traceroute6 to 2001:192:168:51::1 (2001:192:168:51::1) from 2001:192:168:50::1, 64 hops max, 12 byte packets :10:0:4::1 (2001:10:0:4::1) ms ms ms 2 * * * 3 * * * :192:168:51::1 (2001:192:168:51::1) ms ms ms Do the P router hops show up in the resulting display? How do you think this is accomplished? The P router hops might not show up because as packets between VPN sites traverse the provider core, the outer MPLS header s TTL value is initially set to 255 when using the original FPC on the PE router no matter what the original packet s TTL might have been. The P router hops might show up as traceroute timeouts, as above, when using the Enhanced FPC on the PE router. The Enhanced FPC copies the original packet s TTL into all levels of the encapsulating MPLS headers. Because the P routers have no VPN routes in their routing table, they are unable to respond to the TTL expirations of a traceroute. Part 13: Configure BGP Routing on the PE-CE Link Step 13.1 We will now convert the PE-CE protocol from static routing to EBGP. While it is possible to have one PE-CE link using static routing while the other is running BGP, it is recommended that both PE teams embark upon this task in unison. Remove the static route definitions, vrf-import and vrf-export statements, and the routedistinguisher from the PE router s VRF table. lab@tokyo-pe> edit Entering configuration mode lab@tokyo-pe# edit routing-instances vpn-a lab@tokyo-pe# delete routing-options lab@tokyo-pe# delete vrf-import 36

37 delete vrf-export delete route-distinguisher Step 13.2 Configure the ability for your PE router to automatically generate a Type 1 route distinguisher for each of its potential VRF tables. Enter the following command at the [edit routing-options] hierarchy on your PE router!!: lab@tokyo-pe# top edit routing-options [edit routing-options] lab@tokyo-pe# set route-distinguisher-id Step 13.3 To configure EBGP peering to your CE using the VRF interface. Enter the following commands at the [edit protocols routing-instances vpn-name] portion of the configuration hierarchy on your PE router: [edit routing-options] lab@tokyo-pe# top edit routing-instances vpn-a lab@tokyo-pe# set protocols bgp group ce-a1 type external peer-as lab@tokyo-pe# set protocols bgp group ce-a1 neighbor 2001:10:0:4::2 Step 13.4 Configure the VRF table to automatically advertise all routes in the VRF table as MP-BGP routes tagged with the appropriate route target community using the vrf-target statement. Enter the following commands at the [edit routing-instances vpn-name] hierarchy on your PE router: lab@tokyo-pe# set vrf-target import target:65412:100 lab@tokyo-pe# set vrf-target export target:65412:100 Step 13.5 View the resulting VPN configuration, and commit your changes when you are satisfied that all is correct. Your configuration should look similar to Tokyo-PE s configuration: 37