Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[PGNd]

I've got a DGS-1210-24 switch.

It's assigned IP/mask on a mgmt-subnet: 10.90.90.90/24

All my LAN IPs are in 172.28.19.0/24

My desktop's a Linux box, with both subnets assigned

Code: [Select]

ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
3: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 18:d6:c7:01:19:3c brd ff:ff:ff:ff:ff:ff
    inet 172.28.19.7/24 brd 172.28.19.255 scope global enp2s0
       valid_lft forever preferred_lft forever
    inet 10.90.90.7/24 brd 10.90.90.255 scope global enp2s0
       valid_lft forever preferred_lft forever
    inet6 fe80::1ad6:c7ff:fe02:614a/64 scope link
       valid_lft forever preferred_lft forever

My routes are

Code: [Select]

ip route list
default via 172.28.19.100 dev enp2s0
10.90.90.0/24 dev enp2s0 proto kernel scope link src 10.90.90.7
172.28.19.0/24 dev enp2s0 proto kernel scope link src 172.28.19.7

I can ping from my desktop to the switch,

Code: [Select]

ping -c1 10.90.90.90
PING 10.90.90.90 (10.90.90.90) 56(84) bytes of data.
64 bytes from 10.90.90.90: icmp_seq=1 ttl=64 time=8.51 ms

--- 10.90.90.90 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 8.518/8.518/8.518/0.000 ms

but telnet to the WebUI is refused

Code: [Select]

telnet 10.90.90.90 80
Trying 10.90.90.90...
telnet: connect to address 10.90.90.90: Connection refused

and I'm unable to access the UI via browser.

I've ensured that NO acls on the DLINK are defined/active.

If I disable my desktop's primary IP, and place it ONLY in the 10.90.90.0/24 segment, then BOTH telnet and WebUI browser access work.

This is also reproducible with Windows7 clients -- dual IPs, no access.  single IP, access is granted.

And, no such problem with other-branded switches' webUIs.

What's preventing the access/response to the DLINK by multiIP clients?

[PacketTracer]

Hi,

from a network perspective there is no reason why the access from a multi IP client is blocked. Maybe the switch has some internal policy that prevents access to port 80\tcp (listening at its management interface) from ethernet ports that map two different IP addresses (10.90.90.7 and 172.18.19.7) to the same MAC address (18:d6:c7:01:19:3c). But of course this is a pure speculation ...

But why not change the switch's management address to an address that fits your network (say 172.18.19.254/24 if this address is still available)?

If this is unwanted because you want to prevent all network clients but your Linux desktop (=Switch Admin) from getting network access to the management interface, you could configure the following:

Remove the IP address configuration 172.18.19.7/24 from your Linux desktop's interface enp2s0 (leaving the other IP address 10.90.90.7/24 alone at that interface).

Leave the switch's management address configuration as is, add a new VLAN x <> 1 (say VLAN 2) and set all switchports except the one for your Linux desktop to be untagged members of VLAN 2 (and set their PVID to 2). Only for the port, your Linux desktop is connected to, you would configure the following:

Leave its predefined untagged membership of VLAN 1 and its PVID=1 setting as is (VLAN 1 is the VLAN, the switch management interface is connected to per default) and set it in addition to be a tagged member of VLAN 2 (the network 172.28.19.0/24). Create a subinterface enp2s0.2 for your Linux desktop's Ethernet NIC (enp2s0), and configure it to sent/receive frames to be tagged with VID 2. Finally assign the IP address 172.18.19.7/24 to subinterface enp2s0.2.

