home *** CD-ROM | disk | FTP | other *** search
- 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.
-