Number: F4TH071990U164 Subject: WAN Scenario Message Thread Date: August 1, 1990 - - - - - - - - - - - - - - - - - - - - - - - GENERAL INFORMATION: This message is intended to start a discussion on this subject. We have the following situation: DOWNTOWN MIDTOWN VERTICAL VERTICAL BACKRING /----------X.25 London BACKRING / +------+ / X.25 Chicago +------+ 39th fl--| | X.25----------/ \ | | subnet1 | | \ | |--21st fl--| 38th fl--| | ---------X.25 | | subnet2 | | / | |--7th fl 33rd fl--| | X.25 Los Angeles | | | | | | | |--VITALINK====via T1===VITALINK--| | +------+ +------+ The scenario is as follows: There are existing X.25 routers in place, connecting several different areas on the network with a variety of different locations worldwide via a private X.25 network. Currently, this is also how DOWNTOWN speaks to MIDTOWN. To improve performance and allow additional nonNetWare traffic to cross between DOWNTOWN and MIDTOWN, they are installing a Vitalink bridge with a full T1 circuit to unite the two vertical riser back-rings together. They understand that they need to change some network addresses to make the scheme work. Now, both back-rings will be address BBBBBBBB (this is actually being piloted tomorrow). The problem that's being anticipated is this: What happens if the T1 link or one of the bridges go down? We suddenly have a misconfigured network. Two different, not-connected-together networks are being called BBBBBBBB. More than that, if any one of their X.25 bridges just happen to connect to the same remote city, we won't know we have a problem, exactly. We would not anticipate that we would have traffic jumping DOWNTOWN to Chicago to MIDTOWN (if that would work, we would tell them to use the X.25 routing as a backup by maintaining their current configuration in parallel) since the destination network for a resource on the other side of the bridge is BBBBBBBB. The shortest route to that network would continue to be the same router, but the destination node would be inaccessible since it's on the wrong side of the bridge that's out. The issue will go away for this site when they add a third downtown site to the Vitalink+T1 network -- the spanning tree algorithm will deal with links that are unavailable. Even without that, the reliability of the Vitalink could be beefed up by dedicating a second, smaller circuit to back it up. That leaves them with the concern of what happens if the bridge box itself fails. We suggested that they consider using two separate bridge boxes. The concern there was that the Vitalink adds a lot of value in terms of minimizing broadcast chatter if one bridge manages both parallel links. One group discussing this suggested we eliminate the multiple routes. That's good for reliability (if the link fails, we just lose the service, not the network integrity) but bad from a services level. It means that if the link fails (and we can tell you as NY Telephone digital customers that it will - several times per year), half the network losed connection to Chicago. Ideally, they are looking for a solution that: - Allows them to maintain their multiple connections via X.25 - Withstands loss of the link without causing the network to fail in a mysterious manner (i.e, No Response from given server) - Is less expensive than point to point lines all over the place (they own GEONET - a worldwide X.25 private data network) Well, it's a challenge. Let us know your thoughts, random or sequential, on this matter. ---------------------------------------------------------------------------- I have two suggestions: 1. This may sound a little hairbrained but: On the Vitalink connection, extend the network #BBBBBBBB off the Vitalink from the downtown backbone with an external bridge (or internal). So what you would have is a MAU with two connections; one from the Vitalink and the other from the bridge to downtown ring call it network number "BACB". That way you would have the highspeed preferred route over the Vitalink and safety from network failure it if goes down. See below. DOWNTOWN MIDTOWN VERTICAL VERTICAL BACKRING /----------X.25 London BACKRING / +------+ / X.25 Chicago +------+ 39th fl--| | X.25----------/ \ | | subnet1 | | \ | |--21st fl--| 38th fl--| | ---------X.25 | | subnet2 | | / | |--7th fl 33rd fl--| | X.25 Los Angeles | | | | | | | |-- FS/ ----- VITALINK==VITALINK--| | +------+ Bridge +------+ #BACB #BBBBBBBB You are also protected this way from failure of any route. The other alternative, would be set up the X.25 hardware but NOT make the network call connection EXCEPT in case of failure of the Vitalink. Your customer could be back up with within minutes of the failure over the X.25 network. You could setup circuits which could be initiated from either side (i.e. place a call answer on both sides which would wait for the call originate from the other side). We like the first solution better because there is no chance of failure and we believe that the end user would see no degradation of the Vitalink connection because our internal bridge has to be faster than T1. Good luck and let us know what you decide. ------------------------------------------------------------------------------ Pretty good...but they do want some nonNetWare traffic to cross from backbone to backbone eventually (primarily 3174's talking to 3725's and the like). But maybe using NetWare routers w/o source routing in parallel to IBM source routing bridges. It's got lots of delay but it would probably be reliable. The problem with the X.25 scenario is that if they have both sides configured as BBBBBBBB, when the link is broken, even if they have another route, NetWare will never use it. It will still see all kinds of activity on a network called BBBBBBBB that will always be fewer ticks away than the one across GEONET. In fact, you would probably be able to see the SAP of all the servers on the other side, but you could never get to them. The only way to make that work is to temporarily renumber one side to something other than BBBBBBBB. ------------------------------------------------------------------------------ One possibility that they are going to look into with Vitalink is a BROUTER - a combination bridge/router that can route the IPX traffic and bridge the rest. That would solve the problem immediately. ------------------------------------------------------------------------------ We think the reason for putting the Vitalink between the two offices in the first place is so that protocols other than IPX/SPX will travel between the two rings. Putting the Novell router in series with the Vitalink sort of "filters" out the other protocols before they get to the other ring. We think a CYSCO router between the two rings will allow them to route all sorts of traffic through the link and still keep the LAN addresses unique.