Project Meeting

Had a project meeting to discuss the debug outcomes which seemed to be conflicting., but there's need to investigate why the outputs have come out that way. When an interface is shut from the analysis it was noticed that the furthest router was taking less time than its predecessor. From the discussion it maybe due to  the number of networks connected to it. The directions were changed and R2 also was slower in converging. as was R4. Further investigations are to be carried out. NTP is the other suspect, we investigated its operation in terms of monitoring the instances and we could see the diversion. If that is the case why is it only affecting when a network is disabled and not when it's enabled. Investigations need to be done ie tracing signals in and out of routers the time delays on device interfaces etc, ascertain whether that is a factor.  Further analysis of the debug output is needed.

Conflicting updating times for Debug outputs EIGRP IPv6

I am discovering some inconsistencies in  the duration which the update is being propagated thru the network. I was expecting that the times will flow smoothly from R1 --> R2-->R3-->R4 to R5, the times should increase as it move to R5. What I am noticing is in some instances the time I am getting on R5 is smaller than the router before it (R4). How can this be possible when R4 is the one which is updating R5???.
I particularly getting this for EIGRP IPv6 debug outputs. Most of the outputs have the flow right except of a couple of outputs, What could be the reasons if any? Check your e-mails for the debug outputs and  the network topology .

IPv6 EIGRP debug output

I have been analyzing the debug output of EIGRP  IPv6 and  am not sure  which times to take. The time when the DLS1 interface was shut or enabled in written  before the debug output. The first output was somehow simple because I have taken the time when the route has been added to the Routing Information base. On the 2nd output was the tricky one , what I have considered is when FEC0::6:0/112 has been deleted. The logic being that , this when this route is being removed from the table because it can not be accessed due to a shut down interface. I stand to be corrected. The duration taken for each route to be removed or added is just below each  output.





Interface fa0/1 was enabled on DLS1 @ 11:59:55.422


Sep 19 11:59:57.738: IPv6-EIGRP(0:20): Processing incoming UPDATE packet
Sep 19 11:59:57.738: IPv6-EIGRP(0:20): Int FEC0::6:0/112 M 41666560 - 40000000 1666560 SM 41154560 - 40000000 1154560
Sep 19 11:59:57.738: IPv6-EIGRP(0:20): FEC0::6:0/112 (90/41666560) added to RIB
Sep 19 11:59:57.754: IPv6-EIGRP(0:20): FEC0::6:0/112 - do advertise out FastEthernet0/0
Sep 19 11:59:57.754: IPv6-EIGRP(0:20): Int FEC0::6:0/112 metric 41666560 - 40000000 1666560
Sep 19 11:59:57.758: IPv6-EIGRP(0:20): Int FEC0::6:0/112 metric 41666560 - 40000000 1666560
R5#
R5#
R5#
R5#11:59:57.738
R5#11:59:55.422
R5#           2.316 secs
R5#

Interface fa0/1 was shut down on DLS1 @ 12:00:38.304


Sep 19 12:00:39.422: IPv6-EIGRP(0:20): Processing incoming QUERY packet
Sep 19 12:00:39.422: IPv6-EIGRP(0:20): Int FEC0::6:0/112 M 4294967295 - 25600 4294967295 SM 4294967295 - 25600 4294967295
Sep 19 12:00:39.438: IPv6-EIGRP(0:20): FEC0::6:0/112 - do advertise out FastEthernet0/0
Sep 19 12:00:39.438: IPv6-EIGRP(0:20): Int FEC0::6:0/112 metric 4294967295 - 25600 4294967295
Sep 19 12:00:39.470: IPv6-EIGRP(0:20): Processing incoming REPLY packet
Sep 19 12:00:39.470: IPv6-EIGRP(0:20): Int FEC0::6:0/112 M 4294967295 - 25600 4294967295 SM 4294967295 - 25600 4294967295
Sep 19 12:00:39.470: IPv6-EIGRP(0:20): FEC0::6:0/112 deleted FE80::C0A8:1401(FE80::C0A8:1401)/Serial0/0/1
Sep 19 12:00:39.470: IPv6-EIGRP(0:20): FEC0::6:0/112 (90/-1) added to RIB
Sep 19 12:00:39.478: IPv6-EIGRP(0:20): Processing incoming UPDATE packet
Sep 19 12:00:39.478: IPv6-EIGRP(0:20): Int FEC0::6:0/112 M 4294967295 - 25600 4294967295 SM 4294967295 - 25600 4294967295
Sep 19 12:00:39.486: IPv6-EIGRP(0:20): FEC0::6:0/112 - do advertise out FastEthernet0/0
Sep 19 12:00:39.486: IPv6-EIGRP(0:20): Int FEC0::6:0/112 metric 4294967295 - 25600 4294967295
Sep 19 12:00:39.490: IPv6-EIGRP(0:20): FEC0::6:0/112 - do advertise out Serial0/0/1
Sep 19 12:00:39.490: IPv6-EIGRP(0:20): Int FEC0::6:0/112 metric 4294967295 - 25600 4294967295
Sep 19 12:00:39.518: IPv6-EIGRP(0:20): FEC0::6:0/112 deleted FE80::C0A8:1401(FE80::C0A8:1401)/Serial0/0/1
Sep 19 12:00:39.522: IPv6-EIGRP(0:20): FEC0::6:0/112 - not in IPv6 routing table
Sep 19 12:00:39.522: IPv6-EIGRP(0:20): Int FEC0::6:0/112 metric 4294967295 - 25600 4294967295
R5#
R5#
R5#12:00:39.470
R5#12:00:38.304
R5#           1.166 secs
R5#

Ipv6 Test with RIP

Have been working with the group yesterday, doing some test using Rip on IPV6.. We found some interesting result from the test that we have, we used couple of different debug command to capture the results, like debug ipv6 icmp, debug ipv6 rip etc.. We have collect all the output through txt file and now we try to analyze the output from all the test that we have done to get the average convergence time as our best result, we also play around with the bandwidth but it was no effect on rip.
TEVITA