Do you have a question? Post it now! No Registration Necessary
Subject
- Posted on
- pozzugno
March 30, 2017, 10:55 pm

I think this is little OT here, because the question is mostly network orie
nted. However my nodes will be Linux embedded boxes and some solutions coul
d be very low-level, so I think many of you could help me in some way.
I have N Ethernet hosts based on embedded Linux. Each one features an Ether
net interface dedicated to the final user that could change the IP address
configuration. On that interface a Web server responds. All the nodes will
be configured on the same subnet and conected to a switch.
Now I need to make an "internal" communication among those hosts. With the
work "internal" I mean the user should ignore the presence of this communic
ation and relevant details (it should not be necessarily invisible to a tra
ffic monitoring tools).
For example, when the user changes the IP address of host 1, the new IP add
ress shouldn't be configured in host 2 too and the internal communication b
etween host 1 and 2 should continue without interruption.
I thought about three possible solution, but I'm not a netowrk guru.
The first is to add other logical IP addresses (aliases) used for internal
communication only. Those IP addresses will be hardcoded and never changed
by whoever. The user will be able to configure only the main IP address for
each host. Is this could work with a simple switch? I think yes, because t
he switch looks at the MAC address and doesn't see the IP addresses.
Anyway I don't know what negative effects could be when the same broadcast
domain is shared by two different subnet (internal, with hardcoded and fixe
d IP addresses, and external, configurable by the user as he wants).
Another solution is to implement the internal communication staying at leve
l 2, so avoiding IP addresses, but using only MAC addresses. I could invent
a proprietary layer 2 protocol. This could avoid any conflict with IP addr
esses customized by the user, but there are some disadvantages.
How host 1 could know the MAC address of host 2 for internal communication?
It could be written during delivery of the system, but replacing one host
on the field could be difficult (the MAC address of replaced host should be
changed on the other nodes). I could invent a proprietary broadcast ARP pr
otocol (what is MAC address of **host 2**).
In order to avoid the issue of knowing the MAC address of other hosts for i
nternal communication, I could invent a L2 protocol made by all broadcast f
rames, considering it will a low-bandwidth protocol.
The third solution is using VLANs, but I don't know if they can be useful i
n my case. Indeed, I couldn't use static (port-based) VLAN, because I will
have two VLANs on the same switch ports. Anyway I should have two IP addres
sed on each host (as in the first solution).
Other suggestions?
nted. However my nodes will be Linux embedded boxes and some solutions coul
d be very low-level, so I think many of you could help me in some way.
I have N Ethernet hosts based on embedded Linux. Each one features an Ether
net interface dedicated to the final user that could change the IP address
configuration. On that interface a Web server responds. All the nodes will
be configured on the same subnet and conected to a switch.
Now I need to make an "internal" communication among those hosts. With the
work "internal" I mean the user should ignore the presence of this communic
ation and relevant details (it should not be necessarily invisible to a tra
ffic monitoring tools).
For example, when the user changes the IP address of host 1, the new IP add
ress shouldn't be configured in host 2 too and the internal communication b
etween host 1 and 2 should continue without interruption.
I thought about three possible solution, but I'm not a netowrk guru.
The first is to add other logical IP addresses (aliases) used for internal
communication only. Those IP addresses will be hardcoded and never changed
by whoever. The user will be able to configure only the main IP address for
each host. Is this could work with a simple switch? I think yes, because t
he switch looks at the MAC address and doesn't see the IP addresses.
Anyway I don't know what negative effects could be when the same broadcast
domain is shared by two different subnet (internal, with hardcoded and fixe
d IP addresses, and external, configurable by the user as he wants).
Another solution is to implement the internal communication staying at leve
l 2, so avoiding IP addresses, but using only MAC addresses. I could invent
a proprietary layer 2 protocol. This could avoid any conflict with IP addr
esses customized by the user, but there are some disadvantages.
How host 1 could know the MAC address of host 2 for internal communication?
It could be written during delivery of the system, but replacing one host
on the field could be difficult (the MAC address of replaced host should be
changed on the other nodes). I could invent a proprietary broadcast ARP pr
otocol (what is MAC address of **host 2**).
In order to avoid the issue of knowing the MAC address of other hosts for i
nternal communication, I could invent a L2 protocol made by all broadcast f
rames, considering it will a low-bandwidth protocol.
The third solution is using VLANs, but I don't know if they can be useful i
n my case. Indeed, I couldn't use static (port-based) VLAN, because I will
have two VLANs on the same switch ports. Anyway I should have two IP addres
sed on each host (as in the first solution).
Other suggestions?

Re: [OT] Embedded Linux hosts sharing Ethernet broadcast domains with two IP subnets

