10-30-2009 10:09 AM - edited 03-04-2019 06:33 AM
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.
10-30-2009 12:04 PM
How do router B's routes look from the routing table of router A?
10-30-2009 12:35 PM
10-30-2009 01:44 PM
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?
10-30-2009 02:55 PM
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?
10-31-2009 05:57 AM
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!
10-31-2009 07:55 AM
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.
10-31-2009 08:02 AM
How are you performing your ping to verify?
10-31-2009 08:38 AM
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
10-31-2009 09:22 AM
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!
10-31-2009 09:31 AM
I forgot a bit in the last octet of the packet: 10011-000. Thanks.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide