| Title: | FDDI - The Next Generation |
| Moderator: | NETCAD::STEFANI |
| Created: | Thu Apr 27 1989 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2259 |
| Total number of notes: | 8590 |
Hello there,
I want a sanity check on the following confiuration and if possible
some hints on where the problem could be, We are experiencing this
problem when we installed FDDI network using a GIGASWITCH and CISCO
7000 routers connecting a VAX and a ALPHA .
Following is the general diag:
| Ethernet
|
| 3.958 3.959
| --------- ----------
| | CISCO |A B| CISCO | Designated
----------- | 7000 |----------------- | 7000 | Router
| | | | |
| - - -- -- ---------
| |B A|
| | |
| |
| | A -------- B |
------------| |----------
| | GIGA |
| |
| ---------
3.117 s| |s 3.146
| ----- | | -------
| 7610|---------- -----------| | DEC 7630
| | VAX |s s|ALPHA|
------- ------- (End node)
| |Host router |
| |
|______________ DECNET.LAT |
|
|________________________________________________
| LAT only
|Ethernet
Problems (DECNET only):
1. Set host from VAX to ALPHA or vice versa takes long time and times
out or some times we do get response - but very very slow.
2. Disconnected GIGAswitch from the Ring and then ALPHA and VAX
communication was OK - but ALPHA cannot talk to nodes on Ethernet
using VAX as a router. That is VAx does not forward the DECNEt
Packets to nodes on Ethernet.
Please indicate is this config valid - if so why the response
time problem - when GIGA is expected to bridge the packets between
ALPHA and VAX
Next when GIGA is out of ring - why the VAX is unable to forward
the packets between Ethernet and FDDI or simply put VAX is not acting
as router.
Thanks for any feedback
Mohan Kulhalli
CSC Sydney
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1288.1 | You can't have the AA-00-04-xx-xx-xx address on both interfaces | 4286::MDLYONS | Michael D. Lyons - Young enough and dumb enough | Thu Mar 24 1994 10:21 | 2 |
You most likely have the DECnet address applied to both interfaces
on the VAX and/or Alpha
| |||||
| 1288.2 | GIDDAY::KULHALLI | Thu Mar 24 1994 17:51 | 18 | ||
Michael,
Thanks for your quick response.
Yes , I forgot to mention one more point in the previous note that is
both CISCO routers are configured for Bridging in DEC SPANNINg tree and
GIGA supports only IEEE 802.1 D.
Next CISCO does Routing before it bridges DECNET and hence I do not
believe the SPANNING Tree incompatibility would be an issue here ??
Am I right? There will be two seperate spanning trees.
Now - by disabling bridging on the CISCO router the response gets back
to normal and can you suggest where in config lies the problem?
Thanks again
Mohan
| |||||
| 1288.3 | KONING::KONING | Paul Koning, B-16504 | Thu Mar 24 1994 18:07 | 14 | |
Two spanning trees is USUALLY a very bad problem. There are a FEW configurations that don't break. I don't remember all the rules (they are not simple). The one you have here sure looks like one that DOES break. Anyway, if the Cisco boxes are set up as to bridge, you're (probably) violating the rule that a given datalink address must not appear on more than one LAN that is bridged. The Cisco at the left will see the DECnet address of the left VAX both on the Ethernet port and on the FDDI port. This will confuse the address learning. It's possible to do routing in a way that isn't affected by that, but I have no idea what Cisco does. So I can see two reasons for this not to work... paul | |||||
| 1288.4 | GIDDAY::KULHALLI | Tue Mar 29 1994 21:54 | 7 | ||
Thanks Paul and Michael.
Customer has disabled bridging on CISCO routers and all works fine. He
hass decided to stay with that config.
Mohan
| |||||
| 1288.5 | Cisco's and bridging | NSTG::OUIMETTE | Don't just do something, sit there! | Fri Apr 01 1994 13:44 | 9 |
A FYI: In our lab here, we've seen several bugs in Cisco's
implementation of DEC spanning tree. We haven't found any bugs in
their 802.1d implementation yet, though, so we usually reccomend
running Ciscos in 802.1d mode where possible. In general, bridging is
an afterthought for Cisco; it tends to take a big chuck of the brouter
CPU horsepower if enabled, and this may cause other problems.
Chuck Ouimette
NSTG
| |||||