[Cross-posting to news:comp.protocols.tcp-ip, as the issue at
hand seems more on-topic there. Apologies for some over-quoting
to preserve context.]
> I think this is little OT here, because the question is mostly
> network oriented. However my nodes will be Linux embedded boxes and
> some solutions could be very low-level, so I think many of you could
> help me in some way.
> I have N Ethernet hosts based on embedded Linux. Each one features
> an Ethernet interface dedicated to the final user that could change
> the IP address configuration. On that interface a Web server
> responds. All the nodes will be configured on the same subnet and
> conected to a switch.
> Now I need to make an "internal" communication among those hosts.
> With the work "internal" I mean the user should ignore the presence
> of this communication and relevant details (it should not be
> necessarily invisible to a traffic monitoring tools).
> For example, when the user changes the IP address of host 1, the new
> IP address shouldn't be configured in host 2 too and the internal
> communication between host 1 and 2 should continue without
> interruption.
> I thought about three possible solution, but I'm not a network guru.
> The first is to add other logical IP addresses (aliases) used for
> internal communication only. Those IP addresses will be hardcoded
> and never changed by whoever. The user will be able to configure
> only the main IP address for each host. Is this could work with a
> simple switch? I think yes, because the switch looks at the MAC
> address and doesn't see the IP addresses. Anyway I don't know what
> negative effects could be when the same broadcast domain is shared by
> two different subnet (internal, with hardcoded and fixed IP
> addresses, and external, configurable by the user as he wants).
There're none that I know of. The only trouble to watch out for
is the user (accidentally) configuring the "main" address that
matches the "internal" network.
> Another solution is to implement the internal communication staying
> at level 2, so avoiding IP addresses, but using only MAC addresses.
> I could invent a proprietary layer 2 protocol. This could avoid any
> conflict with IP addresses customized by the user, but there are some
> disadvantages.
JFYI, there're already MAC-based IPv6 "link-local" addresses --
which, unless you've configured your kernel differently, are
probably already available. Consider, for example:
$ ip addr list
...
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether D0:BA:98:76:54:32 brd ff:ff:ff:ff:ff:ff
...
inet6 fe80::D2BA:98ff:fe76:5432/64 scope link
valid_lft forever preferred_lft forever
...
$ ping6 -n -c 3 -- fe80::D2BA:98ff:fe76:5432%eno1 ; ## that is, local host
PING fe80::D2BA:98ff:fe76:5432%eno1(fe80::D2BA:98ff:fe76:5432%eno1) 56 data bytes
64 bytes from fe80::D2BA:98ff:fe76:5432%eno1: icmp_seq=1 ttl64% time=0.020 ms
...
3 packets transmitted, 3 received, 0% packet loss, time 2042ms
rtt min/avg/max/mdev = 0.020/0.026/0.030/0.006 ms
$
(Note that the exact interface to use -- eno1 in this case --
needs to be specified when referring to these addresses.)
> How host 1 could know the MAC address of host 2 for internal
> communication? It could be written during delivery of the system,
> but replacing one host on the field could be difficult (the MAC
> address of replaced host should be changed on the other nodes).
> I could invent a proprietary broadcast ARP protocol (what is MAC
> address of **host 2**). In order to avoid the issue of knowing the
> MAC address of other hosts for internal communication, I could invent
> a L2 protocol made by all broadcast frames, considering it will a
> low-bandwidth protocol.
There're already a number of "service discovery" protocols
available. You may want to check [1] and follow from there.
[1] http://en.wikipedia.org/wiki/Multicast_DNS
[...]
--
FSF associate member #7257 58F8 0F47 53F5 2EB2 F6A5 8916 3013 B6A0 230E 334A
FSF associate member #7257 58F8 0F47 53F5 2EB2 F6A5 8916 3013 B6A0 230E 334A

Re: [OT] Embedded Linux hosts sharing Ethernet broadcast domains with two IP subnets
snipped-for-privacy@gmail.com writes:

This method works very well and is easy to set up. You can set up eth0:1
with static address in your internal between-nodes address space and
eth0:0 with DHCP to provide the web UI.
Using layer 2 or VLANs is much more complicated, especially if you've
got limited network experience.
One interesting application for VLANs is that if you can use a PHY chip that
has integrated switch and VLAN support so that on the CPU you have only
one MII with VLANs and you route different VLANs to different ports on
the switch, effectively creating multiple separated ethernet interfaces
for an embedded system.

This method works very well and is easy to set up. You can set up eth0:1
with static address in your internal between-nodes address space and
eth0:0 with DHCP to provide the web UI.
Using layer 2 or VLANs is much more complicated, especially if you've
got limited network experience.
One interesting application for VLANs is that if you can use a PHY chip that
has integrated switch and VLAN support so that on the CPU you have only
one MII with VLANs and you route different VLANs to different ports on
the switch, effectively creating multiple separated ethernet interfaces
for an embedded system.
--
mikko
mikko

Re: [OT] Embedded Linux hosts sharing Ethernet broadcast domains with two IP subnets

