Using Zabbix 4.2 I detect that a device, more specifically, an Access Point, shows an alert saying that, the mentioned device is unavailable by ICMP Ping.
Does this mean that the mentioned device is offline or that it has been turned off?
Related
i'm trying to test XDP program but the test environment was provided by the client consists of one server and qemu guest running on it and act as a traffic generator ( using scapy or DPDK ). and to have this test run successfully,the packets from the guest should arrive/be injected to the NIC driver ( XDP working in native mode ) of the host. is there's any configs/hacks that can make the traffic goes from the guest to the host driver?
edit :
some points to be cleared as #vipin suggested,
on the host, the NIC is connected to virbr0 on kernel.
the XDP is running on the physical NIC.
i'm using bpf_redirect_map for redirecting as we still in simple stage.
anyway, i got a work around is just to add a physical router to the lab setup and it's enough for this stage of test.
XDP (Express Data Path) supported in Linux is for RX side, and there were patches for TX but not integrated. Based on the current update XDP-eBPF is on Physical NIC. So all RX packet on physical NIC is processed.
But as per the question shared packets from the guest should arrive/be injected to the NIC driver ( XDP working in native mode ) of the host.. If one needs to run the logic for traffic coming from GUEST OS, XDP has to be loaded to emulator or TAP or Bridge interface. This will allow to redirect packets based on Kernel NIC id to Physcial NIC.
I have set up an Google Cloud Compute Instance:
Machine type
n1-standard-1 (1 vCPU, 3.75 GB memory)
CPU platform
Intel Haswell
Zone
us-east1-c
I can ssh in using the external address.
I have installed the vncserver and can access it on port 5901 from localhost as well as the internal IP.
I am trying to access it from the static, external IP address but it is not working.
I have configured the firewall to open to port to 0.0.0.0/0, but it is not reachable.
Can anyone help?
------after further investigation from the tips from the two answers (thanks, both!), I have a partial answer:
The Google Cloud Compute instance was set, by default, to not allow
HTTP traffic. I reset the configuration to allow HTTP traffic. I
then tried the troubleshooting tip to run a small HTTP service in
python. I was able to get a ressponse from the service over the
internet.
The summary of the current situation is as follows:
The external IP address can be reached
It is enabled and working for SSH
It is enabled and working for HTTP
It does not seem to allow traffic from vncserver
Any idea how to configure the compute instance to allow for vncserver traffic?
If you already verified that Google Firewall or your VM are not blocking packets, you must make sure that VNC service is configured to listen on the external IP address.
You can always use a utility like nmap outside Google project to reveal information on the port status.
enable http/https traffic form the firewall as per the need. it will work!!
The Google Cloud Compute instance was set, by default, to not allow HTTP traffic. I reset the configuration to allow HTTP traffic. I then tried the troubleshooting tip to run a small HTTP service in python. I was able to get a response from the service over the internet.
As such, the original question is answered, I can access Google Cloud Compute Instance External IP. My wider issue is still not solved, but I will post a new, more specific question about this issue
TLDR: make sure you are requesting http not https
In my case i was following the link from my CE instance's External Ip property which takes you directly to the https version and i didn't set up https, so that was causing the 'site not found' error.
Create an entry in your local ssh config file as below with mentioned local forward port. In my case its an example of yarn's IP, which I want to access in browser.
Host hadoop
HostName <External-IP>
User <Local-machine-username>
IdentityFile ~/.ssh/<private-key-for-above-user>
LocalForward 8089 <Internal-IP>:8088
In addition to having the firewall rules to allow HTTP traffic in both Google Cloud Platform and within the OS of the instance, make sure you install a web server such as Apache or Nginx.
After installing the web server, you connect to the instance using SSH and verify you do not get a failed connection with the following command:
$ sudo wget http://localhost
If the connection is positive, it means that you can access your external URL:
http://<IP-EXTERNAL-VM>
Usually there are two main things to check.
1. Port
By default, only port 80, 443 and ICMP are exposed. If your server is running on a different port, create a record for the same.
2. Firewall
Make sure you are allowing http and https traffic based on your need.
oua re
For me the problem was that I set up the traffic for the firewall rule to be 'Egress' instead of 'Ingress'.
If anyone already initiated 'https'
just disable it and check again.
I know the ICMP request contains the IP address. Is the client MAC address included in an ICMP request? What other info (if any) is included in a ping request?
An ICMP request is a layered packet which is sent over the internet. It contains the Ether layer, which has the target and source MAC address in it. It also contains the IP layer, which has the source and target IP and also a couple of flags included. And at last it contains the ICMP data. This contains a type, a subtype, then a checksum and the rest of the header, which can vary from type and subtype (E.g. The code for echo is 8 and reply is 0).
There is a lot of information in a network packet. Also note that ICMP is an part of the IPv4 protocol, so it cannot officially be carried by other protocols. Although the IP protocol can be carried on a different protocol than the ethernet protocol.
The MAC address will be changed after each passing of a router. So this is never the MAC address of the source IP address on the internet. But the IP address is definitely included and on a local network, the mac address of the client is still in the packet in the Ether layer.
Wikipedia has some readable article about ICMP packets: icmp message and different protocols with readable diagrams.
If you want to see some live requests, you can install wireshark, which will show and dissect all network traffic for you. It is a very convenient and cool tool.
The ICMP 'ping' packet, officially known as 'echo request', contains whatever the originating ping executable wants to have echoed back to it. In the Bad Old Days when the internet was first getting started up, the routers they had (and all computers, really) were subject to random memory failures. In order to detect that the path between two systems was clear, they would send echo request packets and compare the contents of the request with the reply. If the contents differed, they knew that there was a problem with either of the machines involved, or the routers in between.
It's impossible to state here categorically exactly what's in any given ping packet because it changes between implementations of ping.
It is usually not possible for a person to get the MAC address of a computer from its IP address alone. These two addresses originate from different sources. Simply stated, a computer's own hardware configuration determines its MAC address while the configuration of the network it is connected to determines its IP address.
However, computers connected to the same TCP/IP local network can determine each other's MAC addresses.
Look RFC 792 for full ICMP fields.
I have written a application, which uses libpcap to capture packets. But the application can only capture a few packets, the traffic is about several kbps. But the captured traffic will be over 10Mbps if tcpdump is opened. When tcpdump is closed, the captured traffic dropped to several kbps again.
Anyone know why? Thank you very much.
If you're calling pcap_open_live(), you're probably passing 0 as the ''promisc'' argument. If you're calling pcap_create() and pcap_activate(), you're probably not calling pcap_set_promisc() between those calls (or are passing pcap_set_promisc() a ''promisc'' argument of 0).
I.e., you're probably not turning promiscuous mode on, so your machine is only capturing traffic to and from your machine, not other traffic on the network. Tcpdump, by default, turns promiscuous mode on, so, while it's running, the adapter on which you're capturing, which is probably the same adapter as the one on which tcpdump is capturing, is in promiscuous mode, and you'll see other traffic on your network.
Is there a performance difference between TCP connections to:
localhost / 127.0.0.1
a domain which resolves to the local machine
Or more specifically, do the latter connections go through the loopback device, or over the actual network?
The reason I'm asking is I'm thinking about changing database settings in many PHP apps so they use a full domain instead of localhost. That way we could more easily move the database to a different server, if the need arises.
This is implementation and operating system dependent. On Windows, anything connecting to a local IP address, even if it is an outside-facing IP, will go over loopback. This is a documented problem for applications such as packet sniffers, because you can't sniff the loopback. (Windows doesn't treat loopback as a "device" -- it is handled at the network level.) However, in this case it would work in your favor.
Linux, in contrast, will follow whatever you have in your routing table, so packets that are destined to your local machine will go to your local machine over the network if the routing table isn't properly configured. However, in 99% of the cases the routing will be configured properly. Your packets won't go over the loopback device, but the TCP/IP stack will know that you are contacting a local IP and it will virtually go out and back in the proper ethernet device.
In a properly configured environment, the only bottleneck for using a domain name would be DNS resolution time. Contacting an outside DNS can add additional latency into your configuration. However, if you add in the domain name into your /etc/hosts file (C:\Windows\System32\drivers\etc\hosts on Windows), your system will skip the DNS resolution phase and obtain an IP directly, making this time cost moot.
That depends on how the names are resolved. The procedure is typically /etc/hosts first and then DNS if that fails. If localhost is in your /etc/hosts, putting whatever.wherever in the file as well will make it resolve with the same speed.