OSPF Design Question

Gents need some advice.

At work we are in the middle of a massive project which includes building two new datacentres and redesigning our campus. I'm looking after the design for the campus network and need some advice.

So the campus will be OSPF area 176 and the datacenters area 0.

There are two Cisco 3560E switches installed as the core of the campus network. There are linked via two 10Gb links and configured in an etherchannel. The two datacentres connect to these two switches as well.

So my question is about the etherchannel link between the two core switches. See the diagram below, area 0 and area 176 will potentially need to traverse this link if there is ever a break in on of the primary paths.

So the discussions we have had at work is around the routing configuring of the core switch interconnect. Should it be:

a) A routed etherchannel (no switchport command) with the etherchannel in area 0
b) A routed etherchannel (no switchport command) with the etherchannel in area 176
c) A layer 2 trunk etherchannel, using two VLAN interfaces on each end used for routing. So there would be for example,
interface vlan 100 in area 0 on both switches
interface vlan 200 in area 176 on both switches.

It will work using any of the methods above,I was originally thinking A, but the solution architect reckons C is the way to go...

just wondering what you guys think of this?

Thanks!

ospf design.jpg

Find more posts tagged with

Comments

APA

Hey Rakem,

Your solutions architect is correct....... let me pose a question to get you thinking why I agree with C....

Considering the RIB prefers 'intra-area' routes over 'inter-area' routes, how do you think the two core switches are going to route to networks they each own in Area 176, if they only have a Area 0 cross-connect between them?

It would be the same for routing to Area 0 networks, albeit different path(Area 0 path) if you only had an Area 176 cross-connect between the two core switches.....

This will answer why the need for the cross-connect to carry both area0 and area176 routes...

If you don't like the sound of a trunk with SVIs.... investigate whether the 3560-Es support RFC5185 'OSPF Multi-area Adjacency' where a single interface can participate in two different areas. This feature was standardized to overcome issues like this.....

If you don't quite understand, let me know and I'll explain further......

I think its better to pose a question at first to let you think about the caveats\reasoning... before completely giving away all answers

accely

I also agree with option C, SVI's over the trunk link for both areas

rakem

APA wrote: »

Hey Rakem,

Considering the RIB prefers 'intra-area' routes over 'inter-area' routes, how do you think the two core switches are going to route to networks they each own in Area 176, if they only have a Area 0 cross-connect between them?

I think I see what you're getting at, the intra-area routes will be preferred, which could result in sub-optimal routing in some circumstances. The core switches might route traffic destined to area 176 across their intra-area route first, then into 176 via the inter-area route.

Is that about it?

yuriz43

Hmmm.. The only problem I see with option A is if there were routes in Area 176 which had an optimal path via core1 (for example). In this case you may want core2 to route this traffic via core1, however the intra-area route in area 176 would be preferred and thus a sub-optimal routing path for such network.

If area 176 is symmetric I don't see a need for option C.

APA

Rakem, yep that's on the right track....

Yuriz and Rakem - what about if core1 lost its area 176 interconnect..... and there is only an Area 0 interconnect between the two... what path will core 1 take for Area 176 traffic????

Having an interface in Area 0 and an interface in Area 176 between the two cores will save the hassle of worrying about sub-optimal routing that can occur during a failure.... but more so even when there isn't a failure due to the 'intra' before 'inter' rule of OSPF...

Investigate 'Multi-area' adjacencies... that would mean you don't need a trunk and multiple SVIs between the two as it can just be a flat ptp routed link.... with the benefit of having in adjacency in area 0 and area 176.

yuriz43

APA wrote: »

Rakem, yep that's on the right track....
Yuriz and Rakem - what about if core1 lost its area 176 interconnect..... and there is only an Area 0 interconnect between the two... what path will core 1 take for Area 176 traffic????

If core1 lost its area 176 interconnect it would forget those intra area routes, and instead use the IA routes advertised by core2.

EDIT:

I just did a quick lab to test this and when core1 loses its link to area 176 it uses the InterArea routes from core2 as expected.

Am I missing something here?

APA

No you're not..... trick question (edit - bad example on my part) ....

The sub-optimal routing occurs when the Area 176 circuits are up..... so to prevent that from occuring it is a preferred design to deploy a Area 176 circuit between the two cores...

If there are no issues with the sub-optimal path (e.g - oversubscribed ports, lack of CPU power, simply cannot handle aggregated traffic that will pass across the circuit) other than being sub-optimal and you really don't deem it necessary to have an interconnect between the two cores in Area 176 then thats the engineers decision at the end of the day.

Certainly I would want to be deploying with it though... as I'd prefer my traffic to be taking the shortest path possible.

Think of the bigger picture....e.g - provisioning a new router off core2 in area 176.... Core1 will need to get to it via the sub-optimal path, rather than go directly to core2 onwards to the new router.

yuriz43

The sub-optimal routing only occurs for networks directly connected to the cores which are in area 176. In such cases core1 would ake the path through area 176 vs the path directly through core2. In my lab the link between core1|2 <----> area176 is a p2p /30, and yes core1 would take the path through area 176 to reach the /30 between core2--area176, instead of directly through core2, obviously sub-optimal.

If the routers in area176 are symmetricly connected to core1[2] this isnt a problem, except for those /30 networks connecting core1|2 to area176 ( assuming that is the design). But I dont see a lot of traffic destined for those networks.....

APA

Thats my point Yuriz.... the directly connected 176 networks that each core own is what will experience sub-optimal routing....

use my example above..... regarding adding another router in 176 off core 2....thus breaking the symmetrical connectivity to the cores..... potential for traffic increase from core 1 to this new router....and without the link between the two cores the suboptimal path is the only path that can be used....

When redesigning a network its good to think of the bigger picture.... saves reconfiguration later down the track.... perhaps minor channel increases to handle excess demand...(if you're using LAG that is) but at least the underlying infrastructure and topology is already in place.

Lab is one thing...... production traffic without understanding the full traffic profile\behaviour of the network is a whole other ball game....

At the end of the day, like I mentioned earlier.... it is up to the designer\architect\engineer........ whether they deem the cross connect absolutely necessary.

rakem

So I have been looking into RFC5185 'OSPF Multi-area Adjacency' but can't find much in the cisco world about how its configured or if they even support it...

Anyone got any info?

Edit: Just found this doco

http://docwiki.cisco.com/wiki/Cisco_NX-OS/IOS_OSPF_Comparison

"An interface can support multi-area adjacencies using the multi-area option with the ip router ospf interface command. "