Conference netcad::hub_mgnt

    Rewording it a bit, you want to connect the DECserver to both rings. We
    don't make a FDDI bridge with 2 independent FDDI ports, so you need two
    bridges, each connected to a different external ring but both connected
    to the internal Ethernet lan in the Hub to which the DECserver is also
    connected. Or am I missing something?
    
    How are the two rings connected today? Via a router? If not, the two
    bridge scheme will probably work.

Thanks for the reply.  This is a new LAN, so it isn't connected today.

    Rewording it a bit, you want to connect the DECserver to both rings. We
    don't make a FDDI bridge with 2 independent FDDI ports, so you need two
    bridges, each connected to a different external ring but both connected
    to the internal Ethernet lan in the Hub to which the DECserver is also
    connected. Or am I missing something?

We have a DECbridge 900MX in the DEChub 900.  So we just need to get 
another bridge for the hub.

The two rings are connected today via DECnis routers.

Not being knowledgable about IP routing, I'm concerned that connecting the 
same segment to two different FDDI rings, where these rings are themselves 
connected, might form some kind of loop.  How does this not happen?

Thanks!
tl

    Yep, as I said, it would only work if there wasn't a router in the way.
    
    The only other idea I have is to connect your Hub directly to the
    DECnis. I dunno how you'd do that, I don't know DECnis'.
    
    md

Just want to make sure I'm clear:  since we have DECnis routers between the 
two rings, then we can NOT connect a segment via two bridges to both rings 
directly?

tl

    you're clear.
    

    Thanks!  But why is this so?  (I know there's a lot I'm missing, but
    I'd appreciate a few pointers).
    
    Thanks!
    tl

    My guess would be that it's the same reason that you don't connect two
    Ethernets with a bridge/switch and then also connect them with a
    router.   It differes on a per-protocol point of view.  For
    example....in DECnet each MACHINE has an address.......so...
    
    
        System 1                        System 2
         address 1.2                     address 1.3
    -------LAN--------------Bridge--------LAN----------
                router                        router
                  -----------(wan)---------------
    
    
    I believe that in the above, DECnet would work and all would be fine,
    the 'least cost path' would always be over the LAN.   (tho if the
    routers were just locally connected, it would be a rather silly waste
    of a router).  in DECnet you'd need different AREA routers if the two
    nodes were in different AREAS.
    
    If the above example were IP....it would depend if thing were in the
    same SUBnet or not, in addition, each INTERFACE in IP has it's own
    address.....
    
    
              NODE1                                    NODE2------------           
             |      1.1.1.1                               1.1.2.1      |
             |     (LAN address)                         (LAN address) |
             |        ------------------Bridge-------------            |
             1.1.1.2 (WAN address)                       1.1.2.2 (WAN address)
             |                                                |
             |                                                |
            Router-----------------(WAN)-----------------Router
    
    
    Different "ethernets" are usually "routed" and have 'subnet masks'.  In
    the above it's likelyt htat the mask is 255.255.255.0 (meaning that
    if node 1 has to look for anything that does not start with "1.1.1.x"
    it asks a router for help with an ARP (Address resolution protocol).
    
    If the node 1 does an ARP to find node 1, Router 1 says that Node 2 can
    be found out on the WAN via the adjacent router, but router 2 says that
    it can be found on the LAN.
    
    So, the node ARPS again to get a correct answer....
    And it ARPS again....
    And again..
    etc.
    
    Can you say ARP STORM?
    
    Flawed stuff like this is why IP folks like ROUTERS separating lans.  A
    mis-connection can cause the network to get confused and start
    screaming about it.  (Typically in DECnet you'll just loose adjacency,
    not eat up LAN bandwidth)
    
    My explaination is likely flawed, but in general, unless you're CAREFUL
    be wary about simply bridging LANS that are routing IP.  It can cause
    unexpected results based on subnet-masks, routing etc.
    
    u c?
    j
    

	Re: .7
    
    Just to keep the record straight re: IP, an End System will never ARP
    for an address which it does not think is in its own subnet, or for
    which a manual routing table entry ("route add net 1.1.2.0 my_interface
    0") has been entered.... It will look in its routing table, and 
    (hopefully) find the IP address of the appropriate router, and ARP for the 
    router's MAC address. The only nodes which would ARP for node 2 would be 
    other nodes in the 1.1.2 subnet, such as router 2. 
    
    	so.....
    
    While there may be other reasons why routing & bridging IP can cause
    problems, I can't think of them offhand, and I don't think that ;-1 is 
    one of them. In fact, if you have multiple subnets on the same LAN 
    (replace the bridge with a barrel connector), then routing between the 2 
    subnets on the same LAN with a router with two interfaces, one in each 
    LAN (replace the WAN connection with a backplane in the router, or make it 
    unnumbered for the same effect) is a common solution. But ;-1 is 
    definitely correct that it's always prefereable to route, rather than 
    bridge IP, whenever possible.
    
    	Now, with DECnet IV, if the router between LANs is a system with 2
    LAN interfaces, then each interface will have the same "AA-00-04"
    address, which will cause the bridge no end of confusion ("it's on port
    1; no, 2; no, 1, etc."). So again, I can't *think* of a situation where
    IP would have similar problems, but it may exist.... ARP storms are
    usually related to improper ARP implementations, and mixing 1's/0's
    broadcast addresses. But DECnet IV will decidedly hurl, as noted
    above..... 
    
    		regards,
    
    -chuck