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

Conference netcad::hub_mgnt

Title:DEChub/HUBwatch/PROBEwatch CONFERENCE
Notice:Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7
Moderator:NETCAD::COLELLADT
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

2112.0. "Decswitch900 forwarding database to file ?" by COPCLU::EBC () Thu Mar 16 1995 11:48

I had a call from a customer who claimed, that when on his Hubwatch Openvms he
opened the Decswitch900EF summary window, selected the Forwarding icon and
pressed the File button to save the forwarding database to file, a file was
created, but containing only a header, but with no addresses.
I tried the same locally on both the Windows and OSF based Hubwatch and got the
same result.
Later (the Decswitch had been reset in between) I tried again, and now the
database was dumped correctly to file.
Hubwatch is V3.1.3, Dechub900 is V3.1 and Decswitch is V1.4.

Has anybody seen something like this ?

Erik
T.RTitleUserPersonal
Name		DateLines
2112.1try this...NETCAD::IACOBONEThu Mar 16 1995 17:4724
    This will happen if the illegal address 00:00:00:00:00:00 is stored in the
    forwarding database. When HUBwatch sees this entry it jumps out of the
    dump routine. Because this entry is the first, nothing gets dumped to
    the file. 
    
    I've fixed this in v4.0 (the release we're working on now).
    
    How the bogus address of all 0's got in the database is another
    question. Maybe someone doing testing or a device booting up and
    broadcasting bogus addresses? I don't know but would like to if anyone
    knows how this happens.
    
    One way around this for now is to create an address filter of
    00:00:00:00:00:00 and then delete it. This will delete
    00:00:00:00:00:00 from the forwarding database until it is broadcast
    again. Hopefully you can get a file dump in before then.
    
    Let me know how this works.
    
    Thanks,
    
    Dave Iacobone (HUBwatch development)
2112.2Illegal frame gets aged out of forwarding table....NETCAD::BATTERSBYThu Mar 16 1995 18:086
    Whatever is causing the 00:00:00:00:00:00 address to be added
    in the first place, is not clear. Apparently when the dump
    is attempted again, the 00:00:00:00:00:00 address has aged out,
    and would explain why it works after the initial time.
    
    Bob
2112.3Illegal address will be kept in forwarding databaseZUR01::METZGERWed Mar 22 1995 12:108
    Re .2
    Bob,
    the illegal address 00-00-00-00-00-00 stays in the forwarding database
    until the DEFBA is reset, or the workaround of .1 is used. It will 
    receive the status "aged out" or "invalid", but as such will be kept
    in the forwarding database.
    
    Norbert