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

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

4203.0. "5 MCC <-> DECbridge 610 problems" by BRAT::BUKOWSKI () Mon Dec 07 1992 11:13

Help,
    
1.	On one of my DECbridge 610 bridge ports (line 4), I have a need to 
	only allow certain static and multicast address to pass, so I need
	to use manual mode.  As soon as I set line 4 manual mode = true,
	all Ethernet lines stopped forwarding packets.  I tried to  reverse 
	the situation by setting the manual mode = false, although the command
	was successful, it didn't not fix the problem.  I had to reset the 
	bridge in order to get operations back to normal.  Why does setting 
	manual mode = true have this effect?  It shouldn't.

2.	I thought that maybe that it was a bug and I could get around it
	by leaving the port set with manual mode = true and reboot the
	bridge.  I tried it, and it sort of worked.  After the bridge came
	up line 1, 2, and 3 were forwarding properly, but line 4 was not 
	allowing a session across itself, even though I had explicitly entered 
	the nodes addresses as static entries with forwarding maps to all ports.
	I am certain that the static entries I had entered should have worked,
	because I have the same setup with a LANbridge 200 (set up using ELMS)
	and it works fine.  Why doesn't this work?

3.	Discouraged, I continued to to try more static entries, and double
	checked them with show commands.  They all showed to be set properly
	as permanent = true , management set, forward map from all ports to all 
	ports, etc.  As I was typing one of the create commands, the bridge 
	rebooted itself.  All of the self-tests passed, and I was soon online 
	again.  

4.	Then I looked around for a while.  I noticed that the permanent static
	entries that I had set were no longer there.  Why are permanent static
	entries disappearing?  BTW: the defaults dip switch is disabled.

5.	I decided to forget about trying to deal with all these problems, and	
	set line 4 manual mode = false.  As a result, the bridge stopped
	forwarding packets on all Ethernet lines just like problem 1, except 
	this time I was disabling manual mode instead of enabling it. Why?


Regards,
Network Management,
Mike
T.RTitleUserPersonal
Name		DateLines
4203.1Will look into problemQUIVER::WALTERThu Jan 14 1993 09:2422
    Re: Manual mode
    I'm not familiar with the use of this mode, but I will look into this
    problem and see what is going on.
    
    Re: Not forwarding packets
    This might be the same problem as discussed in Note 4201. That is, if
    you create a forwarding database entry on a 600 series bridge without
    specifying any attributes, it gets set to disposition = filter, and it
    won't forward packets even if forwarding ports are specified later in a
    SET command.
    
    Re: Reboot
    Even if the above is true (and I realize something else might be
    happening), the bridge still shouldn't crash. If you send me a dump
    of the diagostic block from that bridge, maybe I can trace the problem
    down. You get the dump using the following command:
    
      MCC> TEST BRIDGE bridge_name DIAG BLOCK = TRUE
    
    
    Dave
4203.2More informationABACUS::BUKOWSKIMon Jan 18 1993 11:44113
Dave,
	I performed some manual mode testing this weekend.  I was not able
	to make the bridge crash, but all of the troubles that I originally
	mentioned in 4203.0 are still present.

	What information does the TEST BRIDGE name DIAG BLOCK = TRUE give
	you?  I am curious becuase I have some other information that may
	be of some help.  When I set line 4 manual mode = true, the bridge
	stops forwarding (I have also noticed that the Carrier Present 
	indicator on lines 2-4 change from a constant on to a random blink).
	At this point I loose my connection to the host running MCC, becuase
	my LAT connection runs across line 2 of the bridge under test.  Hence,
	I had to manually reboot the bridge.  At this point would a diag
	block be of any use to you?  If so I have appended it below.

	I have some information on what may be another problem that I have 
	noticed.  After the bridge is powered back on.  I reconnect to MCC and 
	run a COM program to create the 200+ static entries that I want to pass
	across line 4.  I randomly validate the entry creation and forwarding
	attributes by showing all characteristics.  Then I took a look on the 
	LAN analyzer that is connected to the line 4 segment, and I do not see 
	any of the multicast packets that I created to forward.  I thought 
	it may work if I rebooted the bridge again.  After the bridge powered 
	back on, all of the STATIC and MULTICAST address that I previously 
	created are gone.  Some are completely gone, but some show evidence 
	that they may exists without characteristics.  Here is the response of 
	a few show commands that I recieve when trying to show their 
	characteristics:   

	Mike

