TCP/IP Routing question

[Mike Scott]

I was wondering if something is possible (I can't see why it would not
be).

We have a site that services several models of Ethernet-based
instruments.
One line has an IP address of 192.100.100.x/24, with the last octet
factory-programmed based on the device serial number. At the customer
site, these devices are connected to a private network that exists only
within the lab. The other products use standard DHCP and can use any
subnet.

We are going to build a VLAN to isolate the instruments from the rest of
the corporate LAN and what I was thinking is to designate the LAN on a
network of 192.100.100.0/23 and hand out DHCP addresses from
192.100.101.0 - 192.100.101-254 with a 255.255.254.0 netmask and a
default route of 192.100.100.1 (this would also be used on the static
devices). This would ensure that the DHCP addresses would never
duplicate a static device that may happen to share the LAN.

I realize that the /24 netmask on the static devices would not allow
them to communicate with anything in the DHCP scope, but that is not a
requirement.

Does this sound reasonable, kind of binding two essentially Class-C
networks into sort of a "supernet"?
My main concern is that DHCP servers may balk about the "illegal" 23-bit
Class-C netmask.

- Mike Scott

[Arun Khan]

On Wed, May 18, 2016 at 5:30 PM, Mike Scott <lu...@pyewacket.org> wrote:
> I was wondering if something is possible (I can't see why it would not
> be).
>
>

When in doubt, do a small Proof of Concept - the best way to learn is
to try it out hands on.

> We have a site that services several models of Ethernet-based
> instruments.
> One line has an IP address of 192.100.100.x/24, with the last octet
> factory-programmed based on the device serial number. At the customer
> site, these devices are connected to a private network that exists only
> within the lab. The other products use standard DHCP and can use any
> subnet.
>
>
> We are going to build a VLAN to isolate the instruments from the rest of
> the corporate LAN and what I was thinking is to designate the LAN on a
> network of 192.100.100.0/23 and hand out DHCP addresses from
> 192.100.101.0 - 192.100.101-254 with a 255.255.254.0 netmask and a
> default route of 192.100.100.1 (this would also be used on the static
> devices).

sipcalc is a great tool to work out these numbers (see below)

$ sipcalc 192.100.100.0/23
-[ipv4 : 192.100.100.0/23] - 0

[CIDR]
Host address - 192.100.100.0
Host address (decimal) - 3227804672
Host address (hex) - C0646400
Network address - 192.100.100.0
Network mask - 255.255.254.0
Network mask (bits) - 23
Network mask (hex) - FFFFFE00
Broadcast address - 192.100.101.255
Cisco wildcard - 0.0.1.255
Addresses in network - 512
Network range - 192.100.100.0 - 192.100.101.255
Usable range - 192.100.100.1 - 192.100.101.254

> This would ensure that the DHCP addresses would never
> duplicate a static device that may happen to share the LAN.

In which LAN segment does the DHCP server reside? Assuming you will
define only one VLAN 192.100.100.0/23 segment you should be OK

>
>
> I realize that the /24 netmask on the static devices would not allow
> them to communicate with anything in the DHCP scope, but that is not a
> requirement.
>

Good.

> Does this sound reasonable, kind of binding two essentially Class-C
> networks into sort of a "supernet"?

Absolutely,

> My main concern is that DHCP servers may balk about the "illegal" 23-bit
> Class-C netmask.
>

CIDR notation is standard and ISC DHCP server accepts it. Built in
DHCP servers in enterprise grade managed switches should also accept
them.

-- Arun Khan

[Matthew Kurowski]

A few quick comments:

* these are quick comments and not an official statement/opinion/policy of my firm or partners. We can't be held liable as this isn't a paid engagement but some quick, casual data for consideration.

* 192.100.100/24 isn't a good RFC 1918 address. Bad practice but I realize it may be difficult to change. However, you can always NAT that segment and build the new segment/VLAN with proper addressing and have the NAT range land in RFC1918 space.

* Modbus? Unicast or multicast?

* yes, you can supernet via CIDR but that's in the same L2 domain, not a distinct VLAN. Sure you'll still have gateway access but you also don't really separate anything

In general, you want to isolate those components. If you create a second VLAN, just have the same server (even if an intermediary switch) process the address disbursement - you may need directed broadcasts or forwarding via unicast (helper functionality). Then you have a small fault domain, protection from unwanted multicast snooping/membership, have protection on the device net from other systems, and minimize unwanted interrupts on the devices themselves. It's relatively easy to interfere with dcs components esp those with hard coded mfg passwords. Always best to protect. If you don't have a switch capable of IGMP, you may be able to work around that. Some firms go with dual homed hosts on control system managers such that they don't need to worry routing mcast.

From a firewalling perspective or L3 or L2 ACLs, the true separation is still best. 

YMMV though depending on gear/code. That guides things considerably.

HTH

 

- Mike Scott

--
You received this message because you are subscribed to the Google Groups "Linux Users of Northern Illinois" group.
To unsubscribe from this group and stop receiving emails from it, send an email to luni-chicago...@googlegroups.com.
To post to this group, send email to luni-c...@googlegroups.com.
Visit this group at https://groups.google.com/group/luni-chicago.
For more options, visit https://groups.google.com/d/optout.

--

Matthew Kurowski
Mobile: 847.361.1880
VoIP: 224.552.0052

www.linkedin.com/in/mkurowski

[Arun Khan]

On Thu, May 19, 2016 at 12:31 PM, Matthew Kurowski <mat...@kurowski.org> wrote:
>
> * 192.100.100/24 isn't a good RFC 1918 address. Bad practice but I realize
> it may be difficult to change. However, you can always NAT that segment and
> build the new segment/VLAN with proper addressing and have the NAT range
> land in RFC1918 space.

Good point! The 192.100.100.0/24 belongs to the DoD NIC! The first
octet 192. kind of fogged my vision.
Superneting a public domain rout-able IP range @ /23 is not a good idea.

-- Arun Khan

[Mike Scott]

Yikes. The 192 blinded me as well. We don't want to mess with them!
I am confirming with the technician now.
Hoping I wrote it down wrote and it is 192.168.100.x

- Mike Scott

-- Arun Khan

--