 |
» |
|
|
|
Ask the Wizard Questions
How to keep LAVC traffic on the FDDI?
The Question is:
I am helping with a 4 node cluster 2 alpha's (3000/400) and
2 vax's (4000/90). Each machine has 2 network interfaces
the built in ethernet interface and a turbo channel FDDI
interface. The 4 FDDI nodes are connected using an
FDDI concentrator and they are an isolated ring
(ie no connection to any other machines). The 4 ethernet
ports are connected using a hub which is also connected to
the buildings backbone.
DECNET is enabled on both of the lines (ie FDDI and ethernet)
My problem is this one of vaxes (call it sv1) tends to send
a large number of LAVC traffic to one of the Alpha's
(call it sv4) using the ethernet interface.
Using a packet sniffer I have observed that the traffic
seems to be one way (ie sv4 sends its data to sv1 using
the FDDI link) but sv1 seems to send data to sv4
using the ethernet link. Obviously I would like the nodes
to use the FDDI link for LAVC traffic. I have
checked the line and circuit counters and there does
not seem to be any high error rates or other things to
indicate why it is using the ethernet interface.
When I do a show net on sv1 it
indicates that it is using the FDDI interface to talk
to sv4 so I do not understand why it is using the ethernet
inteface to send packets.
I have also set the cost of the FDDI circuit to less the
and ethernet so it should force the traffic to the FDDI
ring.
Any suggestions on what to set up so the sv1 will
use FDDI to talk to sv4.
The Answer is:
Modifying the DECnet cost values has no effect, as cluster traffic runs under
another completely different protocol called SCS, or actually the LAN variant
of SCS in this case, which is called NISCS.
By default, the cluster software enables the use of the NISCS protocol on all
LAN adapters it finds. About every 3 seconds, a Hello packet is multicast from
each LAN adapter. PEDRIVER checks the transit times of the multicast packets,
and remembers, for each remote node, which path had the lowest latency. It
then uses that "best" path for the next ~3-second interval as the path by which
to transmit packets to that remote node. In your case, the Ethernet path
is sometimes seen as having a lower latency, and thus gets used.
There are two ways to prevent NISCS traffic from taking the Ethernet path:
- Raise NISCS_MAX_PKTSZ (LRPSIZE for V5.5-2 and earlier) to a value
above what Ethernet can handle. The exact value varies by release
(see the VMScluster manual) but instead of being at around 1500 for
Ethernet, it can be raised as high as close to 4500 for FDDI.
Because when two nodes make an SCS connection, the maximum transfer
size is one of the parameters, if you raise the maximum packet size,
PEDRIVER will form a virtual circuit using only FDDI paths. It is
only if the last FDDI path between two nodes goes away that PEDRIVER
will fail over to using an Ethernet path, which it does by closing and
then immediately re-opening the virtual circuit with a smaller maximum
transfer size.
- Use the LAVC$STOP_BUS program from SYS$EXAMPLES: to completely turn off
use of the Ethernet adapters for the NISCS protocol. Unlike option
1 above, this prevents failover to the Ethernet in case of a failure
on the FDDI.
|
