Speeding up NetRain response on 5.1?

[David Cutter]

We have Tru64 5.1 with patch kit 006 installed.
And have two 100 BT FD (ee0 and ee1) cards configured for NetRain. NetRain is working fine except it takes too long to switch from a failed NIC to a good NIC. Initially, this time was ~40 seconds. I've tweeked the NR settings and the fastest I can get is 7 seconds. I need less then 1 second.

I did not see a patch for 5.1 for this. However, there is a patch for 5.1A and 5.1B and the release notes state that it is possible for less then 1 seconds response times for NR. I'd really not like to upgrade to 51A or 51B as this is more risky.

Here is the /etc/sysconfigtab entries for NR:
netrain:
nr_timeout_t=1
nr_timeout_o=4
nr_timeout_dead_interface=2

Any help appreciated.
Thanks,
Dave Cutter
585-279-1807
david.cutter@transport.alstom.com

[Michael Schulte zur Sur]

Hi,

from the manual about netrain, you can set all values to zero. What happens then? You also must take into consideration the time, the switch takes to notice the change.

greetings,

Michael

[Ralf Puchner]

niffd is the mechanism checking the adapter. So have a look into the man page of niffd. There are some timing values which can be changed via niffconfig.

[David Cutter]

Guys,
I've also tried the following:
- setting all the timeouts above to 0
- setting the timeouts above to something lower.
And the network does not respond at all.
Also I've tried to add the following to rc.config:

NIFFC_FLAGS="-d 0.5 -t 0.2 -o 1.1 -a ee0 ee1"

And it did not speed things up at all.
I tried the NIFFC_FLAGS with and without the settings in /etc/sysconfigtab.

Any other toughts.
FYI: I've checked google and there is an old post (groups) ~2001 from someone who had the same problem - but no response.
Thanks,
Dave

[Ralf Puchner]

dave,

have you configured the switch properly? Spanning tree etc. must be disabled for example....

Have you monitored the appearence of the niff events? Is the disconnect be seen faster than the failover process occures or what is the behaviour. Give us more details....

[David Cutter]

Onsite we have Cabletron/Enterasys SSR 8000.
No spanning tree enabled.

However, in the lab I have a dumb 100BT switch (3com).

I've tried the NR settings in both environments and reacts the same way.

Dave

[Ralf Puchner]

I repeat:
what does the evm log say? At what time does the niff event occure?

Btw. the NIFF_* variables defines if active or passive testing will be done. After some testings fail (the timespan between is the sum of failover) the interface will be switched over.

An easy test can be done by using the "ifconfig switch" command, check how long the failover time will be. If it is fast check the evm events of niff if you plug off the network cable. This timespan will give you the amount of time required to detect the outage.

[Michael BUTOW]

Hello Ralf,

I am trying to locate information on the NIFFC_FLAGS parameters that you describe.
Specifically, I am interested in a description of the "active" testing.
I found an example in the niffd(8) manual page, using the -a option, but the manual page for niffconfig does not mention anything about such "active" testing.

As this would be potentially a very useful mode for us, I'd like to ask if you have any further pointers...

Best regards,
Michael

[Ralf Puchner]

Hi Michael,

you need the following entries within /etc/rc.config:

NIFFD="Yes"
NIFFC_FLAGS="-a ee0"

have a look into the man-pages of niffd, niffconfig explaining more parameters for the timing intervalls.

[Michael BUTOW]

Hello Ralf,

I have looked at the documentation (man pages, Tru64 manuals etc) but could not find any description of "active" and "passive" testing.

The reason this caught my interest is because I believe that NetRAIN monitors only passively (looking at the receive counters) as long as it thinks the interface is "GREEN" (operating normally).

What I was hoping for was to find an option which would make NetRAIN monitor actively even when it thinks the interface is ok.
Potential benefit would be quicker detection of failure...

Regards,
Michael

[Al Licause]

The last description of the NetRAIN algorithm for failure detection was to compare the number of packets sent successfully with the number of packets sent with failures. If the number of packets sent with failure exceeds that of the number of packets sent w/o errors, then a failure state is declared and a failover is initiated if and only if the standby interface is determined to be in working order.

If you look at man sys_attrs_netrain, you will see a number of settable parameters. The nr_timeout_o has a minimum value of 1.1 seconds. This is the total time necessary to declare an interface dead. If you factor in the other timers, I don't think you'll be able to get a failover time of less than one second. At least in my experience, such a short failover time is not possible.

We have also tcpdumped a NetRAIN interface while forcing a failover and found that no data is lost even when we have fairly long failover periods ( approaching 10 seconds ).

Is there some reason you need such a fast failover time ?

Perhaps you should be looking at LAG (Link Aggregation). With LAG, all interfaces are active and any failures should not be noticed.

[Al Licause]

Let me correct my last statement.....I meant to say, the last description I had of the failover algorithm was as described.

[Mr. N. Baarse]

Good old FDDI, we are looking for replacement with the same specifications as FDDI. In Radar envirements 10 seconds is a long way flying......(after 250 ms data is discarded) So no Netrain for us I assume.

Has somebody a good advise? (bonding is to slow too)
Nick

[Al Licause]

I suspect NetRAIN, bonding and other similar technologies were developed with the average system/application in mind in which small amounts of delay in sending or receiving data are tolerable.

But in your case, where you need realtime updates, you're probably looking at a need for a completely redundant parallel feed such that switch over is almost if not instantaneous. Such a technology probably does exist but I am not aware of any standard software or hardware that provides such a solution for the general purpose consumer.

It may have to be built for your installation.