Kevin,

I just return from Cisco's facility in North Carolina in their PDVC lab
where we tested our network.  Our purpose and design of our network was to
provide total redundancy from the core to the access layers.  We are using
7206 routers for our edge routers running BGP and HSRP, 6509 switches for
load balancing and vlan routing, and Cisco PIX boxes for security with
several DMZ's.  We have virtual server farms supported by multiple SUN
servers using dual NIC's.  Also, we have a 7513 router as an aggregation
router with a BVI connecting to the two 6509 switches for redundant
connections.  We are running a port channel between the switches for VTP
traffic and also use the switches for vlans into the different dmz's in the
PIX boxes.  The switches also have a MSFC module in them which routers with
ports limited only by the number you purchase.  We run HSRP on the edge
routers and spantree on the switches and router with the BVI.  

The test worked great.  We failed various links and watched as the traffic
redirected to the redundant paths with minimal disruptions to the traffic
flow(default spantree settings).

Steve Whitton
Manager of Deployment & Engineering Services
Cox Communications
Cox Internet Services


 -----Original Message-----
From:   Brian [mailto:[EMAIL PROTECTED]] 
Sent:   Friday, October 13, 2000 9:31 AM
To:     Kevin Welch
Cc:     [EMAIL PROTECTED]
Subject:        Re: High Availability. (Maybe OT)

On Fri, 13 Oct 2000, Kevin Welch wrote:

> I am trying to figure out how to impliment a redundant network design.  
> The problem I keep running into is the connection to the server.  I
> can provide Access redundancy through the use of two switches.  I can
> provide some level of server redundancy via the use of 2 NICs or 2
> Servers.  The problem is how to provide application layer redundancy.  
> I have been able to prove the network itself is redundant, but
> connectivity to servers seems to be where I am having trouble with my
> studies.

what types of servers are these.  layer 4-7 switching is a possibility.

> 
> >From my understanding I cannot do etherchannel accross switches, and
> more over, I remember that etherchannel does not provide redundancy
> because if one link goes down the whole channel goes down.  Please
> correct me if this is wrong.

yes that is wrong.  You can etherchannel between switches, and if you have
a 4port channel, and lose a port, you are ok.

> 
> Example:
>   Realizing that the expectation that a server stay up all the time
> would still be a single point of failure.  In the event of a network
> failure on a switch, how do I provide network access to the Server.

Using Server Load Balancing on switches.  Then between the switches you
run a hot standby protocol.  For example:

The ip the clients use for the server would really be a "virtual" ip
address, which is actually bound to the layer4 switch.  The layer 4 switch
receives requests for the application (lets say port 80) and then load
balances accross a server farm using a hash table.  If servers die......it
can handle this, because it does health checks to the servers.  If the
switch dies, then hot standby kicks in and another switch is activated.

Even "session" level stuff like cookies and whatnot can be handled by
these switches, to make sure your session stays on the same server.

Other applications like databases etc, have similar scenerios.  Normally
in the above scenerio, you backend all the servers off a single file
server so that the data is the same on all servers (NFS).  This file
server would be a high reliable server such as a NetApp

> 

> 
> Problem, maintaing the same layer 3 address accross both switches in
> the advent that one link should fail, the server maintains
> reachability.



> 
> Giving that in this case I would be talking about a solaris system, I
> have thought about using simple scripts to watch for the interface to
> go down and reconfigure.  I am curious if anyone knows of any
> hardware/software solutions for doing this?  I am guessing that I am
> not the first person to ask for something like this.

Brian


> 
> -- Kevin
> 

-----------------------------------------------
Brian Feeny, CCNP, CCDP       [EMAIL PROTECTED]   
Network Administrator         
ShreveNet Inc. (ASN 11881)            

_________________________________
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to