Maybe a bit of a thick question, and i think i sort of understand it, but why do we always ping (or i always see) in labs to ping from the loopback address. I would like to see a good and clear explanation for it but so far i haven't been able to find it.
i think it is because we do not advertise directly connected routes, and because all the routers have
a loopback address they are in the same network so they know how to get back. If we don't ping from the loopback it might source it from a address that the foreign network doesn't know how to get back to because it isn't advertised. so if we use the loopback as a source, if there is a any connection to that remote router or network available at all, it will take it back.
I don't know if this is correct or not, and i'm not even sure i understand it myself completely.
Thanks to anyone who can point me in the right direction !
In lab environments loopback interfaces are can be created to emulate local networks connected behind the router when its not practical to have a bunch of switches and PCs connected to the router. In this case sourcing the ping from the loopback interface is effectively the same as running ping from a PC that would connected to the router.
Of couse there are lots of other uses for loopback interfaces on a router and the above is only one example.
Testing from a loopback or any specific IP or interface, tests the route back to that specific IP (the path that the echo-reply will take) as well is the route forward. If you don't specify a source, IOS selects the egress interface based on the route table. The IP of the egress is used as the source of the echo.
Loopbacks are the most reliable IP address than any other IPs on a router.
The reason behind is, when your intention is to check wheter a rotuer is live and reachable via any path, it makes more sence to ping the loopback as it can go down only when the router is turned off or completely isolated.
On the other hand, if If you use an interface's IP for testing availability of a rotuer, then you have a chance where the interface you are trying to reach is down, but the rotuer is still up (reachable via an alternate link/interface) and you can end up deciding that the router itself is down or not reachable.
Ok i think i finally understand this (admittedly simple) thing.
I got it by doing a lab and having ebgp neighbors with igp connected in a r1-r2-r3 and r4 connected to r2 fashion.
When i sourced from loopback0, i had ping and connectivity. If i didn't, i did not. Makes perfect sense ofcourse, as i did not advertised the physical/directly connected interfaces in igp (not even running any), only the loopbacks on all devices. And if i don't specify a interface, it will take the outgoing interface by default as Paul said and it won't be able to get there (will it even get to R3?) or return.
So most issues with pinging from loopback failing will probably arise from not having advertised in the directly connected networks properly. And if you ping with loopback (assuming these networks are advertised in), if the physical path is ok, the connectivity should be ok.
But could i not just achieve the same thing by just advertising in a connected interface properly and pinging from the source there ? That would do the same thing as pinging from a loopback right ? With the difference that with pinging a loopback would be more resilient, as long as there is one path up to the router the loopback would succeed.
Does that sortof make sense?