Connectivity issue - tcpdump reports ping a success, ping itself does not - ip

I am having some connectivity issues. The arp table is not populated even if the arp request are successfully transferred on the wire. Which leads to unsuccessfully ping. When I add a arp entry manually, tcpdump shows replies but not ping itself.
Ping packets got reply in tcpdump but not in ping.
Pinging 12.12.12.10 from 12.12.12.7
Ping Screen:
From 12.12.12.7 icmp_seq=594 Destination Host Unreachable
From 12.12.12.7 icmp_seq=595 Destination Host Unreachable
From 12.12.12.7 icmp_seq=596 Destination Host Unreachable
From 12.12.12.7 icmp_seq=598 Destination Host Unreachable
From 12.12.12.7 icmp_seq=599 Destination Host Unreachable
Tcpdump output:
08:18:38.117478 IP 12.12.12.7 > 12.12.12.10: ICMP echo request, id 64559, seq 197, length 64
08:18:38.118852 IP 12.12.12.10 > 12.12.12.7: ICMP echo reply, id 64559, seq 197, length 64
08:18:39.117471 IP 12.12.12.7 > 12.12.12.10: ICMP echo request, id 64559, seq 198, length 64
08:18:39.119015 IP 12.12.12.10 > 12.12.12.7: ICMP echo reply, id 64559, seq 198, length 64
All help is much appreciated.

I have seen this issue too, could you check your firewall policy is set up right?

Related

Neutron+VLAN. Allow a trunk traffic between VMs

