A problem with an Exercise of CCIE Routing TCP/IP Volume 1.

Unanswered Question
Oct 30th, 2009

I wonder if in Configuration Exercise 5 of Chapter 5 (RIP) RTB can route packets correctly.

For example, a packet with IP destination address 192.168.20.152, the last byte is 10011000,

has the first 5 bits of the last byte 10011. In RTB's route table we have:

c 192.168.20.32 (last byte 00100000)

c 192.168.20.48 (last byte 00110000)

c 192.168.20.40 (last byte 00101000)

r 192.168.20.128 (last byte 10000000)

r 192.168.20.64 (last byte 01000000)

and, after matching the major class, we have not the match with the subnet (/29 in RTB).

The author wrote that in this case the packet is discarded but in the solution it seems ok.

Thanks for an answer.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
slmansfield Fri, 10/30/2009 - 13:44

The reason I asked is that I set this up between two 1841 routers. What I saw in the routing table of Router A was two host routes (/32 masks) to the non-connected subnets of Router B.

Did you see the same thing?

speculor_cisco Fri, 10/30/2009 - 14:55

I can not do practice but I want understand if the solution is corrected if the logic behind the exercise is the RIP logic. Router A should see those subnets as 192.166.20.32, the same between the two routers and like the solution tells. I do not agree about the good routing done by router B, while the solution tells that router B has not problems. Did you see the text, the figure and the solution I attached before?

justinmitchell Sat, 10/31/2009 - 05:57

The author is correct, due to the differing subnet masks router RTA does not have a proper view of the network.

RTA#sh int | i net

FastEthernet0/0 is up, line protocol is up

Internet address is 192.168.20.33/27

Internet address is 192.168.20.129/27

Internet address is 192.168.20.65/27

RTA#sh run | s rip

router rip

network 192.168.20.0

RTA#sh ip rip data

192.168.20.0/24 auto-summary

192.168.20.32/27 directly connected, FastEthernet0/0

192.168.20.40/32

[1] via 192.168.20.34, 00:00:11, FastEthernet0/0

192.168.20.48/32

[1] via 192.168.20.34, 00:00:11, FastEthernet0/0

192.168.20.64/27 directly connected, Loopback2

192.168.20.128/27 directly connected, Loopback1

RTB#sh int | i net

FastEthernet0/0 is up, line protocol is up

Internet address is 192.168.20.34/29

Internet address is 192.168.20.49/29

Internet address is 192.168.20.41/29

RTB#sh run | s rip

router rip

network 192.168.20.0

RTB#sh ip rip data

192.168.20.0/24 auto-summary

192.168.20.32/29 directly connected, FastEthernet0/0

192.168.20.40/29 directly connected, Loopback2

192.168.20.48/29 directly connected, Loopback1

192.168.20.64/29

[1] via 192.168.20.33, 00:00:08, FastEthernet0/0

192.168.20.128/29

[1] via 192.168.20.33, 00:00:08, FastEthernet0/0

However, this behavior is corrected if you use RIP version 2.

RTA#sh int | i net

FastEthernet0/0 is up, line protocol is up

Internet address is 192.168.20.33/27

Internet address is 192.168.20.129/27

Internet address is 192.168.20.65/27

RTA#sh run | s rip

router rip

version 2

network 192.168.20.0

RTA#sh ip rip data

192.168.20.0/24 auto-summary

192.168.20.32/27 directly connected, FastEthernet0/0

192.168.20.40/29

[1] via 192.168.20.34, 00:00:12, FastEthernet0/0

192.168.20.40/32

[1] via 192.168.20.34, 00:02:22, FastEthernet0/0

192.168.20.48/29

[1] via 192.168.20.34, 00:00:12, FastEthernet0/0

192.168.20.48/32

[1] via 192.168.20.34, 00:02:22, FastEthernet0/0

192.168.20.64/27 directly connected, Loopback2

192.168.20.128/27 directly connected, Loopback1

RTB#sh int | i net

FastEthernet0/0 is up, line protocol is up

Internet address is 192.168.20.34/29

Internet address is 192.168.20.49/29

Internet address is 192.168.20.41/29

RTB#sh run | s rip

router rip

version 2

network 192.168.20.0

RTB#sh ip rip data

192.168.20.0/24 auto-summary

192.168.20.32/29 directly connected, FastEthernet0/0

192.168.20.40/29 directly connected, Loopback2

192.168.20.48/29 directly connected, Loopback1

192.168.20.64/27

[1] via 192.168.20.33, 00:00:19, FastEthernet0/0

192.168.20.128/27

[1] via 192.168.20.33, 00:00:19, FastEthernet0/0

Hope that helps!

speculor_cisco Sat, 10/31/2009 - 07:55

Ok, with RIPv1 the route tables should be as yours first two. But if I ping from network 192.168.20.48 connected to RTB, for example host 192.168.20.152 in the network 192.168.20.128 connected to RTA, the routing algorithm RIPv1 should have some problems and discard the packet, while the author did not say nothing about this problem.

slmansfield Sat, 10/31/2009 - 08:38

RouterB's routing table shows its skewed view of the network with all advertised subnets showing up as /29's instead of /27's.

192.168.20.0/29 is subnetted, 5 subnets

R 192.168.20.64 [120/1] via 192.168.20.33, 00:00:02, FastEthernet0/1

C 192.168.20.48 is directly connected, Loopback1

C 192.168.20.40 is directly connected, Loopback0

C 192.168.20.32 is directly connected, FastEthernet0/1

R 192.168.20.128 [120/1] via 192.168.20.33, 00:00:02, FastEthernet0/1

RouterA's skewed view of the network recognizes its attached networks as /27s. The longer masks of RouterB are interpretted as /32s because RouterA cannot correctly interpret a longer-than-27-bit mask as a /29.

192.168.20.0/24 is variably subnetted, 5 subnets, 2 masks

C 192.168.20.64/27 is directly connected, Loopback1

R 192.168.20.48/32 [120/1] via 192.168.20.34, 00:00:06, FastEthernet0/1

R 192.168.20.40/32 [120/1] via 192.168.20.34, 00:00:06, FastEthernet0/1

C 192.168.20.32/27 is directly connected, FastEthernet0/1

C 192.168.20.128/27 is directly connected, Loopback0

speculor_cisco Sat, 10/31/2009 - 09:22

When an host in the network 192.168.20.48 of RTB sends a packet to host 192.168.20.152 in the network 192.168.20.128 of RTA, RIPv1 algorithm in RTB first match the full class C network and it is ok, then it tries to match the subnets with mask /29 and here is the problem: the last octet of the routes are

10000-000 for 192.168.20.128 from RTA

01000-000 for 192.168.20.64 from RTA

but the last octet of the packet is

1001-100 and there is not match. All say that in this case the packet is discarded, I am talking about pure RIPv1 as RFC says. Only some host in that network are reachable, those with 00 in the forth and fifth bits. I am looking for a simulator pure RIPv1 in order to try...anyway if the algorithm is like I have read in many books that scenario does not work and if the simulator instead works may be the implementator does not use pure RIPv1. But what is exactly pure RIPv1? I am quite sure about it. It seems a problem chicken and egg!

Actions

This Discussion