Conference 7.286::fddi

Hi All,
Some more info for the previous note we received today:


the DECconcetrator we are concerned with is :

echo.csi.forth.gr (147.52.128.230)

and on one of it's ports we have the DECbridge we are talking about is :

dia.csi.forth.gr	147.52.128.32

which is :

 2  charybde.csi.forth.gr (139.91.1.91)  2 ms  2 ms  3 ms
 3  skylla-charybde2.csi.forth.gr (139.91.240.94)  21 ms  11 ms  11 ms
 4  * dia.csi.forth.gr (147.52.128.32)  13 ms  12 ms

3 hops away from the Greek Internet gateway to Intern.networks.


as well as a SUN690 SAS server. :

calliope.csi.forth.gr (147.52.128.1)


now THE DEMO OF THE REMOTE MONITORING of the 3 devices of the
FDDI : a cisco (skylla) a NSC (venus) and the concstrator (echo)
will take place NEXT Tuesd/Weds at AVEIRO/PORTUGAL at CET .

please, if you can give us some information on why the
MIB II variables that count FDDI in/out octets are NOT counting
all FDDI traffic, SAY IT SO QUICKLY!
otherwize we HAVE to report that except the DEC devices, the rest
of equip. providers fully support MIBII , thus giving us the
ability to *partly* measure the ring utilization as well as the rest
of thinks we do measure via our phase1 TMN platforms.

The way the concentrator is supposed to work is exactly like an end station:
it counts traffic ADDRESSED TO IT.  Other traffic that's just passing through
is not counted.  You need a bridge to do that.

So if you see the counters on the concentrator reflect the traffic to that
concentrator (i.e., the SNMP packets to/from it, any PING traffic, etc.) then
it is working correctly.  Is that what you observed?  Obviously, if one of
the counters stays zero even though you're talking to the concentrator, that's
a bug.

	paul

    Regarding the 0 values -
    
    	The snmp agent on the DEFEB does not count the ifinoctets/ifoutoctets. 
     	I spoke with the maintainer of the firmware and it appears that there 
    	was a fear of overflowing the counters so those mib objects weren't 
    	implemented.  
    
    	The problem is we say that the DEFEB supports MIBII and I don't think 
    	that means we can pick and choose which objects to implement.  Its a 
    	bug and you should open a cld so it won't get lost.  
        
                                                                     
    
    
    

Actually, it's not a bug, it's a product restriction.  There isn't time to
do the byte counting.  

	paul

Hi all, 

what is follows are our reply to the customer and his comments
about this.Is true that we are not implement all of MIB II ?

thanks for the help

thanos

************************* Customer's reply **********************


Dear Thano/Dionysh,

thank you *very much* for the prompt and correct answer, we really appreciate
your help.

This is the way the concetrator should work anyway. I agree with you.

Do you happen though to have an explanation for the high value we get in :
ifInUnknownProtos in that same concetrator?  :

Fri Jan 21 14:09:33 1994 [ echo ] : Quick Dump: snmp-mibII.ifInput

KEY  ifIndex  ifInOctets  ifInUcastPkts  ifInNUcastPkts  ifInDiscards  ifInErrors  ifInUnknownProtos
1          1   483773413         749151         1043768             0           0            1723403                                                                                                                                               

And this closes the case with the concetrator.

I would like though to remind you that we are mainly interest in
the **DECbridge** (dia.csi.forth.gr) behaviour.

If your answer :

 "The DEFEB's ifinoctet/ifoutoctet counters are restricted from the factory in
  order to avoid overflows"

is the reason (or "excuse") for the 0 in ifInOctets :

Fri Jan 21 14:05:52 1994 [ dia ] : Quick Dump: snmp-mibII.ifInput

KEY  ifIndex  ifInOctets  ifInUcastPkts  ifInNUcastPkts  ifInDiscards  ifInErrors  ifInUnknownProtos        
1          1           0      124668630         1127716             0           0                  0                                                                     
2          2  3861779621       22794334            2433             4           0                  0                                                                     
3          3  4052117984      222175532          845271          2327      218826                  0                                                                     
4          4  1460383729        1609707           94905             0           0                  0                                                                     
Then, I'm sorry, I have to say that we the answer is "too litle too late" ;-)

