| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 762.1 | | STAR::PARRIS | CI,DSSI,SCSI,FDDI:Any port in a StorME | Thu Oct 29 1992 11:00 | 3 |
| Sounds like VAXcluster multicasts may be being filtered. VAXcluster protocol
type is 60-07; the multicast address is a function of the VAXcluster group
number, in the form of AB-00-04-01-xx-xx.
|
| 762.2 | Filter is not the issue here | BRAT::BUKOWSKI | | Thu Oct 29 1992 12:45 | 23 |
| re: -1
I work with Donna (.0). It is definetly not filtering. I understand
the different types of filtering inclusionary vrs. exclusionary,
manual mode, default sap type, default snap type, default ethernet
type, static entries, and the forward and filter maps. This has
happened to us in two separate cases (two different FDDI rings), and
has only happened when we converted our backbones to FDDI. I have
a feeling that the TRT is too long in comparison to average Ethernet
access time on the backbone that we used to have. Granted, we shouldn't
be boot LAVC's across bridges, but due to distance limitations, we are
stuck with this scenario for now.
I also just got wind that some VS2000's that used to boot via
inforservers across bridges are also timing out.
Should I change TTRT to the lowest allowable value?
BTW: our rings each have approximately 10 Bridge 610's connected, and
no systems at this point. The issues we are talking about are
all inter-ring related and not crossing between rings.
Mike
|
| 762.3 | | KONING::KONING | Paul Koning, A-13683 | Thu Oct 29 1992 13:12 | 13 |
| I VERY much doubt it's TTRT. For one thing, the default is 8 ms, which is
quite short (and only twice the minimum). Second, TTRT has no effect on
delay unless the FDDI is very highly loaded. (At 50% load, latency is about
1 ms independent of TTRT.)
Finally, usual higher layer protocols have timeouts measured in multiples of
a whole second, so all these time values are several orders of magnitude less
than those. Certainly that's true for MOP, and I'm pretty sure it's true
for SCA as well.
Do you have any datascope data?
paul
|
| 762.4 | Here comes the LAN analyzer | BRAT::BUKOWSKI | | Thu Oct 29 1992 13:54 | 15 |
|
Ok, so modifying the ring parameters probably will not help. I guess
I should try your suggestion for the next step (connect my Lan
analyzer). This may take a few days, as the problem folks have been
moved to other segments or locations in the buildings, so I have to
set up a duplicate scenario.
Is there anything out there that can approximately compare latency of
FDDI vrs. a Ethernet segment. I know that I am trying to compare apples
with oranges, but I would feel warm and fuzzy if I knew that 40 FDDI
stations on a ring backbone would have the same or quicker response
than 35 bridge 100's/200's on an Ethernet backbone.
Thanks,
Mike
|
| 762.5 | | KONING::KONING | Paul Koning, A-13683 | Thu Oct 29 1992 19:11 | 7 |
| At 50% load, the latency of FDDI and Ethernet are both about 1 ms.
(This is one useful simulation result, which was used to evaluate what we
had to do about the "7 bridge rule". Since the anwer was 1 ms either way,
the 7 bridge rule remains in effect for both types.)
paul
|
| 762.6 | 60-07 was filtered | BRAT::BUKOWSKI | | Mon Nov 02 1992 13:58 | 6 |
| We found the problem. We had overlooked a 60-07 filter on a 10/100
bridge in path to the boot node. It's a long story as to how we misled
ourselves, and I feel like a heel, but mistakes do happen. Thanks for
the input.
Mike
|