1

Subnet: 10.14.64.0

Host Addresses: 10.14.64.1–10.14.95.254

Broadcast: 10.14.95.255

Subnet: 172.25.0.224

Host Addresses: 172.25.0.225–175.25.0.254

Broadcast: 172.25.0.255

Subnet: 172.25.16.0

Host Addresses: 172.25.16.1–172.25.16.126

Broadcast: 172.25.16.127

2

192.168.13.175/28 is the broadcast address of subnet 192.168.13.160/28.

1

Subnet 192.168.1.64/27 will no longer be reachable from Piglet. Subnets 10.4.6.0/24 and 10.4.7.0/24 are also no longer reachable from Piglet.

2

Mistakes occur in the following:

3

The mistakes are as follows:

1

The new access list causes two hops to be added to every route except 10.33.32.0.

2

RTB interprets all subnets of 172.16.0.0 according to its misconfigured masks. The consequences, as exhibited in each of the four entries in its route table, are

Entry 1: This entry is correct because 172.16.24.0 can be masked with either 22 bits or 23 bits.

Entry 2: Subnet 172.16.26.0 is advertised by RTC. Because the 23rd bit of this address is one and RTB is using a 22-bit mask, from RTB’s perspective this one appears in the host address space. Therefore, RTB interprets the advertisement of 172.16.26.0 as a host route and marks it with a 32-bit mask in the route table.

Entry 3: RTB interprets its interface address 172.16.22.5 as being a member of subnet 172.16.20.0/22, instead of 172.16.22.0/23. When RTB receives RTA’s advertisement of subnet 172.16.20.0/23, RTB, thinking it has a directly connected link to that subnet, ignores the advertisement. Notice that subnet 172.16.22.0 is not in the route tables of RTA and RTC for the same reason: RTB is advertising it as 172.16.20.0.

Entry 4: RTB interprets its interface address 172.16.18.4 as being a member of subnet 172.16.16.0/22 instead of 172.16.18.0/23.

3

The answer is in RTC’s route table in Example 5-30. Notice that the route to 172.16.26.0/23 has not been updated in 2 minutes, 42 seconds. RTC’s invalid timer is expiring before it hears a new update from RTD, and it is declaring the route to 172.16.26.0/23 invalid. Because no routes from RTA or RTB are being invalidated, the problem is with RTD’s update timer—the update period is too long. When RTD finally sends an update, it is re-entered in RTC’s route table and remains until RTC’s invalid timer again expires.

1

RTA and RTB send and receive only RIPv2 messages. RTC receives both RIPv1 and RIPv2 but sends only RIPv1. Consequently, RTA and RTB do not have subnet 192.168.13.75/27 in their route tables. Although it receives the updates from RTA and RTB, RTC does not have subnets 192.168.13.90/28 and 192.168.13.86/29 in its route table because it interprets both of them as 192.168.13.64/27, which is directly connected to RTC’s E0 interface.

2

Yes. Subnet 192.168.13.64/27 will be added to the route tables of RTA and RTB because they can now receive RIPv1 updates from RTC.

1

RTG is RTF’s successor to subnet A.

2

RTC’s feasible distance to subnet A is 309760.

3

RTG’s feasible distance to subnet A is 2214319.

4

RTG’s topology table shows RTD and RTE as feasible successors to subnet A.

5

RTA’s feasible distance to subnet B is 2198016.

1

Either the IP address or the mask is misconfigured on one of the neighboring interfaces.

2

One router is configured as a stub area router, and the other is not.

3

The receiving router is configured for MD5 (type 2) authentication, and the neighbor has no authentication configured (type 0).

4

The passwords configured on the two routers do not match.

5

The neighboring interfaces are not configured with the same area ID.

6

RTA’s network statements are in the wrong order. The first statement matches IP address 192.168.50.242 and puts it in area 192.168.50.0.

7

Link ID 10.8.5.1 is the most likely suspect because its sequence number is substantially higher than the sequence numbers of the other links.

1

Although IS-IS has formed an adjacency, its type is IS rather then L1, L2, or L1L2, indicating there is a problem. The IP addresses are not on the same subnet.

2

The router sends only L1 Hellos, indicating that it is an L1 router. It receives only L2 Hellos from 0000.3090.c7df, indicating that it is an L2 router.

1

Split horizon will prevent 192.168.10.0/24 from being advertised into the RIP domain from the IGRP domain.

2

No, because not all subnets of 10.0.0.0 are directly connected to Mantle on the RIP side.

3

The network statement under Robinson’s EIGRP 1 configuration matches interface 192.168.3.32, even though no EIGRP Hellos are being forwarded out that interface. Therefore, the subnet is advertised as internal within the EIGRP 1 domain.

4

EIGRP automatically entered this summary route because subnets of 192.168.3.0 are being redistributed into EIGRP from OSPF.

5

A level-1 router in area 1 will not know of the summary route. RIP is being redistributed into level-2 (this is the default distribution level). The summary-prefix command is summarizing routes that are getting advertised into level-1.

1

The inverse mask of the first line of the access list is wrong. With this mask, all routes are matched. The line should be access-list 1 deny 0.0.0.0 0.0.0.0.

2

All routes not matched by the access lists are given a distance of 255 (unreachable). If a preferred route fails, Grimwig will not use an alternative path.

3

OSPF calculates its routes from the information learned from LSAs. The route filter has no effect on LSAs, and so the filter affects only the router on which it is configured.

4

The two route filters refer to the wrong interfaces. distribute-list 1 should refer to E1, and distribute-list 2 should refer to E0.

1

Both errors are errors of sequence. First, the telnet keyword in access list 101 is associated with the destination port; the correct association is with the source port. Second, the route map statements are in the wrong order. Telnet packets from 192.168.10.5 match the first statement and are forwarded to 192.168.16.254.