Networking Protocols Lab PDF

# Networking Protocols Lab. ## **Course Plan** ### **First: Basic Information** | Category | Details | | ----------- | ----------- | | College | Faculty of engineering technology | | Department | Computer and networks engineering | | Course Title | Networks protocols lab | | Course Code | 30106432 | | Credit Hour | 1 | | Prerequisite | 30106431 | | **Instructor** || | Name | Dr. Belal Ayyoub | | Office No. | B17 F4 | | Tel (Ext) | 515 | | E-mail | [email protected]. | | Office Hours | || | Class Times | Building| Day|Start Time|End Time|Room No.| | | 17|Tue-WeD|16|18|9| | | 17|SUN-Tue-ThR|10|11|| ## **Week 6** ## **Lab 5: Multiarea OSPFv2 and OSPFv3** Multiarea OSPF is used to divide a large OSPF network. Too many routers in one area increase the load on the CPU and create a large link-state database. In this chapter, directions are provided to effectively partition a large single area into multiple areas. Area 0, used in a single-area OSPF, is known as the backbone area. ### **OSPF Two-Layer Area Hierarchy** ![Image of a network diagram] Multiarea OSPF is implemented in a two-layer area hierarchy: * Backbone (Transit) area * Regular (Non-backbone) area Note: A regular area can have a number of subtypes, including a standard area, stub area, totally stubby area, and not-so-stubby area (NSSA). Stub, totally stubby, and NSSAs are beyond the scope of this lab. OSPF enforces this rigid two-layer area hierarchy. The underlying physical connectivity of the network must map to the two-layer area structure, with all non-backbone areas attaching directly to area 0. All traffic moving from one area to another area must traverse the backbone area. This traffic is referred to as interarea traffic. The optimal number of routers per area varies based on factors such as network stability, but Cisco recommends the following guidelines: * An area should have no more than 50 routers. * A router should not be in more than three areas. * Any single router should not have more than 60 neighbors. The hierarchical-topology possibilities of multiarea OSPF have these advantages: * Smaller routing tables * Reduced link-state update * Reduced frequency of SPF calculations ### **Types of OSPF Routers** There are four different types of OSPF routers: * **Internal router** - This is a router that has all of its interfaces in the same area. * **Backbone router** - This is a router in the backbone area. The backbone area is set to area 0. * **Area Border Router (ABR)** - This is a router that has interfaces attached to multiple areas. It must maintain separate LSDBs for each area it is connected to, and can route between areas. ABRs are exit points for the area, which means that routing information destined for another area can get there only via the ABR of the local area. ABRs can be configured to summarize the routing information from the LSDBs of their attached areas. ABRs distribute the routing information into the backbone. * **Autonomous System Boundary Router (ASBR)** - This is a router that has at least one interface attached to an external internetwork. An external network is a network that is not part of this OSPF routing domain. For example, a network connection to an ISP. An ASBR can import external network information to the OSPF network, and vice versa, using a process called route redistribution. Redistribution in multiarea OSPF occurs when an ASBR connects different routing domains (e.g., EIGRP and OSPF) and configures them to exchange and advertise routing information between those routing domains. A static route, including a default route, can also be redistributed as an external route into the OSPF routing domain. ### **Configuring Multiarea OSPFv2** ![Image of a network diagram] ``` R1(config)# router ospf 10 R1(config-router)# router-id 1.1.1.1 R1(config-router)# network 10.1.1.1 0.0.0.0 area 1 R1(config-router)# network 10.1.2.1 0.0.0.0 area 1 R1(config-router)# network 192.168.10.1 0.0.0.0 area 0 R1(config-router)# end R1# ``` ### **Configuring Multiarea OSPFv3** ![Image of a network diagram] ``` R1(config)# ipv6 router ospf 10 R1(config-rtr)# router-id 1.1.1.1 R1(config-rtr)# exit R1(config)# R1(config)# interface GigabitEthernet 0/0 R1(config-if)# ipv6 ospf 10 area 1 R1(config-if)# R1(config-if)# interface Serial0/0/0 R1(config-if)# ipv6 ospf 10 area 0 R1(config-if)# end R1# ``` ### **Verifying Multiarea OSPFv2 and OSPFv3 ** The same verification commands used to verify single-area OSPFv2 also can be used to verify the multiarea OSPF topology in the figure: * show ip ospf neighbor * show ip ospf * show ip ospf interface Commands that verify specific multiarea OSPFv2 information include: * show ip protocols * show ip ospf interface brief * show ip route ospf * show ip ospf database for IPv6 use the same command but change IP to IPv6 ## **Packet Tracer - Configuring Multiarea OSPFv2** ### **Topology** ![Image of a network diagram] ### **Addressing Table** | Device | Interface | IP Address | Subnet Mask | OSPFv2 Area | | ----------- | ----------- | ----------- | ----------- | ----------- | | R1 | G0/0 | 10.1.1.1 | 255.255.255.0 | 1 | | R1 | G0/1 | 10.1.2.1 | 255.255.255.0 | 1 | | R1 | S0/0/0 | 192.168.10.2 | 255.255.255.252 | 0 | | R2 | G0/0 | 10.2.1.1 | 255.255.255.0 | 0| | R2 | S0/0/0 | 192.168.10.1 | 255.255.255.252 | 0 | | R2 | S0/0/1 | 192.168.10.5 | 255.255.255.252 | 0 | | R3 | G0/0 | 192.168.2.1 | 255.255.255.0 | 2 | | R3 | G0/1 | 192.168.1.1 | 255.255.255.0 | 2 | | R3 | S0/0/1 | 192.168.10.6 | 255.255.255.252 | 0 | ### **Objectives** * Part 1: Configure Multiarea OSPFv2 * Part 2: Verify and Examine Multiarea OSPFv2 ### **Background** In this activity, you will configure multiarea OSPFv2. The network is already connected and interfaces are configured with IPv4 addressing. Your job is to enable multiarea OSPFv2, verify connectivity, and examine the operation of multiarea OSPFv2. ### **Part 1: Configure OSPFv2** * **Step 1**: Configure OSPFv2 on R1. Configure OSPFv2 on R1 with a process ID of 1 and a router ID of 1.1.1.1. * **Step 2**: Advertise each directly connected network in OSPFv2 on R1. Configure each network in OSPFv2 assigning areas according to the Addressing Table. ``` R1(config-router)# network 10.1.1.0 0.0.0.255 area 1 R1(config-router)# network 10.1.2.0 0.0.0.255 area 1 R1(config-router)# network 192.168.10.0 0.0.0.3 area 0 ``` * **Step 3**: Configure OSPFv2 on R2 and R3. Repeat the steps above for R2 and R3 using a router ID of 2.2.2.2 and 3.3.3.3, respectively. ### **Part 2: Verify and Examine Multiarea OSPFv2** * **Step 1**: Verify connectivity to each of the OSPFv2 areas. From R1, ping each of the following remote devices in area 0 and area 2: 192.168.1.2, 192.168.2.2, and 10.2.1.2. * **Step 2**: Use show commands to examine the current OSPFv2 operations. Use the following commands to gather information about your OSPFv2 multiarea implementation. ``` show ip protocols show ip route show ip ospf database show ip ospf interface show ip ospf neighbor ``` ### **Reflection Questions** * Which router(s) are internal routers? * Which router(s) are backbone routers? * Which router(s) are area border routers? * Which router(s) are autonomous system routers? * Which routers are generating Type 1 LSAs? * Which routers are generating Type 2 LSAs? * Which routers are generating Type 3 LSAs? * Which routers are generating Type 4 and 5 LSAs? * How many inter area routes does each router have? ## **Packet Tracer – Configuring Multiarea OSPFv3** ### **Topology** ![Image of a network diagram] ### **Addressing Table** | Device | Interface | IPv6 Address | OSPF Area | | ----------- | ----------- | ----------- | ----------- | | RA | G0/0 | 2001:DB8:1:A1::1/64 | 1 | | RA | G0/1 | 2001:DB8:1:A2::1/64 | 1 | | RA | S0/0/0 | 2001:DB8:1:AB::2/64 | 0 | | RA | Link-Local | FE80::A | N/A | | RB | G0/0 | 2001:DB8:1:B1::1/64 | 0 | | RB | S0/0/0 | 2001:DB8:1:AB::1/64 | 0 | | RB | S0/0/1 | 2001:DB8:1:BC::1/64 | 0 | | RB | Link-Local | FE80::B | N/A | | RC | G0/0 | 2001:DB8:1:C1::1/64 | 2 | | RC | G0/1 | 2001:DB8:1:C2::1/64 | 2 | | RC | S0/0/1 | 2001:DB8:1:BC::2/64 | 0 | | RC | Link-Local | FE80::C | N/A | ### **Objectives** * Part 1: Configure OSPFv3 * Part 2: Verify Multiarea OSPFv3 Operations ### **Background** In this activity, you will configure multiarea OSPFv3. The network is already connected and interfaces are configured with IPv6 addressing. Your job is to enable multiarea OSPFv3, verify connectivity and examine the operation of multiarea OSPFv3. ### **Part 1: Configure OSPFv3 ** * **Step 1**: Enable IPv6 routing and configure OSPFv3 on RA. Enable IPv6 routing. Configure OSPFv3 on RA with a process ID of 1 and a router ID of 1.1.1.1. * **Step 2**: Advertise each directly connected network in OSPFv3 on RA . Configure each active IPv6 interface with OSPFv3 assigning each to the area listed in the Addressing Table. * **Step 3**: Configure OSPFv3 on RB and RC Repeat the Steps 1 and 2 for RB and RC, changing the router ID to 2.2.2.2 and 3.3.3.3 respectively. ### **Part 2: Verify Multiarea OSPFv3 Operations** * **Step 1**: Verify connectivity to each of the OSPFv3 areas. From RA, ping each of the following remote devices in area 0 and area 2: 2001:DB8:1:B1::2, 2001:DB8:1:A1::2, 2001:DB8:1:A2::2, 2001:DB8:1:C1::2, and 2001:DB8:1:C2::2. * **Step 2**: Use show commands to examine the current OSPFv3 operations. Use the following commands to gather information about your OSPFv3 multiarea implementation. ``` show ipv6 ospf ipv6 route show ipv6 ospf database show ipv6 ospf interface show ipv6 ospf neighbor ``` Note: Packet Tracer output for show ipv6 protocols is currently not aligned with IOS 15 output. Refer to the real equipment labs for correct show command output. ## **Lab 6: Part 2 OSPF DR & BDR** ## **OSPF Network Types** OSPF defines five network types: * **Point-to-point** - Two routers interconnected over a common link. No other routers are on the link. * **Broadcast multiaccess** - Multiple routers interconnected over an Ethernet network. * **Nonbroadcast multiaccess (NBMA)** - Multiple routers interconnected in a network that does not allow broadcasts, such as Frame Relay. * **Point-to-multipoint** - Multiple routers interconnected in a hub-and-spoke topology over an NBMA network. Often used to connect branch sites (spokes) to a central site (hub). * **Virtual links** - Special OSPF network used to interconnect distant OSPF areas to the backbone area. ## **OSPF Designated Router** The solution to managing the number of adjacencies and the flooding of LSAs on a multiaccess network is the DR. On multiaccess networks, OSPF elects a DR to be the collection and distribution point for LSAs sent and received. A BDR is also elected in case the DR fails. The BDR listens passively to this exchange and maintains a relationship with all the routers. If the DR stops producing Hello packets, the BDR promotes itself and assumes the role of DR. All other non-DR or BDR routers become DROTHER (a router that is neither the DR nor the BDR). ### **Verifying DR/BDR Roles** ![Image of a network diagram] In the multiaccess topology shown in Figure above, there are three routers interconnected over a common Ethernet multiaccess network, 192.168.1.0/28. Each router is configured with the indicated IPv4 address on the Gigabit Ethernet 0/0 interface. Because the routers are connected over a common multiaccess broadcast network, OSPF has automatically elected a DR and BDR. In this example, R3 has been elected as the DR because its router ID is 3.3.3.3, which is the highest in this network. R2 is the BDR because it has the second highest router ID in the network. To verify the roles of the OSPFv2 router, use the **show ip ospf interface** command. The output generated by R1 confirms that: 1. R1 is not the DR or BDR, but is a DROTHER with a default priority of 1. (1) 2. The DR is R3 with router ID 3.3.3.3 at IPv4 address 192.168.1.3, while the BDR is R2 with router ID 2.2.2.2 at IPv4 address 192.168.1.2. (2) 3. R1 has two adjacencies: one with the BDR and one with the DR. (3) Note: For the equivalent OSPFv3 command, simply substitute ip with ipv6. ### **Verifying DR/BDR Adjacencies** To verify the OSPFv2 adjacencies, use the **show ip ospf neighbor** command Default ### **DR/BDR Election Process** How do the DR and BDR get elected? The OSPF DR and BDR election decision is based on the following criteria, in sequential order: 1. The routers in the network elect the router with the highest interface priority as the DR. The router with the second highest interface priority is elected as the BDR. The priority can be configured to be any number between 0 – 255. The higher the priority, the likelier the router will be selected as the DR. If the priority is set to 0, the router is not capable of becoming the DR. The default priority of multiaccess broadcast interfaces is 1. Therefore, unless otherwise configured, all routers have an equal priority value and must rely on another tie breaking method during the DR/BDR election. 2. If the interface priorities are equal, then the router with the highest router ID is elected the DR. The router with the second highest router ID is the BDR. Recall that the router ID is determined in one of three ways: * The router ID can be manually configured. * If no router IDs are configured, the router ID is determined by the highest loopback IPv4 address. * If no loopback interfaces are configured, the router ID is determined by the highest active IPv4 address. Note: In an IPv6 network, if there are no IPv4 addresses configured on the router, then the router ID must be manually configured with the **router-id rid** command; otherwise, OSPFv3 does not start. ### **The OSPF Priority** The DR becomes the focal point for the collection and distribution of LSAs; therefore, this router must have sufficient CPU and memory capacity to handle the workload. It is possible to influence the DR/BDR election process through configurations. To set the priority of an interface, use the following commands: * **ip ospf priority value** - OSPFv2 interface command * **0** - Does not become a DR or BDR. * **ipv6 ospf priority value** - OSPFv3 interface command The value can be: * **1 – 255** - The higher the priority value, the more likely the router becomes the DR or BDR on the interface. ### **Changing the OSPF Priority** ``` R1 (config)# interface GigabitEthernet 0/0 R1 (config-if)# ip ospf priority 255 R1 (config-if)# end R1# R3 (config)# interface GigabitEthernet 0/0 R3 (config-if)# ip ospf priority 0 R3 (config-if)# end R3# R1# clear ip ospf process Reset ALL OSPF processes? [no]: yes R1# tanr 6 16:00:44 282. 30SPF-5-ADJCHG Process 10 ``` ## **Packet Tracer - Determining the DR and BDR** ### **Topology** ![Image of a network diagram] ### **Addressing Table** | Device | Interface | IP Address | Subnet Mask | | ----------- | ----------- | ----------- | ----------- | | RA | G0/0 | 192.168.1.2 | 255.255.255.0 | | RA | Lo0 | 192.168.31.11| 255.255.255.255 | | RB | G0/0 | 192.168.1.2 | 255.255.255.0 | | RB | Lo0 | 192.168.31.22 | 255.255.255.255 | | RC | G0/0 | 192.168.1.3 | 255.255.255.0 | | RC | Lo0 | 192.168.31.33 | 255.255.255.255 | ### **Objectives** * Part 1: Examine DR and BDR Changing Roles * Part 2: Modify OSPF Priority and Force Elections ### **Scenario** In this activity, you will examine DR and BDR roles and watch the roles change when there is a change in the network. You will then modify the priority to control the roles and force a new election. Finally, you will verify routers are filling the desired roles. ### **Part 1: Examine DR and BDR Changing Roles** * **Step 1**: Wait until the amber link lights turn green. When you first open the file in Packet Tracer, you may notice that the link lights for the switch are amber. These link lights will stay amber for 50 seconds while the switch makes sure that one of the routers is not another switch. Alternatively, you can click Fast Forward Time to bypass this process. ### **Packet Tracer - Determining the DR and BDR** * **Step 2**: Verify the current OSPF neighbor states.\ a. Use the appropriate command on each router to examine the current DR and BDR. b. Which router is the DR? c. Which router is the BDR? * **Step 3**: Turn on IP OSPF adjacency debugging. a. You can monitor the DR and BDR election process with a debug command. On RA and RB, enter the following command. ``` RA# debug ip ospf adj RB# debug ip ospf adj ``` * **Step 4**: Disable the Gigabit Ethernet 0/0 interface on RC. a. Disable the link between RC and the switch to cause roles to change. b. Wait about 30 seconds for the dead timers to expire on RA and RB. According to the debug output, which router was elected DR and which router was elected BDR? * **Step 5**: Restore the Gigabit Ethernet 0/0 interface on RC. a. Re-enable the link between RC and the switch. b. Wait for the new DR/BDR elections to occur. Did DR and BDR roles change? Why or why not? * **Step 6**: Disable the Gigabit Ethernet 0/0 interface on RB. Disable the link between RB and the switch to cause roles to change. Wait about 30 seconds for the holddown timers to expire on RA and RC. According to the debug output on RA, which router was elected DR and which router was elected BDR? * **Step 7**: Restore the Gigabit Ethernet 0/0 interface on RB. Re-enable the link between RB and the switch. Wait for the new DR/BDR elections to occur. Did DR and BDR roles change? Why or why not? * **Step 8**: Turn off Debugging. Enter the command **undebug all** on RA and RB to disable debugging. ### **Part 2: Modify OSPF Priority and Force Elections** * **Step 1**: Configure OSPF priorities on each router.\ To change the DR and BDR, configure the Gigabit Ethernet 0/0 port of each router with the following OSPF interface priorities: * **RA:** 200 * **RB:** 100 * **RC:** 1 (This is the default priority) * **Step 2**: Force an election by reloading the switch. Note: The command **clear ip ospf process** can also be used on the routers to reset the OSPF process. * **Step 3**: Verify DR and BDR elections were successful. a. Wait long enough for OSPF to converge and for the DR/BDR election to occur. This should take a few minutes. You can click Fast Forward Time to speed up the process. b. According to output from an appropriate command, which router is now DR and which router is now BDR? ## **Propagating a Default Static Route in OSPFv2** To propagate a default route, the edge router (R2) must be configured with: * A default static route using the **ip route 0.0.0.0 0.0.0.0 {ip-address | exit-intf}** command. * The **default-information originate** router configuration mode command. This instructs R2 to be the source of the default route information and propagate the default static route in OSPF updates ![Image of a network diagram] ``` R2(config)# ip route 0.0.0.0 0.0.0.0 209.165.200.226 R2(config)# R2(config)# router ospf 10 R2(config-router)# default-information originate R2(config-router)# end R2# ``` ## **Propagating a Default Static Route in OSPFv3** * A default static route using the **ipv6 route ::/0 ipv6-address|exit-intf}** command. * The **default-information originate** router configuration mode command. This instructs R2 to be the source of the default route information and propagate the default static route in OSPF updates. ![Image of a network diagram] ``` R2(config)# ipv6 route ::/0 2001:DB8:FEED:1::2 R2(config)# R2(config)# ipv6 router ospf 10 R2(config-rtr)# default-information originate R2(config-rtr)# end R2# ``` ## **OSPF Hello and Dead Intervals** The OSPF Hello and Dead intervals are configurable on a per-interface basis. The OSPF intervals must match or a neighbor adjacency does not occur ### **Modifying OSPFv2 Intervals** It may be desirable to change the OSPF timers so that routers detect network failures in less time. Doing this increases traffic, but sometimes the need for quick convergence is more important than the extra traffic it creates. Note: The default Hello and Dead intervals are based on best practices and should only be altered in rare situations. OSPFv2 Hello and Dead intervals can be modified manually using the following interface configuration mode commands: * **ip ospf hello-interval seconds** * **ip ospf dead-interval seconds** Use the **no ip ospf hello-interval** and **no ip ospf dead-interval** commands to reset the intervals to their default. ``` R1(config)# interface serial 0/0/0 R1(config-if)# ip ospf hello-interval 5 R1(config-if)# ip ospf dead-interval 20 R1(config-if)# end R1# ``` ### **Modifying OSPFv3 Intervals** Like OSPFv2, OSPFv3 intervals can also be adjusted. OSPFv3 Hello and Dead intervals can be modified manually using the following interface configuration mode commands: * **ipv6 ospf hello-interval seconds** * **ipv6 ospf dead-interval seconds** Note: Use the **no ipv6 ospf hello-interval** and **no ipv6 ospf dead-interval** commands to reset the intervals to their default. ``` R1(config)# interface serial 0/0/0 R1(config-if)# ipv6 ospf hello-interval 5 R1(config-if)# ipv6 ospf dead-interval 20 R1(config-if)# end R1# ``` ## **Packet Tracer - Propagating a Default Route in OSPFv2 And Configuring OSPF Advanced Features** ### **Topology** ![Image of a network diagram] ### **Addressing Table** | Device | Interface | IPv4 Address | Subnet Mask | Default Gateway | | ----------- | ----------- | ----------- | ----------- | ----------- | | R1 | G0/0 | 172.16.1.1 | 255.255.255.0 | N/A | | R1 | S0/0/0 | 172.16.3.1 | 255.255.255.252 | N/A | | R1 | S0/0/1 | 192.168.10.5 | 255.255.255.252 | N/A | | R2 | G0/0 | 172.16.2.1 | 255.255.255.0 | N/A | | R2 | S0/0/0| 172.16.3.2 | 255.255.255.252 | N/A | | R2 | S0/0/1| 192.168.10.9 | 255.255.255.252 | N/A | | R2 | S0/1/0 | 209.165.200.225 | 255.255.255.224 | N/A | | R3 | G0/0 | 192.168.1.1 | 255.255.255.0 | N/A | | R3 | S0/0/0 | 192.168.10.6 | 255.255.255.252 | N/A | | R3 | S0/0/1| 192.168.10.10 | 255.255.255.252 | N/A | | PC1 | NIC | 172.16.1.2 | 255.255.255.0 | 172.16.1.1 | | PC2 | NIC | 172.16.2.2 | 255.255.255.0 | 172.16.2.1 | | PC3 | NIC | 192.168.1.2 | 255.255.255.0 | 192.168.1.1 | ### **Objectives** * Part 1: Propagate a Default Route * Part 2: Verify Connectivity * Part 3: Modify OSPF Default Settings ### **Packet Tracer - Propagating a Default Route in OSPFv2** ### **Background** In this activity, you will configure an IPv4 default route to the Internet and propagate that default route to other OSPF routers. You will then verify the default route is in downstream routing tables and that hosts can now access a web server on the Internet. ### **Part 1: Propagate a Default Route** * **Step 1**: Configure a default route on R2. Configure R2 with a directly attached default route to the Internet. ``` R2(config)# ip route 0.0.0.0 0.0.0.0 Serial0/1/0 ``` * **Step 2**: Propagate the route in OSPF. Configure OSPF to propagate the default route in OSPF routing updates. ``` R2 (config-router)# default-information originate ``` * **Step 3**: Examine the routing tables on R1 and R3. Examine the routing tables of R1 and R3 to verify that the route has been propagated. ``` R1> show ip route <output omitted> O*E2 0.0.0.0/0 [110/1] via 172.16.3.2, 00:00:08, Serial0/0/0 !---- ip route <output omitted> R3> show O*E2 0.0.0.0/0 [110/1] via 192.168.10.9, 00:08:15, Serial0/0/1 ``` ### **Part 2: Verify Connectivity** Verify that PC1, PC2, and PC3 can ping the web server. ### **Part 3: Modify OSPF Default Settings** * **Step 1**: Test connectivity between all end devices. Before modifying the OSPF settings, verify that all PCs can ping the web server and each other. * **Step 2**: Adjust the hello and dead timers between R1 and R2. Enter the following commands on R1. ``` R1(config)# interface s0/0/0 R1(configif)# ip ospf hello-interval 15 R1(config-if)# ip ospf dead-interval 60 ``` After a short period of time, the OSPF connection with R2 will fail. Both sides of the connection need to have the same timers in order for the adjacency to be maintained. Adjust the timers on R2. * **Step 3**: Adjust the bandwidth setting on R1. Trace the path between PC1 and the web server located at 64.100.1.2. Notice that the path from PC1 to 64.100.1.2 is routed through R2. OSPF prefers the lower cost path. * On the R1 Serial 0/0/0 interface, set the bandwidth to 64 Kb/s. This does not change the actual port speed, only the metric that the OSPF process on R1 will use to calculate best routes. ``` R1(config-if)# bandwidth 64 ``` * Trace the path between PC1 and the web server located at 64.100.1.2. Notice that the path from PC1 to 64.100.1.2 is redirected through R3. OSPF prefers the lower cost path. ### **Part 4: Verify Connectivity** Verify all PCs can ping the web server and each other.

Networking Protocols Lab PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue