cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
589
Views
10
Helpful
6
Replies

Routing question OSPF, BGP - Main Site and DR

wilson_1234_2
Level 3
Level 3

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.

6 Replies 6

wilson_1234_2
Level 3
Level 3

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)

Jon Marshall
Hall of Fame
Hall of Fame

Hi

Could you send the full config of your DR router as we need to see the advertise and non-exist maps.

Jon

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

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

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?

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?

Getting Started

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco