| Title: | GIGAswitch |
| Notice: | GIGAswitch/FDDI Jan 97 BL3.1 914.0 documentation 412.1 ion 412.1 |
| Moderator: | NPSS::MDLYONS |
| Created: | Wed Jul 29 1992 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 995 |
| Total number of notes: | 4519 |
I have put this entry already in November (#842.3) - with no answer.
A customer sees quite a lot of ifInDiscards as well as
dot1dBasePortDelayExceededDiscards on a FGL-2 linecard.
The linecard connects to a FDDI-ring.
The are 2 filters enabled for the port with the discards: IP and ARP
The number of Discards is about 200000 per month, about 5000-15000 a day.
All other error counters show nothing special ( no receive errors, no transmit
discards, no errors in the Station and Port summary ).
Meanwhile I have updated the firmware to SCP 3.09, FGL 3.0e (not yet 3.1).
The symptoms are still the same.
The customer does not see or report real problems with his gigaswitch, but he
is wondering whether the behavior of having Discards is normal.
My opinion is: on bridges we should NOT have too much discards.
The following appendix shows the Interface-, Bridge- and Flooding-Counters
on the Gigaswitch:
1. Interface Counters:
----------------------
SNMP gigasw01 Interface 4
AT 13-FEB-1997 10:33:04 All Attributes
ifIndex = 4
ifSpeed = 100000000
ifOperStatus = up
ifLastChange = 57219471
ifOutQLen = 0
ifInOctets = 3984325215
ifInUcastPkts = 848649226
ifInNUcastPkts = 50375771
ifInDiscards = 212737 !!!!!!!!!
ifInErrors = 0
ifInUnknownProtos = 137
ifOutOctets = 3691917807
ifOutUcastPkts = 420272249
ifOutNUcastPkts = 63783271
ifOutDiscards = 27
ifOutErrors = 0
CounterCreationTime = 18-JAN-1997 18:34:20.21
ifDescr = "FGL-2"
ifType = fddi
ifMtu = 4608
ifPhysAddress = %X08002BB4C88B
ifAdminStatus = up
ifSpecific = "1.3.6.1.2.1.10.15"
2. Bridge Counters:
----------------------
SNMP gigasw01 dot1dBridge dot1dBase dot1dBasePortTable 4
AT 13-FEB-1997 10:32:13 All Attributes
dot1dBasePort = 4
CounterCreationTime = 18-JAN-1997 18:34:19.62
dot1dBasePortDelayExceededDiscards = 212599 !!!!!!!!!
dot1dBasePortMtuExceededDiscards = 0
dot1dBasePortIfIndex = 4
dot1dBasePortCircuit = "0.0.0"
3. Flooding Counters:
----------------------
SNMP gigasw01 dec ema sysobjid bridges gigaswitch gigaversion1 gigaBridge
flooding floodTable (4,1)
AT 13-FEB-1997 10:39:27 All Attributes
floodTable_Index = ( 4,
1 )
floodQuotaQualifier = 4
floodQuotaClass = 1
floodBytesSent = 780068571
floodPacketsSent = 2615057
floodGeezers = 195899 !!!!!!!!!!
floodLosers = 0
floodHogs = 0
floodSinglePathDiscards = 207
floodPacketsFiltered = 316189
floodPacketsPurged = 0
floodBytesPurged = 0
floodLocalCopyPacketsDelivered = 0
floodLocalCopyPacketsDiscarded = 0
SNMP gigasw01 dec ema sysobjid bridges gigaswitch gigaversion1 gigaBridge
flooding floodTable (4,2)
AT 13-FEB-1997 10:39:27 All Attributes
floodTable_Index = ( 4,
2 )
floodQuotaQualifier = 4
floodQuotaClass = 2
floodBytesSent = -820918308
floodPacketsSent = 49812613
floodGeezers = 16700
floodLosers = 0
floodHogs = 0
floodSinglePathDiscards = 0
floodPacketsFiltered = 1150
floodPacketsPurged = 0
floodBytesPurged = 0
floodLocalCopyPacketsDelivered = 16494928
floodLocalCopyPacketsDiscarded = 0
SNMP gigasw01 dec ema sysobjid bridges gigaswitch gigaversion1 gigaBridge
flooding floodTable (4,3)
AT 13-FEB-1997 10:39:28 All Attributes
floodTable_Index = ( 4,
3 )
floodQuotaQualifier = 4
floodQuotaClass = 3
floodBytesSent = 0
floodPacketsSent = 0
floodGeezers = 0
floodLosers = 0
floodHogs = 0
floodSinglePathDiscards = 0
floodPacketsFiltered = 0
floodPacketsPurged = 0
floodBytesPurged = 0
floodLocalCopyPacketsDelivered = 0
floodLocalCopyPacketsDiscarded = 0
SNMP gigasw01 dec ema sysobjid bridges gigaswitch gigaversion1 gigaBridge
flooding floodTable (4,4)
AT 13-FEB-1997 10:39:28 All Attributes
floodTable_Index = ( 4,
4 )
floodQuotaQualifier = 4
floodQuotaClass = 4
floodBytesSent = -1841175583
floodPacketsSent = 14103768
floodGeezers = 0
floodLosers = 0
floodHogs = 0
floodSinglePathDiscards = 0
floodPacketsFiltered = 192
floodPacketsPurged = 0
floodBytesPurged = 0
floodLocalCopyPacketsDelivered = 0
floodLocalCopyPacketsDiscarded = 0
4. Gigaswitch Slot Usage:
-------------------------
SNMP gigasw01 dec ema sysobjid bridges gigaswitch gigaversion1 gigaBox slot
slotTable 1
AT 13-FEB-1997 10:43:02 All Attributes
slotIndex = 1
slotCardStatus = notPresent
slotCardType = other
slotCardHwRev = "Not apply
"
slotCardFwRev = "Not apply
"
SNMP gigasw01 dec ema sysobjid bridges gigaswitch gigaversion1 gigaBox slot
slotTable 2
AT 13-FEB-1997 10:43:02 All Attributes
slotIndex = 2
slotCardStatus = powerUp
slotCardType = fgl2
slotCardHwRev = "F
"
slotCardFwRev = "3.0e
"
SNMP gigasw01 dec ema sysobjid bridges gigaswitch gigaversion1 gigaBox slot
slotTable 3
AT 13-FEB-1997 10:43:02 All Attributes
slotIndex = 3
slotCardStatus = notPresent
slotCardType = other
slotCardHwRev = "Not apply
"
slotCardFwRev = "Not apply
"
SNMP gigasw01 dec ema sysobjid bridges gigaswitch gigaversion1 gigaBox slot
slotTable 4
AT 13-FEB-1997 10:43:02 All Attributes
slotIndex = 4
slotCardStatus = powerUp
slotCardType = switchEngine
slotCardHwRev = "H
"
slotCardFwRev = " 3.09 DL1.00 BB2.00
"
SNMP gigasw01 dec ema sysobjid bridges gigaswitch gigaversion1 gigaBox slot
slotTable 5
AT 13-FEB-1997 10:43:03 All Attributes
slotIndex = 5
slotCardStatus = notPresent
slotCardType = other
slotCardHwRev = "Not apply
"
slotCardFwRev = "Not apply
"
SNMP gigasw01 dec ema sysobjid bridges gigaswitch gigaversion1 gigaBox slot
slotTable 6
AT 13-FEB-1997 10:43:03 All Attributes
slotIndex = 6
slotCardStatus = powerUp
slotCardType = fgl4
slotCardHwRev = "A
"
slotCardFwRev = "3.0e
"
SNMP gigasw01 dec ema sysobjid bridges gigaswitch gigaversion1 gigaBox slot
slotTable 7
AT 13-FEB-1997 10:43:03 All Attributes
slotIndex = 7
slotCardStatus = powerUp
slotCardType = clockCard
slotCardHwRev = "D
"
slotCardFwRev = " 3.00
"
SNMP gigasw01 dec ema sysobjid bridges gigaswitch gigaversion1 gigaBox slot
slotTable 8
AT 13-FEB-1997 10:43:03 All Attributes
slotIndex = 8
slotCardStatus = powerUp
slotCardType = cbs36
slotCardHwRev = "Not available
"
slotCardFwRev = "Not apply
"
SNMP gigasw01 dec ema sysobjid bridges gigaswitch gigaversion1 gigaBox slot
slotTable 9
AT 13-FEB-1997 10:43:04 All Attributes
slotIndex = 9
slotCardStatus = notPresent
slotCardType = other
slotCardHwRev = "Not apply
"
slotCardFwRev = "Not apply
"
SNMP gigasw01 dec ema sysobjid bridges gigaswitch gigaversion1 gigaBox slot
slotTable 10
AT 13-FEB-1997 10:43:04 All Attributes
slotIndex = 10
slotCardStatus = notPresent
slotCardType = other
slotCardHwRev = "Not apply
"
slotCardFwRev = "Not apply
"
SNMP gigasw01 dec ema sysobjid bridges gigaswitch gigaversion1 gigaBox slot
slotTable 11
AT 13-FEB-1997 10:43:04 All Attributes
slotIndex = 11
slotCardStatus = notPresent
slotCardType = other
slotCardHwRev = "Not apply
"
slotCardFwRev = "Not apply
"
SNMP gigasw01 dec ema sysobjid bridges gigaswitch gigaversion1 gigaBox slot
slotTable 12
AT 13-FEB-1997 10:43:04 All Attributes
slotIndex = 12
slotCardStatus = notPresent
slotCardType = other
slotCardHwRev = "Not apply
"
slotCardFwRev = "Not apply
"
SNMP gigasw01 dec ema sysobjid bridges gigaswitch gigaversion1 gigaBox slot
slotTable 13
AT 13-FEB-1997 10:43:05 All Attributes
slotIndex = 13
slotCardStatus = notPresent
slotCardType = other
slotCardHwRev = "Not apply
"
slotCardFwRev = "Not apply
"
SNMP gigasw01 dec ema sysobjid bridges gigaswitch gigaversion1 gigaBox slot
slotTable 14
AT 13-FEB-1997 10:43:05 All Attributes
slotIndex = 14
slotCardStatus = notPresent
slotCardType = other
slotCardHwRev = "Not apply
"
slotCardFwRev = "Not apply
"
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 926.1 | Perhaps lots of unecessary flooding? | NPSS::RLEBLANC | Thu Feb 13 1997 12:13 | 40 | |
ifindiscards = in_bound_timestamped_expired + in_queue_overflow.
in_bound_timestamped_expired = packets which are good but
did not get processed in time (2 seconds). Counter
does not include filtered packets
in_queue_ovfl = the number of otherwise good packets
which were not received due to
insufficient resources.
dot1dBasePortDelayExceededDiscards
The number of frames discarded by this port due
to excessive transit delay through the bridge. It
is incremented by both transparent and source
route bridges.
floodGeezers
This object is the count of packets that could not be
flooded because they had remained in the SCP or in the
inbound linecard too long.
The floodGeezers makes me suspicious that some application/node is
doing alot of flooding. Maybe the receiver node is perhaps not transmitting
its own source address and not getting learn by the GIGAswitch?
However this is just a guess, not knowing exactly is attached to the
GIGAswitch.
I would like to see the results of dvt test #117 and perhaps a dump of
error logs. Also in the OBM menu under #12 (extend Options) there
somewhere is a counters and staticistics menu which in turn is a
flooding counter display. I would also like to see the results of
that too.
| |||||
| 926.2 | NPSS::MDLYONS | Michael D. Lyons DTN 226-6943 | Thu Feb 13 1997 13:04 | 4 | |
Gee, I could swear that 842.4 was a reply including an answer to
your note.
MDL
| |||||
| 926.3 | NPSS::MDLYONS | Michael D. Lyons DTN 226-6943 | Thu Feb 13 1997 13:12 | 6 | |
...and I will combine this notes string in another day or two with the
preexisting topic once again, since it replicates an existing topic.
This time I'll rename the topic so it may be more clear.
Michael D. Lyons
GIGAswitch moderator
| |||||
| 926.4 | NPSS::MDLYONS | Michael D. Lyons DTN 226-6943 | Thu Feb 13 1997 13:24 | 67 | |
When I have time, I will look at your numbers, but I will summarize
in general for you:
ifInDiscards are counts of frame the GIGAswitch/FDDI system
discarded when the frame itself was valid.
There are a variety of reasons this can happen.
Most of the time, it's because the user is sending more data to one
or more output ports than that port can handle, causing contention,
which causes the input queues to back up and eventually overflow.
Some of the time, it's becaused by flooding discards. Flooding
discards typically happen because:
1) You're exceeding the default rate limits
2) The DA has aged out and you're flooding unicast traffic causing
too much flooding traffic for the SCP to handle
3) You're simply sending too much multicast
Some of the time, it's caused by bursts of back-to-back frames
overrunning the FGL buffers. This is unlikely in most networks.
This is a very complex topic and there are not simple analytical
tools to examine the situation. The SNMP MIB objects do not convey all
the necessary information.
...from something I wrote up for a customer problem:
To diagnose perceived "performance problems", you need to capture the
discards and traffic loads over a regular basis, I.E. the following SNMP
objects need to be monitored and correlated to problems:
For all interfaces:
ifInDiscards
ifOutDiscards
ifInOctets
ifInUcastPkts
ifInNUcastPkts
ifOutOctets
ifOutUcastPkts
ifOutNUcastPkts
For all interfaces and quota classes:
floodBytesSent
floodPacketsSent
floodGeezers
floodLosers
floodHogs
floodSinglePathDiscards
(not indexed):
xacInDiscardUnkownDAUCast [sic]
xacInDiscardMulticast
xacInDiscardIPForwading [sic]
....after this information is collected, most likely it will be desireable to
run DVT monitor tests 114 and 117 on each port and attempt to correlate the
types of discards with the observed problems.
MDL
| |||||
| 926.5 | Overload ? | ISAR50::SCHUSTER | Karl Schuster @MUC OMS Munich Germany | Fri Feb 14 1997 08:04 | 26 |
Thanks for your replies. As I mentioned, the customer does not see real problems with his Gigaswitches. Concerning your proposals to do the tests (dvt 114, 117), I hope to have the chance to do it within the next 2 - 3 weeks. The customer has 2 gigaswitches, with both gigaswitches connected to the same Ring. On the linecards of both gigaswitches there are the Discards. So I think, we can exclude a HW-problem with components in one of the gigaswitches. Other FDDI-Components on the same Ring (900EF-Switches) do not see any errors on the Ring. If too heavy traffic, or too many multicasts, is the problem, this is something we can not prevent, because this is given by the network applications we cannot influence. Perhaps the gigaswitch is really overloaded with flooding of multicasts, because of insufficient bufferspace in the linecards or in the SCP ? As soon I have results from the tests I will post them here. Regards, Karl | |||||
| 926.6 | More information is needed | NPSS::RLEBLANC | Fri Feb 14 1997 11:53 | 8 | |
>>>Perhaps the gigaswitch is really overloaded with flooding of multicasts,
>>>because of insufficient bufferspace in the linecards or in the SCP ?
Instead of guessing, perhaps you should collect all the information we asked
and analyze the network with a FDDI lan analyzer so you can verify what is really
happening.
| |||||
| 926.7 | NPSS::MDLYONS | Michael D. Lyons DTN 226-6943 | Fri Feb 14 1997 13:02 | 20 | |
ifInDiscards are not indicative of hardware problems.
The most likely explanation (as I've mentioned before) is that they
are sending too much data. Although it's quite conceiveable that they
are sending a reasonable amount of data, it is *more likely* that they
are sending more than the output port is capable of dealing with. I.E.
They are sending more than 100 mbps (less actually) over a duration
long enough to exhaust the input buffers which are queued up for the
port seeing contention. ...and that's ignoring the multicast/flooding
scenario, which is also likely.
For example: there is nothing to stop ten ports from all trying to
send 50 mbps to a single port at the same time. What does that add up
to? 10*50mbps = 500 mbps - that isn't going to work, and it isn't a
GIGAswitch/FDDI system buffer problem. Infinite sized input buffers
would be nice, but not exactly realistic. Any non-infinite buffers
will be exhausted, it's just a question of how long it would take.
MDL
| |||||
| 926.8 | NPSS::MDLYONS | Michael D. Lyons DTN 226-6943 | Fri Feb 14 1997 18:24 | 8 | |
...having looked at the counters in .0 now, as Rene says, port 4 is
tossing flooded frames - mostly unknown DAs - (quota class 1).
It would be helpful to see the other MIB variables mentioned in the
other notes to see if any of the other ports are seeing contention on
the output side.
MDL
| |||||
| 926.9 | inDiscards no have disappeared | ISAR50::SCHUSTER | Karl Schuster @MUC OMS Munich Germany | Wed Mar 26 1997 10:05 | 21 |
Meanwhile several things have changed in the environmenmt.
We could not find out what was the reason, but after all the changes
no more inDiscards can be seen !!
What we changed:
1. We installed firmware release 3.1 on all Gigaswitch modules.
2. On a AlphaVMS cluster we made adjustments to the MTU size
(niscs_max_pktsz 4500 --> 1498). The reason we did this, was a cluster
connectivity problem (connection lost) between Servers that were on the
Gigaswitch and Clients that were on ethernet segments behind a ALANTEC
FDDI-Ethernet switch. We saw a problem with FDDI-frames not having the
Piority field in the FC-field set to 0. We could not find it out for
100% that the frames came from the Alantecs. But after using ethernet
maximum packetsize the problem with the cluster "connection lost"
disappeared.
Karl
| |||||