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

Test on MD5

The last two days I have been conducting tests on topology 1  on all three routing protocols (RIPv2, EIGRP and OSPF) Tests have been carried out on protocols without authentication and with authentication MD5. I am trying to to build up my test results which I have lost. . I have been running debug commands  to see what  the protocols would be doing during the recalculation of an alternate route.

I will also use GNS3  to try and compare the outputs and another issue is the ability to use wireshark on the serial interfaces which can help understand the debug outputs.
 Currently I am doing the analysis on the debug outputs -its time consuming .

Analysis of RIPv2 outputs Authentication vs Non-Authentication

 Last Wednesday I carried out tests on Topology 1 to compare the convergence speed difference if any between a network with authentication and that without. I am doing an analysis of the results., my opinion before the test was that convergence speed for network with authentication would have slower  convergence. But results should reveal  the correct opinion.

Bug

Disaster, 50% of my flash drive has been wiped of several folders in the lab, on computer on position 8. including my project folder. All my configurations and outputs I had from February 2012. I am now looking into my backup which may not be up to date but may give me some where to start from. What a dull day for me,....

That's a bad news, and good to know so that we don't have to use that PC and backup our data all the times.. We have to all bring up the files that we have to see which one that we don't have so we can work on it again and to catch up with the rest of the project too..
Tevita