All Ports Can be pinged from other systems externally

C

CloudHopping

New Member
May 1, 2017
12
0
1
49
Racine, Ohio
connectivity.engineer
Hello - This is a strange one for us.

In short - Every port if assigned an ip is able to be pinged (even if it is NOT plugged in!) from systems external to the Proxmox System
auto lo
iface lo inet loopback

iface eth0 inet manual

iface eth1 inet manual

iface eth2 inet manual

auto eth3
iface eth3 inet static
address 100.70.100.3
netmask 255.255.255.0

auto eth4
iface eth4 inet static
address 100.70.100.4
netmask 255.255.255.0

iface eth5 inet manual

iface eth6 inet manual

iface eth7 inet manual

auto vmbr0
iface vmbr0 inet static
address 192.168.1.16
netmask 255.255.255.0
gateway 192.168.1.1
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_vlan_aware yes

auto vmbr1
iface vmbr1 inet manual
bridge_ports eth1
bridge_stp off
bridge_fd 0
bridge_vlan_aware yes

auto vmbr2
iface vmbr2 inet manual
bridge_ports eth2
bridge_stp off
bridge_fd 0
bridge_vlan_aware yes

iface vmbr3 inet manual
bridge_ports eth3
bridge_stp off
bridge_fd 0
bridge_vlan_aware yes

iface vmbr4 inet manual
bridge_ports eth4
bridge_stp off
bridge_fd 0

auto vmbr5
iface vmbr5 inet manual
bridge_ports eth5
bridge_stp off
bridge_fd 0
bridge_vlan_aware yes

auto vmbr6
iface vmbr6 inet static
address 192.168.1.40
netmask 255.255.255.0
bridge_ports eth6
bridge_stp off
bridge_fd 0
bridge_vlan_aware yes

auto vmbr7
iface vmbr7 inet static
address 100.70.100.7
netmask 255.255.255.0
bridge_ports eth7
bridge_stp off
bridge_fd 0
Click to expand...


so - Interface eth3 is plugged in however eth4 is not.
Yet we are able to ping 100.70.100.3 and 100.70.100.4

Same with VMBR6 nothing is plugged into eth6 and vmbr6 is a member to eth6.
Yet external from the proxmox system we can ping 192.168.1.40 as it it were plugged in.


Any thoughts?
 

Attachments

  • debianDrunkbutIhavetheHangoverheadache.PNG
    debianDrunkbutIhavetheHangoverheadache.PNG
    33.8 KB · Views: 6
> Same with VMBR6 nothing is plugged into eth6 and vmbr6 is a member to eth6.
Yet external from the proxmox system we can ping 192.168.1.40 as it it were plugged in.

what is the ouput of
ip link show dev eth6

and traceroute -n 192.168.1.40 from the external system ?
 
  • Like
Reactions: CloudHopping
ip link show dev eth6
8: eth6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master vm br6 state DOWN mode DEFAULT group default qlen 1000
link/ether 00:1f:29:57:f0:93 brd ff:ff:ff:ff:ff:ff


Very odd when it has No-Carrier for it to ping ;-/

Tracert -n from Windows does not work
But its within the same broadcast domain - so its just 1 hop away (sadly not showing hitting anything else which is what we hoped for)

Thanks for the reply btw - :)
 
Last edited:
can you see with tcpdump if the ICMP anwser is really coming from this interface ?
the command would be

tcpdump -i eth6 icmp

you can use the physical port (eth6) or the bridge device (vmbr6) it should display the same answer
 
