Re: bridging
From: Phillip Windell (_at_.)
Date: 07/23/04
- Next message: Andrew Wong: "Printer Permission Issue"
- Previous message: Greg Brewer: "Re: bridging"
- In reply to: Greg Brewer: "Re: bridging"
- Next in thread: Greg Brewer: "Re: bridging"
- Reply: Greg Brewer: "Re: bridging"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 23 Jul 2004 10:01:08 -0500
This doesn't make any sense at all to me. The Servers don't have anything to
do with this.
It is not about IP#s. It is about physical links and what devices have
control over them.
If the two links come into the same physical device (a router) then that
physical device can handle the "fail-over" (if it is capable). If two links
come into two separate physical devices than "fail over" is not typically
possible. Routers perform this by using redundant physical links and use
their own built in abilities combined with routing protocols (RIP, IGRP,
EIGRP, etc) to perform the "fail over". It is the routing protocols that
determine a link is no longer operational and causes changes to the "routing
tables" in the next routing table update, and the new changes in the
routing tables cause a different route to be taken to a given destination if
a redundant path exists.
This is why the ISP has to be the one to build a solution. It is thier
lines, it is their equipment (in part), it is their service, and it is they
you have to work together with to create a solution.
-- Phillip Windell [MCP, MVP, CCNA] www.wandtv.com "Greg Brewer" <greg-spam@brewer.net> wrote in message news:41011d15$0$449$be864849@news.hal-mli.net... > Someone pointed out a flaw in my plans. I was figuring on being able to use > the internal network to go around a T1 failure. Of course, that won't work > because it is the router that has the IP address; not the server. > > My new idea is to get a couple of new public IP addresses for the routers > and move the current ones to the servers. But that would mean they aren't > on the same subnet. Hmmm, perhaps a second NIC with a private IP address. > > Any thoughts? > > Greg > > > > "Phillip Windell" <@.> wrote in message > news:uI1db8ybEHA.2660@tk2msftngp13.phx.gbl... > > "Greg Brewer" <greg-spam@brewer.net> wrote in message > > news:40fd8d65$0$447$be864849@news.hal-mli.net... > > > time they could check it out. What I want to do is set the thing up > that > > if > > > the primary T1 for either Web Server or Mail Server goes down, it will > go > > > around. > > > > You can not easily do "fail over" with those T1s and still uses them like > > you currently are at the same time. You can manually switch them, but the > > way you do that depends on the methods you are currently using now in the > > "normal" operation. > > > > I could do ours with one toggle on one device because my Default Gateway > for > > all machines is a LAN Router (not a firewall) and the firewall is the LAN > > Router's DFG. So if a link went down I would simply change the DFG on the > > LAN Router and would be all done, assuming both links had firewalls using > > the same subnet. > > > > You could have the T1s setup for "fail over" themselves but that requires > > they both be from the same ISP and the ISP would actually be the one to > rig > > it up since those lines are more their "territory" than yours. This would > > change the whole way you are now running your stuff. Most likely the ISP > > would run both lines into the same Internet Router and would use a Router > > capable of doing the fail-over between redundant links. From your side of > > the network it would appear as a single Internet link rather than two as > you > > have now. Now if the T1s are from different ISPs then you would have very > > few if any options. > > > > -- > > > > Phillip Windell [MCP, MVP, CCNA] > > www.wandtv.com > > > > > >
- Next message: Andrew Wong: "Printer Permission Issue"
- Previous message: Greg Brewer: "Re: bridging"
- In reply to: Greg Brewer: "Re: bridging"
- Next in thread: Greg Brewer: "Re: bridging"
- Reply: Greg Brewer: "Re: bridging"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|