View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 669 | RackTables | default | public | 2012-11-16 14:11 | 2013-05-19 17:30 |
| Reporter | grin | Assigned To | andriyanov | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | won't fix | ||
| Product Version | 0.20.1 | ||||
| Summary | 669: SFP/GBIC/... modules have hw-type and mac and other attributes too | ||||
| Description | SFP/GBIC/... modules have hw-type and mac and other attributes too, and they indeed are very incompatible with one another and the various equipment. Right now SFP plugs are not objects just an attribute. Maybe there's a point to consider this to change; maybe it's only me who gets all the fun with gigalite sfp and juniper switches, etc. ;-) | ||||
| Tags | No tags attached. | ||||
|
Do transceivers really have MAC addresses? Regarding the compatibility issues you mention, this part of RackTables implements a rather idealistic data model, that is, only the form-factor and the signalling standard matter. For example, it is assumed, that any SFP+ transceiver can be plugged into an SFP+ socket, and any 10GBase-SR piece will bring the link up with another 10GBase-SR one. It is perfectly known some vendors enforce a lock on the transceiver hardware their equipment accepts, but it's also a matter of fact it is a pure software limitation (sometimes a bug), which comes and goes as such. Tracking such software issues would be a pain. If you mean cases of, say, two "SR" transceivers not bringing the link up because at least one of them violating the way SR must be implemented, well, then the maker defies the very concept of a standard and should return your money back. To make things worse, such incompatibility can be specific to a particular lot number or range of serial numbers. I guess the solution space shouldn't go thus far. All that said, letting the user to track the hardware product number of a transceiver installed into a port is a good idea. BTW, I'd suggest putting the product list into a separate table rather than into Dictionary table. But, again, this should be an accounting measure, not the way to split a standard into incompatible subsets. May be I'm missing something important here, then please explain. |
|
|
You are almost completely right, including using a separate models table. I am no expert on optical stuff, I work on the logical/topological layers, but I know the guys swearing a lot about transceivers' incompatibility. Everytime a new equipment model arrives we have to test which transceivers are "okay" with its interface, and that made me mention the idea. Right now we mostly use the comment field to record the xciever types (if at all). Maybe it's soft/firmware, but my guess it's mostly undetermined electrical/logical incompatibility. If it's serial number bound it'd be possible to create a table for "type1" "type2" etc hardware versions/revisions, and set slot/transciever compatibility for those. About MAC address... I don't know whether it's bound to the socket or the transceiver, that was a fine question. But this is a low prioity problem, at least for me. Rather an idea for the future. |
|
|
Thank you for reporting problem. Maybe we will come up with some solution. Anyway it will need serious redesign of the system, so it won't happen soon. I will close the ticket, because it is no sense to keep it opened for so long. |
|
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-11-16 14:11 | grin | New Issue | |
| 2012-11-21 23:40 | infrastation | Note Added: 0000995 | |
| 2012-11-22 17:03 | grin | Note Added: 0000999 | |
| 2013-05-19 17:30 | andriyanov | Note Added: 0001429 | |
| 2013-05-19 17:30 | andriyanov | Status | new => closed |
| 2013-05-19 17:30 | andriyanov | Assigned To | => andriyanov |
| 2013-05-19 17:30 | andriyanov | Resolution | open => won't fix |