The effect is that you change your multi IP client (two IP networks on the same physical Ethernet link - not very nice for IPv4 while being normal for IPv6 e.g. a global prefix and the link local prefix fe80::/64 coexisting on the same IPv6 network interface ...) to a multihomed client (one IP network on the main (physical) Ethernet and the other IP network on the "logical" Ethernet defined by the subinterface - so you return to the usual network model with one IP network per (logical) Ethernet). And it's only your Linux desktop that can access the switch's management interface via VLAN 1 (that the switch assigns the untagged frames from/to your Linux desktop's main interface enp2s0), while you can participate in the standard network communication of network 172.18.19.0/24 via the subinterface enp2s0.2 (which the switch assignes to VLAN 2 due to the explicit frame tagging with VID 2).

In case your Linux desktop isn't available, as a fallback any other PC can be plugged to the special switch port that is normally connected to your Linux desktop. Configuring that PC's interface with an address out of 10.90.90.0/24 (other than 10.90.90.90) allows it to access the switch's management interface, but it can't participate in standard network communication of network 172.18.19.0/24 (if this were wanted, you would have to create a subinterface on that PC again as described above. For a Windows PC you would need a VLAN capable NIC driver from the NIC's vendor, because Windows client OS's lack VLAN support for NICs - this feature is only available for Windows server OS's with HyperV-Role activated).

PT

[PGNd]

from a network perspective there is no reason why the access from a multi IP client is blocked.

It appears there is ... but the problem's not use of multiple IPs.

Rather it's DLink's inability to cope with ECN (Explicit Congestion Notification) bit set on the connecting client.

Investigation with tcpdump showed RST/ACK in the desktop telnet session, with "Flags [SEW]" getting set; The "E" here refers to ECN.

ECN's only effective when supported by *both* transaction endpoints.

Bit of digging online found a this hint:

"Rather than responding properly or ignoring the bits, some outdated or buggy network equipment drop packets which have ECN bits set. (note these tests were performed in 2002)"

, and several reports of DGS-2016's failing to correctly implement ECN per rfc3168 (Sep 2001), even with latest firmware (2013).

Connectivity to the DLink's admin interface is immediately restored with

 

Code: [Select]

echo 0 > /proc/sys/net/ipv4/tcp_ecn
; Setting added to systcl.conf makes it persistent.

[PacketTracer]

So, your observation of a failing TCP connection to the switch's management interface only in case of a multi IP client configuration was either misleading or your client only had set ECN if configured with 2 IP addresses?

[TheDreamer]

Wow, this is insane.... I already don't have much hair...

But, I've been working on getting a DGS-1210-20 setup, had initially, put it in a little corner of my precious public IPv4 address space, but planned to move it and my other switches into their own private subnet. (10.10.10.0/24)

But, each time I made the switch, I couldn't access it anymore.  Most of the other websmart switches didn't have this problem.

But, apparently, its a feature to use ECN on virtual interfaces?  But, not additional interfaces.  On macos....

I had on my desktop's Ethernet interface set to a 198.x.x.x by DHCP, with an "Ethernet 2" for 10.90.90.99, so I could talk to the D-Link in factory state, and an "Ethernet 3" for 192.168.0.73, to work with the other vendor that uses 192.168.0.1 as its factory IP.  And, yet another for 10.10.10.0/24....  But, had decided for some reason July 3rd would be a good day to move out of vlan1 (since the other vendor switches are hard set on having vlan1 as its management vlan.  Had thought it would only take a couple of hours in the morning....

But, once I switched to my desktop in its native vlan, and virtual interfaces for various tagged vlans, including vlan1.  I couldn't reach the D-Link anymore.

At first I thought I had gotten something wrong with whether I had vlan1 tagged or untagged somewhere (and did find a switch where I had forgotten to change PVID on all the ports from 1, even though vlan1 wasn't on most of the ports.  But, that didn't affect my access to the other vendor switches...just made vlan1 a very noisy place when I got wireshark hooked into it.

I did notice my attempts to connect had ECN for some, while others didn't.  It seemed more like it was doing too many parallel connections causing the D-Link to retaliate. It was like every 3 or 4 connections was killed, eventually causing the browser to say its too busy or unreachable.  Though refreshing would cause random parts of the page to show up, before the browser replaced the page with its own to make me stop asking it to try to get enough.  I got furtherest with firefox, but turning off safeguard din't help.

And, then I spotted this message....

Anyways on macos

# sysctl net.inet.tcp.ecn_initiate_out=0
net.inet.tcp.ecn_initiate_out: 2 -> 0

is what cleared up that problem.  Wonder what I'll do with the USB ethernet adapter I bought....had thought there was some weird conversion problem with accessing vlan1 tagged vs untagged.

Oh well...  guess I'll have to find something else to blow up to end my 4th of July.

The Dreamer.