Please tell me, how can I make it possible to transfer Trunk traffic at the user level in the Neutron Private Network?
Description
We have the following private, non-shared network without any Gateway:
I want to make sure that VMs can configure Trunk-VLAN connections to each other. At the same time, the creation of these connections was controlled at the OS level (the count of such connections and VMs is completely chaotic and random )
The problem is the following - if you make several VMs on, for example, Centos and try to set up the relationship of one VM to another through the Trunk port with ID, for example, 5, the Neutron network completely drop such traffic.
### Both VMs ###
[root#vlan-X centos]# modprobe bonding
[root#vlan-X centos]# modprobe 8021q
[root#vlan-X centos]# echo "8021q" > /etc/modules-load.d/8021q.conf
[root#vlan-X centos]# echo "bonding" > /etc/modules-load.d/bonding.conf
### VM1 ###
[root#vlan-1 centos]# vi /etc/sysconfig/network-scripts/ifcfg-eth1
NAME="eth1"
DEVICE="eth1"
ONBOOT="yes"
TYPE="Ethernet"
BOOTPROTO="none"
[root#vlan-1 centos]# vi /etc/sysconfig/network-scripts/ifcfg-eth1.5
ONBOOT=yes
VLAN=yes
DEVICE=eth1.5
BOOTPROTO=static
IPADDR=192.168.10.15
PREFIX=24
[root#vlan-1 centos]# systemctl restart network
### VM2 ###
[root#vlan-2 centos]# vi /etc/sysconfig/network-scripts/ifcfg-eth1
NAME="eth1"
DEVICE="eth1"
ONBOOT="yes"
TYPE="Ethernet"
BOOTPROTO="none"
[root#vlan-2 centos]# vi /etc/sysconfig/network-scripts/ifcfg-eth1.5
ONBOOT=yes
VLAN=yes
DEVICE=eth1.5
BOOTPROTO=static
IPADDR=192.168.10.16
PREFIX=24
[root#vlan-2 centos]# systemctl restart network
[root#vlan-2 centos]# ping 192.168.10.15
PING 192.168.10.15 (192.168.10.15) 56(84) bytes of data.
From 192.168.10.16 icmp_seq=1 Destination Host Unreachable
From 192.168.10.16 icmp_seq=2 Destination Host Unreachable
From 192.168.10.16 icmp_seq=3 Destination Host Unreachable
From 192.168.10.16 icmp_seq=4 Destination Host Unreachable
From 192.168.10.16 icmp_seq=5 Destination Host Unreachable
From 192.168.10.16 icmp_seq=6 Destination Host Unreachable
From 192.168.10.16 icmp_seq=7 Destination Host Unreachable
From 192.168.10.16 icmp_seq=8 Destination Host Unreachable
^C
--- 192.168.10.15 ping statistics ---
11 packets transmitted, 0 received, +8 errors, 100% packet loss, time 10001ms
pipe 4
At the same time, tcpdump looks like this - that is, VLAN was successfully accepted, but then even ARP is unsuccessful
[root#vlan-2 centos]# tcpdump -e -nvvvti eth1
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
fa:16:3e:8f:7f:df > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.15 tell 192.168.10.16, length 28
fa:16:3e:8f:7f:df > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.15 tell 192.168.10.16, length 28
fa:16:3e:8f:7f:df > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.15 tell 192.168.10.16, length 28
fa:16:3e:8f:7f:df > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.15 tell 192.168.10.16, length 28
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel
At the same time, the same design on VirtualBox with an internal network works fine.
What I have tried to solve this problem:
I tried creating a network with option "--transparent-vlan" - nothing changed
I tried creating a network with option "--transparent-vlan --disable-port-security" - nothing changed
I tried to connect the "Trunk" option to Neutron and configure additional entities like "network trunk" and "subport" - nothing changed. I had a suspicion that this was all intended to set up communication between two VMs on different networks, and not many VMs on the same network.
In general, this option has one limitation - it only works with Linuxbridge
A worked configuration for me:
vi /etc/neutron/neutron.conf
...
[DEFAULT]
vlan_transparent = true
...
vi /etc/neutron/plugins/ml2/ml2_conf.ini
...
[ml2]
type_drivers = flat,vlan,vxlan,gre
tenant_network_types = vxlan
mechanism_drivers = linuxbridge
...
vi /etc/neutron/plugin.ini
...
[ml2]
type_drivers = flat,vlan,vxlan,gre
mechanism_drivers = linuxbridge
...
And only then I was able to create a network with option "vlan_transparent", but not through the CLI, but through the API:
$ curl -s -X POST http://internal.mystack.net:9696/v2.0/networks -H "X-Auth-Token: <TOKEN>" -H "Content-Type: application/json" -d '{"network": {"name": "test", "admin_state_up": true, "tenant_id": "56b0cfe82ef94b2b8a60c53d72921a8b", "vlan_transparent": true}}'
$ openstack network show test --debug
...
{"networks": [{"provider:physical_network": null, "ipv6_address_scope": null, "dns_domain": null, "revision_number": 4, "port_security_enabled": true, "provider:network_type": "vxlan", "id": "78af4991-1b50-4b8d-9299-3a5dfaf689a2", "router:external": false, "availability_zone_hints": [], "availability_zones": [], "ipv4_address_scope": null, "shared": false, "project_id": "56b0cfe82ef94b2b8a60c53d72921a8b", "status": "ACTIVE", "subnets": [], "private_dns_domain": "mcs.local.", "description": "", "tags": [], "updated_at": "2022-03-29T13:22:00Z", "provider:segmentation_id": 88, "name": "test", "admin_state_up": true, "tenant_id": "56b0cfe82ef94b2b8a60c53d72921a8b", "created_at": "2022-03-29T13:22:00Z", "mtu": 1400, "vlan_transparent": true}]}
That is, if you add any "openvswitch" or "l2population" to the configuration in the "mechanism_drivers", then all this will abruptly stop working
I didn't develop the experiment further. realized that it doesn't suit me

Terminal not seeing ping messages from TUN port

Hi I'm working on a project and I had a question involving ping commands and how they interface over network TUN ports.
Basically I'm sending out ping requests which are routed to my TUN port and the reply's are sent to the TUN port over the VPN. There are no other internet interfaces (i.e. no wifi/ethernet). Using wireshark and tcpdump I can see that the correct reply messages are seen on the TUN0 port but terminal does not see the replys and instead shows 100% drop rate. The issue seems to be that the TUN0 port is not properly linking back to the kernal? (total guess I'm quite new to IP routing).
The IP address of the TUN is 10.0.0.73 and I am pinging a computer with IP address 10.0.0.28
Bellow is a snippet from the tcpdump on TUN0 this is a request and reply that to my untrained eye should work:
23:08:52.257566 IP (tos 0x0, ttl 64, id 11185, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.0.73 > 10.0.0.28: ICMP echo request, id 24667, seq 2, length 64
23:09:11.508002 IP (tos 0x0, ttl 64, id 13315, offset 0, flags [none], proto ICMP (1), length 84)
10.0.0.28 > 10.0.0.73: ICMP echo reply, id 24667, seq 2, length 64
Based on other posts I checked my ip route list and the output is as such
pi#raspberrypi:~$ sudo ip route list
10.0.0.0/24 dev tun0 proto kernel scope link src 10.0.0.73
and the ifconfig is this:
pi#raspberrypi:~$ ifconfig tun0
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.0.73 P-t-P 10.0.0.73 Mask:255.255.255.0
...
Turns out the issue was that the replies were showing up in incorrect orders and greatly delayed, when I fixed the network connections this issue went away without changing any configurations in the iptables

az login returns error "Failed to establish a new connection: [Errno -3] Temporary failure in name resolution"

I was doing az login from WSL of my windows machine. Then it gives an error:
Please ensure you have network connection. Error detail: HTTPSConnectionPool(host='login.microsoftonline.com', port=443): Max retries exceeded with url: /common/oauth2/token (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f401d135630>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',))
I hope this is a DNS issue.
So I checked /etc/resolv.conf of WSL:
# This file was automatically generated by WSL. To stop automatic generation of this file, remove this line.
nameserver 192.168.1.1
nameserver fcc0:0:0:ffff::1
nameserver fcc0:0:0:ffff::2
192.168.1.1 is the default gateway.
There are the results of some commands I tried:
$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=128 time=0.351 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=128 time=0.888 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=128 time=0.883 ms
$ dig 192.168.1.1
; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> 192.168.1.1
;; global options: +cmd
;; connection timed out; no servers could be reached
$ nslookup 192.168.1.1
;; connection timed out; no servers could be reached
These commands also give an output that indicates an issue.
Ping google.com
dig google.com
All these commands( or its alternatives) work from the Windows command prompt works correctly.
I found a workaround here:
https://askubuntu.com/questions/91543/apt-get-update-fails-to-fetch-files-temporary-failure-resolving-error
It says that I should add the followinng line to /etc/resolv.conf. If I try it like this, it works.
nameserver 192.168.1.1
nameserver 8.8.8.8
nameserver fcc0:0:0:ffff::1
nameserver fcc0:0:0:ffff::2
After this, the ping google.com and dig google.com works fine. But I can see that the nameserver it uses to resolve is 8.8.8.8.
If I connect to VPN, it adds our own nameservers to /etc/resolv.conf and after that, there is no problem in resolving the URLs. Once the VPN is disconnected, the issue arises again.
Note:
There were no issues like this before.
Last day we changed our router in order to use a new ISP's connection and after that, the issue occurs.
Other machines in the same network don't have this issue.
Why this occurs and How can I properly fix this issue of WSL?
Why only one machine in our network can ping, but can't dig to the default gateway?
Update:
I can see that there are two entries that are marked as default in routing table:
$ ip route show table all | grep default
none default via 192.168.0.1 dev wifi0 proto unspec metric 0
none default via 192.168.1.1 dev eth6 proto unspec metric 0

Cannot ping gateway for external Openstack network

I installed Openstack Ansible, Pike version. There is a separate network controller and on it one physical network interface. We created VLAN 139 that leads the traffic to gateway. Config file for that part looks like:
/etc/network/interfaces
...
auto eno1.139
iface eno1.139 inet manual
vlan-raw-device eno1
# OpenStack Networking VLAN bridge
auto br-vlan
iface br-vlan inet manual
bridge_stp off
bridge_waitport 0
bridge_fd 0
bridge_ports eno1.139
We created an external Openstack network using:
openstack network create --external --share --provider-physical-network vlan --provider-network-type vlan --provider-segment 139 provider1
and all the other steps (subnet, router, etc)
As per documentation, first test should be pinging default gateway from router namespace. When I try that it is not working:
root#infra1-neutron-agents-container-e800e983:/# ip netns exec qrouter-eb842b12-9a35-4a93-baa9-38cc73531d9f ping 139.25.25.193
When I do TCP dump on physical network interface of controller node I can see packets going out without any problem:
openstackadmin#clcontroller:~$ sudo tcpdump -i eno1 --immediate-mode -e -n | grep 139.25.25.193
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
16:30:09.182894 fa:16:3e:d4:b6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 50: vlan 139, p 0, ethertype 802.1Q, vlan 139, p 0, ethertype ARP, Request who-has 139.25.25.193 tell 139.25.25.200, length 28
I see ARP request getting to gateway that has 139.25.25.193 and I am trying to ping:
hpadmin#hos-gw01:~$ sudo tcpdump -i any --immediate-mode -e -n | grep 139.25.25.193
[sudo] password for hpadmin:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
15:53:29.857281 B fa:16:3e:d4:b6:a1 ethertype 802.1Q (0x8100), length 62: vlan 139, p 0, ethertype 802.1Q, vlan 139, p 0, ethertype ARP, Request who-has 139.25.25.193 tell 139.25.25.200, length 38
15:53:29.857281 B fa:16:3e:d4:b6:a1 ethertype 802.1Q (0x8100), length 58: vlan 139, p 0, ethertype ARP, Request who-has 139.25.25.193 tell 139.25.25.200, length 38
but what is confusing is my gateway is not responding to those ARP requests.
If I try to do same thing from stand alone Linux machine connected to same network segment and same VLAN everything works perfect.
Any idea what the problem might be? Thanks in advance.
It seems that problem was that external OpenStack network was set up to be on VLAN 139. Once we changed it to be flat everything started working without any problems. I am still confused, though, why gateway did not sent ARP responses.

Can I use http tunnel to ping or traceroute through a proxy with firewall?

I don't know if there is a way to ping a target outside my LAN proxy which accepts only Http requests through a squid proxy... I read somewhere that one way to deal with such problem is to use a http tunnel so that the proxy still sees the request as a Http request. Can I use this to ping,say, www.google.com which otherwise is giving the following error because the firewall is rejecting the request:
$ ping www.google.com
ping: unknown host www.google.com
If so how is it done...?
I have installed httptunnel.Any help in how to use it will be much appreciated.
No. Ping and traceroute make use of lower layer network protocols (ICMP and/or UDP, in particular, which are layer 4 protocols) and will not work over an HTTP (layer 7) tunnel. In any case, even if you could convince the HTTP proxy to open a raw TCP session for you (which is how some HTTP tunneling works) you would not receive the necessary packets to confirm that the host is reachable. (ICMP echo reply, in the case of ping, or the time-to-live expired ICMP packets in the case of traceroute)
To test for connectivity in this situation, I think the best you can do is an HTTP "ping". (Try to establish an HTTP connection with the remote host and see if it works.) For example, you could do something like:
$ http_proxy=http://webproxy.example.com:3128 \
> curl -I http://google.com/ > /dev/null 2>&1 \
> && echo success || echo failure
Assuming you have curl installed, this would print "success" if google.com is reachable through your proxy and "failure" if not.
It's not exactly what you were looking for, but if you can access and external ssh server, you can run it through that, and the results will reflect the ping time to the ssh server:
$ ssh username#server 'ping -c 1 google.com'
PING google.com (72.14.204.147) 56(84) bytes of data.
64 bytes from iad04s01-in-f147.1e100.net (72.14.204.147): icmp_seq=1 ttl=57 time=2.64 ms
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.640/2.640/2.640/0.000 ms

Resources