01-27-2015 06:51 AM - edited 03-07-2019 10:24 PM
Hey, We are having Cisco 6500 Switch at aggregation layer where all our SVIs are created and we need to advertise them in OSPF for reachability purpose. Now we are using L2 campus model so access layer is not running any routing protocol but we need to segregate our SVIs traffic based on different buildings. We are doing this by assigning unique areas to a group of SVIs while advertising in OSPF. My question is, is this a recommended way ? or we have to advertise all the SVIs in Area 0? because we don't have multiple areas but still we are adding them while advertising at 6500 switch. Thanks.
Solved! Go to Solution.
01-27-2015 09:21 AM
it kind of defeats the whole logic of multi Areas in OSPF
But still i am not finding any concrete reason to make any argument on this design
I think the first statement is the reason ie. it is not logical.
If I had to support that network without initially knowing anything about it I would struggle to understand why it had been done that way.
Of course good documentation could explain the setup but it would still make little sense to me.
A good general design principle is don't add things you don't need and I can't see the need here.
Like I say there may be an argument to have all SVIs in their own area but even that you may not need.
It depends on what else there is connected to the core etc.
But to have multiple areas on that aggregation switch really doesn't make sense.
Jon
01-27-2015 06:54 AM
You say you want to segregate traffic but then you talk about redistributing routes so I'm not sure what the point is.
What exactly are you trying to achieve ?
Jon
01-27-2015 07:17 AM
I am sorry Jon.. I meant advertising in OSPF not redistribution. I just corrected my question.
01-27-2015 07:22 AM
It's still not clear ie. you say you don't have multiple areas but then you say you are assigning different OSPF areas per building.
What is it you are trying to achieve ie. you say you want to segregate traffic but what do you mean by that.
And where are you advertising the OSPF routes ie. which devices etc.
If you give us enough information we may be able to help you.
Jon
01-27-2015 07:40 AM
01-27-2015 07:52 AM
Well your aggregation switch will be an ABR as far as OSPF is concerned.
Again, why exactly are you doing this ?
Jon
01-27-2015 08:29 AM
Yup it will be ABR for OSPF process.. And we are just doing it to classify our different buildings' traffic. Like if we check routing table at Core SW, we will see SVIs with different areas and it will be easier to troubleshoot any problem as we will know which area represent which building. Moreover, Area0 represents backbone in OSPF so we are not directly advertising all our SVIs in Area0.
Having said that, i am still confused whether is it a good approach or we should advertise all our SVIs directly into OSPF Area0.
01-27-2015 08:52 AM
Having said that, i am still confused whether is it a good approach or we should advertise all our SVIs directly into OSPF Area0.
Using an area per building seems unnecessary because all the L3 routing is done on the aggregation layer so it doesn't really make a lot of sense, at least to me.
I think using one area for all SVIs may be a good idea because then you can simply advertise one summary for the all the SVI subnets into area 0 towards the core.
This is assuming you can summarise all the aggregation IP subnets with one summary address.
Even that may not be necessary as it depends on the rest of your topology.
For example if your core connected multiple buildings as in a campus and each building had a distribution pair of switches connected back to the core then yes it would make sense to use an area per building/site and only advertise a summary to the core.
Up to you really.
Jon
01-27-2015 09:02 AM
Yes, you are right. As in this scenario which i posted, there is really no use of creating multiple areas for SVIs, because still it will be the Aggregation router doing all the processing and it kind of defeats the whole logic of multi Areas in OSPF. But still i am not finding any concrete reason to make any argument on this design because our customer is satisfied with this one :)
01-27-2015 09:21 AM
it kind of defeats the whole logic of multi Areas in OSPF
But still i am not finding any concrete reason to make any argument on this design
I think the first statement is the reason ie. it is not logical.
If I had to support that network without initially knowing anything about it I would struggle to understand why it had been done that way.
Of course good documentation could explain the setup but it would still make little sense to me.
A good general design principle is don't add things you don't need and I can't see the need here.
Like I say there may be an argument to have all SVIs in their own area but even that you may not need.
It depends on what else there is connected to the core etc.
But to have multiple areas on that aggregation switch really doesn't make sense.
Jon
01-27-2015 09:36 AM
Very Right and thanks for your time =)
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide