Monitor RSVP LSP Configure and monitor a LDP LSP Manipulate the default behavior of RSVP and LDP, depending on network requirements.

Transcription

1 Lab 1 MPLS Overview This lab demonstrates configuration and monitoring of Resource Reservation Protocol (RSVP) and Label Distribution (LDP) signalled label switched path (LSP) features on routers running the Junos operating system. In this lab, you use the command-line interface (CLI) to configure and monitor network interfaces, IS-IS, Border Gateway Protocol (BGP), RSVP LSPs, and LDP LSPs All these exercises assume you already have some basic 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 interface addresses and families on your PE and CE routers Configure the core IGP Configure IBGP & EBGP peering between communicating routers Configure CE routing options Configure and monitor a RSVP LSP Monitor RSVP LSP Configure and monitor a LDP LSP Manipulate the default behavior of RSVP and LDP, depending on network requirements. Please refer to the next page lab diagram to perform this exercise and only use the topology that corresponds to your assigned POD (either A, B or C) : 1

2 Lab Diagram Lab 1: MPLS x.y/24 = Serial Interfaces 10.0.x.y/24 = PE-CE Interfaces x.y/32 = Loopback Interfaces 172.x.0-7/24= Static Routes POD A AS MPLS LSP AS CE-A1 Barcelona: / / / / / / / / ge-0/0/1.0 Tokyo-PE se-1/0/1 se-1/0/1 Sydney-P se-1/0/0 se-1/0/0 HongKong-PE 12.1 ge-0/0/1.0 fe-2/0/ lo0: 1.2 lo0: lo0: ge-0/0/ ebgp Route Reflector ebgp ibgp ibgp Static Routes (Virtual Customer Networks) Provider Core ISIS Level 2 AS CE-A2 SaoPaulo / / / /24 2

3 Lab 1: MPLS x.y/24 = Serial Interfaces 10.0.x.y/24 = PE-CE Interfaces x.y/32 = Loopback Interfaces 172.x.0-7/24 = Static Routes POD B AS MPLS LSP AS CE-B1 Madrid / / / / / / / / ge-0/0/1.0 London-PE se-1/0/0 se-2/0/0 Sydney-P se-2/0/1 se-1/0/0 Amsterdam-PE lo0: 14.1 ge-0/0/1.0 ge-0/0/ lo0: lo0: ge-0/0/ Route Reflector ebgp ebgp ibgp ibgp Static Routes (Virtual Customer Networks) Provider Core ISIS Level 2 AS CE-B2 NewYork / / / /24 3

4 Lab 1: MPLS x.y/24 = Serial Interfaces 10.0.x.y/24 = PE-CE Interfaces x.y/32 = Loopback Interfaces 172.x.0-7/24 = Static Routes POD C AS MPLS LSP AS CE-C1 Rome / / / / / ge-0/0/3.0 fe-0/0/ ebgp SanJosePE lo0: Static Routes (Virtual Customer Networks) / /24 se-1/0/1 se-3/0/1 Sydney-P ge-0/0/3 ge-0/0/ lo0: Route Reflector ibgp ibgp Provider Core ISIS Level 2 AS Montreal-PE lo0: / ge-0/0/2.0 ge-0/0/ ebgp CE-C2 Denver / / / /24 4

5 Key Commands Key operational mode commands used in this lab include the following:? configure show bgp summary show route advertising-protocol bgp show route protocol bgp clear mpls lsp show mpls interface show mpls lsp show rsvp interface show rsvp neighbor show rsvp sessions show ldp database show ldp neighbor show ldp session show route table inet.3 traceroute Part 1: Patching and Configuration Reset Step 1.1 Familiarize yourself with the MPLS setup in the lab 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 lab1-mpls-start file that is located in the mpls/ directory of your device. This will give us a working baseline configuration on the devices. Note Please do NOT delete interface ge-0/0/0 as this is your management interface which provides access to your session!! Do NOT delete either the security section of your configurations. This allows your system to permit any traffic in/out. lab@tokyo-pe> configure Entering configuration mode lab@tokyo-pe# load override mpls/lab1-mpls-start load complete Familiarize with the configuration just loaded. You will notice that family inet is already configured on the interfaces with respective IPv4 addresses for the core facing interfaces and customer facing interfaces. There is not much more configured Once you are satisfied commit your configuration. 5

6 commit and-quit commit complete Now login into both your CE assigned devices and load the mpls/lab1-mpls-start file. This will give us a working baseline configuration. lab@barcelona-ce_a1> configure Entering configuration mode lab@barcelona-ce_a1# load override mpls/lab1-mpls-start load complete Familiarize with the configuration just loaded. Like in the PE case, you will notice that the inet family is configured on the interfaces with respective addresses. Nothing else really. Once you are satisfied with your inspection go ahead and commit your configuration. lab@barcelona-ce_a1# commit and-quit commit complete Note Remember that the exercise proposed in this documentation is generic and the examples given here apply only to one particular pod of devices. Please adapt the example to your assigned set of devices (POD-A, POD-B or POD-C). Look at you lab diagram and mind the pod of systems that you have been assigned! Part 2: Configure Core And Core Facing IGP (IS-IS) Step 2.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 assigned two PE routers. Router Name ISO NET Address San Jose (PE) Amsterdam (PE) Hong Kong (PE) Montreal (P3) Tokyo (PE) London (PE)

7 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 2.2 You must add the family iso to each of your PE core facing interface (that is the serial interface se-x/x/x or ge-x/x/x) 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 iso Note Repeat these commands for your other assigned PE device 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-Barcelona"; unit 0 { family inet { address /24; se-1/0/1 { description "to Sydney-P"; unit 0 { family inet { address /24; family iso; 7

8 lo0 { unit 0 { family inet { address /32; family iso { address ; lab@tokyo-pe# commit commit complete Step 2.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. lab@tokyo-pe# run ping count 3 PING ( ): 56 data bytes 64 bytes from : icmp_seq=0 ttl=64 time=2.519 ms 64 bytes from : icmp_seq=1 ttl=64 time=1.405 ms 64 bytes from : icmp_seq=2 ttl=64 time=4.082 ms ping statistics packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.405/2.669/4.082/1.098 ms [edit interfaces] lab@tokyo-pe# run ping count 3 PING ( ): 56 data bytes 64 bytes from : icmp_seq=0 ttl=64 time=3.354 ms 64 bytes from : icmp_seq=1 ttl=64 time=2.682 ms 64 bytes from : icmp_seq=2 ttl=64 time=2.654 ms ping statistics packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.654/2.897/3.354/0.324 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 8

9 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 inet /24 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 Ensure you perform similar steps on your other PE device. Step 2.4: IS-IS For IS-IS, we will configure a single Level 2 routing area. Enable the protocol just in the core facing interfaces. Enter the following commands while at the [edit protocols isis] portion of the configuration hierarchy (this example is taken from the Tokyo router, please adapt your configuration to your PE assigned devices): lab@tokyo-pe# set protocols isis level 1 disable lab@tokyo-pe# set protocols isis interface se-1/0/1 9

10 set protocols isis interface lo0 Note Repeat similar steps on your other assigned PE device. Ensure you include the loopback (lo0); do not configure the PE-CE interface here! Step 2.5 Show your work, and commit changes when you are satisfied that IS-IS Level 2 has been correctly configured: lab@tokyo-pe# show protocols 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 2.6 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 topology. 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 adjacency Interface System L State Hold (secs) SNPA se-1/0/1.0 Sydney-P 2 Up 23 lab@tokyo-pe> show isis interface IS-IS interface database: 10

11 Interface L CirID Level 1 DR Level 2 DR L1/L2 Metric lo x1 Passive Passive 0/0 se-1/0/ x1 Disabled Point to Point 10/10 lab@tokyo-pe> show isis hostname IS-IS hostname database: System ID Hostname Type Tokyo-PE Static HongKong-PE Dynamic Sydney-P Dynamic lab@tokyo-pe> 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 x6d 0xf L1 L2 HongKong-PE x4 0x L1 L2 Sydney-P x6f 0xcc L1 L2 3 LSPs (Do not worry if you see additional LSPs from other PODs) lab@tokyo-pe> traceroute traceroute to ( ), 30 hops max, 40 byte packets ( ) ms ms ms ( ) ms ms ms Part 3: View the Configuration of the P Router Step 3.1 The router Sydney is performing a P role and has been preconfigured. You do not need to touch it or configure anything in there. However, feel free at any time to take a look at its configuration. You will notice that it contains OSPF, ISIS, BGP, MPLS, RSVP and LDP protocols enabled as well as some other miscellaneous IPv6 statements not relevant for this lab exercise 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 (ttyp0) 11

12 login: lab Password: --- JUNOS 9.3R3.8 built :33:43 UTC show configuration ## Last commit: :17:00 UTC by lab version 9.3R3.8; groups { ISIS { interfaces { <*-*> { unit 0 { family iso; family mpls; system { host-name Sydney-P; interfaces { apply-groups ISIS; ge-0/0/0 { apply-groups-except ISIS; description "MGMT INTERFACE - DO NOT DELETE"; unit 0 { family inet { address /16; se-1/0/0 { description se-1/0/0.hk; encapsulation ppp; serial-options { clocking-mode dce; clock-rate 8.0mhz; unit 0 { family inet { address /24; family inet6 { address 2001:10:0:33::1/64; se-1/0/1 { description se-1/0/1.to; encapsulation ppp; serial-options { 12

13 ... clocking-mode dce; clock-rate 8.0mhz; unit 0 { family inet { address /24; family inet6 { address 2001:10:0:30::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 { rsvp { interface all; interface ge-0/0/0.0 { disable; mpls { interface all; interface ge-0/0/0.0 { disable; bgp { group vpn { type internal; local-address ; passive; family inet { unicast; family inet-vpn { unicast; 13

14 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; ospf { area { interface all; interface ge-0/0/0.0 { disable; ospf3 { 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; 14

15 interface all; Note that BGP is already configured on the P router (for future usage as RR), and that MPLS and RSVP & LDP signaling has been enabled on all interfaces. Once you are satisfied logout the P router and return to your PE device: lab@sydney-p> exit Connection closed by foreign host. lab@tokyo-pe> Part 4: Configure IBGP and EBGP Peering Sessions Step 4.1 Every router within the Provider Core should have an IBGP session to each other, that is a full mesh of sessions. In this lab exercise, instead of implementing a full mesh of IBGP sessions we will practice with the concept of Route Reflection. Your PE routers inside the AS should only peer with the reflector of its cluster (the Sydney-P router), becoming then clients. As you have noticed in the previous section, the Sydney-P router has been preconfigured to take the role of a Route Reflector within a cluster Remember that clients do not peer between them so the only thing to be done at the PE routers is to peer to the Route Reflector loopback address. Issue the following commands while at the [edit protocols bgp] portion of the configuration hierarchy. Here is an example taken from the Tokyo router lab@tokyo-pe> configure Entering configuration mode lab@tokyo-pe# edit protocols bgp [edit protocols bgp] lab@tokyo-pe# set group ibgp type internal local-address [edit protocols bgp] lab@tokyo-pe# set group ibgp neighbor Step 4.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

16 Step 4.3 Show your work, and commit changes when you are satisfied that your PE MP-IBGP peering session has been correctly configured. show routing-options autonomous-system 65412; show protocols bgp group ibgp { type internal; local-address ; neighbor ; lab@tokyo-pe# commit commit complete Step 4.4 Note Repeat similar steps on your other assigned PE device so the IBGP session with the Route Reflector will come up too Wait a minute or so, and verify that the IBGP peering session with your route reflector has been correctly established. Issue the following command in both your PE router and based on the output answer the questions: 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 :44 0/0/0/0 0/0/0/0 Did the IBGP peering session establish successfully? Yes it did. Both your PE routers should be now clients to the Sydney-P route reflector with their respective IBGP sessions established 16

17 Please review your configuration if your 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: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) lab@tokyo-pe# run show route protocol bgp inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) Step 4.5 For EBGP links, peer to the neighbor s physical interface address of the directly connected CE device. Check the lab diagram for IP addresses and AS numbers to be configured and go ahead and configure your EBGP sessions. Mind the AS number indicated in the lab diagram for each POD! lab@tokyo-pe# edit protocols bgp [edit protocols bgp] lab@tokyo-pe# set group ebgp type external [edit protocols bgp] lab@tokyo-pe# set group ebgp peer-as [edit protocols bgp] lab@tokyo-pe# set group ebgp neighbor Display your configuration. It should look like this: [edit protocols bgp] lab@tokyo-pe# show group ibgp { type internal; local-address ; neighbor ; group ebgp { type external; peer-as 65000; neighbor ; 17

18 Step 4.6 Create an aggregate route in your PE device that encompasses the loopback address of each PE on the AS For our case, let s be generous and configure no less than a /19. That will catch all loopbacks from every PE on every POD in AS [edit protocols bgp] lab@tokyo-pe# top lab@tokyo-pe# set routing-options aggregate route /19 Now create a policy called adv-aggr that matches and accepts this aggregate route. lab@tokyo-pe# edit policy-options policy-statement adv-aggr [edit policy-options policy-statement adv-aggr] lab@tokyo-pe# set term 1 from protocol aggregate [edit policy-options policy-statement adv-aggr] lab@tokyo-pe# set term 1 from route-filter /19 exact [edit policy-options policy-statement adv-aggr] lab@tokyo-pe# set term 1 then accept Your policy should look like this: [edit policy-options policy-statement adv-aggr] lab@tokyo-pe# show term 1 { from { protocol aggregate; route-filter /19 exact; then accept; At last, apply this newly created policy to your ebgp group so your external peers will get this /19 advertisment that comprises all possible loopback addresses in AS Once you are satisfied with your configuration go ahead and commit your changes: [edit policy-options policy-statement adv-aggr] lab@tokyo-pe# top lab@tokyo-pe# set protocols bgp group ebgp export adv-aggr lab@tokyo-pe# commit commit complete 18

19 Note Perform similar steps on your other assigned PE device so your EBGP session gets configured as described in this lab section. Please refer to the lab diagram. Part 5 : Configure CE Routing Options and BGP Step 5.1 Log into both your CE routers and configure the static routes and AS number shown on the lab handout. Enter the following commands at the [edit routing-options] portion of the hierarchy: lab@barcelona-ce_a1# edit routing-options [edit routing-options] lab@barcelona-ce_a1# set autonomous-system Begin configuring a static route that encompasses your CE s loopback interface. [edit routing-options] lab@barcelona-ce_a1# set static route /24 reject Next, define the 172.x static routes on your CE router. Please refer to the lab diagram to figure out which routes should be configuring on each CE device!. We are using reject in this case so that attempts to ping or trace routes to these prefixes will result in an ICMP error message. [edit routing-options] lab@barcelona-ce_a1# set static route /24 reject [edit routing-options] lab@barcelona-ce_a1# set static route /24 reject [edit routing-options] lab@barcelona-ce_a1# set static route /24 reject [edit routing-options] lab@barcelona-ce_a1# set static route /24 reject Step 5.2 Verify the correct routing-options configuration on your CE router and commit the configuration. lab@barcelona-ce_a1# show static { route /24 reject; route /24 reject; route /24 reject; route /24 reject; route /24 reject; autonomous-system 65000; 19

20 [edit routing-options] commit commit complete Note Repeat similar steps on your other assigned CE device making sure you configure the right static routes as stated in the lab diagram. Do not forget to configure a static route that encompasses your loopback interface! This is a common mistake that will make the lab not to work Step 5.3 On the CE router, configure the EBGP session with the local PE router. Enter the following commands at the [edit protocols bgp] hierarchy on your CE router: [edit routing-options] lab@barcelona-ce_a1# top edit protocols bgp [edit protocols bgp] lab@barcelona-ce_a1# set group pe type external peer-as [edit protocols bgp] lab@barcelona-ce_a1# set group pe neighbor Step 5.4 Create and apply a policy to redistribute the CE router s static routes into BGP. Enter the following commands at the [edit policy-options] hierarchy on your CE router: [edit protocols bgp] lab@barcelona-ce_a1# top edit policy-options [edit policy-options] lab@barcelona-ce_a1# set policy-statement stat term 1 from protocol static [edit policy-options] lab@barcelona-ce_a1# set policy-statement stat term 1 then accept Your completed policy should be similar to this example from router Barcelona-CE-A1: [edit policy-options] lab@barcelona-ce_a1# show policy-statement stat { term 1 { from protocol static; then accept; 20

21 Step 5.5 Apply your static route redistribution policy to BGP and commit you configuration. Enter the following commands at the [edit protocols bgp] hierarchy on your CE router: [edit policy-options] top edit protocols bgp [edit protocols bgp] set group pe export stat [edit protocols bgp] commit and-quit commit complete Exiting configuration mode Note Perform identical steps on your other assigned CE device Has the EBGP peering session been established between the CE and PE routers? The BGP peering session should now be established between CE and PE routers. You can verify this with the show bgp summary command. 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 :34 1/1/1/0 0/0/0/0 Is the CE advertising its static routes to the PE via EBGP? 21

22 The CE router should be advertising the configured static routes to the PE router using BGP. You can verify this advertisement with the show route advertisingprotocol bgp command. show route advertising-protocol bgp inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * /24 Self I * /24 Self I * /24 Self I * /24 Self I * /24 Self I Part 7: Repair Unusable Routes Step 7.1 Return to your PE devices and answer the following questions: Are both your PE devices receiving the routes that their respective EBGP peers are advertising to them? Yes they do. You could check that fact by typing the command show route receiving-protocol bgp x.x.x.x lab@tokyo-pe# run show route receive-protocol bgp inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * / I * / I * / I * / I * / I Following BGP advertisement rules, is your PE device readvertising to its IBGP peers (the Sydney-P route reflector) those EBGP learned routes? (that is, the ones you have checked in previous question) 22

23 Yes it is. You could check that fact by typing the command show route advertising-protocol bgp x.x.x.x run show route advertising-protocol bgp inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * / I * / I * / I * / I * / I So far so good. Your last check will draw your attention to the remote PE. Is your remote PE receiving those routes being advertised into IBGP by the former PE? In other words, is the route reflector readvertising (or reflecting ) the above routes to the remote PE? Answer is no. You could check that fact by typing the command show route receiving-protocol bgp Nothing seems to be arriving from the Route Reflector. Can you guess why? lab@hongkong-pe# run show route receive-protocol bgp inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden) iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) Step 7.2 Let s go and look into the Route Reflector itself to see what is going on. Go ahead and telnet into the Sydney-P router and perform the following checks in there. lab@tokyo-pe# run telnet Trying Connected to Escape character is '^]'. 23

24 Sydney-P (ttyp0) login: lab Password: lab JUNOS 9.3R3.8 built :33:43 UTC Issue the following commands in the route reflector and answer the questions: show route summary Autonomous system number: Router ID: inet.0: 29 destinations, 34 routes (19 active, 0 holddown, 10 hidden)... Direct: 7 routes, 7 active Local: 7 routes, 7 active OSPF: 6 routes, 1 active BGP: 10 routes, 0 active IS-IS: 4 routes, 4 active Do you see anything odd? Yes. You should have noticed the presence of 10 hidden routes in the route reflector. Why do you think those routes are hidden?? (Hint: Use the extensive and hidden switches to display additional information about a hidden route, or try the show route resolution unresolved command.) The routes are hidden because the associated BGP next hop cannot be resolved. lab@sydney-p> show route hidden extensive inet.0: 29 destinations, 34 routes (19 active, 0 holddown, 10 hidden) /24 (1 entry, 0 announced) BGP Preference: 170/-101 Next hop type: Unusable Next-hop reference count: 10 24

25 State: <Hidden Int Ext> Local AS: Peer AS: Age: 19:22 Task: BGP_ AS path: I Accepted Localpref: 100 Router ID: Indirect next hops: 1 Protocol next hop: Indirect next hop: /24 (1 entry, 0 announced) BGP Preference: 170/-101 Next hop type: Unusable Next-hop reference count: 10 State: <Hidden Int Ext> Local AS: Peer AS: Age: 19:07 Task: BGP_ AS path: I Accepted Localpref: 100 Router ID: Indirect next hops: 1 Protocol next hop: Indirect next hop: lab@sydney-p> show route resolution unresolved Tree Index 1 Tree Index 2 Tree Index 3 Tree Index /24 Protocol Nexthop: Indirect nexthop: /24 Protocol Nexthop: Indirect nexthop: /24 Protocol Nexthop: Indirect nexthop: /24 Protocol Nexthop: Indirect nexthop: /24 Protocol Nexthop: Indirect nexthop: /24 Protocol Nexthop: Indirect nexthop: 0-25

26 /24 Protocol Nexthop: Indirect nexthop: /24 Protocol Nexthop: Indirect nexthop: /24 Protocol Nexthop: Indirect nexthop: /24 Protocol Nexthop: Indirect nexthop: 0 - Step 7.3 At this point of the training course you are well aware that the hidden routes occur because the advertised protocol next hop is considered unreachable by your router ( and ). Log out the Sydney-P router and return to your PE device. Implement an export policy that manipulates the BGP next-hop and changes it to self for every route received from EBGP. lab@sydney-p> exit Connection closed by foreign host. lab@tokyo-pe# edit policy-options policy-statement NHS [edit policy-options policy-statement NHS] lab@tokyo-pe# set term 1 then next-hop self [edit policy-options policy-statement NHS] lab@tokyo-pe# show term 1 { then { next-hop self; Now apply your NHS policy as an export policy to the ibgp group. When you are satisfied with your changes do not forget to commit your configuration. [edit policy-options policy-statement NHS] lab@tokyo-pe# top lab@tokyo-pe# set protocols bgp group ibgp export NHS lab@tokyo-pe# commit commit complete Note Needless to say that you should implement a similar policy in your other PE device to repair the unusable routes 26

27 Step 7.4 Once again check the routes you are receiving from your route reflector. Is your PE receiving now the routes that the remote PE receives from its EBGP peer? Yes. Soon after you repaired the next-hop for those routes, they should now be arriving well into your device. run show route protocol bgp terse inet.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both A Destination P Prf Metric 1 Metric 2 Next hop AS path * /24 B > I * /24 B > I * /24 B > I * /24 B > I * /24 B > I * /24 B > I * /24 B > I * /24 B > I * /24 B > I * /24 B > I How about your CE devices? Do they receive routing information from the remote CEs? Yes they do lab@barcelona-ce_a1> show route protocol bgp terse inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both A Destination P Prf Metric 1 Metric 2 Next hop AS path * /24 B > I * /24 B > I * /24 B > I 27

28 * /24 B > I * /19 B > I * /24 B > I Could you do end-to-end pings from CE to CE? Yes you can. Ensure you source your pings from the loopback address of your CE device. lab@barcelona-ce_a1> ping source PING ( ): 56 data bytes 64 bytes from : icmp_seq=0 ttl=61 time=5.144 ms 64 bytes from : icmp_seq=1 ttl=61 time=5.242 ms 64 bytes from : icmp_seq=2 ttl=61 time=5.521 ms ^C ping statistics packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 5.144/5.302/5.521/0.160 ms Part 8: Add Support for the MPLS Family on Transit Interfaces Step 8.1 You must configure each logical interface expected to process labeled packets to support the mpls family. The interface is omitted from the output of a show mpls interface command if the mpls family is not configured. Return to your PE device and add the mpls family to the logical units of all transit interfaces with attached neighbors. There is no need to include the mpls family on the loopback interface. Actually, your only interface to be configured is the your PE core facing interface (that is the serial interface se-x/x/x or the ge-x/x/x interface in some cases). lab@tokyo-pe# edit interfaces se-1/0/1 [edit interfaces se-1/0/1] lab@tokyo-pe# set unit 0 family mpls Step 8.2 Confirm that your interfaces are correctly configured by comparing your station s mpls family settings to the example taken from the Tokyo-PE station. [edit interfaces se-1/0/1] lab@tokyo-pe# show 28

29 description "to Sydney-P"; unit 0 { family inet { address /24; family iso; family mpls; Note Repeat similar steps on your other PE device. Part 9: Enable MPLS Processing Step 9.1 Adding the mpls family to your interfaces does not enable an MPLS instance on that interface. In this step, you add MPLS instance support for each transit interface with attached neighbors by listing each such interface at the [edit protocols mpls] configuration hierarchy. If you decide to use the interface all shortcut, you should explicitly disable the MPLS instance on the router s ge- 0/0/0 OOB interface. [edit interfaces se-1/0/1] lab@tokyo-pe# top edit protocols mpls [edit protocols mpls] lab@tokyo-pe# set interface se-1/0/1 Step 9.2 Display your mpls stanza to confirm that it is similar to the samples taken from Tokyo-PE router: [edit protocols mpls] lab@tokyo-pe# show interface se-1/0/1.0; An equally workable, and commonly found, alternative is shown here for your other PE device; this approach makes use of the all keyword to the interface statement: lab@hongkong-pe# edit protocols mpls [edit protocols mpls] lab@hongkong-pe# set interface all [edit protocols mpls] lab@hongkong-pe# set interface ge-0/0/0 disable [edit protocols mpls] lab@hongkong-pe# show 29

30 interface all; interface ge-0/0/0.0 { disable; Part 10: Configure RSVP Signaling Step 10.1 RSVP is the primary signaling protocol for establishing signaled LSPs. A signaled LSP is analogous to a switched virtual circuit (SVC) in Frame Relay or ATM (SVCs are also called demand connections in ATM). Establishing LSPs with a signaling protocol offers many advantages over static LSP definitions. Among these are ease of use, increased visibility into operational status, and enhanced features like constrained routing and support for fast reroute. A static LSP is somewhat analogous to a PVC in other virtual circuit technologies. JUNOS software offers support for RSVP and LDP signaling as well as static LSP definitions. Enable the RSVP signaling protocol on all transit interfaces with attached neighbors. There is no need to run RSVP on the loopback interface, and, as with most other protocols, you should not run RSVP on the router s fxp0/ge-0/0/0 OOB interfaces. If you decide to use the interface all shortcut, you should explicitly disable the MPLS instance on the router s fxp0/ge-0/0/0 OOB interfaces. [edit protocols mpls] lab@tokyo-pe# up [edit protocols] lab@tokyo-pe# edit rsvp [edit protocols rsvp] lab@tokyo-pe# set interface se-1/0/1 Step 10.2 Display your rsvp stanza to confirm that it is similar to the samples taken from Tokyo: [edit protocols rsvp] lab@tokyo-pe# show interface se-1/0/1.0; Another equally workable alternative is taken from the other PE HongKong router, which again makes use of the interface all approach: [edit protocols rsvp] lab@hongkong-pe# set interface all [edit protocols rsvp] lab@hongkong-pe# set interface ge-0/0/0 disable [edit protocols rsvp] lab@hongkong-pe# show interface all; interface ge-0/0/0.0 { disable; 30

31 Part 11: Configure an RSVP-Signaled LSP Step 11.1 Each one of your PE routers serves as an ingress node for the LSP it originates and terminates on the remote PE. The goal is to configure bidirectional LSPs between your pair of PE routers. In this lab, the routing of the RSVP path message, and therefore the routing of the resulting LSP, is left to the druthers of your IGP. Note For the moment we are not going to worry about the Constrained Shortest Path First (CSPF) routing constraints. Because the CSPF algorithm is enabled by default for RSVP-signaled LSPs, you must be sure to disable CSPF with a nocspf statement. CSPF-based LSPs should succeed if the class decides to deploy IS-IS as its IGP because IS-IS automatically builds the requisite traffic engineering database (TED). The OSPF protocol requires explicit configuration to build a TED to support CSPF-based LSPs. Configure your PE station s ingress LSP at the [edit protocols mpls] hierarchy. Be sure to disable CSPF by adding the no-cspf statement to your LSP definition. We suggest that you assign a name to your LSP that reflects both the LSP s ingress and egress points, such as TKY-to-HKG for the LSP that originates at Tokyo and terminates at HongKong. Using a descriptive name tends to simplify subsequent analysis of the resulting LSPs. Ingress Egress (Egress LSR lo0 Address) Tokyo Hong Kong HongKong Tokyo London Amsterdam Amsterdam London SanJose Montreal Montreal San Jose [edit protocols rsvp] lab@tokyo-pe# up [edit protocols] lab@tokyo-pe# edit mpls [edit protocols mpls] lab@tokyo-pe# set label-switched-path TKY-to-HKG to [edit protocols mpls] lab@tokyo-pe# set label-switched-path TKY-to-HKG no-cspf 31

32 Step 11.2 Your mpls stanza and LSP definition should be similar to this example taken from the Tokyo station: [edit protocols mpls] show label-switched-path TKY-to-HKG { to ; no-cspf; interface se-1/0/1.0; Step 11.3 When satisfied with your RSVP-signaled LSP configuration, commit your changes, and return to operational mode: [edit protocols mpls] lab@tokyo-pe# commit and-quit commit complete Exiting configuration mode Note Do not forget to create a similar LSP for the way back from your other PE. Part 12: Verify Interface Support for RSVP and MPLS Step 12.1 Execute a show mpls interface command, and confirm that all transit interfaces with attached neighbors are listed as Up. The presence of an interface in this listing confirms that the mpls family is configured and that the interface is supported by the router s MPLS instance. lab@tokyo-pe> show mpls interface Interface State Administrative groups (x: extended) se-1/0/1.0 Up <none> Step 12.2 Confirm that all your transit interfaces with attached neighbors are listed as running RSVP with a status of Up. lab@tokyo-pe> show rsvp interface RSVP interface: 1 active Active Subscr- Static Available Reserved Highwater Interface State resv iption BW BW BW mark se-1/0/1.0 Up 1 100% 8Mbps 8Mbps 0bps 0bps 32

33 Are the required interfaces listed as Up and enabled for RSVP? The sample output obtained from the Tokyo station indicates that the required interfaces are correctly enabled for RSVP operation. All interfaces also display an Up status. By default, how much of a given interface s bandwidth can RSVP reserve? By default, RSVP can reserve 100% of an interface s bandwidth. Are there any active reservations on any of your interfaces? Step 12.3 The sample display shows that one active reservation is present on the Tokyo station s transit interfaces. Whether your router is acting as ingress or egress each LSP that touches your router has an RSVP session supporting it. Issue a show rsvp session command to answer the following question: lab@tokyo-pe> show rsvp session Ingress RSVP: 1 sessions To From State Rt Style Labelin Labelout LSPname Up 0 1 FF TKY-to- HKG Total 1 displayed, Up 1, Down 0 Egress RSVP: 1 sessions To From State Rt Style Labelin Labelout LSPname Up 0 1 FF 3 - HKG-to- TKO Total 1 displayed, Up 1, Down 0 Transit RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 33

34 In how many RSVP sessions is your router currently involved? Step 12.4 The sample capture shows that there are a total of two RSVP sessions one egress and one is ingress. Add the detail switch to gather additional information about your RSVP interfaces. Note When using the detail switch, all interfaces are displayed, even though RSVP might not be enabled on that interface. The beginning of the display for each interface indicates whether RSVP is actually operational on that interface. lab@tokyo-pe> show rsvp interface detail no-more RSVP interface: 1 active ge-0/0/0.0 Index 69, State Dis/Up NoAuthentication, NoAggregate, NoReliable, NoLinkProtection HelloInterval 9(second) Address PacketType Total Last 5 seconds Sent Received Sent Received Path PathErr PathTear Resv ResvErr ResvTear Hello Ack Srefresh EndtoEnd RSVP ge-0/0/1.0 Index 70, State Dis/Up NoAuthentication, NoAggregate, NoReliable, NoLinkProtection HelloInterval 9(second) Address PacketType Total Last 5 seconds Sent Received Sent Received Path PathErr PathTear Resv ResvErr ResvTear Hello Ack Srefresh EndtoEnd RSVP

35 se-1/0/1.0 Index 77, State Ena/Up NoAuthentication, NoAggregate, NoReliable, NoLinkProtection HelloInterval 9(second) Address , ActiveResv 1, PreemptionCnt 0, Update threshold 10% Subscription 100%, StaticBW 8Mbps, AvailableBW 8Mbps ReservedBW [0] 0bps[1] 0bps[2] 0bps[3] 0bps[4] 0bps[5] 0bps[6] 0bps[7] 0bps PacketType Total Last 5 seconds Sent Received Sent Received Path PathErr PathTear Resv ResvErr ResvTear Hello Ack Srefresh EndtoEnd RSVP sp-0/0/0.0 Index 72, State Dis/Up NoAuthentication, NoAggregate, NoReliable, NoLinkProtection HelloInterval 9(second) Address PacketType Total Last 5 seconds Sent Received Sent Received Path PathErr PathTear Resv ResvErr ResvTear Hello Ack Srefresh EndtoEnd RSVP Is RSVP authentication in effect on any of your interfaces? Step 12.5 By default, RSVP authentication is disabled. The sample output clearly shows that authentication is not in effect. Display information about any RSVP neighbors that have been detected. lab@tokyo-pe> show rsvp neighbor RSVP neighbor: 1 learned Address Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd /0 7: /

36 Note RSVP neighbors appear in this listing only after their first use. Once they appear in the neighbor listing, they are never removed. This is somewhat different from the neighbor listings in routing protocols like BGP and IS-IS where all neighbors appear whether they are being used or not. This is because the RSVP hello protocol does not function to detect neighbors. Are any neighbors currently in a down (Dn) state? (Hint: Is the Up count higher than the Dn count?) In the sample output, all neighbors are up by virtue of the up count (1) being higher than the down count (0). Part 13: Verify LSP Establishment Step 13.1 Confirm that your ingress LSP is operational. lab@tokyo-pe> show rsvp session ingress Ingress RSVP: 1 sessions To From State Rt Style Labelin Labelout LSPname Up 0 1 FF TKY-to-HKG Total 1 displayed, Up 1, Down 0 Is your ingress LSP listed as being Up? In the sample output taken from Tokyo, the ingress session to the HongKong station is correctly established. What label is pushed onto packets as they enter this LSP? In this example, packets have a label coded with the value pushed onto them as they enter the LSP. 36

37 Why do you think the labelin for this session indicates a null value? Step 13.2 There is no incoming label associated with ingress LSPs; by definition, the ingress LSR handles unlabeled packets. Obtain detailed information about your ingress session: lab@tokyo-pe> show rsvp session ingress detail Ingress RSVP: 1 sessions From: , LSPstate: Up, ActiveRoute: 0 LSPname: TKY-to-HKG, LSPpath: Primary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: Resv style: 1 FF, Label in: -, Label out: Time left: -, Since: Mon Mar 24 13:29: Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: (se-1/0/1.0) 21 pkts RESV rcvfrom: (se-1/0/1.0) 16 pkts Record route: <self> Total 1 displayed, Up 1, Down 0 To which router did the router send the RSVP path message? The sample output shows that Tokyo sent the RSVP path message to via its se-1/0/1.0 interface. Document the complete path of your LSP using the information contained in the record route object (RRO). The path of the TKY-to-HKG is listed as <self> , which equates to Tokyo, Sydney and the egress Hong-Kong routers. 37

38 Can you explain why the LSP was established over the path shown? Without routing constraints, the RSVP session is routed over the IGP s shortest path between ingress and egress nodes. lab@tokyo-pe> show route inet.0: 24 destinations, 24 routes (24 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both /32 *[IS-IS/18] 01:24:43, metric 20 > to via se-1/0/1.0 inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both /32 *[RSVP/7/1] 00:12:45, metric 20 > via se-1/0/1.0, label-switched-path TKY-to-HKG lab@tokyo-pe> traceroute traceroute to ( ), 30 hops max, 40 byte packets ( ) ms ms ms ( ) ms ms ms Step 13.3 Telnet to the router that received your path message to confirm that it shows a transit RSVP session with an incoming label that matches the value you documented in step lab@tokyo-pe> telnet Trying Connected to Escape character is '^]'. Sydney-P (ttyp0) login: lab Password: lab JUNOS 9.3R3.8 built :33:43 UTC lab@sydney-p> show rsvp session transit Transit RSVP: 2 sessions To From State Rt Style Labelin Labelout LSPname Up 1 1 FF HKG-to-TKO Up 1 1 FF TKY-to-HKG Total 2 displayed, Up 2, Down 0 38

39 Does this router show a transit session with Labelin value that matches the label being pushed at your station? The sample display confirms that the Sydney router is expecting traffic associated with the TKY-to-HKG LSP to arrive with a label value of ; this is the same label value that is being pushed at the ingress LSR What happens to this label as the traffic is forwarded downstream towards the LSP egress point? Step 13.4 The transit LSR performs a label pop operation. Note the labelout of 3 Break your Telnet connection, and issue a show mpls lsp command to answer the following question: lab@sydney-p> quit Connection closed by foreign host. lab@tokyo-pe> show mpls lsp Ingress LSP: 1 sessions To From State Rt P ActivePath LSPname Up 0 * TKY-to-HKG Total 1 displayed, Up 1, Down 0 Egress LSP: 1 sessions To From State Rt Style Labelin Labelout LSPname Up 0 1 FF 3 - HKG-to-TKO Total 1 displayed, Up 1, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Is your ingress LSP considered a primary path? 39

40 Step 13.5 Yes, by default, an LSP is treated as a primary LSP unless specifically flagged as secondary. Display the route to the egress point of your LSP. lab@tokyo-pe> show route inet.0: 24 destinations, 24 routes (24 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both /32 *[IS-IS/18] 01:24:43, metric 20 > to via se-1/0/1.0 inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both /32 *[RSVP/7/1] 00:12:45, metric 20 > via se-1/0/1.0, label-switched-path TKY-to-HKG Into what routing table is the signaled LSP installed? The host address associated with signaled LSPs are installed in the inet.3 routing table. Assuming for the moment that only BGP can use the information stored in inet.3 (for the purpose of resolving a BGP next hop), and that the LSP endpoint is not a BGP route, predict what will happen if you should trace a route to the endpoint of your LSP? Step 13.6 Because LSPs installed in inet.3 are only usable to resolve the BGP next hop of a given route, and because the tunnel endpoint is not a BGP route, the LSP s presence in the inet.3 table has no effect on the forwarding of traffic to the LSP s endpoint. Put simply, traffic addressed to the LSP egress is not forwarded over the LSP. Trace a route to the LSP s egress point. lab@tokyo-pe> traceroute traceroute to ( ), 30 hops max, 40 byte packets ( ) ms ms ms ( ) ms ms ms 40