WAN migration - multiple OSPF processes

tim.heizer · ‎02-11-2011

I am trying to wrap my head around a cutover to a new WAN provider, specifically surrounding the OSPF routing.

Currently, I have 3 sites connected via an AT&T MPLS cloud – a data center with 2 6509s and two other sites with 4506’s. We are bringing up a TWT Layer2 ENLAN solution between all 3 sites. Each site will see the devices at the other sites as if they were sitting in the next rack.

For routing, we have OSPF implemented at each site which redistribute into our WAN provider’s BGP. Below are the routing configurations for each site as they are today:

SITE A - DataCenter CoreSW:

router ospf 10

router-id 10.2.1.252

log-adjacency-changes

auto-cost reference-bandwidth 10000

area 0 authentication message-digest

redistribute connected subnets tag 10

redistribute static subnets route-map STATIC-OSPF

passive-interface default

no passive-interface Vlan9

no passive-interface Vlan600

network 10.2.1.252 0.0.0.0 area 0

network 10.0.0.0 0.31.255.255 area 0

network 10.60.0.0 0.0.0.255 area 0

network 10.101.0.0 0.0.0.255 area 0

network 10.240.10.0 0.0.0.255 area 0

!

ip default-gateway 10.3.2.1

ip classless

ip route 0.0.0.0 0.0.0.0 10.3.2.1 115

ip route 10.64.0.0 255.240.0.0 10.253.253.254 tag 10

ip route 10.80.0.0 255.240.0.0 10.1.0.254 250

ip route 10.144.0.0 255.240.0.0 10.1.0.254 250

ip route 10.250.64.0 255.255.255.0 10.1.0.250

ip route 10.250.80.0 255.255.255.0 10.1.0.254

ip route 10.250.152.0 255.255.255.0 10.1.0.254

ip route 172.16.96.0 255.255.255.0 10.3.2.1 tag 10

ip route 192.168.129.0 255.255.255.0 10.3.2.1 tag 10

ip route 192.168.224.0 255.255.255.0 10.3.2.1 tag 10

ip route 192.168.225.0 255.255.255.0 10.3.2.1 tag 10

!

route-map STATIC-OSPF permit 10

match tag 10

!

Site B

router ospf 10

log-adjacency-changes

redistribute connected subnets tag 20

redistribute static subnets route-map STATIC-OSPF

passive-interface default

no passive-interface Vlan300

network 10.80.0.0 0.15.255.255 area 0

network 10.240.10.0 0.0.0.255 area 0

!

ip route 0.0.0.0 0.0.0.0 10.80.212.250

ip route 10.0.0.0 255.224.0.0 10.80.0.254 250

ip route 10.152.0.0 255.255.0.0 10.80.0.254 250

ip route 10.250.1.0 255.255.255.0 10.80.0.254

ip route 10.250.64.0 255.255.255.0 10.80.0.254

ip route 10.250.152.0 255.255.255.0 10.80.0.254

ip route 172.16.96.0 255.255.255.0 10.80.0.254 250

ip route 172.16.224.0 255.255.255.0 10.80.212.254 tag 20

ip route 172.16.230.0 255.255.255.0 10.80.212.254 tag 20

ip route 192.168.1.201 255.255.255.255 10.80.212.254

ip route 192.168.1.203 255.255.255.255 10.80.212.254

ip route 192.168.1.206 255.255.255.255 10.80.212.254

ip route 192.168.15.254 255.255.255.255 10.80.212.254

ip route 192.168.129.0 255.255.255.0 10.80.0.254 250

ip route 192.168.224.0 255.255.255.0 10.80.0.254 250

ip route 192.168.225.0 255.255.255.0 10.80.0.254 250

!

route-map STATIC-OSPF permit 10

match tag 20

Site C

router ospf 10

router-id 10.152.200.2

log-adjacency-changes

auto-cost reference-bandwidth 10000

redistribute connected subnets tag 30

redistribute static subnets route-map STATIC-OSPF

passive-interface default

no passive-interface Vlan300

no passive-interface Vlan600

network 10.144.0.0 0.15.255.255 area 0

network 10.250.152.0 0.0.0.255 area 0

!

ip route 0.0.0.0 0.0.0.0 10.152.212.250

ip route 10.0.0.0 255.224.0.0 10.152.0.254 250

ip route 10.80.0.0 255.255.0.0 10.152.0.254 250

ip route 10.152.208.253 255.255.255.255 Loopback0

ip route 10.250.1.0 255.255.255.0 10.152.0.254

ip route 64.126.100.101 255.255.255.255 10.152.212.250

ip route 64.126.100.104 255.255.255.255 10.152.212.250

ip route 172.16.96.0 255.255.255.0 10.152.0.254 250

ip route 172.16.246.0 255.255.255.0 10.152.212.254

ip route 192.168.129.0 255.255.255.0 10.152.0.254 250

ip route 192.168.150.0 255.255.255.0 10.152.212.254 tag 30

ip route 192.168.224.0 255.255.255.0 10.152.0.254 250

ip route 192.168.225.0 255.255.255.0 10.152.0.254 250

!

route-map STATIC-OSPF permit 10

match tag 30

The end game should have OSPF at each site neighbored directly to each other advertising the networks at each site as OSPF intra-area routes, no redistribution required as we would have layer 2 connectivity between sites. I would configure a single interface at each site as a routed interface (all on the same subnet) that would be the non-passive interface for the new OSPF process.

My confusion is surrounding the migration process. Not all sites are being turned up at the same time. Site A and Site B will be turned up first and then weeks later, Site C.

I thought about configuring a second OSPF process at each site and then shutting down the AT&T interfaces once all 3 sites are up. If I have two completely separate OSPF processes running on each core switch, and the same networks are listed in each process, will I have one E2 route(from AT&T redistribution) and one O route(from the TWT OSPF) for each network? If so, since they are separate OSPF processes, will there be any preference at all between the external E2 route from one process and the Intra-area route from the other?

Is there a better, simpler way to do this migration?

What if I made my newly allocated TWT interfaces at each site a non-passive interface in my existing OSPF process? Would I then see an E2 route and an intra-area O route for each remote network?AND, would the intra-area route take preference over the E2 route? Am I at risk for any redistribution loops? If this worked, would I then just shut down/pull the cable on the AT&T WAN interface and all my E2 routes would go away leaving just my intra-area routes?

Thanks for any insight and guidance on this!

Richard Burts · ‎02-16-2011

Tim

There are several things that we do not know about your network and they might impact the advice that we would give you. But I have these comments and suggestions which I hope will be helpful.

I do not grasp the need for so many static routes in the presence of a dynamic routing protocol but maybe there are good reasons for doing it the way that you are doing and maybe if we knew more about the topology of the network we would understand better the logic for statics.

You mention the ATT routes as being external routes in OSPF, but I do not see where any routing protocol is being redistributed into your OSPF. (or is it perhaps the case that you are configuring static routes for the ATT routes?)

One thing to bear in mind about having multiple OSPF processes is that an interface can be active in only a single OSPF process.

My suggestion would be to have only a single OSPF process. If routes are being learned via OSPF advertisement (they are inter and intra area routes) then they will be preferred over external routes. It seems to me that this is the easy way to handle the transition. If a route is learned only via ATT then it is in the table as an OSPF external. As OSPF forms neighbors directly with other sites the routes will be learned as internal routes and will automatically be preferred to the external alternative.

HTH

Rick

HTH

Rick