| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2713.1 | | NETCAD::DOODY | Michael Doody | Wed Sep 06 1995 20:28 | 8 |
| 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.
|
| 2713.2 | More information | CRONIC::argyle.hlo.dec.com::lemons | | Thu Sep 07 1995 18:43 | 19 |
| 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
|
| 2713.3 | | NETCAD::DOODY | Michael Doody | Thu Sep 07 1995 19:08 | 6 |
| 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
|
| 2713.4 | | CRONIC::argyle.hlo.dec.com::lemons | | Thu Sep 07 1995 19:21 | 6 |
| 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
|
| 2713.5 | | NETCAD::DOODY | Michael Doody | Thu Sep 07 1995 19:49 | 2 |
| you're clear.
|
| 2713.6 | But, but, why? | CRONIC::LEMONS | And we thank you for your support. | Fri Sep 08 1995 03:28 | 5 |
| Thanks! But why is this so? (I know there's a lot I'm missing, but
I'd appreciate a few pointers).
Thanks!
tl
|
| 2713.7 | IP, don't bridge & route both | PTOJJD::DANZAK | | Sat Sep 09 1995 12:11 | 62 |
| 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
|
| 2713.8 | In IP's defense... | FOUNDR::OUIMETTE | Eyes of the World | Mon Sep 11 1995 17:31 | 37 |
| 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
|