Score:0

Limiting hosts on a network

jp flag

I am in need of some networking advice and hopefully some of you will be able to help me. My network is shown in this block diagram: Network The ethernet switches are from Microchip, model KSZ9897, which is a managed layer 2 switch. The switch has multiple features, for example it supports IEEE 802.1X (port-based authentication and Access Control List (ACL) filtering) and IEEE 802.1Q (VLAN). All hosts are Windows 10 PCs. I need the following:

  • Hosts 1A, 1B and 1C must have the same fixed IP address (this is due to an initialization process, where hosts 2A, 2B and 2C not yet know if they are located in Unit A, Unit B or Unit C. This information is communicated from host 1, which is why I need Hosts 1A, 1B and 1C to have the same IP address, in order for Host 2 to know where to send the identification request)
  • Host 1A can communicate with Host 2A and no other host
  • Host 2A can communicate with all hosts except Host 1B and Host 1C
  • Host 1B can communicate with Host 2B and no other host
  • Host 2B can communicate with all hosts except Host 1A and Host 1C
  • Host 1C can communicate with Host 2C and no other host
  • Host 2C can communicate with all hosts except Host 1A and Host 1B

Right now all the hosts are on the same subnet, let's say 192.168.1.X, subnet mask 255.255.255.0. My first idea was to give hosts 1A, 1B and 1C an IP address on another subnet, say 192.168.2.1, and give hosts 2A, 2B and 2C an alias IP address on that same subnet. This way Hosts 2 will be able to communicate on both subnets. However, this will not work, as e.g. Host 2A will be able to communicate with both 1B and 1C. This will cause IP dublicate addresses on the same subnet. But placing Host 1A, Host 1B and Host 1C on three different subnets is also an issue, because of the identification issue outlined in the first point in the list. It seems to me like a chicken and egg problem, but hopefully I am missing something that can remedy the problem, maybe VLANs, access control or something else.

Davidw avatar
in flag
This is basically what VLAN's are for. But you will need a router and configure it as "router on a stick".
Lunde avatar
jp flag
This is a viable solution, but if possible, I would like to omit a router. Can you think of a way to restrict traffic on the same subnet? E.g. from one switch port to another for a specific IP address? Like static routing, but for a switch. Not sure that´s even a thing. Maybe access control could help me.
Davidw avatar
in flag
Not without a layer three switch, if you're using IP addressing.
Davidw avatar
in flag
And ACL's depend on net masks, which also require routing.
Lunde avatar
jp flag
Ok, do you have an idea about what what my options are if I go down one layer in the OSI model, i.e. MAC addresses? Hosts 1A, 1B and 1C will have different MAC addresses.
Score:0
ru flag

Depending on what that switch actually supports for ACLs (can't find any manual), port-bound ACLs should do the trick - no VLANs or routing required. I'm assuming hosts are configured statically, without DHCP. The syntax likely varies but I hop you get the idea. Simply apply the ACL to all ports on all switches. Alternatively, applying the ACL to the default VLAN might also work.

  • hosts 1A-5A use IP addresses 192.168.1.1/24 - 192.168.1.5/24
  • hosts 1B-5B use IP addresses 192.168.1.11/24 - 192.168.1.15/24
  • hosts 1C-5C use IP addresses 192.168.1.21/24 - 192.168.1.25/24
  • hosts 1D-5D use IP addresses 192.168.1.31/24 - 192.168.1.35/24

ACL:

1000 permit ip 192.168.1.1/32 192.168.1.2/32
1010 deny ip 192.168.1.2/32 192.168.1.11/32
1020 deny ip 192.168.1.2/32 192.168.1.21/32
1030 permit ip 192.168.1.2/32 any
1040 permit ip 192.168.1.11/32 192.168.1.12/32
1050 deny ip 192.168.1.12/32 192.168.1.1/32
1060 deny ip 192.168.1.12/32 192.168.1.21/32
1070 permit ip 192.168.1.12/32 any
1080 permit ip 192.168.1.21/32 192.168.1.22/32
1090 deny 192.168.1.22/32 192.168.1.1/32
1100 deny 192.168.1.22/32 192.168.1.11/32
1110 permit 192.168.1.22/32 any

Note that there's an implied deny any any rule at the end of the ACL, so if you don't explicitly permit something it's denied. You need to permit both directions of a communication - ACLs are stateless. Rules are evaluated on a first fit basis from top to bottom, so if a previous deny matches, a subsequent permit isn't used.

If the switch doesn't accept the /32 (no wildcard bits) you need to use 0.0.0.0 instead. The wildcard bits have no direct relation to the subnet mask. Instead, they define bits that are ignored while matching. 192.168.1.2/31 or 192.168.1.2 0.0.0.1 matches 192.168.1.2 and 192.168.1.3. 192. 192.168.1.3 0.0.0.2 matches 192.168.1.1 and 192.168.1.3.

Lunde avatar
jp flag
This is a good solution, but only “in steady state”. You are right in assuming that no DHCP is used, but due to the identification issue outlined in my first bullet point, Host 2A, 2B and 2C are unaware in which unit they are placed until they can request this info from host 1. So assigning the IPs as you suggest, is not an option. But my problem would be solved if the switch could be configured to only forward packets from a specific IP address to a specific port. Then I could configure hosts 1A, 1B and 1C on e.g. 192.168.2.1 and give hosts 2A, 2B and 2C an alias IP of 192.168.2.2.
Lunde avatar
jp flag
The idea being that if switch port 1 forwards packets from 192.168.2.1 to port 2 and no other ports, this would not result in IP copy conflicts. The switch would also be set up to forward packets from 192.168.2.2 on port 2 to port 1 exclusively. In this manner the 192.168.2.X subnet on each unit will be isolated. But this requires the switch to be able to forward traffic based on a “static routing table” specifyingthe IPs and which ports to forward to. Is this possible to do? All configuration of the KSZ9897 are done on register level via SPI interface from a processor.
Lunde avatar
jp flag
I do not think that a manual is available for the switch, but the registers are available in the data sheet: https://ww1.microchip.com/downloads/en/DeviceDoc/KSZ9897R-Data-Sheet-DS00002330D.pdf
Zac67 avatar
ru flag
Sorry, hardware and software development are not on-topic here, see the [help].
Lunde avatar
jp flag
Ok, sorry about that, I wasn’t aware of that.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.