up and down

[Stevep]

I'm good to go up to the last sentence before Cisco's SDM on page 223. "the likely culprit is the result of a bad cable..." The interface was up but the protocol is down was the result of show ip interface. In accordance with your explanation on the bottom of page 218, "The first parameter refers to the Physical Layer, and it's up when it receives carrier detect." Down on the second parameter is the Data Link Layer and clocking or frame problem. So how does a bad cable work into this solution? I'm asking for clarification not justification for the book text.

Also, on page 222 the example in the middle of the page sitting FIGURE 4.5 (page 210) states "you will not see this in a production network." Ok, but I missed the reason why not.

And just to give input, the next example just below FIGURE 4.6 states the label was wrong on the R1 router and if clocking is added the interface will come up. Then the label on R2 must be incorrect and if so why wasn't this discovered when the interface was configured. And I believe that with the extreme depth of knowledge with Cisco's, Todd and company can give a much better illustration than a label problem. Now I have to wonder if every solution could possibly be mislabeled. I expect a fix in Ed.7.

I will tell you that I enjoy going through this study guide, even though it is a tedious process. It is well written and the explanations are clear and repetitive. I've got ten chapters yet so there is still much to be done.

[lammle]

Steve, the answer to both are correct. I mentioned throughout the chapter about the cable and how it works and why it is not used in production. Even in that paragraph I mention how you need a CSU/DSU, which is what you'd find in production.

In your first question the figure is showing a router as a DTE - this means that interface must receive clocking. Since there is not CSU/DSU, the clocking must configured on the other router. The answer states that the cable could be bad or clocking is not configured. In a WAN crossover cable network connection, those are the only two issue that can exist.

In figure 4.6, the routers are labled as DTE and DCE, although by using the show controllers commands, we can see that they are backwards or possibly labeled incorrectly. This is a typical problem found in test enviornments. The way to verify the interfaces is with the show controllers command. Always verify your connections.

My book is correct and these are typically problems found, as well as issues that are directly related to the CCNA objectives. I suggest that you reread the section and see if you can get more clarity as it is very important information to understand.

I hope this help clear up any misunderstandings.

Cheers!
Todd Lammle

[Stevep]

Todd, I get the clocking issue on the 4.7 example but I don't see how the cable could be the problem. That would be contrary to previous instruction that stated if the interface is up then a carrier was received. That is the Physical Layer, can the router detect a carrier if the cable is bad? I'm just looking for the correct answer, rereading the section still gives me the same two statements without the very important clearity.
Thanks,
Steve

[lammle]

The cable might not be the issue. The router shows up/down, which means it is not getting clocking from the remote side. If this were a production network, you'd call your remote site to verify power, then call your ISP to fix the connection. Either way, the up/down means "check the other side". I've seen this problem with a "wan crossover" cable problem, or when clocking is not configured.
Hope this helps.
Todd