| 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,
We have a customer that is reporting that he is seeing packets on the
workgroup side of a DECbridge 90 that should not be forwarded there
from the backbone side. They are not broadcast nor multicast packets,
but single destination addressed packets. He is observing this
behaviour through the use of a Sniffer.
The first time that this was reported to us, the only thing on the
workgroup side of the DECbridge 90 was the Sniffer connected to one of
the DECrepeater 90C ports. Just in case this was some kind of abnormal
type of thing being seen due to the DECbridge 90 not knowing of any
addresses on the workgroup side, we had him repeat the test with
something active on the workgroup side. The results did not differ.
The following is some of the information about the DECbridge 90:
DECbridge> SHOW BRIDGE
DEWGB V2.1 08-00-2B-BA-FA-C1 �1991,92 Digital Equip Corp
FPROM V3.1 �1991,93 Digital Equip Corp 5-APR-93
Bridge states:
Console owner: AA-00-04-00-10-04 Uptime: 21,941.90 seconds
Bridge state: 17 Work group size: 0
Hub mgmt enable: 1 Spanning tree enable: 1
Flash ROM erasures: 0 Address lifetime: 450*2 sec.
User flood mode enable: 0
Event counters:
Sys buffer unavail. errors: 0
WG size exceeded errors: 0
Spanning tree parameters:
Bridge id: FF-FF-08-00-2B-BA-FA-C1 Root port: 1
Designated_root: 00-35-08-00-7C-00-1D-89 Root path cost: 903
Current Forward delay: 15, Hello interval: 1, Listen time: 15
Def. Forward delay: 15, Hello interval: 1, Listen time: 15
Topology change flag: 0 Topology change timer: 30
Bad hello limit: 15 Bad hello reset interval: 5
Epoch_mode: 1 Epoch1 who: 00-00-00-00-00-00 Mode changes: 1
Epoch 1 poll time: 18 seconds Epoch 1 response time: 15 seconds
Any words of wisdom in this matter would be most appreciated as well as
anything else that we might check into.
Thanks,
John
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 989.1 | What are they trying to filter? | ROGER::GAUDET | Because the Earth is 2/3 water | Mon May 16 1994 12:10 | 5 |
Could you post the output of the SHOW PROTOCOL command at the bridge's DECbridge> prompt (MOP console carrier)? That will tell us what they are trying to filter and perhaps why it is not working. ...Roger... | |||||
| 989.2 | Protocol Filter Information | ALFAXP::J_HASSENCAHL | USCSC LATmaster AXP/VAX Support | Mon May 16 1994 13:27 | 42 |
Hello,
The following is the output as you requested:
DECbridge> SHOW PROTOCOL
Protocol 1: filter all ethernet protocol 60-07
Protocol 2: unused protocol
Protocol 3: unused protocol
Protocol 4: unused protocol
Protocol 5: unused protocol
Protocol 6: unused protocol
Protocol 7: unused protocol
Protocol 8: unused protocol
Protocol 9: unused protocol
Protocol 10: unused protocol
Protocol 11: unused protocol
Protocol 12: unused protocol
Protocol 13: unused protocol
Protocol 14: unused protocol
Protocol 15: unused protocol
Protocol 16: unused protocol
The customer also include the following comments:
================================================================================
I have defined (and SET) the bridge to filter 60-07 both ways. After doing this
I went back to my repeater and connected my sniffer. Below is a report I
created after doing this. Please note according to the sniffer I still see
60-07. I went into another option of this sniffer software that allows me to
decode the packets, and notice most of the LAVC packets were 60-07 multicasts,
but not all. Some were workstations talking to their bootnode, and vice-versa.
I re-verified that the bridge is filtering 60-07 (supposed to???) and it says
it is!!!!
================================================================================
Thanks,
John
| |||||
| 989.3 | Now I'm confused | ROGER::GAUDET | Because the Earth is 2/3 water | Tue May 17 1994 14:40 | 19 |
I am at a loss to explain what your customer is seeing. I managed to scrape up a V2.2 DECbridge 90 (apparently there's a version later than the V2.1 your customer has) and set the protocol filter just like your customer has it set. Within a few seconds after the filter was set I did see some 60-07 multicast packets on the workgroup side (a total of 31, all multicast). But then they stopped. I then setup a V1.14 DECbridge 90 in another hub with the same backbone connected to the front bezel of the bridge and the 60-07 filter set. I thought maybe there was something different in the behavior of the V1.x and V2.x bridges. I've been monitoring both hubs with different sniffers on the workgroup side for two hours and have not seen any 60-07 packets. Very weird. FYI, I did check before I started my tests and there are lots of 60-07 packets flying around our backbone. Is there any chance that your customer is seeing the problem only shortly after the filter is set, or are the 60-07 packets coming through regularly after setting the filter? ...Roger... | |||||
| 989.4 | Checking ... | ALFAXP::J_HASSENCAHL | USCSC LATmaster AXP/VAX Support | Tue May 17 1994 16:07 | 7 |
Hi,
I will check with the customer and see what he has to say ...
Thanks,
John
| |||||
| 989.5 | Follow up information ... | ALFAXP::J_HASSENCAHL | USCSC LATmaster AXP/VAX Support | Wed May 18 1994 09:30 | 14 |
Hi, I got the following information back from the customer in regards to your query: To the best of my knowledge I had the bridge up for some time (1 hour or more) before I had captured the frames I sent you. I have 60-07 filters set "both ways" on the DECbridge 90. I issued a SET and DEFINE PROTOCOL on it, and have not altered it since. Thanks, John | |||||