| Title: | DEChub/HUBwatch/PROBEwatch CONFERENCE |
| Notice: | Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7 |
| Moderator: | NETCAD::COLELLA DT |
| Created: | Wed Nov 13 1991 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4455 |
| Total number of notes: | 16761 |
Hello, one of our big customers is in the process of final testing a project. The have an FDDI RING consisting of about 100 ALpha Systems. They use a DECHUB900 (FW:V4.1.0) with a DECswitch900EF (FW:V1.5.2) (In fact the use about 70 HUB900's) The DECswitch is configured on the FDDI side in manual Mode so that the customer has to enter all the addresses of the stations on the FDDI Ring. On the Ethernet side they use Learning Mode. This config works fine as long as the traffic on the FDDI is "moderate" However the customer has an application running on the systems on the FDDI Ring, that, when started creates a lot of RSH Sessions and FTP sessions from various systems on the FDDI to other Systems on the FDDI. This produces a very high Traffic rate on the FDDI Ring. Unfortunately the DECswitch900EF does not isolate this traffic from the Ethernet side, and according to the customer packets with source and Destination address of FDDI stations show up on the Ethernet side effectively taking up all the bandwith on the Ethernet which results in the Ethernet being unusable for the time the application running on the FDDI Nodes is producing the high traffic rate on FDDI. In contrast if they use Learning mode on the FDDI side (of the switch) the ground network load is a little higher but the problem with the switch not isolating FDDI traffic from the Ethernet side does not occur. The customer requires to run the FDDI side in manual mode. Another effect happens to the forwarding database of the switch. before the "High Traffic situtation" the forwarding Database is rather small while after the "High Traffic situtaion" the forwarding Database is grown and contains entries that are "inactive" How can that happen given the setup of the switch and what is the meaning of an entry in the forwarding database of inactive ? From this story I have a few questions: Are there any problems similar to this already known, or fixed in FW V1.7.0 ? Is this a new problem ? Is it nonsense what the customer is doing/told me ?? Thanks for any /all answers OTTO
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 4246.1 | Doesn't sound like a true flooding situation.... | NETCAD::BATTERSBY | Tue Mar 04 1997 09:47 | 16 | |
Well, my first reaction to reading the description in the base
note, is that the customer is maybe over-reacting, and trying
to overly "micro-manage" what should be seen as a natural behavior.
"Inactive" addresses in the forwarding database will age out and
dissapear in short time. On the traffic level changing and addresses
coming from the FDDI side and being seen on the Ethernet ports, this
can be resolved with filtering, and also understanding whether these
source & destination addresses are unicast packets or multicast in
nature. If they are multicast, then enabling and tweaking the value
of rate-limiting may help ease whatever bandwidth loss may be occuring
on the Ethernet ports. I'm not sure I understand why the customer
absolutely needs the FDDI side in manual mode. I've forwarded the
base note to a couple of people who may be able to offer additional
suggestions.
Bob
| |||||
| 4246.2 | Aren't networks fun? | CGOS01::DMARLOWE | Have you been HUBbed lately? | Tue Mar 04 1997 11:50 | 13 |
100 Alpha's on a single FDDI ring and no GIGAswitch/FDDI?? Your
customer is much braver than you think. 8^)
You need to find out much more as to what systems are talking to what
systems and how. Also are any applications sending out data from the
Alpha's to users via multicast? Is a satutared FDDI ring, Alpha to
Alpha traffic, keeping the users from getting onto the ring?
Get V.1.7.0 on the EF switches and use MCM to show the packet stats
(RMON) for the 6 ethernets. It may offer some clues as to what is
happening.
dave
| |||||
| 4246.3 | NETCAD::HOPPE | Tue Mar 04 1997 14:01 | 42 | ||
I believe all of the questions in the previous replies need to be
answered. I'd also like to add some comments and questions in this
discussion.
My first question, which I believe Bob also asked, is
what is the customer trying to accomplish by putting the
FDDI port in manual mode?
Putting a port, say "port X", in manual mode does the following:
- disables learning on port X.
- filters all packets on port X who's SA is not
management-specified as allowed on port X.
- filters packets destined to port X who's DA
is not management-specified as allowed to go
to port X.
So, the intention of manual mode is a security feature. In this
case, it sounds like the customer wants to insure that any unauthorized
node on the FDDI ring is not allowed to communicate with nodes on the
ethernet ports. Also, nodes on the ethernet ports are not allowed
to communicate with unauthorized nodes on the FDDI port. Realize that
this does not protect against unauthorized nodes on the ethernet ports.
With that said, it sounds like there are nodes on the FDDI ring
who's MAC address has not been management defined in the
switch database. Remember, learning has been disabled on the FDDI
port if it's been placed in manual mode. So, if a node who's MAC
address has been management-specified on the FDDI port sends a packet
to another node on the FDDI ring who's address has NOT been
mgmt-specified, the packet will be flooded by the switch because
the SA is allowed and the DA is unknown and cannot be dynamically
learned.
So, the customer needs to make sure that EVERY MAC address that
resides on the FDDI ring is mgmt-specified in the switch's
forwarding database. Otherwise, pkts destined to the unspecified
addresses will be flooded by the switches.
Hope this helps!
Chris
| |||||
| 4246.4 | PRIVAT::OTTO | getting better all the time | Wed Mar 05 1997 04:58 | 12 | |
Thanks for the answers so far I will further digg into what the customer is doing. Also I will clearify exactly what type of packets show up on the ethernet side that shouldn't. I will also convince the customer to upgrade the DECswitch900EF to FW V1.7.0. A correction to my base note: They have only about 30 ALPHA Systems on that Ring and that Ring is indeed connected to a GIGAswitch. OTTO | |||||