Heh, well, my boss of course already had a solution for me today.
Basically, we need to move the T1 between sites outside the firewall, and
establish a VPN between them for continued access. This is so obvious that
I can't see why it didn't hit me before. It of course solves the problem of
the existing VPNs to other offices, as each PIX will just have VPNs to each
office and the two sites' internal networks won't be linked.
Tonight I got to move all IP/DNS for internal customers at the second site
to UUNET IPs. Basically went through the PIX 520 and isolated all the
configuration that needed to be added to the 515 and did so. Then I edited
all the zone files for DNS. Lastly, I created a policy route-map as I
couldn't get in touch with Corporate to set up the 515 to VPN in (and our
main Exchange box that talks to Corp. is at site 2), so the route-map just
redirects traffic from the Exchange box to the Corp network up through the
520. With all that set, I swapped the default routes and restarted the name
server, and everything just worked. By Monday, no one will no the
difference as DNS will have caught up globally.
Next step is to get all the users at site 1 upgraded to the latest NetWare
client and configured to use IP as a preference as that's all that will be
going in the IPSEC tunnel, and get the VPNs configured to the other offices
at site 2's 515. Once that's done, no reason we can't yank the T1 between
sites, move it outside the firewall, and then proceed with getting eBGP up
between our ISPs and iBGP between sites.
Internal 2621 that is the default gateway at site 2:
interface Ethernet0/0
!snipped unnecessary stuff
ip policy route-map ModestoPIX
access-list 110 permit ip host 10.12.3.8 any
access-list 110 deny ip any any
route-map ModestoPIX permit 10
match ip address 110
set ip next-hop 192.168.10.2
10.12.3.8 = Exchange box
192.168.10.2 = Site 1 Looback.
--
Jason Roysdon, CCNA, MCSE, CNA, Network+, A+
List email: [EMAIL PROTECTED]
Homepage: http://jason.artoo.net/
Cisco resources: http://r2cisco.artoo.net/
""Jason Roysdon"" <[EMAIL PROTECTED]> wrote in message
904ftt$b71$[EMAIL PROTECTED]">news:904ftt$b71$[EMAIL PROTECTED]...
> Netcom Sprint
> | \ |
> | \ |
> | 3640 -- T1s to various external IP customers
> | |
> VPN| External Hub -- Ethernet to various external IP servers
> to \ |
> Corp \--PIX 520
> | |- T1/ISDN backups to various internal IP customers
> Internal Hubs --|
> | |- Ethernet to various internal IP
> 2500 servers, PC, etc.
> | |
> T1 | | ISDN Backup
> | |
> 2621 Ethernet to various
> | |- internal IP servers, PC, etc.
> Internal Hubs --|
> | |- T1/ISDN backups to various internal IP customers
> PIX 515R
> |
> 2621 -- T1s to various external IP customers
> |
> |
> UUNET
>
> (Set your font to Courier to have the above make sense)
>
> Ok, the above is the current situation. Netcom was the first ISP and all
> IPs are from them. I'll be hammering on their phone lines tomorrow to
find
> out if I can get them to BGP with us (I've sent a ton of emails, and the
> whole Netcom -> Mindspring -> Earthlink has made their business services
> unit take a dive). If the will, that saves us renumbering all of our
> existing stuff, if not, we'll be moving to our new Sprint & UUNET IPs.
> Anyone know if Mindspring/Earthlink will exchange BGP with customers? The
> main reason why we've kept them is that they're in the same building, so
no
> telco T1, just a physical CAT5 running between CSU'/DSUs on different
> floors.
>
> Ok, the problem is that we want to get multihomed with Sprint & UUNET at
the
> least and hopefully Netcom as well. However, the ISPs are connected at
two
> different sites, which are connected via an internal network behind PIXs.
> We know we're going to have to do some design changes, so basically I'm
> looking for any input/ideas from folks that have dealt with this sort of
> thing.
>
> My thoughts were these: Take full BGP routes from Sprint to the 3640
(128mb
> DRAM). Take UUNET's own BGP routes to the 2621. Have the 3640 learn
> UUNET's BPG routes via iBGP learned from the 2621. Since the 2621 can't
> hold the full routing table, I'm not sure the best thing to do there, but
my
> thought is to just have it default all traffic out UUNET. The 3640 would
be
> able to make intelligent decisions between Sprint & UUNET (and hopefully
> Netcom). We'll probably be replacing the 2621 with a 3600 so we can take
> full routes from UUNET. BGP is totally new to me, but my boss has worked
> with it a little before.
>
> Of course the real end goal is to have things totally redundant. If the
> link to UUNET or Sprint should fail, traffic should go out the other ISP.
> I'm not sure how to do this at the 2621 should the default UUNET route
fail.
> The 3640 would know via iBGP that UUNET was dead and stop sending traffic
> that way, or to send all traffic that way if the Sprint link died. Also,
if
> the T1 failed between the sites, could we have all internal traffic pass
via
> VPN/internet and maintain a seemless internal network (I know we could
> reconfigure it to do it manually, but not sure if it can be automated).
> Basically, any of the 3 T1 fails, we've got another way around things
>
> The next thing is how do we re-work all of our internal networks and the
> PIXs? External traffic isn't a problem, assuming we could get the 3640 &
> external 2621 talking iBGP between it and allow them to send traffic
through
> the PIXs (I think... not sure), but we may need another T1 for this
external
> traffic between sites to bypass the PIXs.
>
> Internal traffic trying to get to the internet, what are our options for
> intelligently routing it? My thought would be both sites default out
their
> PIXs, and once outside the BGP routers send it either to the ISP, or
across
> the internal T1 to the other BGP router and out that ISP. Of course
> crossing the PIX twice adds latency, but hopefully not enough to get rid
of
> the advantage of intelligent BGP routing.
>
> Then there are the VPNs to our different branches that we don't maintain,
> but need connectivity. They each have PIXs and VPN tunnels to them. No
> VPNs come to the PIX 515 at the second site, but we'd like to have a
backup
> VPN tunnel out the ISP there as well. Haven't the slighest idea how to
make
> this work other than manually reconfigure in the event of a T1/ISP
failure.
>
> Thoughts? Points where I should clarify (or most likely, need
clarification
> on what exactly can be done, heh)?
>
> --
> Jason Roysdon, CCNA, MCSE, CNA, Network+, A+
> List email: [EMAIL PROTECTED]
> Homepage: http://jason.artoo.net/
> Cisco resources: http://r2cisco.artoo.net/
>
>
> _________________________________
> 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]
