| When IP switching is released, the GIGAswitch will have a restriction
that there may be only one IP address in any IP address range, which
means in practice that there will be only one GIGAswitch IP address
allowed in any subnet. This is partly because it makes things easier
for us, but also because having multiple addresses in the same subnet
seems like a strange way to do business.
Does anyone know of any customers who use multiple addresses in the
same subnet, and is so, could you please post a quick note explaining
why they do that?
If this is a major problem, we will have to change things to allow
multiple addresses per subnet, as is now done.
Thanks for any input,
Stu
|
| To clarify what I said in my previous note, here's an example:
Currently, you can (through OBM) specify the following interfaces:
Port IP address Net mask
1.1 16.24.96.1 255.255.255.0
1.2 16.24.96.2 255.255.255.0
This means that for IP packets being sent by the GIGAswitch to
addresses 16.24.96.0 to 16.24.96.255, it will use source IP address
16.24.96.1 if the packet is going out port 1.1 but source IP address
16.24.96.2 if it is going out port 1.2. Also, the GIGAswitch will
respond to SNMP, ICMP, etc. packets addressed to 16.24.96.1 only if
those packets were received on port 1.1 and will, similarly, respond to
such packets addressed to 16.24.96.2 only if those packets were
received on port 1.2.
In the future, we will make it impossible to have two different IP
addresses in the same subnet, so that you could specify these
interfaces:
Port IP address Net mask
1.1 16.24.96.1 255.255.255.0
1.2 16.24.96.1 255.255.255.0
or these interfaces:
Port IP address Net mask
1.1 16.24.96.2 255.255.255.0
1.2 16.24.96.2 255.255.255.0
... but you won't be able to mix the two.
|
| I made a mistake in my "clarification" (which Michael kindly pointed
out). In my first example, it turns out that either IP address would
have been accepted on either port. An IP address is accepted on any
port for which an interface is defined provided that IP address is
defined as the interface on SOME port.
My note, corrected, reads as follows:
Currently, you can (through OBM) specify the following interfaces:
Port IP address Net mask
1.1 16.24.96.1 255.255.255.0
1.2 16.24.96.2 255.255.255.0
This means that for IP packets being sent by the GIGAswitch to
addresses 16.24.96.0 to 16.24.96.255, it will use source IP address
16.24.96.1 if the packet is going out port 1.1 but source IP address
16.24.96.2 if it is going out port 1.2. Also, the GIGAswitch will
respond to SNMP, ICMP, etc. packets addressed to 16.24.96.1 or
16.24.96.2 only if those packets were received on port 1.1 or 1.2
In the future, we will make it impossible to have two different IP
addresses in the same subnet, so that you could specify these
interfaces:
Port IP address Net mask
1.1 16.24.96.1 255.255.255.0
1.2 16.24.96.1 255.255.255.0
or these interfaces:
Port IP address Net mask
1.1 16.24.96.2 255.255.255.0
1.2 16.24.96.2 255.255.255.0
... but you won't be able to mix the two.
|
| > Does anyone know of any customers who use multiple addresses in the
> same subnet, and is so, could you please post a quick note explaining
> why they do that?
I think I've set multiple IP addresses in the same subnet because I couldn't
figure out why there was an option to set different addresses on interfaces
that had to be in the same network. There wasn't anything in the docs that
explained how to chose addresses (just the mechanics of how to set them).
Since there was a reason for assigning each MAC of a bridge a different
address (and the reason escapes me), I figured that a similar reason required
that each interface have a unique IP address (although I only set a couple
because I was lazy).
There are lots of reasons for end systems to have multiple IP addresses
per interface, one example being the UCX cluster alias and the more
general ASE and now Trucluster service failover ARP hack.
Just to be sure that you understand that, this is the deal.
You have two or more nodes that provide access to a service of some sort
(ie., NFS) which is tied to one or more disks. This group of disks is
bound statically to one system, but when that system fails, the other
system detects the failure and grabs the disk and the IP address associated
with the disks and service, mounts the disks, restarts the service, and
then ARPs the IP address which results in most IP stacks replacing the
MAC address for that IP address, so that service resumes "transparently".
In the case of GS/FDDI, one might expect that 8 Tlasers might each be
connected to one of 8 ports on a GS/FDDI and then would offer collectively
several dozen services scattered among the nodes. The ports that the IP
addresses are bound should move "instantly" after an ARP from the system
that takes over an IP address from another system.
Note that CLIP (classical IP on ATM) precludes this hack.
There are some proposals that have the MAC address move as well when a
service fails over, but I don't believe that anyone expects that there would
be multiple MAC addresses per interface. This isn't easy with ATM, and
might be precluded as well.
If GS/FDDI and other frame switching systems support quick movement of
IP and MAC addresses from one port to another, then this will offer
capability that will not easily be matched with ATM, even if the people
working on ATM standards understood the utility and could overcome their
religious objections.
(Early Ethernet adapters allowed this, but then this was rejected as
non-standard, so some adapters precluded it, an so while its usually easy
to setup multiple Ethernet addresses on an Ethernet interface, this can't
be done in practice, for end systems. FDDI required that at least one MAC
address be constant, so it made sense to "correct" the error made for
Ethernet.)
(Of course, the reason for these hacks is to make up for deficiencies in
the protocols used so that features that are natural in DEC proprietary
protocols like ISO OSI and OpenVMS NISCS, LAT, and LAST, all of which
have been forward engineered by competitors. Forward engineering is when
you start from specs and develop an implementation, rather than starting
from an implementation and developing a spec.)
|
| Actually, my concern was limited to customers who might want/need to
give the GIGAswitch itself two different addresses in the same subnet.
The examples you discuss would only apply to endsystems, particularly
server and cluster endnodes, not a GIGAswitch.
|