Hey Andy
How comfortable are you with NAT?
Ill be honest, that although this is something nice to play with, you should
really consider if this is worth supporting after implemented.
I personally would advise against silly setups like this as it almost always
points to poor design and a client wanting a one stop solution without
spending money.
I have not considerate the limitations or options of your intranet
application, so use this as a framework
Assume the following schematics:
10.0.0.1----HQ_CE1-------PE1- - - - -MPLS- - -
-PE2---------DR_CE2---------10.5.0.1
Meeting your first point.(failover)
Providing the failover and failback from the MPLS perspective is pretty
easy.
I would do this using static routes, as you want to utilize track statement
in case either server (HQ or DR) or either CE router goes down.
Using ipsla and track statements as follow on PE1 and PE2 routers:
ip sla monitor 1
type echo protocol ipIcmpEcho 10.0.0.1 !!!server at HQ or DR !
frequency 5
ip sla mon schedule 1 life forever start now
!
track 1 rtr 1
track 11 interface S0/0 line-protocol !! PE-CE link !!!!
!
track 111 list boolean and !!! Both must be up to be used!!!
object 1
object 11
The static routes on the PE1 to HQ will only be used if the CE router and
the Server is up.
ip route vrf BOB 10.0.0.1/32 ser0/0 track 111
The Intranet IP (10.0.0.1) used by other CE branches will also be routed to
the the DR site (backup).
But be sure failover and failback is taken care of. Remember its MPLS.
For failover adding the backup route with an AD of 220 to the static route
will suffice.
(why? because iBGP uses a default AD of 200)
The static route on PE2 to DR should look something like so
ip route vrf BOB 10.0.0.1/32 ser 0/0 track 111 tag 80 220
For failback a route-map as follow matching the tag 80 will be used.
It says for traffic matching tag 80, set the BGP local pref to 80 (less than
100 default)
and change the cisco weight from default 32768 for local routes to 0)
Something like this:
route-map BACKUP-DR permit 10
match tag 80
set local-preference 80
set weight 0
!
route-map BACKUP-DR permit 20
!
router bgp 12345
address-family ipv4 vrf BOB
redistribute static route-map BACKUP-DR
Resetting the weight to zero is important, else all other CE sites
connecting to PE2 will ALWAYS prefer PE2,
since BGP give locally attached routes (backup) a weight of 32768, (first
on the BGP-route selection list)
That takes care of your routing, failover and failback, but no backup server
reachability yet.
On CE2 a single NAT should take care of backup traffic to the Intranet
server when the HQ is down
ip nat inside source static tcp 10.5.0.1 80 10.0.0.1 80 extendable
This meets your first requirement.
- - -
The second point, will depend on the WEB applicationg and how it
'synchnronizes'
Since the servers will still have connectivity to each other via native IP's
(HQ=10.0.0.1 and DR 10.5.0.1), and provided synchronization DOES NOT happen
on port 80
will there be happiness in BOBs DR valley.
If the two servers/their application only synchronize using port 80, (and
this cant be changed)
it will pose a problem.
That could be fixed by doing 2-way NAT using ACL's. (above NAT statement
replaced)
*** forgive typos :) ***
But like I said consider carefully to pros and cons from a support/business
perspective if you should recommend this to your client.
Rather suggest a recommended solution and generate money on a supportable
solution :)
HTH
-- <ruhann> www.routing-bits.com On Wed, Apr 21, 2010 at 9:06 AM, andy thomas <thomasandy32_at_gmail.com> wrote: > Hello Experts, > > > DR Topology > > > CE----PE(DIST)------PE(CORE)------ISP(PE)----(ISP MPLS CLOUD with PE's > where all other customers are connected) > > Sorry Ruhann to reply late,i was stuck is something else. > > The HQ and the DR are connected to different PE. There are not any backdoor > link between the DR and the HQ. > The DR is a carrier supporting carrier ,and each customer in DR is > connected via a back to back VRF with the ISP PE router. > > Hello Pradeep, > > As per ur previous mail u told me that it can be done through AS-path, why > we need this??? As per my knowledge each branch routers have the routes to > HQ and DR, when the HQ fails totally the routes of HQ will disappear from > the routing table of the CE router's and hence users have to open a new > session with the new IP of web application that is located in DR, but what i > want is a seemless failover without chaging the IP address of the web > application > > I have read about content switching switches but i m still in doubt, and > also i don't have content switches in my enterprise. > > Thanks > > > > On Sat, Apr 10, 2010 at 1:12 PM, Ruhann <groupstudy_at_ru.co.za> wrote: > >> Hi andy >> >> Please advise the MPLS setup in more detail. >> Are the HQ and DR site connecting to the same PE or different PE routers? >> Are there any backdoor links between the HQ and DR site? >> >> This is possible... >> >> On Wed, Apr 7, 2010 at 10:18 PM, andy thomas <thomasandy32_at_gmail.com>wrote: >> >>> Hello Experts, >>> >>> >>> >>> HQ-------------MPLS CLOUD --------------- Branch Office >>> >>> | >>> >>> | >>> >>> DR >>> >>> >>> >>> I m on a DR site, >>> >>> >>> Customer requirement is he want his intranet server in HQ (http:a kind >>> of >>> internal Web application) should be failover to DR site whenever the >>> power >>> from the HQ is totally shutdown.this means whenever there is a power >>> outage >>> in HQ , branch office's should continue working with their worflow, they >>> shld access the internal web application through DR site, >>> >>> >>> >>> AND >>> >>> >>> >>> Also customer need the replication (mirroring) of the main server to DR >>> site >>> whenever the changes are applicable in the server, He needs the database >>> replication from HQ end to DR side,incase of any failure, the database >>> shld >>> be accessible from DR site, >>> >>> >>> >>> How can i achieve this. >>> >>> >>> >>> thanks, >>> >>> >>> Blogs and organic groups at http://www.ccie.net >>> >>> _______________________________________________________________________ >>> Subscription information may be found at: >>> http://www.groupstudy.com/list/CCIELab.html >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> -- >> <ruhann> >> www.routing-bits.com Blogs and organic groups at http://www.ccie.netReceived on Thu Apr 22 2010 - 17:53:41 ART
This archive was generated by hypermail 2.2.0 : Sat May 01 2010 - 09:49:57 ART