eshop@saturn.ucsc.edu (Jim Warner) (07/13/88)
I haven't seen a review of the Retix ethernet bridge with network management yet. Here are my first impressions: We purchased a Retix 2244M local bridge with network management. We also got the network management software that Retix offers. The Bridge dropped right in where a baseband repeater stood before. It doesn't seem to mind that it is hosting transceivers without heartbeat. The good news is that the 2244M worked immediately. Performance of the Retix bridge has been commented on (all favorable) in the news groups before. Management software We were looking for access to Ethernet statistics: packet counts, error counters, and the ability to examine the MAC level forwarding data base. We got that, sorta... The management software runs on a PC with a 3com 3c501 ethernet board. It was written by someone that seems to believe that the more menus the better. In this case, they've taken menus to the point of mania. For example the Ethernet stats are three screens below the top level. This gets you get stats for one of its two ports. But if you want the stats for the other port, you have to traverse the tree again. The stats for the first port are, of course, gone from the screen. If you wanted to compare the number of packets incident on the 'a' port with those send out 'b', you'll have to resort to pencil and paper to store the intermediate results. No separate count is kept of packets forwarded on account of being broadcasts as opposed to those that were forwarded because they were added to the dynamic data base. If you're interested in periodic sampling to gauge the peaks and valleys of your network load, you'll have to assign someone to read the statistics regularly and write them down. The manager program has no facility to write to the PC's disk. The manager can add static entries to the forwarding data base that stop destination ethernet addresses from being forwarded through the bridge. These can be station or multicast addresses or the broadcast address. All such information has to be added manually, one entry at a time. If the bridge loses power or is reset, the typing chore will have to be repeated. The 2244M has no nonvolatile RAM and the manager program has no provision for scripts to automate the process. There is a provision for a data file on the management PC that holds symbolic names for ethernet addresses so you don't have to retype 12 digit addresses. Access to the management functions is guarded by a password. Actually, it is access to the PC manager program rather than to the bridges that is guarded. The 2244M has no permanent memory in which to store a password. There is some protection in that, if you don't know its MAC level Ethernet address, you can't talk to it. This requires physical access to the unit to read its serial number. The bridge uses its own Ethernet address only when talking to a management PC, so getting this info should be a challenge to the patience of an Ethersnooper. I had expected some sort of command that would dump the forwarding data base on the screen of my monitor PC. This sort of functionality is not part of the management control set. Manager inquiries into the data base are limited to finding out whether any particular address is in the data base. There is no facility for simply listing out all the addresses, or even finding out how many there are. I was able to verify that all the information that the bridge learns is indeed dynamic. It disappears as it should if the host-owner has been silent for some period. I added a static discard entry to the bridge's forwarding table to block transmission of DEC LAN-BRIDGE packets. The static discard feature works as advertised. I also experimented with a static forward entry. This might be used if my protocol analyzer needed to examine traffic between two computers both located on the far side of the bridge. I am lazy enough that I'd prefer not to drag the analyzer all over campus unless it is necessary. This works too. Error stats include the common ones for Ethernet. For received packets the number of alignment and CRC errors and collision fragments are counted. For transmitted packets, the number of collisions and the number of deferals is reported. The transmit statistics I saw looked reasonable. The receive stats are another matter. The software reports alignment errors but never seems to see any CRC errors. As a check, I used an Excelan lanalyzer to send 1000 packets with bad CRC's onto the network. The 2244M saw these packets as having alignment errors rather than CRC errors. These problems have been reported to Retix for possible resolution in the next software release. Conclusion I am certainly getting more info from the Retix 2244M than I get from an DEC LB100 (we don't have RBMS). I expect that Retix will clear up the bugs in the manager software. Enhancements to security, however, will require changes to the hardware in the box. I can't see making a campus sized lan using these things as building blocks.