tcpdump -i eth3 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth3, link-type EN10MB (Ethernet), capture size 262144 bytes
10:09:14.927272 IP 100.70.100.1 > 100.70.100.4: ICMP echo request, id 33289, seq 0, length 36
10:09:14.927301 IP 100.70.100.4 > 100.70.100.1: ICMP echo reply, id 33289, seq 0 , length 36
10:09:15.929740 IP 100.70.100.1 > 100.70.100.4: ICMP echo request, id 33289, seq 256, length 36
10:09:15.929748 IP 100.70.100.4 > 100.70.100.1: ICMP echo reply, id 33289, seq 2 56, length 36
10:09:16.932224 IP 100.70.100.1 > 100.70.100.4: ICMP echo request, id 33289, seq 512, length 36
10:09:16.932232 IP 100.70.100.4 > 100.70.100.1: ICMP echo reply, id 33289, seq 5 12, length 36
10:09:19.381680 IP 100.70.100.1 > 100.70.100.3: ICMP echo request, id 33289, seq 768, length 36
10:09:19.381701 IP 100.70.100.3 > 100.70.100.1: ICMP echo reply, id 33289, seq 7 68, length 36
10:09:20.384012 IP 100.70.100.1 > 100.70.100.3: ICMP echo request, id 33289, seq 1024, length 36
10:09:20.384046 IP 100.70.100.3 > 100.70.100.1: ICMP echo reply, id 33289, seq 1 024, length 36
10:09:21.386589 IP 100.70.100.1 > 100.70.100.3: ICMP echo request, id 33289, seq 1280, length 36
10:09:21.386602 IP 100.70.100.3 > 100.70.100.1: ICMP echo reply, id 33289, seq 1 280, length 36



I assigned 100.70.100.3 to ether 3 and 100.70.100.4 to ether4 -

If I ping 100.70.100.4 and use tcpdump on ether3 - (as shown above) we still see a response.

Very odd
 