You might get more details in comp.os.linux.networking.

That will work fine, as long as your "internal" network does not collide
with the users network addresses. Pick something in the 10.x.y.z range,
rather than 192.168.x.y. Also consider just using IPv6 here.
As you note the traffic will not be invisible to monitoring tools - it
is easy to hack into this traffic.

That would be theoretically possible, but a great deal of work. Don't
bother.

VLANs have a lot of uses, but in a case like this you would have to make
sure that the switches involved are at least VLAN aware, even if they
are not configured with specific VLAN setups. Standard cheap Ethernet
switches don't pass through packets with VLAN tags.

Your first suggestion is fine.

Re: [OT] Embedded Linux hosts sharing Ethernet broadcast domains with two IP subnets
On Thursday, March 30, 2017 at 3:55:55 PM UTC-7, snipped-for-privacy@gmail.com wrote:

iented. However my nodes will be Linux embedded boxes and some solutions co
uld be very low-level, so I think many of you could help me in some way.

ernet interface dedicated to the final user that could change the IP addres
s configuration. On that interface a Web server responds. All the nodes wil
l be configured on the same subnet and conected to a switch.

e work "internal" I mean the user should ignore the presence of this commun
ication and relevant details (it should not be necessarily invisible to a t
raffic monitoring tools).

ddress shouldn't be configured in host 2 too and the internal communication
between host 1 and 2 should continue without interruption.

l communication only. Those IP addresses will be hardcoded and never change
d by whoever. The user will be able to configure only the main IP address f
or each host. Is this could work with a simple switch? I think yes, because
the switch looks at the MAC address and doesn't see the IP addresses.

t domain is shared by two different subnet (internal, with hardcoded and fi
xed IP addresses, and external, configurable by the user as he wants).

vel 2, so avoiding IP addresses, but using only MAC addresses. I could inve
nt a proprietary layer 2 protocol. This could avoid any conflict with IP ad
dresses customized by the user, but there are some disadvantages.

n? It could be written during delivery of the system, but replacing one hos
t on the field could be difficult (the MAC address of replaced host should
be changed on the other nodes). I could invent a proprietary broadcast ARP
protocol (what is MAC address of **host 2**).

internal communication, I could invent a L2 protocol made by all broadcast
frames, considering it will a low-bandwidth protocol.

in my case. Indeed, I couldn't use static (port-based) VLAN, because I wil
l have two VLANs on the same switch ports. Anyway I should have two IP addr
essed on each host (as in the first solution).

I think what you need is a VPN (merging two subnets), and not to reinvent t
he wheel.

iented. However my nodes will be Linux embedded boxes and some solutions co
uld be very low-level, so I think many of you could help me in some way.

ernet interface dedicated to the final user that could change the IP addres
s configuration. On that interface a Web server responds. All the nodes wil
l be configured on the same subnet and conected to a switch.

e work "internal" I mean the user should ignore the presence of this commun
ication and relevant details (it should not be necessarily invisible to a t
raffic monitoring tools).

ddress shouldn't be configured in host 2 too and the internal communication
between host 1 and 2 should continue without interruption.

l communication only. Those IP addresses will be hardcoded and never change
d by whoever. The user will be able to configure only the main IP address f
or each host. Is this could work with a simple switch? I think yes, because
the switch looks at the MAC address and doesn't see the IP addresses.

t domain is shared by two different subnet (internal, with hardcoded and fi
xed IP addresses, and external, configurable by the user as he wants).

vel 2, so avoiding IP addresses, but using only MAC addresses. I could inve
nt a proprietary layer 2 protocol. This could avoid any conflict with IP ad
dresses customized by the user, but there are some disadvantages.

n? It could be written during delivery of the system, but replacing one hos
t on the field could be difficult (the MAC address of replaced host should
be changed on the other nodes). I could invent a proprietary broadcast ARP
protocol (what is MAC address of **host 2**).

internal communication, I could invent a L2 protocol made by all broadcast
frames, considering it will a low-bandwidth protocol.

in my case. Indeed, I couldn't use static (port-based) VLAN, because I wil
l have two VLANs on the same switch ports. Anyway I should have two IP addr
essed on each host (as in the first solution).

I think what you need is a VPN (merging two subnets), and not to reinvent t
he wheel.
Site Timeline
- » Buildroot configuration for Ethernet and WiFi support on Orange Pi Zero
- — Next thread in » Embedded Programming
-
- » IWOMP 2017 - 13th International Workshop on OpenMP
- — Previous thread in » Embedded Programming
-
- » Is there such thing as a 4 bit CRC ?
- — Newest thread in » Embedded Programming
-
- » OT A modest proposal
- — The site's Newest Thread. Posted in » Electronics Design
-
- » Low Noise Direct Coupled Preamp
- — The site's Last Updated Thread. Posted in » Electronics Design
-