We can do so using NAT (Network Address Translation) table of the firewall. destination machine can directly find this out if it try to trace the incoming packets using tshark/ wireshark like tools. What this means is, we will indeed be using valid IP address of our machine to communicate with destination, but this all will happen under the hood! P.S. Having said that, in the case above to work ping -I (lookback) (destination) we can configure the firewall to transfer the requests generated by the lookback IP to be masqurade so as to change the source IP with the valid eth0 IP. as Lister maintained lookback IP is used by the device to talk to itself for self-diagnostics and trouble shooting. related discriptionĬan we actually use lookback IP to connect with other network machine? It is used mainly for diagnostics and troubleshooting, and to connect to servers running on the local machine. The loopback device is a special, virtual network interface that your computer uses to communicate with itself. We can not use lookback IP to communicate with the outside network! BUT. As we know, the range for loopback addresses is 127.0.0.0 127.255.255.255. If you do send a packet from that ip, it will be ignored by other devices. You could attempt a source ping from your external interface, ping source host 8.8.8.8.If you have no gateway, or the gateway does not know where the network is, then the message is not sent.ġ27.0.0.1 is always on a different subnet to your network, routing devices will never route traffic from it, and your host machines will not try to send messages from it. Hello, I would suggest what BPry stated, check for management interface profiles that allow ping also security policies that allow ping from the subnets you are sourcing from. A message will be sent to the gateway and the devices rely on the gateway to send over the message. However, if I have 192.168.0.1 ping 192.168.1.1, they will again look at the network portion and see it is different. If I try and ping 192.168.0.1 from 192.168.0.2 They will look at their subnet and identify their network portion of the ip address (192.168.0) They both see they are on the same subnet, and communicate. Lets assume your network is on the 192.168.0.0 subnet with the subnet mask of 255.255.255.0. If they are, they will talk, if not, they will attempt to use a gateway (router etc) to try and get there. When computers talk, they check to see if they are on the same subnet as the device they are talking to. If you ping 127.3.3.3 for example your device will ping itself. My ultimate goal is to ping lo0:192.20.11.1 on router 'Good'. I advertise the respective networks Lo0 and Lo1 via OSPF, so I am not sure if I can understand whats going on. From WG4R3 I cant ping Lo0 and Lo1 on WG4R2 and vice and versa. This discussion from the Cisco Learning Network has a nice explanation of why that is the case.Īnd it shows the optional parameter which can be used so that you can protect your network and still be able to ping your own interface.I thought I would give a full answer to follow up on the comments. When the simple version of that command is used one result is that you can no longer ping your own interface. This command is used to improve security in the network and looks for "spoofed" packets. an ip-address that is not part of 10.0.0.0/24) and set a static route on your asa via the ip-address of the ethernet of the device with the loopback-address. The issue was the effect of ip verify unicast. To see, if that is the reason for your issue, please configure the loopback-interface with an ip-address, that is not directly connected to the ethernet-interface of your asa (i.e. Your additional information made it clear that pinging the neighbor address did work and the problem was pinging your own address. I had assumed that the issue was not being able to ping the neighbor address. (which did turn out to be the case) I had not correctly understood the issue. Especially show cdp neighbor would show whether the routers were able to communicate at layer 2 and could indicate that it was a layer 3 issue. In fact it was that type of possible issue that I was looking for when I asked for the information that you posted. Depending on the platform (and perhaps version of code) it could cause the routers to not be able to communicate with each other. Using a straight through cable would not cause this kind of issue. This is a bit after the fact, and congratulations to Pauwen for suggesting removal of ip verify unicast, but let us try to clarify a few things about this issue.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |