NETWORK PRESENCE ABOUT SERVICES PRODUCTS TRAINING CONTACT US SEARCH SUPPORT
 


Search
display results
words begin  exact words  any words part 

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [FW1] Multiple WAN Links.



Will the Rainwall help me in this configuration..


ISP A          ISP B
   |              |
   T1            xDSL
   |              |
  Router        Router
193.193.193.1   194.194.194.1 
           |
          LAN
           |
       Web Server
193.193.193.5 / 194.194.194.6

So, I have a web server , It's got dual IP address of

193.193.193.5 and
194.194.194.6

so, I need traffic to be always routed in a symertic way...
i.e. if the first packet of a connection comes in from ISP A
(connection to 193.193.193.5)
it should always be routed back through ISP A. If a connection
comes into the web server via ISP B (194.194.194.6) then it's 
routed back through ISP B

I've cracked the load balacing bit for DNS, and it work's well,
but if I define default routes on the web server,
I've got no idea's which route the traffic is going to take on
the return path....

d/g 0.0.0.0 193.193.193.1
d/g 0.0.0.0 194.194.194.1 

So, I rekon the operating system will route traffic in an unpredicatble way,
it be really nice if connections to 194.194.194.6 port 80, were routed back
via the 194.194.194.1 router, but my ip knowlage tell's me that's not 
going to really happen, as routing is done at network level, and does not
take into consideration the source IP address when replying....
or does it??? I've not tested it...but this article look like doom and gloom
to this idea...


is there anyway I can tell the operating system to route symetric way?..
(i.e. the source address of a returning IP packet's is linked to the 
gateway choosen to route the actually traffic)

The only way I can think around it, is to add static routes
(detrimined from the source IP of the incomming connection).
this could be dangerous for my web server's heath, I'd rather have just
two default gateway, rather than add static router (around 80,000)  :-(.

Now, running BGP-4 not going to help me really, I'm looking for low cost
fault tollerance, which can be done with out /22 /24 block, and expensive
bgp-4 routers......

hope you guy can help.
Cheers,
Lee


-----Original Message-----
From: iden fw [mailto:[email protected]]
Sent: 04 November 2000 02:46
To: [email protected]; [email protected]
Cc: [email protected]; [email protected]
Subject: RE: [FW1] Multiple WAN Links.



Comments in-line...


>From: "Mark L. Decker" <[email protected]>
>Reply-To: <[email protected]>
>To: "'iden fw'" <[email protected]>, <[email protected]>
>CC: <[email protected]>, <[email protected]>
>Subject: RE: [FW1] Multiple WAN Links.
>Date: Fri, 3 Nov 2000 15:58:52 -0800
>
>iden_fw wrote:
> > Regarding the negatives to BGP:
> > 1. uneven load sharing --  If you have 2 circuits with the
> > same ISP, this is not an issue.  Otherwise, if you have a circuit
> > with 2 ISPs (as the original poster indicated) -- load sharing
> > becomes uneven, and requires a more
> > complex configuration.  And constant tweaking...
>
>True, but if both circuits go to the same ISP, you don't have much
>redundancy.  A problem with the carrier or ISP is likely to simultaneously
>take down both links in that case.  Using different types of links (e.g. a
>T1 and a DSL) to two different providers yields the most fault tolerant
>design.

An organization can work with their ISP to have their T1s terminate on 
different switches, and different routers.  You would be surprised how many 
customers order 2 circuits to their ISP, and then don't know that the T1s 
terminate in the same channelized DS-3 card in the same Cascade 9000/500 
switch, that can ride the same fiber over to the ISPs router.  Or maybe you 
wouldn't be surprised... ;)

Some ISPs even offer the ability to terminate a T1 in another POP.  More $$

Telco could be the problem... if both circuits are ordered from the same 
carrier, and ride common facilities... again, alot of times customers do not

ask for circuit path diversity.

> > How does Rainfinity load-balance incoming traffic?
>
>For connections initiated from inside, the return traffic is load balanced
>because the source address alternates between the two ISP ranges as it 
>heads
>out.  For connections initiated from outside to a webserver hosted
>internally, RainWall doesn't do any load balancing of the links.  You'd 
>need
>some kind of intelligent DNS to do that, maybe custom scripting or a 
>product
>like 3DNS.

Yet another product to configure, troubleshoot, keep up-to-date on patches, 
purchase, support contracts... ugh.

> > 3. requires AS number and cooperation from both ISPs --
> > Requires little
> > effort, and a little $.  The only cooperation you need from
> > the ISPs is for
> > them to configure a BGP session with you, which any ISP
> > should be able to do
> > in their sleep.  I would not classify this as a negative to a
> > BGP solution.
>
>Sure, if you are a big company with your own Class B (i.e., clout).  If
>you're a smaller company, many major ISPs won't peer with you.  They don't
>want to be bothered advertising your routes unless you have a dozen Class
>C's or more.  Some smaller ISPs may have more lenient BGP peering policies,
>but even they tend to draw the line at a full Class C.  Those using NAT 
>with
>a CIDR block smaller than /24 are typically out of luck.

You don't need to peer with your ISP, and you don't need a Class B.  You 
just need to establish a BGP session.  Any ISP should be able to setup a BGP

session with a customer.

The /24 is a valid point.  The large ISPs tend to accept route announcements

less than a /24, but will not advertise those routes to their peers.

> > 4. giant routing tables that eat gobs of router CPU and RAM,
> > etc -- ;)  A
> > full routing table is in the neighborhood of 88000 network
> > entries.  I have
> > recommended, that if you are going to take full feeds from 2
> > providers on
> > one router that the customer have 128 megs on at least a  36XX Cisco.
>
>I agree.  That would be my minimum spec as a BGP router; 128M should be 
>able
>hold the ever-growing routing tables for at least a year or two.  If you
>don't want the router to be a single point of failure, I'd recommend two of
>them with HSRP.

;)  That's exactly what I was referring to...

> > What is the list price of a Rainfinity solution?  What are
> > the maintenance
> > contract costs?
>
>RainWall is US $5,000 for active/standby, or US $12,000 for active/active
>with load balancing.  Standard support is 25% of the software list price 
>for
>a 1-year contract.  For comparison, a pair of Cisco 3640s with 128M DRAM
>running BGP/HSRP will cost over US $24,000, before you even put any LAN or
>WAN modules in them.

So that's $3,000 a year for support...

I think your estimate of $12,000 for an empty 3640 chassis might be a bit 
high.  Maybe not...

>Mark L. Decker
>Rainfinity

Bottom line is that redundancy is a very expensive word.  We haven't even 
discussed redundant power, ethernet switches, redundant switches/routers for

the inside of the firewall, etc...



-iden_fw
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.



============================================================================
====
     To unsubscribe from this mailing list, please see the instructions at
               http://www.checkpoint.com/services/mailing.html
============================================================================
====


================================================================================
     To unsubscribe from this mailing list, please see the instructions at
               http://www.checkpoint.com/services/mailing.html
================================================================================



 
----------------------------------

ABOUT SERVICES PRODUCTS TRAINING CONTACT US SEARCH SUPPORT SITE MAP LEGAL
   All contents © 2004 Network Presence, LLC. All rights reserved.