Models 4 NTP Misc Tools

tag(s)
timestamps, accounting, ntp, stratum, time server, master, client, authentication, clock, logging, buffer, config replace rollback, eem, event manager, sdm, 

Models 3 Models

 As we know we have to be careful with debugs, especially the IP PACKET debug!

very koool! have to try this out

remember can also also use the keyword sorted to sort the most processor intense applications at that time (top to bottom)

reminds us of the old command show controller, which would identify which end of the V.35 cable you had or if it was disconnected!

Show Interface

We typically only look at the top part, but we need to note the queue's and if any errors/drops etc - again this is where the baseline comes in (sure over time we will have some drops here and there)

tag(s)
fcaps, ppddioo, piping, cpu processes, interface, controllers, begin, traceroute, debug ip packet,

Models 2A Unusual Ping Results

Lets test connectivity to them loopbacks:

As we are guessing right now.... there is no routing protocol advertising these networks (DONT ASSUME ONE) so no match in the routing table...

lets enable debug ip packet which shows the issue (obviously in a production network, this is a no no, you would have to be more specific with the debug)

no match shown above in the routing table (and no default route neither)

lets add that static route route in then try pinging again....

MMmmm unreachable, yup you guessed it, R1 does not know how to reach the 2.2.2.2 network, lets run debug ip packet to show:

Here you can see R1 is replying back unreachable (where as before we didnt see anything from R1, we just unroutable from the local router - R3)

Those U's are  a downstream router saying "i dont know how to get to this network"

Lets add the route into R1s routing table:

lets try the ping again from R1 and R3

Notice you can now see the Source address of 2.2.2.2 in the debug

tag(s)
ping, traceroute, show controllers, debug ip packet, recommended nist time server

Models 2 Extended Ping Lab

Lets test out extended ping, the below lab is a simple RIP network;

SO we can see in the above debug on R1 that it recieves an echo reply back from R3, notice the source and destination addresses ....

So this makes sense .... as the ping is going out the same way packets would normally go out (as in the routing table) it goes out the exit interface "serial0"

AND as you have already assumed, this is NOT testing connectivity from the new network segment 10.1.1.0/24

As we can see, now the ping shows no reply (personally i prefer using ping xxxx source command ....)

so if we retest now ...

its all good :0)

In the next lab we will look at getting multiple letters back in our extended pings ...

tags:

extended ping, debug icmp, echo reply, df, fragment