06-14-2007 01:03 PM - edited 03-03-2019 05:26 PM
I am wondering how a certain subnet gets routed into the DR site using BGP during a disaster scenario.
We have our Main site that has an Internet router with an ethernet IP Address 6.2.1.129 (not real)
Our firewall at the Main site has it's outside interface in this subnet and all web servers under normal conditions are NATed to this subnet thru firewall. Our hosted DNS Zone file has host names resolving to this subnet.
During a failover where the Main MPLS router is shut down, the DR site is supposed (has been tested)to start advertising the 2.1.1.65 subnet out of the DR site. The web clients have connectivity to the DR servers via static NAT translations from the 2.1.1.65 subnet.
Does the BGP advertise this route and has the DR internet router as it's Next hop? to get to it?
If so, the DR PIX that has the static NATs set up in the 2.1.1.64 (Main Site) subnet on the outside Interface, has it's outside interface configured in the DR subnet of 6.2.1.128 subnet.
Are the static NATs in the DR PIX to the Main Site Internet subnet, like secondary addresses on routers?
I don't see how this works, attached are configs.
If I wanted to put a device (CSS) to redirect the servers on the inside network, I am not sure how I would set up the interface in between the router and the PIX.
06-14-2007 02:18 PM
Sorry this line :
We have our Main site that has an Internet router with an ethernet IP Address 6.2.1.129 (not real)
Should be:
We have our Main site that has an Internet router with an ethernet IP Address 2.1.1.65 (not real)
06-15-2007 02:11 AM
Hi
Could you send the full config of your DR router as we need to see the advertise and non-exist maps.
Jon
06-15-2007 04:34 AM
Thanks for the reply jon,
I have posted the relevant lines:
Dr Site Router
interface FastEthernet0/0
description Connected GI1/0/6$ETH-LAN$$FW_INSIDE$
ip address 6.2.1.129 255.255.255.224
ip access-group 102 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip nbar protocol-discovery
ip flow ingress
ip flow egress
ip route-cache flow
duplex auto
speed auto
no mop enabled
!
interface Serial0/0
bandwidth 1536
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
encapsulation frame-relay IETF
ip route-cache flow
no dce-terminal-timing-enable
service-module t1 timeslots 1-24
frame-relay lmi-type ansi
!
interface Serial0/0.1 point-to-point
description $FW_OUTSIDE$
bandwidth 1536
ip address 6.6.1.190 255.255.255.252
ip access-group 101 in
ip verify unicast reverse-path
no ip redirects
no ip unreachables
no ip proxy-arp
ip nbar protocol-discovery
ip flow ingress
ip flow egress
ip inspect SDM_LOW out
no cdp enable
frame-relay interface-dlci 500 IETF
!
router ospf 1
log-adjacency-changes
redistribute bgp 467 subnets route-map BGPtoOSPF
network 6.2.1.128 0.0.0.31 area 0
default-information originate
!
router bgp 467
no synchronization
bgp log-neighbor-changes
network 6.6.1.184 mask 255.255.255.252
network 6.2.1.128 mask 255.255.255.224
network 2.1.1.64 mask 255.255.255.224
neighbor 6.6.1.189 remote-as 71
neighbor 6.6.1.189 version 4
neighbor 6.6.1.189 soft-reconfiguration inbound
neighbor 6.6.1.189 prefix-list 1 out
neighbor 6.6.1.189 advertise-map ADVERTISE non-exist-map NON-EXIST
no auto-summary
!
ip classless
ip route 4.2.2.2 255.255.255.255 6.6.1.189
!
ip flow-top-talkers
top 20
sort-by bytes
!
no ip http server
ip http access-class 10
ip http authentication local
ip http secure-server
ip prefix-list 1 seq 5 permit 6.2.1.128/27
ip prefix-list 1 seq 6 permit 2.1.1.64/27
ip prefix-list 1 seq 10 deny 0.0.0.0/0 le 32
logging trap notifications
logging 10.1.10.26access-list 5 permit 0.0.0.0
access-list 10 permit 6.2.1.128 0.0.0.31
access-list 10 deny any log
access-list 10 remark ACL to restrict Telnet access
access-list 60 permit 2.1.1.64 0.0.0.3
access-list 61 permit 6.6.1.184 0.0.0.3
route-map NON-EXIST permit 10
match ip address 61
!
route-map BGPtoOSPF permit 10
match ip address 5
!
route-map ADVERTISE permit 10
match ip address 60
06-15-2007 04:54 AM
Wilson
Should access-list 60 read
access-list 60 permit 2.1.1.64 0.0.0.31
as opposed to
access-list 60 permit 2.1.1.64 0.0.0.3.
What the config on the DR router does re the ADVERTISE and NON-EXIST maps go is
1) The network 6.6.1.184 255.255.255.252 is advertised out of your primary site
2) The network 2.1.1.64/27 is also advertised out of your primary site.
3) If the primary sites loses connectivity to the internet then it stops advertising both networks.
4) On the DR router if it stops receiving a route for 6.6.1.184 (the NON-EXIST part) it begins advertising out the 2.1.1.64 network. That is why i think the inverse mask in access-list 60 on the DR router should be 0.0.0.31.
Not sure about the second question regarding secondary addresses. Could you elaborate.
HTH
Jon
06-15-2007 06:07 AM
Thanks Jon,
So, then, the DR router is advertising the Main site subnet.
Which means that anything destined for the Main Site subnet gets routed to it no matter if there is anything to recive the packets?
In other words there does not have to be an interface in that subnet in the "UP" condition to route to it?
The question is regarding the way the web servers are set up for failover:
Ideally, if the Internet at the main site goes down, we want the DR site to route that subnet to the servers in the Main site through the MPLS cloud.
My understanding is that this works.
It works by the PIX at the DR site having NATed addresses in the same subnet as the PIX at the Main site, even though there is nothing in the routers at the DR site with an interface in that subnet.
If the entire main site goes down, the procedure has been to manually go in and change the DR pix from the main site NATs to the DR subnet NATs and changing DNS to match the DR subnet.
I want a dynamic solution.
We have a CSS at the Main site that has VIP addresses in the 2.1.1.64 subnet and web requests are sent to it, then if the corresponding service is up, it gets sent to the Main site server, if that server is down, they get sent to DR through the Main site, then through the MPLS network.
I want to do the same thing in reverse at the DR site, to (if just Main site internet is down) route to the Main site 2.1.1.64 subnet which will be a CSS VIP, sitting in the DR site switch between the DR router and DR PIX.
If that server is down to redirect web requests to the DR server, which is in the DR subnet of 6.2.1.128.
This way DNS never gets changed and the transition is only minues.
The problem is will the traffic get to the CSS VIP in the Main site subnet of 2.1.1.64 and can I configure the CSS to send it to the two different subnets on the PIX?
06-16-2007 05:08 AM
Thanks Jon,
So, then, the DR router is advertising the Main site subnet.
Which means that anything destined for the Main Site subnet gets routed to it no matter if there is anything to recive the packets?
In other words there does not have to be an interface in that subnet in the "UP" condition to route to it?
The question is regarding the way the web servers are set up for failover:
Ideally, if the Internet at the main site goes down, we want the DR site to route that subnet to the servers in the Main site through the MPLS cloud.
My understanding is that this works.
It works by the PIX at the DR site having NATed addresses in the same subnet as the PIX at the Main site, even though there is nothing in the routers at the DR site with an interface in that subnet.
If the entire main site goes down, the procedure has been to manually go in and change the DR pix from the main site NATs to the DR subnet NATs and changing DNS to match the DR subnet.
I want a dynamic solution.
We have a CSS at the Main site that has VIP addresses in the 2.1.1.64 subnet and web requests are sent to it, then if the corresponding service is up, it gets sent to the Main site server, if that server is down, they get sent to DR through the Main site, then through the MPLS network.
I want to do the same thing in reverse at the DR site, to (if just Main site internet is down) route to the Main site 2.1.1.64 subnet which will be a CSS VIP, sitting in the DR site switch between the DR router and DR PIX.
If that server is down to redirect web requests to the DR server, which is in the DR subnet of 6.2.1.128.
This way DNS never gets changed and the transition is only minues.
The problem is will the traffic get to the CSS VIP in the Main site subnet of 2.1.1.64 and can I configure the CSS to send it to the two different subnets on the PIX?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: