OSPF areas

[kunal-united]

Hi,

My topology is a star topology.

I have a central router connected to all branches. Central router and branches are communicating with each other using OSPF in Area 0.

I handle all the routers.

Problem: There is another branch which is recently come up running OSPF in Area 1. And this branch wants to communicate with only one particular branch office in Area 0.

So in this case my central router would be the ABR. and this central router is communicating with the branch router in Area 1

So how should I implement the configs on the router running OSPF in area 0.

Should I have to create route-maps for outbound filtering. i.e.configure route map on the central router to allow only one subnet to get advertised to the recent intoduced branch

Or should I have to do redistribution.

Kindly show me some scenarios, because i have no idea about this stuff

[Richard Burts · Accepted solution]

kunal

The situation you describe is not easy to solve in OSPF. One of the assumptions within OSPF is that all routers participating in the OSPF should have equivalent link state data bases which essentially means that they should all know the same routes. I believe that the effective solution will depend more on access list filtering on interfaces of the central router (and perhaps the router in area 1) to permit traffic to and from the router in area 1 and the single branch that they want to communicate with.

To go a little deeper into the explanation: if you want to control routing updates so that area 1 only sees routes for the subnet of the branch in your enterprise you could run 2 OSPF processes on your central router. One OSPF process would be the one that you already run for routers in your network. The second OSPF process would be for the central router and the branch in area 1. You would redistribute between the processes and the redistribution would allow you to filter so that you only advertise the single subnet desired to the router in area 1. So area 1 would only know about the single branch. But the weakness in this is that the subnet of area 1 will be advertised to all routers in your enterprise so all your branches will see the subnet of area 1. So this is not a complete solution.

HTH

Rick

[ariela]

Hi Rick,

what about using static routes?

net1 -- R1 -- R2 -- net2

Now R1 and R2 are ABR for area1 and areaX. Between R1 and R2 there is the transit area.

I agree with you, your explanation is very clear. But ...

on R1: static route to net2 (nh: R2)

R1 knows where is R2 (routing table < ospf)

on R2: static route to net1 (nh: R1)

same as R1, R2 knows from ospf

No redi static on R1 and R2, and no redi connected on R1, on ospf process, that is the ospf database ignores where net1 is; but net2 is reachable from ospf cloud, because is on areaX, and R2 is an ABR router. In my opinion area1 is not necessary. In this case, branch1 on net1 knows only branch2 on net2, but branch2 knows branch1 (static route) and the enterprise cloud (ospf). For ospf database, R2 is always an ABR router, and R1 will be an ASBR.

HTH

Andrea

[Richard Burts · Accepted solution]

Andrea

Static routes are a creative thought but I think that they have essentially the same problem as what I described about using OSPF. And part of the difficulty is that I believe that the topology in the original post is different from what you are using in your solution. You assume that there are just 2 routers and R1 and R2 need to communicate. But the original post described a star topology in which the router in area 1 is connected to the center router (hub) and needs to communicate with only one other branch router in area 0. You could put a static on the router in area 1 pointing to the subnet(s) in the other branch router and that is fine. But then you need to put a static on the hub router pointing to the area 1 subnet(s). And now how do you prevent the other branch routers from forwarding to the hub and reaching the area 1 router?

HTH

Rick

[ariela]

Hi Rick,

the router on area 1 is an ABR, o just a simple area 1 device?

I've understood the first case, but maybe I've made a mistake. Then the hub router is the ABR too for area 1?

Regards

Andrea

[Richard Burts]

Andrea

I believe that this line from the original post answers the question about topology:

So in this case my central router would be the ABR. and this central router is communicating with the branch router in Area 1

This seems clear to me that the hub is the ABR and the branch router is just in area 1.

HTH

Rick

[ariela]

Hi,

you said:" You could put a static on the router in area 1 pointing to the subnet(s) in the other branch router and that is fine. But then you need to put a static on the hub router pointing to the area 1 subnet(s). And now how do you prevent the other branch routers from forwarding to the hub and reaching the area 1 router?"