tcpdump -i eth3 icmp -vv
tcpdump: listening on eth3, link-type EN10MB (Ethernet), capture size 262144 bytes
10:11:16.868723 IP (tos 0x0, ttl 255, id 8668, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.1 > 100.70.100.3: ICMP echo request, id 33545, seq 0, length 36
10:11:16.868744 IP (tos 0x0, ttl 64, id 27494, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.3 > 100.70.100.1: ICMP echo reply, id 33545, seq 0, length 36
10:11:17.871216 IP (tos 0x0, ttl 255, id 8669, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.1 > 100.70.100.3: ICMP echo request, id 33545, seq 256, length 36
10:11:17.871224 IP (tos 0x0, ttl 64, id 27658, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.3 > 100.70.100.1: ICMP echo reply, id 33545, seq 256, length 36
10:11:18.873767 IP (tos 0x0, ttl 255, id 8670, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.1 > 100.70.100.3: ICMP echo request, id 33545, seq 512, length 36
10:11:18.873776 IP (tos 0x0, ttl 64, id 27820, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.3 > 100.70.100.1: ICMP echo reply, id 33545, seq 512, length 36
10:11:19.876291 IP (tos 0x0, ttl 255, id 8671, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.1 > 100.70.100.3: ICMP echo request, id 33545, seq 768, length 36
10:11:19.876299 IP (tos 0x0, ttl 64, id 28013, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.3 > 100.70.100.1: ICMP echo reply, id 33545, seq 768, length 36
10:11:20.878863 IP (tos 0x0, ttl 255, id 8672, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.1 > 100.70.100.3: ICMP echo request, id 33545, seq 1024, length 36
10:11:20.878874 IP (tos 0x0, ttl 64, id 28071, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.3 > 100.70.100.1: ICMP echo reply, id 33545, seq 1024, length 36
10:11:24.562682 IP (tos 0x0, ttl 255, id 57313, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.1 > 100.70.100.4: ICMP echo request, id 33545, seq 1280, length 36
10:11:24.562723 IP (tos 0x0, ttl 64, id 49580, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.4 > 100.70.100.1: ICMP echo reply, id 33545, seq 1280, length 36
10:11:25.555020 IP (tos 0x0, ttl 255, id 57314, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.1 > 100.70.100.4: ICMP echo request, id 33545, seq 1536, length 36
10:11:25.555029 IP (tos 0x0, ttl 64, id 49694, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.4 > 100.70.100.1: ICMP echo reply, id 33545, seq 1536, length 36
10:11:26.557522 IP (tos 0x0, ttl 255, id 57315, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.1 > 100.70.100.4: ICMP echo request, id 33545, seq 1792, length 36
10:11:26.557529 IP (tos 0x0, ttl 64, id 49897, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.4 > 100.70.100.1: ICMP echo reply, id 33545, seq 1792, length 36
10:11:27.560040 IP (tos 0x0, ttl 255, id 57316, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.1 > 100.70.100.4: ICMP echo request, id 33545, seq 2048, length 36
10:11:27.560050 IP (tos 0x0, ttl 64, id 50109, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.4 > 100.70.100.1: ICMP echo reply, id 33545, seq 2048, length 36
10:11:28.562569 IP (tos 0x0, ttl 255, id 57317, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.1 > 100.70.100.4: ICMP echo request, id 33545, seq 2304, length 36
10:11:28.562578 IP (tos 0x0, ttl 64, id 50337, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.4 > 100.70.100.1: ICMP echo reply, id 33545, seq 2304, length 36
10:11:29.555045 IP (tos 0x0, ttl 255, id 57318, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.1 > 100.70.100.4: ICMP echo request, id 33545, seq 2560, length 36
10:11:29.555055 IP (tos 0x0, ttl 64, id 50470, offset 0, flags [none], proto ICMP (1), length 56)
100.70.100.4 > 100.70.100.1: ICMP echo reply, id 33545, seq 2560, length 36
 
Since we rebuilt - figured this is worth adding as well:
root@edge1pve:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:1e:c9:4a:17:c0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:26634 errors:0 dropped:0 overruns:0 frame:0
TX packets:4216 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2879361 (2.7 MiB) TX bytes:2254645 (2.1 MiB)

eth3 Link encap:Ethernet HWaddr 90:e2:ba:1f:c3:ec
inet addr:100.70.100.3 Bcast:100.70.100.255 Mask:255.255.255.0
inet6 addr: fe80::92e2:baff:fe1f:c3ec/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:43 errors:0 dropped:0 overruns:0 frame:0
TX packets:39 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4608 (4.5 KiB) TX bytes:2674 (2.6 KiB)

eth4 Link encap:Ethernet HWaddr 90:e2:ba:1f:c3:ed
inet addr:100.70.100.4 Bcast:100.70.100.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:10 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:2778 (2.7 KiB) TX bytes:2778 (2.7 KiB)

vmbr0 Link encap:Ethernet HWaddr 00:1e:c9:4a:17:c0
inet addr:192.168.1.16 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::21e:c9ff:fe4a:17c0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:26681 errors:0 dropped:0 overruns:0 frame:0
TX packets:3354 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2389037 (2.2 MiB) TX bytes:2191636 (2.0 MiB)
 
OK ping is working but what is the link status on these interfaces ?

ip link show dev eth3
ip link show dev eth4
 
  • Like
Reactions: CloudHopping
ip link show dev eth3
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 90:e2:ba:1f:c3:ec brd ff:ff:ff:ff:ff:ff
root@edge1pve:~# ip link show dev eth4
6: eth4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
link/ether 90:e2:ba:1f:c3:ed brd ff:ff:ff:ff:ff:ff


Eth3 is plugged in Eth4 is not
 
tcpdump -i eth3 icmp -vv


100.70.100.4 > 100.70.100.1: ICMP echo reply, id 33545, seq 2304, length 36
10:11:29.555045 IP (tos 0x0, ttl 255, id 57318, offset 0, flags [none], proto ICMP (1), length 56)

why is that this interface sees the ICMP traffic address 100.70.100.4 when 100.70.100.4 is assigned to eth4 ? looks unexpected to me
 
manu said:
tcpdump -i eth3 icmp -vv


100.70.100.4 > 100.70.100.1: ICMP echo reply, id 33545, seq 2304, length 36
10:11:29.555045 IP (tos 0x0, ttl 255, id 57318, offset 0, flags [none], proto ICMP (1), length 56)

why is that this interface sees the ICMP traffic address 100.70.100.4 when 100.70.100.4 is assigned to eth4 ? looks unexpected to me
Click to expand...

I agree - it is VERY VERY ODD

it should not

Thus why I have been scratching my head.

Really really Odd
 
It may be caused by the fact that the two Ips are in the same subnet.

Normally to assign multiple IPs in the same subnet, you use network aliases and one single physical device.
 
We CANNOT duplicate this behavior with other OS versions - also remember - we were seeing this with 192.168.1.x as well as 100.70.100.x which are clearly in a different broadcast subnet

Very Very odd.

Has me scratching my head.

We own a Tier4 Datacenter and have actually held tutorials for customers to use Proxmox here in the States.
Love the system - been using since vs 1 and this is a first.

When the customer asked - I told them - are you sure your not drinking something ;-)

Now I am stuck wondering myself.

anyhow- just a weird behavior

I am going to grab a similar dell system and load to see if we can duplicate it - very odd.

thank you for sticking with me here - I know support can be a pain in the backside sometimes. . . I appreciate your help.
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back