If this was a real device, then ping/ssh/telnet would resolve the name to an IP address, and then would be identical in opereation after that point to what would have happened if you had specified an IP address instead.īut with packet tracer. If you use debug ip packet on the router, you can see that in both cases, a number of IP packets are exchanged, so either the ssh server at the destination is rejecting it for some reason (and at that point, both versions should look identical to it), or there's a problem with packet tracer.
#How to use telnet packet tracer Pc#
In the real world, I would turn ssh debug on, on the target device, and see why it disconnected, but that's not an option in packet tracer, so the next best solution would be to packet capture the traffic between the PC and router and see what's going on there. background information in ip based computer networks, vrf is a technology that allows multiple instances of a routing table to co exist within the same router at the same time.
this document describes the configuration of device access with telnet or secure shell (ssh) across a virtual routing and forwarding (vrf). Reply from 172.16.0.2: bytes=32 time=2ms TTL=254 Configure telnet and ssh on cisco packet tracer newjar. Pinging 172.16.0.2 with 32 bytes of data: This is before any data has been sent, or any ssh protocol version has been negotiated. it's not just the ssh application on the PC that's doing this - we see the same problem if (from one of the PCs), you instead use telnet to connect to the ssh port (tcp/22) - that is, connecting by IP address works, but connecting by hostname appears to connect and disconnect immediately. There's something messed up in packet tracer.
0 kommentar(er)
