[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::fddi

Title:FDDI - The Next Generation
Moderator:NETCAD::STEFANI
Created:Thu Apr 27 1989
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2259
Total number of notes:8590

1269.0. "DECbridge 620- Rate Limit Limits?" by UFP::HUTCHINSON (Hutch) Wed Mar 09 1994 12:56

 I have contacted the CSC and gone through the Vendor MIB elanext v2.7
 DEC Vendor MIB spec and V1.3 release notes attempting to answer some
 questions for a large DECbridge 620 customer. Unfortunately my
 DECbridge 620 is on loan or I would recreate and attempt to derive
 the answers to the remaining outstanding questions at my desk. I will
 greatly appreciate any insights anyone can provide regarding the following:

1) Can we rate limit the broadcast address as specified in the
   release notes?

2) Can rate limiting for a particular multicast or broadcast 
   address be limited to a specific port on the bridge?

3) Can ebrRateLimit be set to a number less than 100?


Situation Background Information:

"Rate limiting - Multicast and Broadcast frames forwarded by the
 bridge can be rate limited. ...."

We tried to rate limit the number of broadcast frames forwarded
by a DECbridge, but didn't have any success. For some reason the
bridge will not allow you to modify the ebrMultiPortStatus entry
for the broadcast address. When you initially query the bridge
for the ebrMultiPortStatus MIB info it returns the following
entries for the broadcast address:

     ebrMultiPortStatus_255.255.255.255.255.255.1   1
     ebrMultiPortStatus_255.255.255.255.255.255.2   1
     ebrMultiPortStatus_255.255.255.255.255.255.3   1
     ebrMultiPortStatus_255.255.255.255.255.255.4   1

I tried the following SNMP set command, to try to rate limit
the broadcast address on all interfaces:

     set ebrMultiPortStatus_255.255.255.255.255.255.0   7

This returns in the message box "The object has replied with a generic
error message".

I get the same error message if I try to rate limit the broadcast 
address on a particular port:

     set ebrMultiPortStatus_255.255.255.255.255.255.1   7

Returns in the message box "The object has replied with a generic 
error message".

If I try to remove the broadcast address entry by setting it to invalid 
I get the same error message as well:

     set ebrMultiPortStatus_255.255.255.255.255.255.0   6

Returns in the message box "The object has replied with a generic 
error message".

Now if I try to rate limit a multicast address it works:

     set ebrMultiPortStatus_1.255.255.255.255.255.1   7

Returns in the message box:
"The set operation completed successfully.  Querying object to verify results
 The set operation of instance ebrMultiPortStatus_1.255.255.255.255.255.1 was
 successful"

Now when I query the bridge it returns the following values for the
multicast address I just set:

     ebrMultiPortStatus_1.255.255.255.255.255.1   7
     ebrMultiPortStatus_1.255.255.255.255.255.2   7
     ebrMultiPortStatus_1.255.255.255.255.255.3   7
     ebrMultiPortStatus_1.255.255.255.255.255.4   7

Even though I specified ebrMultiPortStatus_1.255.255.255.255.255.1 to
set rate limiting for this multicast address on port 1, the bridge
has rate limiting set for this address on all ports. Does this mean
that the bridge will not allow a multicast address to be rate
limited on only one port?

We were able to test the rate limiting of this multicast address and it
works as expected. One thing we did notice is that ebrRateLimit can
not bet set to a number less than 100.


Thanks for your help,

Mike Hutchinson


T.RTitleUserPersonal
Name
DateLines
1269.1KONING::KONINGPaul Koning, B-16504Thu Mar 10 1994 18:0111
(1) I would have thought should be "yes"; this may be a bug/restriction.
    It should definitely be allowed in the DECbridge 900.

(2) No.  Rate limiting either limits a specified multicast address, or
    a specific protocol when sent to any multicast/broadcast address.  In
    either case, the limiting is done independent of the input and output
    ports.

(3) I don't think so, because the actual limiting is done over 10 ms intervals.

	paul