[prev in list] [next in list] [prev in thread] [next in thread] 

List:       firewalls-gc
Subject:    Re: Two ISP's to one DMZ
From:       David Lang <dlang () diginsite ! com>
Date:       1997-07-10 12:54:17
[Download RAW message or body]

My company is in the process of setting this up. we are using a cisco 4700
router connecting to two T1 lines to sprint one in So-Cal on in Texas to
provide us with load balancing and failover capability. in this case both
links are with Sprint but that is a temporary thing. we have 2 class C
address spaces we got from Sprint that we now can link to other services.
Sprint will not support using a 4700 router for full internet routing
tables so we will be upgrading to a 7500 series router when we make the
connection in a few months to other services. We have had these class C
addresses for over a year as a normal link before we decided that we
needed the redundancy and went to BGP4. It's not cheap but is the right
way to go.

David Lang
Digital Insight


On Thu, 10 Jul 1997 mikech@avana.net wrote:

> 
> 
> ------------------------
>   From: Paul Ferguson <pferguso@cisco.com>
>   Subject: Re: Two ISP's to one DMZ 
>   Date: Wed, 09 Jul 1997 17:25:23 -0400 
>   To: "Mark Horn [ Net Ops ]" <mhorn@funb.com>
>   Cc: Firewalls@GreatCircle.COM
> 
> 
> > At 11:40 AM 07/09/97 -0400, Mark Horn [ Net Ops ] wrote:
> <Snip!>
> > 
> > I have no idea what you are referring to with regards to "BGP also
> > requires that you have portable address space" -- this is certainly
> > incorrect. Perhaps you meant something else, or meant it in a
> > different context?
> > 
> 
> Nope, as I stated previously, how do you route one ISP's CIDR addresses 
> through another ISP? Are you saying I can grab a chunk of Sprint's CIDR 
> (Classless Inter-Domain Routing) address space and reroute it thorugh MCI? 
> Will it be added to the MCI routing tables as a separate entry? How will 
> Sprint remove the class C from its CIDR block? Won't this fragment the hell 
> out of the backbone routing tables?
> 
> I understand you have quite a few resources available (Cisco is a pretty big 
> company after all ;^). Do you have any real world examples of BGP being used 
> by a company with a couple of class C's supplied by an ISP to route in a 
> failover situation through another ISP?
> 
> > >Having only looked at it superficially, dynamic DNS + NAT seems like a
> > >workable solution when BGP isn't available.  But if BGP is available, it
> > >seems better.  And that's simply on a performance basis.  BGP also
> > >provides policy setting that DNS doesn't.
> > >
> > 
> > Exactly how does NAT and DNS provide for the announcement of AS's
> > and/or prefixes into the global routing system?
> 
> It doesn't. It is an *alternate* solution. You can remap Internal address 
> space to multiple external IPs. These IPs could even come from different ISPs. 
> The dynamic DNS allows you to remap inbound connections by changing the IPs a 
> domain name is associated with in real time.
> 
> See my previous post for an example of a multi-homed NAT failover example.
> 
> <Snip!>
> > 
> > --
> > Paul Ferguson                                           ||        ||
> > Consulting Engineering                                  ||        ||
> > Herndon, Virginia   USA                                ||||      ||||
> > tel: +1.703.397.5938                               ..:||||||:..:||||||:..
> > e-mail: pferguso@cisco.com                         c i s c o S y s t e m s
> > 
> 
> ---------------End of Original Message-----------------
> 
> Mike
> --
> 00:29:36
> 07/10/97
> _______________________________________________________________________
> Michael W. Chalkley                                Tel: +1.770.823.7846
> ZapNet! Inc.                                       Fax: +1.770.475.7640
> Suite 400-120                                   E-mail: mikech@well.com
> 10945 State Bridge Road                                mikech@avana.net
> Alpharetta, GA 30202                    (wireless) mikech@radiomail.net
> 
> 

[prev in list] [next in list] [prev in thread] [next in thread]