T.R | Title | User | Personal Name | Date | Lines |
---|
359.1 | | SAAR::B_GOODWIN | Time is an illusion... | Tue Oct 08 1991 14:31 | 1 |
| Port A will be in a backup mode. Port B will be passing the data.
|
359.2 | DUAL HOMED CONCENTRATOR | RCOCER::MEAD | Can't think of anything clever yet... | Tue Oct 08 1991 14:57 | 7 |
| Hi,
Is the backup port continually checked to assure that it is available in the
case where port B goes away?
Thanks,
Ted
|
359.3 | | SAAR::B_GOODWIN | Time is an illusion... | Tue Oct 08 1991 15:23 | 1 |
| Yes, port A will become active if port B should fail.
|
359.4 | backup port is checked periodically | BAGELS::LEVY | | Tue Oct 08 1991 16:05 | 9 |
| re: .2
Yes. The backup port is periodically checked. This can be observed
externally as follows:
A port in the backup state will blink its PHY LED
red/green/red/green... If you disconnect the cable connected to this
port (to simulate a cable failure), the PHY LED will change to blinking
GREEN, i.e. waiting for a connection.
|
359.5 | Does it show with DECelms? | RCOCER::MEAD | Can't think of anything clever yet... | Fri Oct 11 1991 14:14 | 7 |
| Folks,
Assume PORT A is operational and PORT B is in standby. If PORT B goes down, is
in indicated via DECelms or any other mechanism other than looking at LEDs?
Thanks,
Ted
|
359.6 | Visible with DECelms | BAGELS::LEVY | | Mon Oct 14 1991 12:14 | 8 |
| Yes. "Physical Port State" changes from "WATCHING" to "WAITING." This
attribute is readable by all supported NMS's (DECelms, DECmcc ELM,
etc.).
Note that the situation described in .5 would never happen for a DEC
device, because a PHY B connection always takes precedence over a PHY
A connection in a dual homing configuration. (i.e. Port B would be
operational, and Port A would be in standby.)
|
359.7 | | KONING::KONING | Paul Koning, NI1D | Mon Oct 14 1991 12:35 | 7 |
| Actually, the standard requires that precedence rule, it's not DEC specific.
The standby link has a data integrity test (Link Confidence Test) running
on it, so if the link quality becomes unacceptable, you'll see that via
management. (It does more than just detecting the presence of the cable!)
paul
|
359.8 | And receive automatic notification.... | BSS::C_OUIMETTE | Holographic Interference Repository | Mon Oct 14 1991 13:23 | 36 |
| And presumably, if you're running the ELMS poller, this state change
will generate an event message. Since your concern appears to be that
you want to receive notification that your "hot standby" link isn't
operational, you can hack a DCL script, like the following, so that
you're sent E-mail, or trigger other events. You could change the
search criteria to match the specific event # you're looking for.
(I'm sure that DECmcc's alarming capabilities make this easier.... I've
been able to remain blissfully ignorant of that platform, focusing on
MSU .... 8^)
chuck
$START:
$ elms format since 'time_stamp' to event.log
$ TIME = f$time()
$ time_stamp = F$EXTRACT(0,17,TIME)
$ FILE = F$SEARCH("SYS$LOGIN:EVENT.LOG")
$ IF FILE .EQS. "" THEN GOTO WAIT
$ sea event.log nsu_con /out=conalarm.txt /wind=10
$ if $STATUS .eqs. "%X00000001" then GOSUB CONALARM
$ sea event.log nsu_lb /out=lanalarm.txt /wind=10
$ if $STATUS .eqs. "%X00000001" then GOTO LANALARM
$ goto WAIT
$ CONALARM:
$ MAIL/SUBJ="ELMS CON ALARM" conalarm.txt holstn::c_ouimette
$ RETURN %X1
$ LANALARM:
$ MAIL/SUBJ="ELMS LAN ALARM" lanalarm.txt holstn::c_ouimette
$WAIT:
$ pu/keep=1 event.log
$ ren event.log event.sav
$ wait 00:02:00
$ goto START
$exit
|
359.9 | | SAAR::B_GOODWIN | Time is an illusion... | Mon Oct 14 1991 20:13 | 2 |
| Yes, But will the DECelms poller work with a DECBridge 6xx...
|
359.10 | Digital's HIP to the EMA thing! | BSS::C_OUIMETTE | Holographic Interference Repository | Tue Oct 15 1991 09:24 | 3 |
| Nope- but this scenario was for the dual-homed concentrator. As
you note, if one wants to talk to the DECBridge 6xx's, one has to get
hip to that DECmcc thang....
|