Are you able tp ping the core router? Are there any ACLs which could be blocking telnet? What IOS and platform do you have?
Please post the line vty config.
I can not tell from your description whether telnet was working and now is not (something changed) or whether telnet has never worked. Perhaps you can clarify since understanding this would influence how we would troubleshoot.
It would also be helpful if you would post the configuration of the vty lines on the router where you can not telnet.
As a rule of thumb, if ping to the box works and if routing is uninterrupted and only telnet is blocked, its an access-list.
If you try to connect and the message says ( telnet connection refused) then its probably
an access-list. Please see the follwoing e.g:
line vty 0 4
access-class 1 in
access-list 1 permit xxx.yyy.0.0 0.0.255.255
In the above e.g., access-class "1" clarifies access-list 1. Please chekc if such an access-list exists on the box referring to the line vty. If so, check the ip address range permitted there and the ip address you are trying to telnet from.
But, if you can actually connect and the box does not accept your username and password then its a problem with authentication username/password combination on the line vty.
As a first simple approach, specify a password for telnet access like this:
line vty 0 4
It is a requirement for telnet access to specify a password.
I offer one clarification to the post by Istvan. He is correct if the router is configured with no aaa new-model. However if the router is configured with aaa new-model then the password on the vty is an option but not a requirement.
And if the router has no aaa new-model and the vty is configured with no login, then the vty password is not required.
Istvan's suggestion represents the best practice for a router which has no aaa new-model.
I am glad that you got it working now. Based on the symptom (could not telnet and after reboot can telnet) I would guess that the problem was that all vty lines were busy. This happens sometimes especially when the vty lines are configured with exec-timeout 0 (or with no exec-timeout). Can you confirm whether this is the case or not?
In my experience it is not good to have exec-timeout 0 on vty lines. You can have a relatively long timeout if you do not want to be logged out after the default of 10 minutes of inactivity. But exec-timeout of 0 invites this problem of vty lines not clearing when a telnet session got terminated but not by logout.
We've run into this problem on 7600 series routers running 12.2(33)SRA5 and SRA6 where it just locks up the VTY completely until you reboot. This is with VTY's that have worked in the past. If you "busy out" the VTY(s) that are locked by telneting into them and letting that session hang, you can open another session and get into another VTY though.
We opened up a TAC case quite awhile ago with no resolution beyond rebooting, but now we have it happening on two routers at once on two different IOS's.. Only 7600 routers though w/ Sup720's, no other routers.