We expect all products that their broshures state "SNMP MIB II support"
to do so and at least count Octets in ALL interfaces (and especially
the fiber ones that we buy at so high prices!)


best regards,
Stelios Sartzetakis             | Tel. : +30 81 221171, 229302, 229368
FORTHnet Manager                | Fax  : +30 81 229342, 229343
           	                | E-mail: [email protected]  
Foundation of Research           
and Technology - Hellas         
Institute of Computer Science    
P.O.Box 1385, Heraklio, Crete GR71110
_____________________________________



----- Begin Included Message -----

From [email protected]  Fri Jan 21 13:10:45 1994
Date: Fri, 21 Jan 94 12:09:49 MET
To: [email protected], [email protected], [email protected]
Cc: [email protected], [email protected]
Apparently-To: [email protected], [email protected], [email protected]
Subject: FDDI counters

Hi Stelios,

i escalated the problem to our network group and here is the answer
if you need more info/help please call me or call Mr. D.Mouzakis

thank you
best reagrds
Thanos Tsakalos
MCS/Tech. Support Unit Manager

****************************** *****************************************
From:	ATHINA::MOUZAKIS_D   21-JAN-1994 12:57:39.43
To:	ATHINA::TSAKALOS
CC:	
Subj:	FDDI problems

Dear Stelio

The way the concentrator  works is exactly like an end station:
it counts traffic ADDRESSED TO IT.  Other traffic that's just passing through
is not counted. 

So if you see the counters on the concentrator reflect the traffic to that
concentrator (i.e., the SNMP packets to/from it, any PING traffic, etc.) then
it is working correctly.  Is that what you observed? 

Thje DEFEB's ifinoctet/ifoutoctet counters are restricted from the factory in
order to avoid overflows

Dr. Dionysios Mouzakis
Communications & Networks 
Architect

   >      
   > Do you happen though to have an explanation for the high value we get in :
   > ifInUnknownProtos in that same concetrator?  :
   >      

	Seems high to me also but the DEFCN snmp agent increments 
	ifInUnknownProtos using this -

	If packet addressed to me then
	  If IP packet then
	   If <> UDP and <> ICMP then
		increment ifInUnknownProtos 

    

That's not right.

ifInUnknownProtos should count the number of packets with unrecognized
DATALINK protocol identification.  For example, an Appletalk packet addressed
to the concentrator would count this.

There is also ipInUnknownProtos, which counts the number of packets that
are IP but have an unrecognized IP Protocol field -- for example an EGP
packet sent to the concentrator.

Finally, there is the udpNoPorts couter, which counts the number of UDP packets
with an unrecognize UDP port number.

In the example you showed, the correct counter to increment is ipInUnknownProtos
and not ifInUnknownProtos.

	paul

    Hello
    
    the customer asks if we can bypass the problem of the 0 counts on the
    ifinoctets/ifoutoctets on the bridge 500. He even considers the idea to
    purchase the new FDDI to Ethernet bridge for the HUB 90 provided htat
    the MIB II is complete.
    
    Any ideas?
    
    Kind Regards
    Dennis
    

Are you interested in traffic forwarded, or traffic filtered?

The DECbridge 900 MX will accurately count forwarded traffic bytes, but it won't
count all the filtered traffic since some of it is done in hardware before
anything has a chance to see the packet length.

	paul

    Hello
    
    the major concern is for traffic forwarding. Thus  we can propose
    to the customer to use the bridge as an solution to the problem?
    
    Dennis
    

Yes, the 900 will do full counting for forwarded traffic.

I think it hasn't been announced quite yet; you might want to talk to the
product manager (Jane Brechlin) to confirm dates and availability.

	paul

    re .7
    
    I agree, I'm just the messenger.
    
    I forwarded this string to the firmware maintainer.
    

    re: .7
    
    Sorry Bill, I was looking at ipInUnknownProtos, not ifInUnknownProtos,
    must have gotten a little fuzzy eyed.
    
    As Paul corrected, ipInUnknownProtos is incremented if it's not UDP & 
    ICMP.
    
    

    
    
    Thenks to all of you 
    
    Regards
    Dennis