Use the saved RIP packets from Router3 and PC3 to describe the count-to-infinity problem in the above exercise. Include relevant fields from the saved RIP packets to illustrate your description.
What will be an ideal response?
The count-to-infinity problem arises when:
1. PC3 sends a RIP message with infinity metric to network 10.0.1.0
2. Router 3 gets the message and immediately updates its routing table with this value.
3. Router 2 has not received the message from PC1 yet, and sends its routing table to Router 2. There
the metric for network 10.0.1.0 is 2.
4. Router 3 gets the message from Router 2. Since this value is lower than the one it has, it sets its
metric for network 10.0.1.0 to 3.
5. Router 2 gets the first message from PC1 and sets its metric to infinity.
6. After 30 seconds Router 3 sends a message where the metric of the network 10.0.1.0 is 3
7. Router 2 gets this message and sets its routing table with a metric of 4.
8. The process goes on until the metric is higher than the path through Router 1, and then the routing
tables converge.
If Router 2 and Router 3 receive the update to infinity metric from PC 1 before sending messages
between them the count-to-infinity problem will not occur. Because, both will update their routing table
with this value simultaneously. Then the lowest metric to reach subnet 10.0.1.0 will be in Router 1, and it
will be sent to the others routers in the next update.
```
Router3#debug ip rip
RIP protocol debugging is on
Router3#
5d19h: RIP: received v2 update from 10.0.4.4 on Ethernet1
5d19h: 10.0.2.0/24 -> 0.0.0.0 in 1 hops
5d19h: RIP: sending v2 update to 224.0.0.9 via Ethernet0 (10.0.3.3)
5d19h: 10.0.4.0/24 -> 0.0.0.0, metric 1, tag 0
5d19h: RIP: sending v2 update to 224.0.0.9 via Ethernet1 (10.0.4.3)
5d19h: 10.0.3.0/24 -> 0.0.0.0, metric 1, tag 0
5d19h: 10.0.1.0/24 -> 0.0.0.0, metric 2, tag 0
5d19h: RIP: received v2 update from 10.0.3.2 on Ethernet0
5d19h: 10.0.2.0/24 -> 0.0.0.0 in 1 hops
5d19h: RIP: received v2 update from 10.0.3.10 on Ethernet0
5d19h: 10.0.1.0/24 -> 0.0.0.0 in 16 hops (inaccessible)
5d19h: RIP: received v2 update from 10.0.3.10 on Ethernet0
5d19h: 10.0.1.0/24 -> 0.0.0.0 in 16 hops (inaccessible)
5d19h: RIP: received v2 update from 10.0.4.4 on Ethernet1
5d19h: 10.0.2.0/24 -> 0.0.0.0 in 1 hops
5d19h: RIP: sending v2 update to 224.0.0.9 via Ethernet0 (10.0.3.3)
5d19h: 10.0.1.0/24 -> 0.0.0.0, metric 16, tag 0
5d19h: 10.0.4.0/24 -> 0.0.0.0, metric 1, tag 0
5d19h: RIP: sending v2 update to 224.0.0.9 via Ethernet1 (10.0.4.3)
5d19h: 10.0.3.0/24 -> 0.0.0.0, metric 1, tag 0
5d19h: 10.0.1.0/24 -> 0.0.0.0, metric 16, tag 0
5d19h: RIP: received v2 update from 10.0.3.2 on Ethernet0
5d19h: 10.0.2.0/24 -> 0.0.0.0 in 1 hops
5d19h: 10.0.1.0/24 -> 0.0.0.0 in 12 hops
5d19h: RIP: received v2 update from 10.0.4.4 on Ethernet1
5d19h: 10.0.2.0/24 -> 0.0.0.0 in 1 hops
5d19h: 10.0.1.0/24 -> 0.0.0.0 in 3 hops
5d19h: RIP: sending v2 update to 224.0.0.9 via Ethernet0 (10.0.3.3)
5d19h: 10.0.1.0/24 -> 0.0.0.0, metric 4, tag 0
5d19h: 10.0.4.0/24 -> 0.0.0.0, metric 1, tag 0
5d19h: RIP: sending v2 update to 224.0.0.9 via Ethernet1 (10.0.4.3)
5d19h: 10.0.3.0/24 -> 0.0.0.0, metric 1, tag 0
5d19h: RIP: received v2 update from 10.0.3.2 on Ethernet0
5d19h: 10.0.2.0/24 -> 0.0.0.0 in 1 hops
5d19h: RIP: received v2 update from 10.0.4.4 on Ethernet1
5d19h: 10.0.2.0/24 -> 0.0.0.0 in 1 hops
5d19h: 10.0.1.0/24 -> 0.0.0.0 in 6 hops
5d19h: RIP: sending v2 update to 224.0.0.9 via Ethernet0 (10.0.3.3)
5d19h: 10.0.1.0/24 -> 0.0.0.0, metric 7, tag 0
5d19h: 10.0.4.0/24 -> 0.0.0.0, metric 1, tag 0
5d19h: RIP: sending v2 update to 224.0.0.9 via Ethernet1 (10.0.4.3)
5d19h: 10.0.3.0/24 -> 0.0.0.0, metric 1, tag 0
5d19h: RIP: received v2 update from 10.0.3.2 on Ethernet0
5d19h: 10.0.2.0/24 -> 0.0.0.0 in 1 hops
5d19h: RIP: received v2 update from 10.0.4.4 on Ethernet1
5d19h: 10.0.2.0/24 -> 0.0.0.0 in 1 hops
5d19h: 10.0.1.0/24 -> 0.0.0.0 in 9 hops
5d19h: RIP: sending v2 update to 224.0.0.9 via Ethernet0 (10.0.3.3)
5d19h: 10.0.1.0/24 -> 0.0.0.0, metric 10, tag 0
5d19h: 10.0.4.0/24 -> 0.0.0.0, metric 1, tag 0
5d19h: RIP: sending v2 update to 224.0.0.9 via Ethernet1 (10.0.4.3)
5d19h: 10.0.3.0/24 -> 0.0.0.0, metric 1, tag 0
5d19h: RIP: received v2 update from 10.0.3.2 on Ethernet0
5d19h: 10.0.2.0/24 -> 0.0.0.0 in 1 hops
5d19h: RIP: received v2 update from 10.0.4.4 on Ethernet1
5d19h: 10.0.2.0/24 -> 0.0.0.0 in 1 hops
5d19h: 10.0.1.0/24 -> 0.0.0.0 in 12 hops
5d19h: RIP: sending v2 update to 224.0.0.9 via Ethernet0 (10.0.3.3)
5d19h: 10.0.1.0/24 -> 0.0.0.0, metric 13, tag 0
5d19h: 10.0.4.0/24 -> 0.0.0.0, metric 1, tag 0
5d19h: RIP: sending v2 update to 224.0.0.9 via Ethernet1 (10.0.4.3)
5d19h: 10.0.3.0/24 -> 0.0.0.0, metric 1, tag 0
5d19h: RIP: received v2 update from 10.0.3.2 on Ethernet0
5d19h: 10.0.2.0/24 -> 0.0.0.0 in 1 hops
5d19h: RIP: received v2 update from 10.0.4.4 on Ethernet1
5d19h: 10.0.2.0/24 -> 0.0.0.0 in 1 hops
5d19h: 10.0.1.0/24 -> 0.0.0.0 in 12 hops
5d19h: RIP: sending v2 update to 224.0.0.9 via Ethernet0 (10.0.3.3)
5d19h: 10.0.1.0/24 -> 0.0.0.0, metric 13, tag 0
5d19h: 10.0.4.0/24 -> 0.0.0.0, metric 1, tag 0
5d19h: RIP: sending v2 update to 224.0.0.9 via Ethernet1 (10.0.4.3)
5d19h: 10.0.3.0/24 -> 0.0.0.0, metric 1, tag 0
5d19h: RIP: received v2 update from 10.0.3.2 on Ethernet0
5d19h: 10.0.2.0/24 -> 0.0.0.0 in 1 hops
5d19h: 10.0.1.0/24 -> 0.0.0.0 in 12 hops
# no debug ip rip RIP protocol debugging is off Router3#
```
You might also like to view...
In addition to running on different operating systems. Ruby also supports execution within various virtual machine environments, including ____.
A. JRuby B. IronRuby C. Both of the above D. Neither of the above
A key component of a DBMS is the ____________________ , the part of the program that actually stores and retrieves data.
Fill in the blank(s) with the appropriate word(s).