I put a static on the router "in area 1" (R1) pointing the hub router (and the hub router how where net2 is, from ospf), and eliminate the area 1 configuration (no routing protocols on R1). Then I put a static to net1 on hub router pointing to R1.

Then:

- if the areaX is a stub area, no more confs

- if not, I put a static on the router R2 in areaX pointing the hub router for the net1

Obviously, no static redistribution on ospf process. I know, that's a bad design, but I think it works.

Please let me know

Andrea

[Richard Burts · Accepted solution]

Andrea

I am not clear what you are saying about areaX. The original post specified that the hub and existing branches were all in area 0 and that the new router was in area 1. So there is no areaX.

So lets assume that in area 0 they want branch B2 to communicate with area 1 router but not want B1 or B3 to communicate with area 1. If the hub router has a route to the subnets in area 1, how do you prevent B1 or B3 from sending traffic to the hub (perhaps via default route) and having that traffic get to area 1?

I guess if we want a really esoteric solution we could configure a GRE tunnel between B2 and area 1 router. Each router could have a static route for the tunnel end point which uses hub as next hop so the tunnel can pass traffic. And then configure static routes on area 1 router and B2 getting to each other via GRE tunnel.

HTH

Rick

[ariela]

Rick,

my idea was:

- there isn't an area 1

- R1 has a static to B2 branch network pointing to hub router

- the hub router has a static to R1 branch network pointing to R1

- no routing processes between R1 and the hub router

- B2 has a static to R1 branch network pointing to hub router

Probably I'm in trouble, but if I don't use a static redistribution on ospf process, B1 or B3 routing table wont have the R1 branch network entry, is it?

B2 on my design could be an ABR or not, np (but I agree with you, the original post specified that B2 is a simple area 0 router, and not an ABR for areaX, I'm sorry).

Please let me know

Andrea

[Richard Burts]

Andrea

You have changed a number of things from the original post. But you pose an interesting scenario on its own merits and we can discuss it as long as we realize that it is no longer a discussion of the original situation.

Given what you suggest here, I agree that B2 and R1 would be able to communicate with each other. What do you suggest to prevent traffic from B1 or B3 from being forwarded to the hub and then forwarded to R1?

HTH

Rick

[kunal-united]

Thank you rburts and Andrea. I have learnt alot.

But, ruburts if you can post a sample config for the routing process, it will be very helpful on the redistribution between area0 and area 1

[ariela]

Hi Rick,

if between R1 and hub-router there are no routing protocols, how R1 could be informed about B1/B3 networks?

Thanks again, Rick, for your patience: my post was in some points a little bit confused ;)

Regards

Andrea

[ariela]

Hemm ...

another thing that could be interesting:

http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a00804556f4.html

HTH

Andrea

[Richard Burts]

Andrea

I agree this could be interesting. And I think it is easy to misunderstand what it accomplishes. OSPF has always supported the use of distribute list and this feature provides a somewhat more flexible approach to what the distribute list can filter. But bear in mind that a distribute list controls what goes into the local routing table and does not control what goes into the OSPF Link State Data Base. To quote from the link that you posted:

Users can define a route map to prevent OSPF routes from being added to the routing table. This filtering happens at the moment when OSPF is installing the route in the routing table. This feature has no effect on LSA flooding.

It may not be obvious until you read it carefully and clearly but what it is saying is that the distribute list will prevent a route from being added to the routing table but will not prevent the LSA from being added to the LSDB and will NOT prevent the route from being advertised to OSPF neighbors.

I remember the first time that I tested using a distribute list with OSPF routes. I configured the distribute list in OSPF and was delighted to see that the routes that I denied were not present in the routing table. But then I looked in the routing table of a neighbor router. I was quite disappointed to see that the route was present in that routing table and that it had been learned from the neighbor on which I had configured the distribute list.

So unless we want to go to every other spoke router and configure distribute lists, I do not think that this feature will help to solve the issue of the original post in which the one branch in area 1 should communicate with only one of the branches in area 0.

HTH

Rick

[ariela]

Yes Rick,

you say "So unless we want to go to every other spoke router and configure distribute lists" ... I agree with you, that's not so scalable ;)

Thanks again for your explanation

Regards

Andrea