Outbound Filtering OSPF routes

[hoelpf1]

We are prepping to move a datacenter. The concept is to move our servers by subnets, ie at the old data center shut down the interface vlan (for example) 10.10.200.1/24 and at the new data center bring up the interface vlan 10.10.200.1/24 and let OSPF advertise where the route now exists. And then to move all servers in that subnet.

This will work fine, however I would like to have a failsafe, so that if someone makes a mistake and brings up an interface vlan at the new datacenter that they shouldn't, OSPF will not automatically cause an outage for that subnet at the old data center. My thought as to this fail safe was to also filter and control what the new data center advertised out of it's WAN link to area 0.

We have a 4 tiered design, with WAN, Core, Distribution, Access Layer. Connection between Dist. and access is L2, all else is L3.

The WAN is a border router between area 0 (the rest of the organization) and area 208 (the new data center).

We have several campuses with a "4 Tier" design all connecting to area 0 at the WAN.

What are some of my options on how to accomplish this?

TIA,

Peter

[abdel_n]

Hi,

One of the OSPF advantages is that it supports VLSM and as you have to advertise vlan subnets with masks /24 OSPF will advertise subnets you will assign in the command :

router(config-router)#network area

So to remove servers in 10.10.200.1/24), you just assign the appropriate wildcard mask to make OSPF advertise only this subnets :

router(config-router)#network 10.10.200.1.0 0.0.0.255 area 208

and each time you remove a new subnet you add it to ospf neyworks :

router(config-router)#network 10.10.200.2.0 0.0.0.255 area 208

then

router(config-router)#network 10.10.200.3.0 0.0.0.255 area 208

...

When you remove all servers you can summarize all subnets into one super subnet using one of those commands:

- On ABR: router(config-router)#area <128> range

- On ASBR: router(config-router)#summary-address

I hope this will help you.

Good work !

[mchoo2005]

I'm not sure if you're aware that filtering with OSPF is not quite as effective as other routing protocols, due to its being link state protocol. For instance, outbound filtering will only work on ASBRs, to filter OSPF routes from being redistributed into other routing protocols. Inbound filtering works on all other routers, BUT, will only stop routes from being installed in the routing table, but the LSAs for those routes will still be accepted and stored in the link state database.

Personally, I'd use BGP if I need granular control of what routes to allow and disallow.

HTH.

[hoelpf1]

Thanks all for your replies, using the network statement doesn't work for us in our case as we need the routes functioning within the new data center just not outside of it. Changing routing protocols is not practical, particularly in the middle of a data center move.

Here's what we ended up doing. Posting a reply from TAC. ip prefix lists:

If I understand your question correctly you're adding a new datacenter to your network - this datacenter will also be a new area for ospf - you would like to restrict the prefixes advertised out that area into area 0 to prevent connectivity issues as servers within that prefix could still be in the old datacenter, is that correct?

What you can do is put a prefix list on the datacenter ABR(s) that will filter the updates that go from area 208 into area 0.

router ospf x

network area 0

network area 208

area 208 filter-list prefix out

ip prefix-list seq 5 permit ...

ip prefix-list seq 999 deny 0.0.0.0/0 le 32

So even if a network statement for a vlan that should not be advertised out the new datacenter is configured, it will not be advertised into area 0 as long as it is not specifically permitted by the prefix-list as well. Prefix-lists have numbered statements, my recommendation would be to start with seq 5 - add 5 every time another network can be advertised

- leave 999 for the statement that blocks everything else (in prefix-list language deny 0.0.0.0/0 le 32 means deny everything else)

-> you're free to insert lots of networks as the migration moves on.

Here's a few URLs that can clarify the usage of these commands:

area filter-list:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124tcr/tirp_r/rteospht.htm#wp1115412

ip prefix-list:

http://www.cisco.com/en/US/customer/products/ps6350/products_command_reference_chapter09186a0080454ced.html#wp1075035

Only exception on this was we needed to follow all the prefix list statements with le 32 at the end. This was the perfect solution.