At 07:06 PM 6/4/02, Nelson Herron wrote: >I have an Olicom switch configured with two rings
OK, got that. >under separate TrBRFs with >Win2k clients running NetBEUI attached to each ring. I have tried a couple >of different methods of bridging starting with a simple SRB and then a >multi-port SRB. I have "source 6 1 4094" and "source spanning" on one To >interface and "source 8 1 4094" and "source spanning" on the other in the >current configuration So you have a router in addition to the Olicom switch? (A router doing bridging?) What are the ring numbers? Have you made sure that for the ring between the switch and router that the switch and router agree on the ring number? Where are the clients? Where are the servers? We need a picture or more precise textual description of the topology... You probably don't need source spanning? I bet basic SRB would work. Definitely start with the simplest first. Don't do spanning or multi-port bridging until you get basic SRB working. Let's say that your network around the router/bridge looks like this: ring 6--To0 Router/Bridge To1--ring 8 The config should be really simple, unless I'm missing something. Let's call the Router/Bridge Bridge #1 (assuming you aren't already using that for the Olicom switch.) int to0 source-bridge 6 1 8 int to0 source-bridge 8 1 6 >(I also threw in a "multiring all" to satisfy my >superstitious nature). I can capture packets going through the bridge, but >I can't browse the network. There is an SMB dialect negotiation packet >coming from the client (in the NetMon capture) but it never gets to the >target. I see no evidence that the router is dropping it, it has >correctly-formed addresses and RIF, it carries a vanilla list of LanMan >dialects. The only hint of trouble that I can see is that the N(R) and N(S) >values both show 0x01 in the packet decription part of the MS NetMon but the >hex printout shows a 0x02 for each byte. Is this a problem? That's probably not a problem. The NR and NS numbers are actually only seven bits. So maybe the decoding is getting confused by that. On the other hand, you should see the send sequence number (NS) keep progressing one by one from each side. You should also see the NR progressing one by one from each side. LLC2 uses a forward acknowledgement, like TCP does. So the NR should state the next expected sequence. For example an NR of 1 means I got 0 and I'm expecting 1 next. > Or have I >forgotten something really fundamental (I'm a newbie to IBM, but even so I >did feel like a right idiot when I finally remembered the "source spanning"). It may be me that's forgetting something fundamental. ;-) Like, I said before, though, I bet you don't need the spanning tree. (Does the Olicom expect it? Do you actually have any redundant links that would cause loops if not pruned into a tree?) Priscilla ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=45788&t=45778 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