show bridge .mko.br.mko2g2brg202 forward data STATIC entry AA-00-04-00-B0-7D all char
!
!
!Bridge DEC:.mko.br.mko2g2brg202 Forwarding Database Static Entry AA-00-04-00-B0-7D 
!AT 17-JAN-1993 11:51:14 Characteristics
!
!No such entity: Bridge DEC:.mko.br.mko2g2brg202 Forwarding Database Static 
!Entry AA-00-04-00-B0-7D 
!                         Unknown Entity = Bridge DEC:.mko.br.mko2g2brg202 
!                                          Forwarding Database Static Entry 
!                                          AA-00-04-00-B0-7D 
!
show bridge .mko.br.mko2g2brg202 forward data STATIC entry AA-00-04-00-29-7E all char
!
!
!Bridge DEC:.mko.br.mko2g2brg202 Forwarding Database Static Entry AA-00-04-00-29-7E 
!AT 17-JAN-1993 11:51:28 Characteristics
!
!Examination of attributes shows:
!
!
show bridge .mko.br.mko2g2brg202 forward data STATIC entry AA-00-04-00-BF-7D all char
!
!
!Bridge DEC:.mko.br.mko2g2brg202 Forwarding Database Static Entry AA-00-04-00-BF-7D 
!AT 17-JAN-1993 11:51:47 Characteristics
!
!Examination of attributes shows:
!
!
EXIT
!

	

test bridge .mko.br.mko2g2brg202 diag block = true
!
!
!Bridge DEC:.mko.br.mko2g2brg202 
!AT 17-JAN-1993 10:45:23 
!
!Examination of attributes shows:
!                       Diagnostic Block = ( %X000B0007000000001B8C00010000DEAD,
!                                            %X00002500002048500000006500000000,
!                                            %X0000000000000000000000013E040487,
!                                            %X00200006000000000000FF0600000148,
!                                            %X40043E043314000C2008923420000758,
!                                            %X2008922A2008923600202128331C0008,
!                                            %X00000000003E3E64DAFE2BDE00000001,
!                                            %X00000007000000070000000000000000,
!                                            %X00000000000000000000000000000000,
!                                            %X000000000000000000000000E8337789,
!                                            %X100B0009000000000BDE00010000DEAD,
!                                            %X00002500002048500000006500000000,
!                                            %X0000000000000000000000013E040487,
!                                            %X00200007000000000000FF0600000148,
!                                            %X40043E043314000C20126A34200001D0,
!                                            %X20126A2A20126A3600202128331C0008,
!                                            %X00000000003E3E64DEFE7FDE00000001,
!                                            %X00000007000000070000000000000000,
!                                            %X00000000000000000000000000000000,
!                                            %X00000000000000000000000060152EA4,
!                                            %X100B000A00000000020500010000DEAD,
!                                            %X00002500002048500000006500000000,
!                                            %X0000000000000000000000013E040487,
!                                            %X00200007000000000000FF0600000014,
!                                            %X00183E043314000C20163634200006E8,
!                                            %X2016362A2016363600202128331C0008,
!                                            %X00000000003E3E64DEFE7FDE00000001,
!                                            %X00000007000000070000000000000000,
!                                            %X00000000000000000000000000000000,
!                                            %X0000000000000000000000005746C7DF,
!                                            %X00000000000000000000000000000000,
!                                            %X00000000000000000000000000000000,
!                                            %X00000000000000000000000000000000,
!                                            %X00000000000000000000000000000000,
!                                            %X00000000000000000000000000000000,
!                                            %X00000000000000000000000000000000 )
!
use logg off
!
!
4203.3Problems reproducedQUIVER::WALTERMon Jan 18 1993 18:4530
Re: Diagnostic Block information

	The diag block is used to report on two types of failure:
	
	   1. Self test failure. It reports the identification number of
	   the test that failed.

	   2. Firmware failure.  It reports the state of the processor
	   when a fatal error was detected. The state consists of the
	   PC, stack, and all other internal registers. In addition, a
	   reason code is logged that specifies the nature of the error.

	The diag block has enough space to log the 4 most recent events.
	It is erased anytime you reset the NVRAM. 

Re: Manual Mode problems

	I have been able to reproduce some of the manual mode problems
	on a 610 in the lab. I agree it doesn't seem to be working right.
	Since this is implemented in the critical path code on the bridge,
	any changes I make will have to be tested very thoroughly before
	releasing. For this reason, it is not likely to be fixed in the
	V1.3 FT2 version, but I hope to have it fixed in the V1.3 final
	release.
	

Regards,
Dave