7.0 Chapter Introduction
7.0.1 Chapter IntroductionPage 1:
RIP Version 2 (RIPv2) is defined in RFC 1723. It is the first classless routing protocol discussed in this course. The figure places RIPv2 in its proper perspective with other routing protocols. Although RIPv2 is a suitable routing protocol for some environments, it has lost popularity when compared to other routing protocols such as EIGRP, OSPF, and IS-IS, which offer more features and are more scalable.
While it may be less popular than other routing protocols, both versions of RIP are still appropriate in some situations. Although RIP lacks the capabilities of many of the later protocols, its sheer simplicity and widespread use in multiple operating systems makes it an ideal candidate for smaller, homogeneous networks where multi-vendor support is necessary - especially within UNIX environments.
Because you will need to understand RIPv2 - even if you do not use it - this chapter will focus on the differences between a classful routing protocol (RIPv1) and a classless routing protocol (RIPv2) rather than on the details of RIPv2. The main limitation of RIPv1 is that it is a classful routing protocol. As you know, classful routing protocols do not include the subnet mask with the network address in routing updates, which can cause problems with discontiguous subnets or networks that use Variable-Length Subnet Masking (VLSM). Because RIPv2 is a classless routing protocol, subnet masks are included in the routing updates, making RIPv2 more compatible with modern routing environments.
RIPv2 is actually an enhancement of RIPv1's features and extensions rather than an entirely new protocol. Some of these enhanced features include:
- Next-hop addresses included in the routing updates
- Use of multicast addresses in sending updates
- Authentication option available
- Use of holddown and other timers to help prevent routing loops.
- Use of split horizon or split horizon with poison reverse to also help prevent routing loops.
- Use of triggered updates when there is a change in the topology for faster convergence.
- Maximum hop count limit of 15 hops, with the hop count of 16 signifying an unreachable network.
7.0.1 - Chapter Introduction
The diagram depicts routing protocols covered in this course. The RIP v2 distance vector classless interior gateway protocol is the focus of this chapter. In this chapter, you learn to:
- Encounter and describe the limitations of RIP v1.
- Apply the basic Routing Information Protocol Version 2 (RIP v2) configuration commands and evaluate RIP v2 classless routing updates.
- Analyze router output to see RIP v2 support for VLSM and Classless Inter-Domain Routing (CIDR).
- Identify RIP v2 verification commands and common RIP v2 issues.
- Configure, verify, and troubleshoot RIP v2 in the hands-on labs.
The diagram depicts routing protocols covered in this course. The RIP v2 distance vector classless interior gateway protocol is the focus of this chapter. In this chapter, you learn to:
- Encounter and describe the limitations of RIP v1.
- Apply the basic Routing Information Protocol Version 2 (RIP v2) configuration commands and evaluate RIP v2 classless routing updates.
- Analyze router output to see RIP v2 support for VLSM and Classless Inter-Domain Routing (CIDR).
- Identify RIP v2 verification commands and common RIP v2 issues.
- Configure, verify, and troubleshoot RIP v2 in the hands-on labs.
7.1 RIPv1 Limitations
7.1.1 Lab TopologyPage 1:
The figure shows the topology and addressing scheme used in this chapter. This scenario is similar to the routing domain with three routers that was used at the end of Chapter 5, "RIP version 1." Remember that both the R1 and R3 routers have subnets that are part of the 172.30.0.0/16 major classful network (class B). Also remember that R1 and R3 are connected to R2 using subnets of the 209.165.200.0/24 major classful network (class C). This topology is discontiguous and will not converge because 172.30.0.0/16 is divided by the 209.165.200.0/24.
Click R1, R2, and R3 to see the starting configuration for each router.
Summary Route
The topology shows that R2 has a static summary route to the 192.168.0.0/16 network. The configuration of this summary route will be displayed later in this section.
The concept and configuration of static summary routes was discussed in Chapter 2, "Static Routing." We can inject static route information into routing protocol updates. This is called redistribution and will also be discussed later in this section. For now, understand that this summary route will cause problems with RIPv1 because 192.168.0.0/16 is not a major classful address and includes all of the /24 versions of 192.168.0.0/16, as shown in the topology.
Finally, notice that the R1 and R3 routers contain VLSM networks and are sharing address space from the 172.30.0.0/16 major classful network. Next, we will look at the VLSM addressing scheme.
7.1.1 - Lab Topology
The diagram depicts the lab topology and addressing scheme used in this chapter. The startup config is shown for the three routers. The diagram is based on the following network topology.
Network Topology:
There are three routers, R1, R2, and R3, and four LAN switches, S1, S2, S3, and S4. Switch S1 is connected to router R1 interface FA0/0. Switch S2 is connected to router R1 interface FA0/1. Router R1 interface S0/0/0 is connected to router R2 interface S0/0/0 via a WAN link. Switch S3 is connected to router R2 interface FA0/0. Router R2 interface S0/0/1 is connected to router R3 interface S0/0/1 via a WAN link. Switch S4 is connected to R3 interface FA0/0.
Router Interface Addresses:
Router R1 FA0/0 IP address: 172.30.1.1/24
Router R1 FA0/1 IP address: 172.30.2.1/24
Router R1 S0/0/0 IP address: 209.165.200.230/30
Router R2 FA0/0 IP address: 10.1.0.1/16
Router R2 S0/0/0 IP address: 209.165.200.229/30
Router R2 S0/0/1 IP address: 209.165.200.233/30
Router R2 has a summary static route to 192.168.0.0/16
Router R3 FA0/0 IP address: 172.30.100.1/24
Router R3 S0/0/1 IP address: 209.165.200.234/30
Router R3 L o 0 IP address: 172.30.110.1/24
Router R3 L o 1 IP address: 172.30.200.17/28
Router R3 L o 2 IP address: 172.30.200.33/28
Router output for R1, R2, and R3 is shown as follows:
R1#show startup-config
hostname R1
interface FastEthernet0/0
i p address 172.30.1.1 255.255.255.0
interface FastEthernet0/1
i p address 172.30.2.1 255.255.255.0
interface Serial0/0/0
description Link to R2
i p address 209.165.200.230 255.255.255.252
clock rate 64000
R2#show startup-config
hostname R2
interface FastEthernet0/0
i p address 10.1.0.1 255.255.0.0
interface Serial0/0/0
description Link to R1
i p address 209.165.200.229 255.255.255.252
interface Serial0/0/1
description Link to R3
i p address 209.165.200.233 255.255.255.252
clock rate 64000
R3#show startup-config
hostname R3
interface FastEthernet0/0
i p address 172.30.100.1 255.255.255.0
interface Serial0/0/1
description Link to R2
i p address 209.165.200.234 255.255.255.252
interface Loopback0
i p address 172.30.110.1 255.255.255.0
interface Loopback1
i p address 172.30.200.17 255.255.255.240
interface Loopback2
i p address 172.30.200.33 255.255.255.240
The diagram depicts the lab topology and addressing scheme used in this chapter. The startup config is shown for the three routers. The diagram is based on the following network topology.
Network Topology:
There are three routers, R1, R2, and R3, and four LAN switches, S1, S2, S3, and S4. Switch S1 is connected to router R1 interface FA0/0. Switch S2 is connected to router R1 interface FA0/1. Router R1 interface S0/0/0 is connected to router R2 interface S0/0/0 via a WAN link. Switch S3 is connected to router R2 interface FA0/0. Router R2 interface S0/0/1 is connected to router R3 interface S0/0/1 via a WAN link. Switch S4 is connected to R3 interface FA0/0.
Router Interface Addresses:
Router R1 FA0/0 IP address: 172.30.1.1/24
Router R1 FA0/1 IP address: 172.30.2.1/24
Router R1 S0/0/0 IP address: 209.165.200.230/30
Router R2 FA0/0 IP address: 10.1.0.1/16
Router R2 S0/0/0 IP address: 209.165.200.229/30
Router R2 S0/0/1 IP address: 209.165.200.233/30
Router R2 has a summary static route to 192.168.0.0/16
Router R3 FA0/0 IP address: 172.30.100.1/24
Router R3 S0/0/1 IP address: 209.165.200.234/30
Router R3 L o 0 IP address: 172.30.110.1/24
Router R3 L o 1 IP address: 172.30.200.17/28
Router R3 L o 2 IP address: 172.30.200.33/28
Router output for R1, R2, and R3 is shown as follows:
R1#show startup-config
hostname R1
interface FastEthernet0/0
i p address 172.30.1.1 255.255.255.0
interface FastEthernet0/1
i p address 172.30.2.1 255.255.255.0
interface Serial0/0/0
description Link to R2
i p address 209.165.200.230 255.255.255.252
clock rate 64000
R2#show startup-config
hostname R2
interface FastEthernet0/0
i p address 10.1.0.1 255.255.0.0
interface Serial0/0/0
description Link to R1
i p address 209.165.200.229 255.255.255.252
interface Serial0/0/1
description Link to R3
i p address 209.165.200.233 255.255.255.252
clock rate 64000
R3#show startup-config
hostname R3
interface FastEthernet0/0
i p address 172.30.100.1 255.255.255.0
interface Serial0/0/1
description Link to R2
i p address 209.165.200.234 255.255.255.252
interface Loopback0
i p address 172.30.110.1 255.255.255.0
interface Loopback1
i p address 172.30.200.17 255.255.255.240
interface Loopback2
i p address 172.30.200.33 255.255.255.240
Page 2:
VLSM
Review the VLSM addressing scheme in the figure. As shown in the top chart, both R1 and R3 have had the 172.30.0.0/16 network subnetted into /24 subnets. Four of these /24 subnets are assigned: two to R1 (172.30.1.0/24 and 172.30.2.0/24) and two to R3 (172.30.100.0/24 and 172.30.110.0/24).
In the bottom chart, we have taken the 172.30.200.0/24 subnet and subnetted it again, using the first four bits for subnets and the last four bits for hosts. The result is a 255.255.255.240 mask or /28. Subnet 1 and Subnet 2 are assigned to R3. This means that the subnet 172.30.200.0/24 can no longer be used even though the remaining /28 subnets can be used.
7.1.1 - Lab Topology
The diagram depicts subnets assigned to the lab topology. In the top chart, both R1 and R3 are using /24 subnets from the 172.30.0.0/16 network. This creates 256 or /24 subnets. Four of these /24 subnets are assigned: two to R1 (172.30.1.0/24 and 172.30.2.0/24) and two to R3 (172.30.100.0/24 and 172.30.110.0/24).
In the bottom chart, the 172.30.200.0/24 subnet has been subnetted. From the last octet, the first four bits are used for subnets and the last four bits are used for hosts. The result is a 255.255.255.240 mask or /28. This creates 16 /28 subnets. Subnet 1 and subnet 2 are assigned to R3.
The subnets are highlighted in the chart as follows:
Subnet: 1
Network: 172.30.1.0
Host Range: 172.30.1.1 to 172.30.1.254
Broadcast: 172.30.1.255
Subnet: 2
Network: 172.30.2.0
Host Range: 172.30.2.1 to 172.30.2.254
Broadcast: 172.30.2.255
Subnet: 100
Network: 172.30.100.0
Host Range: 172.30.100.1 to 172.30.100.254
Broadcast: 172.30.100.255
Subnet: 110
Network: 172.30.110.0
Host Range: 172.30.110.1 to 172.30.110.254
Broadcast: 172.30.110.255
Subnet 200 is subnetted again with two of these subnets assigned to R3:
Network: 172.30.200.0
Host Range: 172.30.200.1 to 172.30.200.254
Broadcast: 172.30.200.255
Subnet 1 of subnet 200 above:
Network: 172.30.200.0
Host Range: 172.30.200.16 to 172.30.200.30
Broadcast: 172.30.200.31
Subnet: 2 of subnet 200 above:
Network: 172.30.200.32
Host Range: 172.30.200.33 to 172.30.200.46
Broadcast: 172.30.200.47
The diagram depicts subnets assigned to the lab topology. In the top chart, both R1 and R3 are using /24 subnets from the 172.30.0.0/16 network. This creates 256 or /24 subnets. Four of these /24 subnets are assigned: two to R1 (172.30.1.0/24 and 172.30.2.0/24) and two to R3 (172.30.100.0/24 and 172.30.110.0/24).
In the bottom chart, the 172.30.200.0/24 subnet has been subnetted. From the last octet, the first four bits are used for subnets and the last four bits are used for hosts. The result is a 255.255.255.240 mask or /28. This creates 16 /28 subnets. Subnet 1 and subnet 2 are assigned to R3.
The subnets are highlighted in the chart as follows:
Subnet: 1
Network: 172.30.1.0
Host Range: 172.30.1.1 to 172.30.1.254
Broadcast: 172.30.1.255
Subnet: 2
Network: 172.30.2.0
Host Range: 172.30.2.1 to 172.30.2.254
Broadcast: 172.30.2.255
Subnet: 100
Network: 172.30.100.0
Host Range: 172.30.100.1 to 172.30.100.254
Broadcast: 172.30.100.255
Subnet: 110
Network: 172.30.110.0
Host Range: 172.30.110.1 to 172.30.110.254
Broadcast: 172.30.110.255
Subnet 200 is subnetted again with two of these subnets assigned to R3:
Network: 172.30.200.0
Host Range: 172.30.200.1 to 172.30.200.254
Broadcast: 172.30.200.255
Subnet 1 of subnet 200 above:
Network: 172.30.200.0
Host Range: 172.30.200.16 to 172.30.200.30
Broadcast: 172.30.200.31
Subnet: 2 of subnet 200 above:
Network: 172.30.200.32
Host Range: 172.30.200.33 to 172.30.200.46
Broadcast: 172.30.200.47
Page 3:
RFC 1918 Private Addresses
You should already be familiar with RFC 1918 and the reasoning behind private addressing. All the examples in the curriculum use private IP addresses for the inside addressing example.
The RFC 1918-compliant addresses are shown in the table. But when IP traffic is routed across WAN links through an ISP, or when inside users need to access outside sites, a public IP address must be used.
Cisco Example IP Addresses
You may have noticed that the WAN links between R1, R2, and R3 are using public IP addresses. Although these IP addresses are not private addresses according to RFC 1918, Cisco has acquired some public address space to use for example purposes.
The addresses shown in the figure are all valid public IP addresses that are routable on the Internet. Cisco has set these addresses aside for educational purposes. Therefore, this course and future courses will use these addresses when there is a need to use public addresses.
In the figure, R1, R2, and R3 are connected using the 209.165.200.224/27 Cisco public address space. Because WAN links need only two addresses, 209.165.200.224/27 is subnetted with a /30 mask. In the topology, subnet 1 is assigned to the WAN link between R1 and R2. Subnet 2 is assigned to the WAN link between R2 and R3.
7.1.1 - Lab Topology
The diagram depicts RFC 1918 private addresses and Cisco example IP addresses. The diagram is based on the network topology described in 7.1.1 diagram 1.
RFC 1918 Private Addresses:
Class: A
Prefix/Mask: 10.0.0.0/8
Address Range: 10.0.0.0 to 10.255.255.255
Class: B
Prefix/Mask: 172.16.0.0/12
Address Range: 172.16.0.0 to 172.31.255.255
Class: C
Prefix/Mask: 192.168.0.0/16
Address Range: 192.168.0.0 to 192.168.255.255
Cisco Example Public IP Addresses:
Prefix/Mask: 209.165.200.224/27
Address Range: 209.165.200.224 to 209.165.200.255
Prefix/Mask: 209.165.201.0/27
Address Range: 209.165.201.0 to 209.165.201.31
Prefix/Mask: 209.165.202.128/27
Address Range: 209.165.202.128 to 209.165.202.159
The diagram depicts RFC 1918 private addresses and Cisco example IP addresses. The diagram is based on the network topology described in 7.1.1 diagram 1.
RFC 1918 Private Addresses:
Class: A
Prefix/Mask: 10.0.0.0/8
Address Range: 10.0.0.0 to 10.255.255.255
Class: B
Prefix/Mask: 172.16.0.0/12
Address Range: 172.16.0.0 to 172.31.255.255
Class: C
Prefix/Mask: 192.168.0.0/16
Address Range: 192.168.0.0 to 192.168.255.255
Cisco Example Public IP Addresses:
Prefix/Mask: 209.165.200.224/27
Address Range: 209.165.200.224 to 209.165.200.255
Prefix/Mask: 209.165.201.0/27
Address Range: 209.165.201.0 to 209.165.201.31
Prefix/Mask: 209.165.202.128/27
Address Range: 209.165.202.128 to 209.165.202.159
Page 4:
Loopback Interfaces
Notice that R3 is using loopback interfaces (Lo0, Lo1, and Lo2). A loopback interface is a software-only interface that is used to emulate a physical interface. Like other interfaces, it can be assigned an IP address. Loopback interfaces are also used by other routing protocols, such as OSPF, for different purposes. These uses will be discussed in Chapter 11 OSPF.
In a lab environment, loopback interfaces are useful in creating additional networks without having to add more physical interfaces on the router. A loopback interface can be pinged and the subnet can be advertised in routing updates. Therefore, loopback interfaces are ideal for simulating multiple networks attached to the same router. In our example, R3 does not need four LAN interfaces to demonstrate multiple subnets and VLSM. Instead, we use loopback interfaces.
Links
"Internet Assigned Numbers Authority," http://www.iana.org/
"Configuring Logical Interfaces," http://www.cisco.com/en/US/docs/ios/12_2/interface/configuration/guide/icflogin.html
7.1.1 - Lab Topology
The diagram depicts the use of loopback interfaces, a software-only interface that is used to emulate a physical interface. The diagram is based on the network topology described in 7.1.1 diagram 1.
Loopback interfaces in the lab topology include the following:
Interface: L o 0
IP Address: 172.30.110.1
Subnet Mask: 255.255.255.0
Interface: L o 1
IP Address: 172.30.200.17
Subnet Mask: 255.255.255.240
Interface: L o 2
IP Address: 172.30.200.33
Subnet Mask: 255.255.255.240
The diagram depicts the use of loopback interfaces, a software-only interface that is used to emulate a physical interface. The diagram is based on the network topology described in 7.1.1 diagram 1.
Loopback interfaces in the lab topology include the following:
Interface: L o 0
IP Address: 172.30.110.1
Subnet Mask: 255.255.255.0
Interface: L o 1
IP Address: 172.30.200.17
Subnet Mask: 255.255.255.240
Interface: L o 2
IP Address: 172.30.200.33
Subnet Mask: 255.255.255.240
7.1.2 RIPv1 Topology Limitations
Page 1:
Static Routes and Null Interfaces
To configure the static supernet route on R2, the following command is used:
R2(config)#ip route 192.168.0.0 255.255.0.0 Null0
Remember that route summarization allows a single high-level route entry to represent many lower-level routes, thereby reducing the size of routing tables. The static route on R2 uses a /16 mask to summarize all 256 networks ranging from 192.168.0.0/24 to 192.168.255.0/24.
The address space represented by the static summary route 192.168.0.0/16 does not actually exist. In order to simulate this static route, we use a null interface as the exit interface. You do not need to enter any commands to create or configure the null interface. It is always up but does not forward or receive traffic. Traffic sent to the null interface is discarded. For our purposes, the null interface will serve as the exit interface for our static route. Remember from Chapter 2, "Static Routing," that a static route must have an active exit interface before it will be installed in the routing table. Using the null interface will allow R2 to advertise the static route in RIP even though networks belonging to the summary 192.168.0.0/16 do not actually exist.
Route Redistribution
The second command that needs to be entered is the redistribute static command:
R2(config-router)#redistribute static
Redistribution involves taking the routes from one routing source and sending those routes to another routing source. In our example topology, we want the RIP process on R2 to redistribute our static route (192.168.0.0/16) by importing the route into RIP and then sending it to R1 and R3 using the RIP process. We will see if this is indeed happening and if not, why not.
Links
"Configuring Logical Interfaces," http://www.cisco.com/en/US/docs/ios/12_2/interface/configuration/guide/icflogin.html
7.1.2 - RIP v1 Topology Limitations
The diagram depicts using static routes and null interfaces. The diagram is based on the network topology described in 7.1.1 diagram 1.
The R2 router has a static route configured to the simulated 192.168.0.0/16 network. The address space represented by the static summary route 192.168.0.0/16 does not actually exist. To simulate this static route, a null interface is used as the exit interface. The following output depicts the configuration of this static route and its redistribution.
R1 (config)#i p route 192.168.0.0 255.255.0.0 null 0
R2 (config-router)#redistribute static
The diagram depicts using static routes and null interfaces. The diagram is based on the network topology described in 7.1.1 diagram 1.
The R2 router has a static route configured to the simulated 192.168.0.0/16 network. The address space represented by the static summary route 192.168.0.0/16 does not actually exist. To simulate this static route, a null interface is used as the exit interface. The following output depicts the configuration of this static route and its redistribution.
R1 (config)#i p route 192.168.0.0 255.255.0.0 null 0
R2 (config-router)#redistribute static
Page 2:
Verifying and Testing Connectivity
To test whether or not the topology has full connectivity, we first verify that both serial links on R2 are up using the show ip interface brief as shown in the figure for R2 Links. If a link is down, the Status field or the Protocol field (or both fields) will display down in the command output. If a link is up, both fields will display up, as shown here. R2 has direct connectivity to R1 and R3 across the serial links.
But can R2 ping LANs on R1 and R3? Are there any connectivity problems with a classful routing protocol and the discontiguous subnets of 172.30.0.0? Let's test the communications between the routers using ping.
Click R2 Pings in the figure.
This output shows R2 attempting to ping the 172.30.1.1 interface on R1 and the 172.30.100.1 interface on R3. Whenever R2 pings any of the 172.30.0.0 subnets on R1 or R3, only about 50% of the ICMP messages are successful.
Click R1 Pings in the figure.
This output shows that R1 is able to ping 10.1.0.1 but is unsuccessful when attempting to ping the 172.30.100.1 interface on R3.
Click R3 Pings in the figure.
This output shows that R3 is able to ping 10.1.0.1 but is unsuccessful when attempting to ping the 172.30.1.1 interface on R1.
As you can see, there is an obvious problem when trying to communicate with the 172.30.0.0 discontiguous subnets. In the following sections we will examine routing tables and routing updates to further investigate this problem and attempt to resolve it.
7.1.2 - RIP v1 Topology Limitations
The diagram depicts verifying and testing connectivity problems with a classful routing protocol, RIP v1, and the discontiguous subnets of 172.30.0.0. The diagram is based on the network topology described in 7.1.1 diagram 1.
The show i p interface brief command is used to verify R2 link status. R2 has active links to R1 and R3.
Interface: Serial0/0/0
IP-Address: 209.165.200.229
Status: up
Protocol: up
Interface: Serial0/0/1
IP-Address: 209.165.200.233
Status: up
Protocol: up
The ping command on each router is used to verify connectivity.
R2 pings the 172.30.0.0 subnets on R1 and R3 using the commands ping 172.30.1.1 and ping 172.30.100.1. The pings are only partially successful. Each shows a success rate of 60%.
R1 pings cannot reach network 172.30.100.0 on R3. R1 pings 10.1.0.1, which is successful, and then pings 172.30.100.1, which shows a success rate of 0%.
R3 cannot reach network 172.30.1.0 on R1. R3 pings 10.1.0.1, which is successful, and then pings 172.30.1.1, which shows a success rate of 0%.
The diagram depicts verifying and testing connectivity problems with a classful routing protocol, RIP v1, and the discontiguous subnets of 172.30.0.0. The diagram is based on the network topology described in 7.1.1 diagram 1.
The show i p interface brief command is used to verify R2 link status. R2 has active links to R1 and R3.
Interface: Serial0/0/0
IP-Address: 209.165.200.229
Status: up
Protocol: up
Interface: Serial0/0/1
IP-Address: 209.165.200.233
Status: up
Protocol: up
The ping command on each router is used to verify connectivity.
R2 pings the 172.30.0.0 subnets on R1 and R3 using the commands ping 172.30.1.1 and ping 172.30.100.1. The pings are only partially successful. Each shows a success rate of 60%.
R1 pings cannot reach network 172.30.100.0 on R3. R1 pings 10.1.0.1, which is successful, and then pings 172.30.100.1, which shows a success rate of 0%.
R3 cannot reach network 172.30.1.0 on R1. R3 pings 10.1.0.1, which is successful, and then pings 172.30.1.1, which shows a success rate of 0%.
Page 3:
Use the Packet Tracer Activity to practice your router configuration skills, including RIPv1 configurations.
Click the Packet Tracer icon for more details.
7.1.2 - RIP v1 Topology Limitations
Link to Packet Tracer Exploration: Configuring Discontiguous Routes
Use the Packet Tracer Activity to practice your router configuration skills, including RIP v1 configurations.
Link to Packet Tracer Exploration: Configuring Discontiguous Routes
Use the Packet Tracer Activity to practice your router configuration skills, including RIP v1 configurations.
7.1.3 RIPv1: Discontiguous Networks
Page 1:
You already know that RIPv1 is a classful routing protocol. As you can see in the RIPv1 message format, It does not include the subnet masks in its routing updates. Therefore, RIPv1 cannot support discontiguous networks, VLSM, or Classless Inter-Domain Routing (CIDR) supernets. However, might there be room to expand the RIPv1 message format to include the subnet mask so that we could actually have a discontiguous network configuration? How would you change the format of this message in the figure to include the subnet mask?
7.1.3 - RIP v1: Discontiguous Networks
The diagram depicts the RIP v1 message format.
The fields included are:
Header consisting of:
- Command = 1 or 2
- Version = 1
- Must be zero entry
Route entry consisting of:
- Address family identifier (2 = IP)
- Must be zero
- IP Address (Network Address)
- Must be zero entry
- Must be zero entry
- Metric (Hops)
Additional Route Entries, up to 25
The diagram depicts the RIP v1 message format.
The fields included are:
Header consisting of:
- Command = 1 or 2
- Version = 1
- Must be zero entry
Route entry consisting of:
- Address family identifier (2 = IP)
- Must be zero
- IP Address (Network Address)
- Must be zero entry
- Must be zero entry
- Metric (Hops)
Additional Route Entries, up to 25
Page 2:
Because the subnet mask is not included in the update, RIPv1 and other classful routing protocols must summarize networks at major network boundaries. As you can see in the figure, RIPv1 on both the R1 and R3 routers will summarize their 172.30.0.0 subnets to the classful major network address of 172.30.0.0 when sending routing updates to R2. From the perspective of R2, both updates have an equal cost of 1 hop to reach network 172.30.0.0/16. As you will see, R2 installs both paths in the routing table.
7.1.3 - RIP v1: Discontiguous Networks
The diagram depicts RIP v1 automatic summarization in updates from R1 to R2 and from R3 to R2. Each update contains a summarized route to the 172.30.0.0 network from R1 and R3. There are no routes to the individual subnets on R1 and R3 due to automatic summarization. The diagram is based on the network topology described in 7.1.1 diagram 1.
The diagram depicts RIP v1 automatic summarization in updates from R1 to R2 and from R3 to R2. Each update contains a summarized route to the 172.30.0.0 network from R1 and R3. There are no routes to the individual subnets on R1 and R3 due to automatic summarization. The diagram is based on the network topology described in 7.1.1 diagram 1.
Page 3:
Examining the Routing Tables
As you have seen, R2 gets inconsistent results when attempting to ping an address on one of the 172.30.0.0 subnets.
Click R2 Routes in the figure.
Notice that R2 has two equal cost routes to the 172.30.0.0/16 network. This is because both R1 and R3 are sending R2 a RIPv1 update for the 172.30.0.0/16 classful network with a metric of 1 hop. Because R1 and R3 automatically summarized the individual subnets, R2's routing table only contains the major classful network address of 172.30.0.0/16.
We can examine the contents of the routing updates as the updates are sent and received with debug ip rip command.
Click R2 Debug 1 in the figure.
The output from this command shows that R2 is receiving two 172.30.0.0 equal cost routes with a metric of 1 hop. R2 is receiving one route on Serial 0/0/0 from R1 and the other route on Serial 0/0/1 from R3. Notice that the subnet mask is not included with the network address in the update.
What about R1 and R3? Are they receiving each other's 172.30.0.0 subnets?
Click R1 Routes in the figure.
Here we see that R1 has its own 172.30.0.0 routes: 172.30.2.0/24 and 172.30.1.0/24. But R1 does not send R2 those subnets. R3 has a similar routing table. Both R1 and R3 are boundary routers and are only sending the summarized 172.30.0.0 network to R2 in their RIPv1 routing updates. As a result, R2 only knows about the 172.30.0.0/16 classful network and is unaware of any 172.30.0.0 subnets.
Click R2 Debug 2 in the figure.
Notice in the debug ip rip output for R2 that it is not including the 172.30.0.0 network in its updates to either R1 or R3. Why not? Because the split horizon rule is in effect. R2 learned about 172.30.0.0/16 on both the Serial 0/0/0 and Serial 0/0/1 interfaces. Because R2 learned about the 172.30.0.0 on these interfaces, it does not include that network in updates it sends out these same interfaces.
7.1.3 - RIP v1: Discontiguous Networks
The diagram depicts testing connectivity, examining routing tables, and identifying issues with RIP v1 and discontiguous networks. The output from various commands is shown. The diagram is based on the network topology described in 7.1.1 diagram 1.
R2 pings to 172.30.1.1 and 172.30.1.1 are inconsistent, as depicted by the ping output: !U!.!.
Note: For some routers, you need to disable IP C E F to see the results shown.
The show i p route command on R2 shows that the routing table has two equal-cost routes to 172.30.0.0. The following entries are highlighted:
R 172.30.0.0/16 [120/1] via 209.165.200.230, 00:00:09, Serial0/0/0
[120/1] via 209.165.200.234, 00:00:11, Serial0/0/1
The debug i p rip command on R2 shows that R2 is receiving two 172.30.0.0 equal-cost routes with a metric of 1 hop. The following entries are highlighted:
RIP: received v1 update from 209.165.200.230 on Serial0/0/0
172.30.0.0 in 1 hops
RIP: received v1 update from 209.165.200.234 on Serial0/0/1
172.30.0.0 in 1 hops
The show i p route command on R1 shows that R1 has routes to local 172.30.0.0 subnets only. The following entries are highlighted:
172.30.0.0/24 is subnetted, 2 subnets
C 172.30.1.0 is directly connected, FastEthernet0/0
C 172.30.2.0 is directly connected, FastEthernet0/1
The debug i p rip command on R2 shows that R2 is not advertising 172.30.0.0 to R1 or R3. The following entries are highlighted:
RIP: sending v1 update to 255.255.255.255 via Serial0/0/0 (209.165.200.229)
RIP: build update entries
Network 10.0.0.0 metric 1
Subnet 209.165.200.232 metric 1
The diagram depicts testing connectivity, examining routing tables, and identifying issues with RIP v1 and discontiguous networks. The output from various commands is shown. The diagram is based on the network topology described in 7.1.1 diagram 1.
R2 pings to 172.30.1.1 and 172.30.1.1 are inconsistent, as depicted by the ping output: !U!.!.
Note: For some routers, you need to disable IP C E F to see the results shown.
The show i p route command on R2 shows that the routing table has two equal-cost routes to 172.30.0.0. The following entries are highlighted:
R 172.30.0.0/16 [120/1] via 209.165.200.230, 00:00:09, Serial0/0/0
[120/1] via 209.165.200.234, 00:00:11, Serial0/0/1
The debug i p rip command on R2 shows that R2 is receiving two 172.30.0.0 equal-cost routes with a metric of 1 hop. The following entries are highlighted:
RIP: received v1 update from 209.165.200.230 on Serial0/0/0
172.30.0.0 in 1 hops
RIP: received v1 update from 209.165.200.234 on Serial0/0/1
172.30.0.0 in 1 hops
The show i p route command on R1 shows that R1 has routes to local 172.30.0.0 subnets only. The following entries are highlighted:
172.30.0.0/24 is subnetted, 2 subnets
C 172.30.1.0 is directly connected, FastEthernet0/0
C 172.30.2.0 is directly connected, FastEthernet0/1
The debug i p rip command on R2 shows that R2 is not advertising 172.30.0.0 to R1 or R3. The following entries are highlighted:
RIP: sending v1 update to 255.255.255.255 via Serial0/0/0 (209.165.200.229)
RIP: build update entries
Network 10.0.0.0 metric 1
Subnet 209.165.200.232 metric 1
7.1.4 RIPv1: No VLSM Support
Page 1:
Because RIPv1 does not send the subnet mask in routing updates, it cannot support VLSM. R3 router is configured with VLSM subnets, all of which are members of the class B network 172.30.0.0/16:
- 172.30.100.0/24 (FastEthernet 0/0)
- 172.30.110.0/24 (Loopback 0)
- 172.30.200.16/28 (Loopback 1)
- 172.30.200.32/28 (Loopback 2)
Click on the Topology in the figure.
To demonstrate how RIPv1 uses the subnet mask of the outgoing interface, R4 is added to the topology connected to R3 through the FastEthernet0/0 interface on the 172.30.100.0/24 network.
Click Router Output in the figure.
Refer to the debug ip rip in the figure. Notice that the only 172.30.0.0 subnet that is sent to the R4 router is 172.30.110.0. Also, notice that R3 is sending the full 172.30.0.0 major classful network out Serial 0/0/1.
Why is RIPv1 on R3 not including the other subnets, 172.30.200.16/28 and 172.30.200.32/28, in updates to R4? Those subnets do not have the same subnet mask as FastEthernet 0/0. This is why all subnets must use the same subnet mask when a classful routing protocol is implemented in the network.
A more detailed explanation
R3 needs to determine which 172.30.0.0 subnets to include in the updates leaving its FastEthernet 0/0 interface with the IP address 172.30.100.1/24. It will only include those 172.30.0.0 routes in its routing table with the same mask as the exit interface. Since the interface is 172.30.100.1 with a /24 mask, it will only include 172.30.0.0 subnets with a /24 mask. The only one that meets this condition is 172.30.110.0.
The other 172.30.0.0 subnets, 172.30.200.16/28 and 172.30.200.32/28, are not included because the /28 masks do not match the /24 mask of the outgoing interface. The receiving router, R4, can only apply its own /24 interface mask to RIPv1 route advertisements with 172.30.0.0 subnets. R4 would apply the wrong mask of /24 to these subnets with /28 masks.
7.1.4 - RIP v1: No VLSM Support
The diagram depicts that RIP v1 updates do not support VLSM. The diagram is based on the network topology described in 7.1.1 diagram 1, except that the R3 portion of the network is shown, and a router R4 is added to the same switch to which R3 is connected.
The debug i p rip output on R3 shows the following:
Subnet 172.30.110.0 metric 1
Network 172.30.0.0 metric 1
Because 172.30.110.0 has the same subnet mask as the outgoing interface on 172.30.100.0, R3 includes 172.30.110.0 in updates to R4.
The diagram depicts that RIP v1 updates do not support VLSM. The diagram is based on the network topology described in 7.1.1 diagram 1, except that the R3 portion of the network is shown, and a router R4 is added to the same switch to which R3 is connected.
The debug i p rip output on R3 shows the following:
Subnet 172.30.110.0 metric 1
Network 172.30.0.0 metric 1
Because 172.30.110.0 has the same subnet mask as the outgoing interface on 172.30.100.0, R3 includes 172.30.110.0 in updates to R4.
7.1.5 RIPv1: No CIDR Support
Page 1:
The 192.168.0.0/16 Static Route
So far, most of this information should be familiar to you from Chapter 5, "RIP version 1." However, there is one issue that we have not yet addressed.
Click R2 Routing in the figure.
We configured a static route to the 192.168.0.0/16 network on R2 and instructed RIP to include that route in its updates using the redistribute static command, as shown in the figure. This static route is a summary of the 192.168.0.0/24 subnets ranging from 192.168.0.0/24 to 192.168.255.0/24.
R2(config)#ip route 192.168.0.0 255.255.0.0 Null0
Click R2 Routes in the figure.
We can see that the static route is included in R2's routing table.
Click R1 Routes in the figure.
Looking at the routing table for R1, we notice that R1 is not receiving this 192.168.0.0/16 route in its RIP updates from R2, although we might expect that it should.
Click R2 Debug in the figure.
Using debug ip rip on R2, we notice that RIPv1 does not include the 192.168.0.0/16 route in its RIP updates to either R1 or R3. Can you think why this route is not included? Look at the route 192.168.0.0/16. What is the class of the route? Class A, B, or C? What is the mask used in the static route? Does it match the class? Is the mask in the static route less than the classful mask?
We configured the static route 192.168.0.0 with a /16 mask. This is fewer bits than the classful class C mask of /24. Because the mask does not match the class or a subnet of the class, RIPv1 will not include this route in its updates to other routers.
RIPv1 and other classful routing protocols cannot support CIDR routes that are summarized routes with a smaller subnet mask than the classful mask of the route. RIPv1 ignores these supernets in the routing table and does not include them in updates to other routers. This is because the receiving router would only be able to apply the larger classful mask to the update and not the shorter /16 mask.
Note: If the 192.168.0.0 static route were configured with a /24 mask or greater, this route would be included in the RIP updates. The receiving routers would apply the classful /24 mask to this update.
7.1.5 - RIP v1: No CIDR Support
The diagram depicts that RIP v1 and other classful routing protocols cannot support CIDR routes that are summarized routes with a smaller subnet mask than the classful mask of the route. The diagram is based on the network topology described in 7.1.1 diagram 1.
R2 has a static route and is configured to redistribute that static route in RIP updates. The following entries are highlighted.
R2(config)#router rip
R2(config-router)#redistribute static
R2(config)#i p route 192.168.0.0 255.255.0.0 null 0
The show i p route command on R2 shows that the static route is in the routing table for R2. The following entry is highlighted.
S 192.168.0.0/16 is directly connected, Null 0
The show i p route command on R1 shows that R1 is not receiving the static route from R2.
The debug i p rip command on R2 shows that R2 is not sending the static route to R1 or R3. The following entries are highlighted:
RIP: sending v1 update to 255.255.255.255 via Serial0/0/0 (209.165.200.229)
RIP: build update entries
Network 10.0.0.0 metric 1
Subnet 209.165.200.232 metric 1
The diagram depicts that RIP v1 and other classful routing protocols cannot support CIDR routes that are summarized routes with a smaller subnet mask than the classful mask of the route. The diagram is based on the network topology described in 7.1.1 diagram 1.
R2 has a static route and is configured to redistribute that static route in RIP updates. The following entries are highlighted.
R2(config)#router rip
R2(config-router)#redistribute static
R2(config)#i p route 192.168.0.0 255.255.0.0 null 0
The show i p route command on R2 shows that the static route is in the routing table for R2. The following entry is highlighted.
S 192.168.0.0/16 is directly connected, Null 0
The show i p route command on R1 shows that R1 is not receiving the static route from R2.
The debug i p rip command on R2 shows that R2 is not sending the static route to R1 or R3. The following entries are highlighted:
RIP: sending v1 update to 255.255.255.255 via Serial0/0/0 (209.165.200.229)
RIP: build update entries
Network 10.0.0.0 metric 1
Subnet 209.165.200.232 metric 1
Page 2:
Use the Packet Tracer Activity in Simulation mode to see that updates are not sent across classful network boundaries with RIPv1. In RealTime mode, verify non-convergence with the show ip route, ping, and debug ip rip.
Click the Packet Tracer icon for more details.
7.1.5 - RIP v1: No CIDR Support
Link to Packet Tracer Exploration: Verify Non-Convergence Using Commands
Use the Packet Tracer Activity in Simulation mode to see that updates are not sent across classful network boundaries with RIP v1. In RealTime mode, verify non-convergence with the show i p route, ping, and debug i p rip.
Link to Packet Tracer Exploration: Verify Non-Convergence Using Commands
Use the Packet Tracer Activity in Simulation mode to see that updates are not sent across classful network boundaries with RIP v1. In RealTime mode, verify non-convergence with the show i p route, ping, and debug i p rip.
7.2 Configuring RIPv2
7.2.1 Enabling and Verifying RIPv2Page 1:
Comparing RIPv1 and RIPv2 Message Formats
RIPv2 is defined in RFC 1723. Like version 1, RIPv2 is encapsulated in a UDP segment using port 520 and can carry up to 25 routes. Although RIPv2 has the same basic message format as RIPv1, two significant extensions are added.
The first extension in the RIPv2 message format is the subnet mask field that allows a 32 bit mask to be included in the RIP route entry. As a result, the receiving router no longer depends upon the subnet mask of the inbound interface or the classful mask when determining the subnet mask for a route.
The second significant extension to the RIPv2 message format is the addition of the Next Hop address. The Next Hop address is used to identify a better next-hop address - if one exists - than the address of the sending router. If the field is set to all zeros (0.0.0.0), the address of the sending router is the best next-hop address. Detailed information about how the Next Hop address is used is beyond the scope of this course. However, an example can be found in RFC 1722 or Routing TCP/IP Volume 1 by Jeff Doyle.
Links
"RFC 1723: RIP Version 2," http://www.ietf.org/rfc/rfc1723.txt
7.2.1 - Enabling and Verifying RIP v2
The diagram depicts a comparison between RIP v1 and RIP v2 message formats. As compared to the RIP v1 message format, the RIP v2 message format changes the version number from one to two. To each route entry, it also adds a route tag before the IP address (network address) and adds the subnet mask and next hop after the IP address.
The diagram depicts a comparison between RIP v1 and RIP v2 message formats. As compared to the RIP v1 message format, the RIP v2 message format changes the version number from one to two. To each route entry, it also adds a route tag before the IP address (network address) and adds the subnet mask and next hop after the IP address.
Page 2:
Version 2
By default, when a RIP process is configured on a Cisco router, it is running RIPv1. However, even though the router only sends RIPv1 messages, it can interpret both RIPv1 and RIPv2 messages. A RIPv1 router will just ignore the RIPv2 fields in the route entry.
Click R2 RIPv1 in the figure.
The show ip protocols command verifies that R2 is configured for RIPv1 but receives RIP messages for both versions.
Click RIPv2 Configs in the figure.
Notice that the version 2 command is used to modify RIP to use version 2. This command should be configured on all routers in the routing domain. The RIP process will now include the subnet mask in all updates, making RIPv2 a classless routing protocol.
Click R2 RIPv2 in the figure.
As you can see from the output, when a router is configured for version 2, only RIPv2 messages are sent and received.
Click Revert to RIPv1 in the figure.
The default behavior of RIPv1 can be restored by using the command no version in the router configuration mode. However, the command version 1 can also be used so that only RIPv1 messages are sent and received.
7.2.1 - Enabling and Verifying RIP v2
The diagram depicts enabling and verifying RIP v2. The diagram is based on the network topology described in 7.1.1 diagram 1.
Before conversion to RIP v2, the show i p protocols command verifies that R2 is configured for RIP v1 and sends RIP v1 updates. However, it receives RIP messages for both versions.
The RIP router command, version 2, is configured on all routers in the routing domain. The RIP process now includes the subnet mask in all updates, making RIP v2 a classless routing protocol.
After conversion to RIP v2, the show i p protocols command verifies that R2 is configured for version 2, and only RIP v2 messages are sent and received. RIPv1 updates are now ignored.
The default behavior of RIP v1 can be restored by using the command, no version, in router configuration mode. However, the command, version 1, can also be used so that only RIP v1 messages are sent and received.
The diagram depicts enabling and verifying RIP v2. The diagram is based on the network topology described in 7.1.1 diagram 1.
Before conversion to RIP v2, the show i p protocols command verifies that R2 is configured for RIP v1 and sends RIP v1 updates. However, it receives RIP messages for both versions.
The RIP router command, version 2, is configured on all routers in the routing domain. The RIP process now includes the subnet mask in all updates, making RIP v2 a classless routing protocol.
After conversion to RIP v2, the show i p protocols command verifies that R2 is configured for version 2, and only RIP v2 messages are sent and received. RIPv1 updates are now ignored.
The default behavior of RIP v1 can be restored by using the command, no version, in router configuration mode. However, the command, version 1, can also be used so that only RIP v1 messages are sent and received.
7.2.2 Auto-summary and RIPv2
Page 1:
Examining the Routing Tables
Because RIPv2 is a classless routing protocol, you might expect to see the individual 172.30.0.0 subnets in the routing tables. However, when we examine the routing table for R2 in the figure, we still see the summarized 172.30.0.0/16 route with same two equal cost paths. Routers R1 and R3 still do not include the 172.30.0.0 subnets of the other router.
Click R1 Routes in the figure.
The only difference so far between RIPv1 and RIPV2 is that R1 and R3 each have a route to the 192.168.0.0/16 supernet. This route was the static route configured on R2 and redistributed by RIP.
Click R1 Debug 1 in the figure.
So, what is happening? To examine which RIPv2 routes are being sent and received, we will use debug ip rip. The figure shows the debug ip rip output for R1. Notice that RIPv2 is sending both the network address and subnet mask:
RIP: sending v2 update to 224.0.0.9 via Serial0/0 (209.165.200.230)
172.30.0.0/16 via 0.0.0.0, metric 1, tag 0
However, notice that the route sent is the summarized classful network address, 172.30.0.0/16, and not the individual 172.30.1.0/24 and 172.30.2.0/24 subnets.
Click Auto-summary in the figure.
By default, RIPv2 automatically summarizes networks at major network boundaries, just like RIPv1. Both R1 and R3 routers are still summarizing their 172.30.0.0 subnets to the class B address of 172.30.0.0 when sending updates out their interfaces on the 209.165.200.228 and 209.165.200.232 networks, respectively. The command show ip protocols verifies that "automatic summarization is in effect."
Click R1 Debug 2 in the figure.
The only change resulting from the version 2 command is that R2 is now including the 192.168.0.0/16 network in its updates. This is because RIPv2 includes the 255.255.0.0 mask with the 192.168.0.0 network address in the update. Both R1 and R3 will now receive this redistributed static route via RIPv2 and enter it into their routing tables.
Note: Remember, the 192.168.0.0/16 route could not be distributed with RIPv1 because the subnet mask was less than the classful mask. Because the mask is not included in RIPv1 updates, there was no way for the RIPv1 router to determine what that mask should be. Therefore, the update was never sent.
7.2.2 - Auto-summary and RIP v2
The diagram depicts that, by default, RIP v2 automatically summarizes networks at major network boundaries, like RIP v1. Both R1 and R3 routers are still summarizing their 172.30.0.0 subnets to the class B address of 172.30.0.0 when sending updates.
The command show i p protocols verifies that automatic summarization is in effect. The diagram is based on the network topology described in 7.1.1 diagram 1.
The show i p route command on R2 shows R2 still has equal-cost routes.
The show i p route command on R1 shows R1 now has a supernet.
The debug i p rip command on R1 shows that R1 is still sending summary routes, but with subnet mask /16.
The show i p protocols command on R1 shows that automatic network summarization is in effect.
The debug i p rip command on R1 shows that supernets are now included in RIP v2 updates.
The diagram depicts that, by default, RIP v2 automatically summarizes networks at major network boundaries, like RIP v1. Both R1 and R3 routers are still summarizing their 172.30.0.0 subnets to the class B address of 172.30.0.0 when sending updates.
The command show i p protocols verifies that automatic summarization is in effect. The diagram is based on the network topology described in 7.1.1 diagram 1.
The show i p route command on R2 shows R2 still has equal-cost routes.
The show i p route command on R1 shows R1 now has a supernet.
The debug i p rip command on R1 shows that R1 is still sending summary routes, but with subnet mask /16.
The show i p protocols command on R1 shows that automatic network summarization is in effect.
The debug i p rip command on R1 shows that supernets are now included in RIP v2 updates.
7.2.3 Disabling Auto-Summary in RIPv2
Page 1:
As you can see in the figure, to modify the default RIPv2 behavior of automatic summarization, use the command no auto-summary in the router configuration mode. This command is not valid with RIPv1. Even though the Cisco IOS will let you configure no auto-summary for RIPv1, the command has no effect. You must also configure version 2 before the Cisco IOS will change the way it sends RIP updates.
Once automatic summarization has been disabled, RIPv2 will no longer summarize networks to their classful address at boundary routers. RIPv2 will now include all subnets and their appropriate masks in its routing updates. The command show ip protocols can be used to verify that "automatic network summarization is not in effect."
7.2.3 - Disabling Auto-Summarization in RIP v2
The diagram depicts how to disable the default behavior of RIP v2 automatic summarization. The diagram is based on the network topology described in 7.1.1 diagram 1.
After issuing the command no auto-summary in router configuration mode, the show i p protocols command on R1 shows that automatic network summarization is not in effect.
The diagram depicts how to disable the default behavior of RIP v2 automatic summarization. The diagram is based on the network topology described in 7.1.1 diagram 1.
After issuing the command no auto-summary in router configuration mode, the show i p protocols command on R1 shows that automatic network summarization is not in effect.
7.2.4 Verifying RIPv2 Updates
Page 1:
Now that we are using the classless routing protocol RIPv2 and we have also disabled automatic summarization, what should we expect to see in the routing tables?
In the figure, the routing table for R2 now contains the individual subnets for 172.30.0.0/16. Notice that there is no longer a single summary route with two equal cost paths. Each subnet and mask has its own specific entry, along with the exit interface and next-hop address to reach that subnet.
Click R1 Routes in the figure.
The routing table for R1 contains all of the subnets for 172.30.0.0/16, including those subnets from R3.
Click R3 Routes in the figure.
The routing table for R3 contains all of the subnets for 172.30.0.0/16, including those subnets from R1. This network is converged.
Click R2 Debug in the figure.
We can verify that the classless routing protocol RIPv2 is indeed sending and receiving the subnet mask information in the routing updates using debug ip rip. Notice that each route entry now includes the slash notation for the subnet mask.
We can also see that an update on one interface has its metric incremented before it is sent out another interface. For example, the update that was received on Serial 0/0/1 for the 172.30.100.0/24 network with 1 hop is sent out other interfaces, such as Serial 0/0/0, with a metric of 2, or 2 hops.
RIP: received v2 update from 209.165.200.234 on Serial0/0/1
172.30.100.0/24 via 0.0.0.0 in 1 hops
RIP: sending v2 update to 224.0.0.9 via Serial0/0/0 (209.165.200.229)
172.30.100.0/24 via 0.0.0.0, metric 2, tag 0
Notice also that the updates are sent using the multicast address 224.0.0.9. RIPv1 sends updates as a broadcast 255.255.255.255. There are several advantages to using a multicast address. Details about multicast addressing are beyond the scope of this course; in general, however, multicasts can take up less bandwidth on the network. In addition, multicasting updates require less processing by devices that are not RIP-enabled. Under RIPv2, any device that is not configured for RIP will discard the frame at the Data Link layer. With broadcast updates under RIPv1 configurations, all devices on a broadcast network like Ethernet must process a RIP update all the way up to the Transport layer, where the device finally discovers that the packet is destined for a process that does not exist.
7.2.4 - Verifying RIP v2 Updates
The diagram depicts the routing tables now that classless routing protocol RIP v2 is in use and automatic summarization has been disabled. The diagram is based on the network topology described in 7.1.1 diagram 1.
R2 now has all 172.30.X.0 subnets learned via RIP v2 in its routing table.
172.30.0.0/16 is variably subnetted, 6 subnets, 2 masks
R 172.30.20.32/28 [120/1] via 209.165.200.234, 00:00:09, Serial0/0/1
R 172.30.20.16/28 [120/1] via 209.165.200.234, 00:00:09, Serial0/0/1
R 172.30.2.0/24 [120/1] via 209.165.200.230, 00:00:03, Serial0/0/0
R 172.30.1.0/24 [120/1] via 209.165.200.230, 00:00:03, Serial0/0/0
R 172.30.100.0/24 [120/1] via 209.165.200.234, 00:00:09, Serial0/0/1
R 172.30.110.0/24 [120/1] via 209.165.200.234, 00:00:09, Serial0/0/1
R1 now has all 172.30.X.0 subnets learned via RIP v2 in its routing table.
R 172.30.200.32/28 [120/2] via 209.165.200.229, 00:00:01, Serial0/0/0
R 172.30.200.16/28 [120/2] via 209.165.200.229, 00:00:01, Serial0/0/0
R 172.30.100.0/24 [120/2] via 209.165.200.229, 00:00:01, Serial0/0/0
R 172.30.110.0/24 [120/2] via 209.165.200.229, 00:00:01, Serial0/0/0
R3 now has all 172.30.X.0 subnets learned via RIP v2 in its routing table.
R 172.30.2.0/24 [120/2] via 209.165.200.233, 00:00:01, Serial0/0/1
R 172.30.1.0/24 [120/2] via 209.165.200.233, 00:00:01, Serial0/0/1
The debug i p rip command on R2 shows R2 receiving a route from R3 as 1 hop and R2 sending route to R1 as 2 hops.
The diagram depicts the routing tables now that classless routing protocol RIP v2 is in use and automatic summarization has been disabled. The diagram is based on the network topology described in 7.1.1 diagram 1.
R2 now has all 172.30.X.0 subnets learned via RIP v2 in its routing table.
172.30.0.0/16 is variably subnetted, 6 subnets, 2 masks
R 172.30.20.32/28 [120/1] via 209.165.200.234, 00:00:09, Serial0/0/1
R 172.30.20.16/28 [120/1] via 209.165.200.234, 00:00:09, Serial0/0/1
R 172.30.2.0/24 [120/1] via 209.165.200.230, 00:00:03, Serial0/0/0
R 172.30.1.0/24 [120/1] via 209.165.200.230, 00:00:03, Serial0/0/0
R 172.30.100.0/24 [120/1] via 209.165.200.234, 00:00:09, Serial0/0/1
R 172.30.110.0/24 [120/1] via 209.165.200.234, 00:00:09, Serial0/0/1
R1 now has all 172.30.X.0 subnets learned via RIP v2 in its routing table.
R 172.30.200.32/28 [120/2] via 209.165.200.229, 00:00:01, Serial0/0/0
R 172.30.200.16/28 [120/2] via 209.165.200.229, 00:00:01, Serial0/0/0
R 172.30.100.0/24 [120/2] via 209.165.200.229, 00:00:01, Serial0/0/0
R 172.30.110.0/24 [120/2] via 209.165.200.229, 00:00:01, Serial0/0/0
R3 now has all 172.30.X.0 subnets learned via RIP v2 in its routing table.
R 172.30.2.0/24 [120/2] via 209.165.200.233, 00:00:01, Serial0/0/1
R 172.30.1.0/24 [120/2] via 209.165.200.233, 00:00:01, Serial0/0/1
The debug i p rip command on R2 shows R2 receiving a route from R3 as 1 hop and R2 sending route to R1 as 2 hops.
Page 2:
Use the Packet Tracer Activity to configure RIPv2, disable automatic summarization, and verify your configurations.
Click the Packet Tracer icon for more details.
7.2.4 - Verifying RIP v2 Updates
Link to Packet Tracer Exploration: Configure RIP v2
Use the Packet Tracer Activity to configure RIP v2, disable automatic summarization, and verify your configurations.
Link to Packet Tracer Exploration: Configure RIP v2
Use the Packet Tracer Activity to configure RIP v2, disable automatic summarization, and verify your configurations.
7.3 VLSM and CIDR
7.3.1 RIPv2 and VLSMPage 1:
Because classless routing protocols like RIPv2 can carry both the network address and the subnet mask, they do not need to summarize these networks to their classful addresses at major network boundaries. Therefore, classless routing protocols support VLSM. Routers using RIPv2 no longer need to use the inbound interface's mask to determine the subnet mask in the route advertisement. The network and the mask are explicitly included in each and every routing update.
In networks that use a VLSM addressing scheme, a classless routing protocol is essential to propagate all of the networks along with their correct subnet masks. Looking at the output from debug ip rip for R3 in the figure, we can see that RIPv2 include the networks and their subnet masks in its routing updates.
Also notice in the figure that we have once again added the R4 router in the topology. Remember, with RIPv1, R3 would only send R4 the 172.30.0.0 routes that had the same mask as the FastEthernet 0/0 exit interface. Because the interface is 172.30.100.1 with a /24 mask, RIPv1 only included 172.30.0.0 subnets with a /24 mask. The only route that met this condition was 172.30.110.0.
However, with RIPv2, R3 can now include all of the 172.30.0.0 subnets in its routing updates to R4, as shown in the debug output in the figure. This is because RIPv2 can include the proper subnet mask with the network address in the update.
7.3.1 - RIP v2 and VLSM
The diagram depicts that RIP v2 can support VLSM. The network and the mask are explicitly included in every routing update. The diagram is based on the network topology described in 7.1.1 diagram 1, except that the R3 portion of the network is shown, and router R4 is added to the same switch to which R3 is connected.
Router R3 debug output shows all 172.30.x.x subnets being advertised. The update entries include the subnet mask in slash format, as shown below.
172.30.1.0/24 via 0.0.0.0, metric 3, tag 0
172.30.2.0/24 via 0.0.0.0, metric 3, tag 0
172.30.110.0/24 via 0.0.0.0, metric 1, tag 0
172.30.200.16/28 via 0.0.0.0, metric 1, tag 0
172.30.200.32/28 via 0.0.0.0, metric 1, tag 0
The diagram depicts that RIP v2 can support VLSM. The network and the mask are explicitly included in every routing update. The diagram is based on the network topology described in 7.1.1 diagram 1, except that the R3 portion of the network is shown, and router R4 is added to the same switch to which R3 is connected.
Router R3 debug output shows all 172.30.x.x subnets being advertised. The update entries include the subnet mask in slash format, as shown below.
172.30.1.0/24 via 0.0.0.0, metric 3, tag 0
172.30.2.0/24 via 0.0.0.0, metric 3, tag 0
172.30.110.0/24 via 0.0.0.0, metric 1, tag 0
172.30.200.16/28 via 0.0.0.0, metric 1, tag 0
172.30.200.32/28 via 0.0.0.0, metric 1, tag 0
7.3.2 RIPv2 and CIDR
Page 1:
One of the goals of Classless Inter-Domain Routing (CIDR) as stated by RFC 1519 is "to provide a mechanism for the aggregation of routing information." This goal includes the concept of supernetting. A supernet is a block of contiguous classful networks that is addressed as a single network. On the R2 router, we configured a supernet - a static route to a single network that is used to represent multiple networks or subnets.
Supernets have masks that are smaller than the classful mask (/16 here, instead of the classful /24). For the supernet to be included in a routing update, the routing protocol must have the capability of carrying that mask. In other words, it must be a classless routing protocol, like RIPv2.
The static route on R2 does include a mask which is less than the classful mask:
R2(config)#ip route 192.168.0.0 255.255.0.0 Null0
In a classful environment, the 192.168.0.0 network address would be associated with the class C mask /24, or 255.255.255.0. In today's networks, we no longer associate network addresses with classful masks. In this example, the 192.168.0.0 network has a /16, or 255.255.0.0, mask. This route could represent a series of 192.168.0.0/24 networks or any number of different address ranges. The only way this route can be included in a dynamic routing update is with a classless routing protocol that includes the /16 mask.
Click R2 Debug in the figure.
Using debug ip rip we can see that this CIDR supernet is included in the routing update sent by R2. Automatic summarization does not have to be disabled on RIPv2 or any classless routing protocol in order for supernets to be included in the updates.
Click R1 Routes in the figure.
The routing table for R1 shows that it has received the supernet route from R2.
7.3.2 - RIP v2 and CIDR
The diagram depicts that RIP v2 can support CIDR. The supernet route to the 192.168.0.0/16 network is now propagated. The diagram is based on the network topology described in 7.1.1 diagram 1.
The supernet 192.168.0.0/16 is configured on R2:
R2(config) #i p route 192.168.0.0 255.255.0.0 null 0
The debug i p rip command on R2 shows R2 building an update entry for the supernet, and the supernet is sent by R2.
192.168.0.0/16 via 0.0.0.0 metric 1, tag 0
The supernet is now in R1's Routing Table.
R 192.168.0.0/16 [120/1] via 209.165.200.229, 00:00:02, Serial0/0/0
The diagram depicts that RIP v2 can support CIDR. The supernet route to the 192.168.0.0/16 network is now propagated. The diagram is based on the network topology described in 7.1.1 diagram 1.
The supernet 192.168.0.0/16 is configured on R2:
R2(config) #i p route 192.168.0.0 255.255.0.0 null 0
The debug i p rip command on R2 shows R2 building an update entry for the supernet, and the supernet is sent by R2.
192.168.0.0/16 via 0.0.0.0 metric 1, tag 0
The supernet is now in R1's Routing Table.
R 192.168.0.0/16 [120/1] via 209.165.200.229, 00:00:02, Serial0/0/0
7.4 Verifying and Troubleshooting RIPv2
7.4.1 Verification and Troubleshooting CommandsPage 1:
There are several ways to verify and troubleshoot RIPv2. Many of the same commands used for RIPv2 can be used to verify and troubleshoot other routing protocols.
It is always best to begin with the basics:
1. Make sure all of the links (interfaces) are up and operational.
2. Check the cabling.
3. Check to make sure you have the correct IP address and subnet mask on each interface.
4. Remove any unnecessary configuration commands that are no longer necessary or have been replaced by other commands.
Click show ip route in the figure.
This is the first command to use to check for network convergence. As you examine the routing table, it is important to look for the routes that you expect to be in the routing table as well as for those that should not be in the routing table.
Click show ip interface brief in the figure.
If a network is missing from the routing table, often it is because an interface is down or incorrectly configured. The show ip interface brief command quickly verifies the status of all interfaces.
Click show ip protocols in the figure.
The show ip protocols command verifies several critical items, including verifying that RIP is enabled, the version of RIP, the status of automatic summarization, and the networks that were included in the network statements. The Routing Information Sources listed at the bottom of the output are the RIP neighbors from which this router is currently receiving updates.
Click debug ip rip in the figure.
As demonstrated throughout the chapter, debug ip rip is an excellent command to use to examine the contents of the routing updates that are sent and received by a router. There may be times when a route is being received by a router but is not being added to the routing table. One reason for this could be that a static route is also configured for the same network being advertised. By default, a static route has a lower administrative distance than any dynamic routing protocol and will take precedence in being added to the routing table.
Click ping in the figure.
An easy way to verify round-trip connectivity is with the ping command. If end-to-end connectivity is not successful, begin by pinging the local interfaces. If successful, ping the router interfaces on the directly connected networks. If that is also successful, continue pinging interfaces on each successive router. Once a ping is unsuccessful, examine both routers and all the routers in-between to determine where and why the ping is failing.
Click show running-config in the figure.
The show running-config can be used to verify all the commands currently configured. Usually, other commands are more efficient and provide more information than a simple listing of the current configuration. However, the show running-config command is useful in determining if anything obvious was forgotten or misconfigured.
7.4.1 - Verification and Troubleshooting Commands
The diagram depicts several commands used to verify and troubleshoot RIP v2. These include the commands described below. The diagram is based on the network topology described in 7.1.1 diagram 1.
Show i p route: Verifies the routing table.
Show i p interface brief: Verifies that interfaces are active.
Show i p protocols: Verifies the routing configuration.
Debug i p rip: Troubleshoots the routing configuration.
Ping: Tests connectivity to other hosts.
Show running-config: Troubleshoots the routing configuration.
The diagram depicts several commands used to verify and troubleshoot RIP v2. These include the commands described below. The diagram is based on the network topology described in 7.1.1 diagram 1.
Show i p route: Verifies the routing table.
Show i p interface brief: Verifies that interfaces are active.
Show i p protocols: Verifies the routing configuration.
Debug i p rip: Troubleshoots the routing configuration.
Ping: Tests connectivity to other hosts.
Show running-config: Troubleshoots the routing configuration.
7.4.2 Common RIPv2 issues
Page 1:
When troubleshooting issues specific to RIPv2, there are several areas to examine.
Version
A good place to begin troubleshooting a network that is running RIP is to verify that version 2 is configured on all routers. Although RIPv1 and RIPv2 are compatible, RIPv1 does not support discontiguous subnets, VLSM, or CIDR supernet routes. It is always better to use the same routing protocol on all routers unless there is a specific reason not to do so.
Network Statements
Another source of problems might be incorrect or missing network statements. Remember, the network statement does two things:
- It enables the routing protocol to send and receive updates on any local interfaces that belong to that network.
- It includes that network in its routing updates to its neighboring routers.
Automatic Summarization
If there is a need or expectation for sending specific subnets and not just summarized routes, make sure that automatic summarization has been disabled.
7.4.2 - Common RIP v2 issues
The diagram depicts a RIP v2 configuration and potential areas for misconfiguration. The diagram is based on the network topology described in 7.1.1 diagram 1
The output from the show running-config command on R1 displays the following RIP-related commands.
router rip
version 2
network 172.30.0.0
network 209.165.200.0
no auto-summary
The diagram depicts a RIP v2 configuration and potential areas for misconfiguration. The diagram is based on the network topology described in 7.1.1 diagram 1
The output from the show running-config command on R1 displays the following RIP-related commands.
router rip
version 2
network 172.30.0.0
network 209.165.200.0
no auto-summary
7.4.3 Authentication
Page 1:
Most routing protocols send their routing updates and other routing information using IP (in IP packets). IS-IS is the notable exception and is discussed in CCNP courses. A security concern of any routing protocol is the possibility of accepting invalid routing updates. The source of these invalid routing updates could be an attacker maliciously attempting to disrupt the network or trying to capture packets by tricking the router into sending its updates to the wrong destination. Another source of invalid updates could be a misconfigured router. Or perhaps a host is attached to the network and - unknown to its user - the host is running the routing protocol of the local network.
For example, in the figure, R1 is propagating a default route to all other routers in this routing domain. However, someone has mistakenly added router R4 to the network, which is also propagating a default route. Some of the routers may forward default traffic to R4 instead of to the real gateway router, R1. These packets could be "black holed" and never seen again.
Whatever the reason, it is good practice to authenticate routing information transmitted between routers. RIPv2, EIGRP, OSPF, IS-IS, and BGP can be configured to authenticate routing information. This practice ensures routers will only accept routing information from other routers that have been configured with the same password or authentication information. Note: Authentication does not encrypt the routing table.
Note: Because RIP has given way to more popular routing protocols, detailed configuration features for authentication in RIPv2 are not discussed in this chapter. Instead, configuring routing protocols to use authentication will be discussed in a later course with other security issues.
7.4.3 - Authentication
The animation depicts the importance of authenticating routing information updates between routers as a means to determine which router has the correct default route. The diagram is based on the following network topology.
Network Topology:
Router R1 is connected to R3 and the Internet. Router R4 is connected to R3.
As the animation progresses, R1 says: I have the valid default route to the Internet!
R4 says: I have a default route to the Internet!
R3 says: Which route do I use?
R3 installs both routes and load balances default traffic between R1 and R4. Default traffic sent to R4 is discarded because R4 does not really have a default route to the Internet. If routing protocol authentication is employed, R1 would authenticate to R3 and R4 would not, thus R3 would not accept any updates from R4.
The animation depicts the importance of authenticating routing information updates between routers as a means to determine which router has the correct default route. The diagram is based on the following network topology.
Network Topology:
Router R1 is connected to R3 and the Internet. Router R4 is connected to R3.
As the animation progresses, R1 says: I have the valid default route to the Internet!
R4 says: I have a default route to the Internet!
R3 says: Which route do I use?
R3 installs both routes and load balances default traffic between R1 and R4. Default traffic sent to R4 is discarded because R4 does not really have a default route to the Internet. If routing protocol authentication is employed, R1 would authenticate to R3 and R4 would not, thus R3 would not accept any updates from R4.
Page 2:
Use the Packet Tracer Activity to see how unintentional routing updates can corrupt the routing table.
Click the Packet Tracer icon for more details.
7.4.3 - Authentication
Link to Packet Tracer Exploration: Routing Table Corruption
Use the Packet Tracer Activity to see how unintentional routing updates can corrupt the routing table.
Link to Packet Tracer Exploration: Routing Table Corruption
Use the Packet Tracer Activity to see how unintentional routing updates can corrupt the routing table.
7.5 RIPv2 Configuration Labs
7.5.1 Basic RIPv2 ConfigurationPage 1:
In this lab, you will work with a discontiguous network that is subnetted using VLSM. As you have seen throughout this chapter and Chapter 5, "RIP version 1", this can be an issue when the routing protocol used does not include enough information to distinguish the individual subnets. To solve this problem, you will configure RIPv2 as the classless routing protocol to provide subnet mask information in the routing updates.
Click the lab icon for more details.
7.5.1 - Basic RIP v2 Configuration
Link to Hands-on Lab: RIP v2 Basic Configuration Lab
In this lab, you work with a discontiguous network that is subnetted using VLSM. As you have seen throughout this chapter and Chapter 5, "RIP version 1", this can be an issue when the routing protocol used does not include enough information to distinguish the individual subnets. To solve this problem, you configure RIP v2 as the classless routing protocol to provide subnet mask information in the routing updates.
Link to Hands-on Lab: RIP v2 Basic Configuration Lab
In this lab, you work with a discontiguous network that is subnetted using VLSM. As you have seen throughout this chapter and Chapter 5, "RIP version 1", this can be an issue when the routing protocol used does not include enough information to distinguish the individual subnets. To solve this problem, you configure RIP v2 as the classless routing protocol to provide subnet mask information in the routing updates.
Page 2:
Use the Packet Tracer Activity to repeat a simulation of Lab 7.5.1. Remember, however, that Packet Tracer is not a substitute for a hands-on lab experience with real equipment.
A summary of the instructions is provided within the activity. Use the Lab PDF for more details.
Click the Packet Tracer icon for more details.
7.5.1 - Basic RIP v2 Configuration
Link to Packet Tracer Exploration: Basic RIP v2 Configuration
Use the Packet Tracer Activity to repeat a simulation of Lab 7.5.1.
Link to Packet Tracer Exploration: Basic RIP v2 Configuration
Use the Packet Tracer Activity to repeat a simulation of Lab 7.5.1.
7.5.2 Challenge RIPv2 Configuration
Page 1:
In this lab activity, you are given a network address that must be subnetted using VLSM to complete the addressing of the network. A combination of RIP version 2 and static routing will be required so that hosts on networks that are not directly connected will be able to communicate with each other and the Internet.
Click the lab icon for more details.
7.5.2 - Challenge RIP v2 Configuration
Link to Hands-on Lab: RIP v2 Challenge Configuration Lab
In this lab activity, you are given a network address that must be subnetted using VLSM to complete the addressing of the network. A combination of RIP version 2 and static routing is required so that hosts on networks that are not directly connected can communicate with each other and the Internet.
Link to Hands-on Lab: RIP v2 Challenge Configuration Lab
In this lab activity, you are given a network address that must be subnetted using VLSM to complete the addressing of the network. A combination of RIP version 2 and static routing is required so that hosts on networks that are not directly connected can communicate with each other and the Internet.
Page 2:
Use the Packet Tracer Activity to repeat a simulation of Lab 7.5.2. Remember, however, that Packet Tracer is not a substitute for a hands-on lab experience with real equipment.
A summary of the instructions is provided within the activity. Use the Lab PDF for more details.
Click the Packet Tracer icon for more details.
7.5.2 - Challenge RIP v2 Configuration
Link to Packet Tracer Exploration: RIP v2 Challenge Configuration Lab
Use the Packet Tracer Activity to repeat a simulation of Lab 7.5.2.
Link to Packet Tracer Exploration: RIP v2 Challenge Configuration Lab
Use the Packet Tracer Activity to repeat a simulation of Lab 7.5.2.
7.5.3 RIPv2 Troubleshooting
Page 1:
In this lab, you begin by loading configuration scripts on each of the routers. These scripts contain errors that will prevent end-to-end communication across the network. After loading the corrupted scripts, troubleshoot each router to determine the configuration errors, and then use the appropriate commands to correct the configurations. When you have corrected all of the configuration errors, all of the hosts on the network should be able to communicate with each other.
Click the lab icon for more details.
7.5.3 - RIP v2 Troubleshooting
Link to Hands-on Lab: RIP v2 Troubleshooting Lab
In this lab, you begin by loading configuration scripts on each of the routers. These scripts contain errors that prevent end-to-end communication across the network. After loading the corrupted scripts, troubleshoot each router to determine the configuration errors, and then use the appropriate commands to correct the configurations. When you have corrected all the configuration errors, all hosts on the network should be able to communicate with each other.
Link to Hands-on Lab: RIP v2 Troubleshooting Lab
In this lab, you begin by loading configuration scripts on each of the routers. These scripts contain errors that prevent end-to-end communication across the network. After loading the corrupted scripts, troubleshoot each router to determine the configuration errors, and then use the appropriate commands to correct the configurations. When you have corrected all the configuration errors, all hosts on the network should be able to communicate with each other.
Page 2:
Use the Packet Tracer Activity to repeat a simulation of Lab 7.5.3. Remember, however, that Packet Tracer is not a substitute for a hands-on lab experience with real equipment.
A summary of the instructions is provided within the activity. Use the Lab PDF for more details.
Click the Packet Tracer icon for more details.
7.5.3 - RIP v2 Troubleshooting
Link to Packet Tracer Exploration: RIP Troubleshooting
Use the Packet Tracer Activity to repeat a simulation of Lab 7.5.3.
Link to Packet Tracer Exploration: RIP Troubleshooting
Use the Packet Tracer Activity to repeat a simulation of Lab 7.5.3.
7.6 Chapter Summary
7.6.1 Summary and ReviewPage 1:
Summary
RIPv2 is a classless, distance vector routing protocol, that is defined in RFC 1723. Because RIPv2 is a classless routing protocol, it includes the subnet mask with the network addresses in the routing updates. As with other classless routing protocols, RIPv2 supports CIDR supernets, VLSM and discontiguous networks.
We saw that classful routing protocols like RIPv1 can not support discontiguous networks because they automatically summarize at major network boundaries. A router that receives routing updates from multiple routers advertising the same classful summary route cannot determine which subnets belong to which summary route. This inability leads to unexpected results including misrouted packets.
The default version of RIP is version 1. The command version 2 is used to modify RIP to RIPv2.
Similar to RIPv1, RIPv2 automatically summarizes at major network boundaries. However, with RIPv2 automatic summarization can be disabled with the no auto-summary command. Automatic summarization must be disabled to support discontiguous networks. RIPv2 also supports CIDR supernets and VLSM because the specific subnet mask is included with the network address in every routing update. You can use the debug ip rip command to view the RIP update sending the subnet mask with the network address as part of the route entry.
The show ip protocols command will display that RIP is now sending and receiving version 2 updates and whether or not automatic summarization is in effect.
7.6.1 - Summary and Review
In this chapter, you learned to:
- Encounter and describe the limitations of RIP v1.
- Apply the basic Routing Information Protocol Version 2 (RIP v2) configuration commands and evaluate RIP v2 classless routing updates.
- Analyze router output to see RIP v2 support for VLSM and Classless Inter-Domain Routing (CIDR).
- Identify RIP v2 verification commands and common RIP v2 issues.
- Configure, verify, and troubleshoot RIP v2 in hands-on labs.
In this chapter, you learned to:
- Encounter and describe the limitations of RIP v1.
- Apply the basic Routing Information Protocol Version 2 (RIP v2) configuration commands and evaluate RIP v2 classless routing updates.
- Analyze router output to see RIP v2 support for VLSM and Classless Inter-Domain Routing (CIDR).
- Identify RIP v2 verification commands and common RIP v2 issues.
- Configure, verify, and troubleshoot RIP v2 in hands-on labs.
Page 2:
7.6.1 - Summary and Review
This is a review and is not a quiz. Questions and answers are provided.
Question 1. What is a discontiguous network and why is it not be supported by classful routing protocols like RIP v1?
Answer:
A discontiguous network occurs when a classful major network address, such as 172.30.0.0/16, is separated by one or more other major networks, like 209.165.200.228/30. Boundary routers running classful routing protocols can only propagate the summarized classful address. When multiple boundary routers are propagating the same classful network, other routers cannot determine the path to the specific subnets of this classful network. The consequence is inconsistent routing and not all packets reaching their destination.
Question 2. RouterX is running the classful routing protocol RIP v1. RouterX has VLSM subnets in its routing table that are all part of the 10.0.0.0/8 network. If RouterX is sending updates out an interface with the address 10.10.10.1/24, which subnets are sent out that interface?
Answer: RIP v1 includes any 10.0.0.0 subnets that have the /24 mask in its updates out the 10.10.10.1/24 interface. The mask is not included in the routing update.
Question 3. RouterX is running the classful routing protocol RIP v1. RouterX has VLSM subnets in its routing table, which are all part of the 10.0.0.0/8 network. If RouterX is sending updates out an interface with the address 192.168.1.1/24, which 10.0.0.0 subnets are sent out that interface?
Answer: RIP v1 sends out the summarized network address of 10.0.0.0. The mask is not included in the routing table.
Question 4. How do you disable automatic summarization on RIP v2?
Answer: With the command no auto-summary in router configuration mode.
Question 5. When do you disable automatic summarization on RIP v2?
Answer: When you have discontiguous subnets or if you want to propagate the individual subnets.
Question 6. What is the defining characteristic of a classless routing protocol?
Answer: The capability of carrying the subnet masks in the route advertisements.
Question 7. What is the default behavior of RIP v2 regarding automatic summarization.
Answer: By default, automatic summarization is enabled with RIP v2.
Question 8. Does RIP v2 include the subnet masks in its routing updates if automatic summarization is enabled?
Answer: Yes, even though the subnets are summarized by the boundary routers, the RIP v2 updates still include the subnet mask, which, in this case, would be the classful mask.
Question 9. Refer to the topology description to answer the question.
Network Topology:
Same as 7.1.1 diagram 1, except with RIP updates coming from router R1 and R3 to R2.
All routers are running RIP v2. R1 has automatic summarization disabled, but router R3 has automatic summary still enabled. Which 172.30.0.0 routes do we expect to see in the routing table for R2?
Answer: R2 Routing Table
172.30.0.0/16 is variably subnetted, 3 subnets, 2 masks
R 172.30.2.0/24 [120/1] via 209.165.200.230, 00:00:09, Serial0/0
R 172.30.0.0/16 [120/1] via 209.165.200.234, 00:00:18, Serial0/1
R 172.30.1.0/24 [120/1] via 209.165.200.230, 00:00:09, Serial0/0
Question 10. Refer to the topology description to answer the question. If R2 has a packet destined for 172.30.1.10, will the packet be consistently forwarded to the proper router R1?
Network Topology:
Same as question 9.
Answer: Yes. When R2 receives both routing updates, it includes both the summary router 172.30.0.0/16 forwarding packets to R3 and the specific subnets 172.30.1.0/24 and 172.30.2.0/24 forwarding those packets to R1. The routing table process always chooses the more specific route over the less specific summary route.
Question 11. Refer to the topology description to answer the question.
Network Topology:
Same as question 9.
Routers R1 and R2 are exchanging routing updates using RIP v2. R2 has a default static route to R3, and R3 has a default static route to R2. If router R1 has automatic summarization disabled (no auto-summary), can R2 reach the networks on both R1 and R3?
Answer: Yes. R2 has the specific routes of the 172.30.1.0/24 and 172.30.2.0/24 subnets, so it will forward those packets to R1. All other packets, such as those destined for 172.30.110.0/24, use the default route and are forwarded to R3.
R2's routing table with R1 configured with RIP v2 and no auto-summary.
172.30.0.0/24 is subnetted, 2 subnets
R 172.30.2.0 [120/1] via 209.165.200.230, 00:00:05, Serial0/0
R 172.30.1.0 [120/1] via 209.165.200.230, 00:00:05, Serial0/0
209.165.200.0/30 is subnetted, 2 subnets
C 209.165.200.232 is directly connected, Serial0/1
C 209.165.200.228 is directly connected, Serial0/0
10.0.0.0/16 is subnetted, 1 subnets
This is a review and is not a quiz. Questions and answers are provided.
Question 1. What is a discontiguous network and why is it not be supported by classful routing protocols like RIP v1?
Answer:
A discontiguous network occurs when a classful major network address, such as 172.30.0.0/16, is separated by one or more other major networks, like 209.165.200.228/30. Boundary routers running classful routing protocols can only propagate the summarized classful address. When multiple boundary routers are propagating the same classful network, other routers cannot determine the path to the specific subnets of this classful network. The consequence is inconsistent routing and not all packets reaching their destination.
Question 2. RouterX is running the classful routing protocol RIP v1. RouterX has VLSM subnets in its routing table that are all part of the 10.0.0.0/8 network. If RouterX is sending updates out an interface with the address 10.10.10.1/24, which subnets are sent out that interface?
Answer: RIP v1 includes any 10.0.0.0 subnets that have the /24 mask in its updates out the 10.10.10.1/24 interface. The mask is not included in the routing update.
Question 3. RouterX is running the classful routing protocol RIP v1. RouterX has VLSM subnets in its routing table, which are all part of the 10.0.0.0/8 network. If RouterX is sending updates out an interface with the address 192.168.1.1/24, which 10.0.0.0 subnets are sent out that interface?
Answer: RIP v1 sends out the summarized network address of 10.0.0.0. The mask is not included in the routing table.
Question 4. How do you disable automatic summarization on RIP v2?
Answer: With the command no auto-summary in router configuration mode.
Question 5. When do you disable automatic summarization on RIP v2?
Answer: When you have discontiguous subnets or if you want to propagate the individual subnets.
Question 6. What is the defining characteristic of a classless routing protocol?
Answer: The capability of carrying the subnet masks in the route advertisements.
Question 7. What is the default behavior of RIP v2 regarding automatic summarization.
Answer: By default, automatic summarization is enabled with RIP v2.
Question 8. Does RIP v2 include the subnet masks in its routing updates if automatic summarization is enabled?
Answer: Yes, even though the subnets are summarized by the boundary routers, the RIP v2 updates still include the subnet mask, which, in this case, would be the classful mask.
Question 9. Refer to the topology description to answer the question.
Network Topology:
Same as 7.1.1 diagram 1, except with RIP updates coming from router R1 and R3 to R2.
All routers are running RIP v2. R1 has automatic summarization disabled, but router R3 has automatic summary still enabled. Which 172.30.0.0 routes do we expect to see in the routing table for R2?
Answer: R2 Routing Table
172.30.0.0/16 is variably subnetted, 3 subnets, 2 masks
R 172.30.2.0/24 [120/1] via 209.165.200.230, 00:00:09, Serial0/0
R 172.30.0.0/16 [120/1] via 209.165.200.234, 00:00:18, Serial0/1
R 172.30.1.0/24 [120/1] via 209.165.200.230, 00:00:09, Serial0/0
Question 10. Refer to the topology description to answer the question. If R2 has a packet destined for 172.30.1.10, will the packet be consistently forwarded to the proper router R1?
Network Topology:
Same as question 9.
Answer: Yes. When R2 receives both routing updates, it includes both the summary router 172.30.0.0/16 forwarding packets to R3 and the specific subnets 172.30.1.0/24 and 172.30.2.0/24 forwarding those packets to R1. The routing table process always chooses the more specific route over the less specific summary route.
Question 11. Refer to the topology description to answer the question.
Network Topology:
Same as question 9.
Routers R1 and R2 are exchanging routing updates using RIP v2. R2 has a default static route to R3, and R3 has a default static route to R2. If router R1 has automatic summarization disabled (no auto-summary), can R2 reach the networks on both R1 and R3?
Answer: Yes. R2 has the specific routes of the 172.30.1.0/24 and 172.30.2.0/24 subnets, so it will forward those packets to R1. All other packets, such as those destined for 172.30.110.0/24, use the default route and are forwarded to R3.
R2's routing table with R1 configured with RIP v2 and no auto-summary.
172.30.0.0/24 is subnetted, 2 subnets
R 172.30.2.0 [120/1] via 209.165.200.230, 00:00:05, Serial0/0
R 172.30.1.0 [120/1] via 209.165.200.230, 00:00:05, Serial0/0
209.165.200.0/30 is subnetted, 2 subnets
C 209.165.200.232 is directly connected, Serial0/1
C 209.165.200.228 is directly connected, Serial0/0
10.0.0.0/16 is subnetted, 1 subnets
Page 3:
The Packet Tracer Skills Integration Challenge Activity integrates all the knowledge and skills you acquired in previous chapters of this course and prior courses. Skills related to the discussion of RIPv2 are also included. In this activity, you build a network from the ground up.
Starting with an addressing space and network requirements, you must implement a network design that satisfies the specifications, then implement an effective RIPv2 routing configuration with integrated default routing. Detailed instructions are provided within the activity.
Packet Tracer Skills Integration Instructions (PDF)
Click the Packet Tracer icon for more details.
7.6.1 - Summary and Review
Link to Packet Tracer Exploration: Packet Tracer Skills Integration Challenge Activity
The Packet Tracer Skills Integration Challenge Activity integrates all the knowledge and skills you acquired in previous chapters of this course and prior courses. Skills related to the discussion of RIP v2 are also included. In this activity, you build a network from the ground up.
Starting with an addressing space and network requirements, implement a network design that satisfies the specifications, and then implement an effective RIP v2 routing configuration with integrated default routing. Detailed instructions are provided within the activity.
Link to Packet Tracer Exploration: Packet Tracer Skills Integration Challenge Activity
The Packet Tracer Skills Integration Challenge Activity integrates all the knowledge and skills you acquired in previous chapters of this course and prior courses. Skills related to the discussion of RIP v2 are also included. In this activity, you build a network from the ground up.
Starting with an addressing space and network requirements, implement a network design that satisfies the specifications, and then implement an effective RIP v2 routing configuration with integrated default routing. Detailed instructions are provided within the activity.
Page 4:
To Learn More
RFC 1723 RIP version 2
RFCs (Request for Comments) are a series of documents submitted to the IETF (Internet Engineering Task Force) to propose an Internet standard or convey new concepts, information or even occasionally even humor. RFC 1723 is the RFC for RIP version 2.
RFCs can be accessed from several web sites including www.ietf.org. Read all or parts of RFC 1723 to learn more about this classless routing protocol.
Packet Tracer
Use Packet Tracer to create two discontiguous classful networks. Each discontiguous network should have several routers and subnets, one using VLSM. Between the two groups of discontiguous networks, add another router linking the two discontiguous networks. Be sure to use a different major network between this router and each of the two discontiguous networks.
Use this scenario to examine the issues with RIPv1 and how RIPv2 can be used to solve these routing issues.
7.6.1 - Summary and Review
The diagram depicts a collage of people using computers and networks.
The diagram depicts a collage of people using computers and networks.
7.7 Chapter Quiz
7.7.1 Chapter QuizPage 1:
7.7.1 - Chapter Quiz
1. What two commands determine whether auto-summarization is in effect for RIP? (Choose two.)
A. show running-config
B. show i p route
C. show i p interface
D. show interface
E. show i p protocols
2. Which statement regarding RIP v2 is correct?
A. RIP version 2 auto-summarizes with the most efficient mask.
B. RIP version 2 auto-summarizes at the major network boundary.
C. RIP version 2 requires manual configuration for summarizing routes.
D. By default, RIP version 2 and RIP version 1 do not handle route summarization the same way.
3. What is the default behavior of the RIP routing protocol if no version type is specified?
A. send and receive version 1 updates only
B. send version 1 updates only, receive version 1 and 2 updates
C. receive version 1 updates only, send version 1 and 2 updates
D. send and receive both version 1 and 2 updates
4. What condition would RIP v2 allow that RIP v1 would not allow?
A. 16 hops from one end of the network to the other
B. redistribution of EIGRP
C. 192.168.0.0/16 network
D. router with more than three interfaces
5. How do RIP v1 and RIP v2 differ?
A. Only RIP v1 provides authentication in its updates.
B. Only RIP v1 uses split horizon to prevent routing loops.
C. Only RIP v2 uses 16 hops as the metric value for infinite distance.
D. Only RIP v2 sends subnet mask information with its routing updates.
6. Refer to the following topology description and partial results from the debug i p rip events command on router B to answer the question.
Topology Description:
There are three routers, A, B, and E.
Router B is connected to Router A and Router E via WAN links.
Router A interface FA0/0 IP address is 10.16.1.1/27.
Router A interface S0/0 IP address is 192.168.1.1/30.
Router B interface S0/0 IP address is 192.168.1.2/30.
Router B interface S0/1 IP address is 192.168.1.5/30.
Router E interface S0/0 IP address is 192.168.1.6/30.
Router E interface FA0/0 IP address is 10.16.1.65/27.
B# debug i p rip events
Output omitted
RIP: ignored v2 packet from 192.168.1.1 (illegal version)
RIP: ignored v2 packet from 192.168.1.6 (illegal version)
Question: What is the likely cause of the debug messages?
A. Routers A and E are sending malformed updates.
B. RIP configuration on router B does not include networks connected to the serial interfaces.
C. Router B serial interfaces are not configured correctly.
D. Router B is running a different version of RIP than A and E.
7. Refer to the following topology description and the output of the show i p route command to answer the question. If all routers are running RIP version 2, why is there no route for the 192.168.1.32/27 network?
Topology Description:
There are three routers, A, B, and C.
Router A S0/0/0 is connected to Router B S0/0/0 via network 192.168.1.64/30.
Router B S0/0/1 is connected to Router C S0/0/0 via network 192.168.2.0/30.
Router A LAN address is 192.168.1.32/27
Router C LAN address is 192.168.3.0/24
Router C# show i p route
output omitted
Gateway of last resort is not set
R 192.168.1.0/24 [120/1] via 192.168.2.1, 00:00:27, Serial0/0/0
C 192.168.2.0/24 is directly connected, Serial0/0/0
C 192.168.3.0/24 is directly connected, FastEthernet0/0
Question: If all routers are running RIP version 2, why is there no route for the 192.168.1.32/27 network?
A. Rip version 2 does not send subnet masks in its updates.
B. Router A is not set up with RIP as a routing protocol.
C. Rip version 2 auto summarizes routes by default.
D. Router B is not set up to advertise the 192.168.1.64/30 network.
8. Refer to the partial results from the debug i p rip events command to answer the question.
Router# debug i p rip events
RIP event debugging is on
Router#RIP: sending v2 update to 244.0.0.9 via FastEthernet0/0 (192.168.1.33)
RIP: build update entries
192.168.1.64/30 via 0.0.0.0, metric 1, tag 0
192.168.2.0/24 via 0.0.0.0, metric 2, tag 0
192.168.3.0/24 via 0.0.0.0, metric 3, tag 0
RIP: sending v2 update to 244.0.0.9 via Serial0/0/0 (192.168.1.65)
RIP: build update entries
192.168.1.32/27 via 0.0.0.0, metric 1, tag 0
Question: What can be determined from this output?
A. A show i p route on a router two hops away will see the 192.168.1.32/27 network in its routing table.
B. The Serial0/0/0 interface is configured with the passive interface command.
C. The router is passing the subnet mask along with the network in its updates.
D. All the routers must be Cisco routers because the network is using RIP version 2.
0 comments:
Post a Comment