ROUTED Access Layer Design

[lamav]

Lately, Cisco has been recommending a departure from the classic hierarchical campus design model to include a routed access layer instead of a switched access layer.

In this new model, it is recommended that the routed access layers (if they are using EIGRP as the core IGP), should be configured as EIGRP stubs, meaning that the access switches will never be queried for reachability information for any networks EXCEPT for the networks it is directly connected to and which it is advertising to the distribution layer. In other words, the access layer switches should never be treated as transit points for traffic to pass through on its way to somewhere else. So, the access layer routed switch will advertise itself as an eigrp stub and the distribution switches will oblige by never querying them for any networks that it is not directly connected to.

Secondly, a route filter in place at the distro switches which will ensure that the routed access switches ONLY receive a default route, is the complement of the eigrp stub design. In other words, the access switch says, "look, I am ONLY connected to these networks and I am NOT to be treated a transit point to get to anywhere else, so NEVER ask me about how to get to any network, EXCEPT for the ones to which I am directly connected."

In turn, the distro switch says, "Fine, I wont ask you for any inpofmration on any networks, EXCEPT for the ones to which you are directly connected, and furthermore, I dont want you to ask me about any specific routing information. I will ONLY advertise a default route to you and you should just send me all your traffic, period."

This way, the routing convergence process between distro and access is minimized and mitigated. And rightfully so, given the topology.

So, here is my question: couldnt all this have been achieved with static routes? Place a static default route in the access switches pointing to the distro, which is exactly the effect that dynamically advertising a default from the distro has on the access switches' routing table. In other words, dynamic or static, either way, the aqcces switche sare going to have ONE route in the routing table -- the default route pointing to the distro.

Furthermore, if, say, the access switches are directly connected to networks A, B, C, and D, why not simply install 4 statics in the distro switches and redistribute them back to the rest of the enterprise?

Why do I ask this? because it seems that in the document, there is this great concern to minimze convergenece time and minimize protocol back plane protocol exchanges between distro and access. Well, if thats the big worry, just go static and get rid of all those routeing protocol-induced worries. NO???

[PETER EIJSBERG]

Sure you can do this with static routes, but there are two reasons why routing protocols are nice to have here:

- If you have multiple uplinks from the access routers to the core of the network, use of a routing protocol will make rerouting in case of a failure easier (static routes only disappear if the directly connected interface goes down, that is why convergence is not a problem with static routes - they just dont converge :-);

- Using static routes means that every change in the access routers will require another change in the distribution or core layer to add or change the static routes. When you use a routing protocol, new network information is distributed into the protocol at the access router itself, and automatically distributed to all other parts of the network. So when you add a new segment to an access router, you do not have to change configurations anywhere else. This will really reduce the number of operational problems.

[Jon Marshall]

Hi

You make a very valid point in my opinion. We have just implemented a Layer 3 routed access-layer in one of our new offices and we chose to use L3 for a number of reasons most notably that we were deploying Nortel IP phones ( don't ask ! ) and Nortel really don't like spanning-tree.

I totally agree about the default route on the access-layer switches pointing back to the distro switches. The only reason i can see for using eigrp stub in the access-layer is if a new subnet was added to the access-layer switches with eigrp stub this would automatically be announced to the distribution layer, providing that is you were either advertising the individual subnets or the new subnet added fell with the summary range you are advertising.

It also depends on your topology. For example in our network we have major sites connected to MPLS receiving routes from BGP and redsitributing into EIGRP. When the routes get redistributed they become AD 170. We needed to distinguish between these and internal routes within the major site and if we redistributed statics even the internal networks would end up with AD 170. So we do use the EIGRP stub feature and advertise from the access-layer to the distribution a summary route only.

Having said that i still largely agree with what you say. Sometimes statics are overlooked as the simplest solution to a problem.

HTH

Jon

[lamav]

Folks:

Thank you kindly for your thoughtful responses and input.

Dont get me wrong, I do understand fully the benfits -- in general -- of running a dynamic routing protocol as opposed to using static routes. But if you read the White Paper on this, you will see that the writer is obsessed with reducing the typical convergence time of 800 msec of a finely-tuned L2/RSTP environment down to 200 msec.

In that connection, link failure detection, route/LSA advertisements, SPF timers, etc, are all tuned to make the protocol as muted as possible. Thats why I figured using 2 statics to provide routes over 2 equal-cost paths up to the distro and back to the routed access may be the way to go.

I guess it could work, depending on the situation, as Jon pointed out.

JON:

By the way, did you deploy HSRP on that routed access layer? If not, are your hosts dual-homed to both switches? Just curious...

[Jon Marshall]

Hi

No HSRP because all our clients are just singly honed. So we have 2 access-layer switches per floor. Each access-layer switch has dual layer 3 etherchannel connections to the distribution switches so each switch sees equal cost paths to any destination. But there is no connection between the access-layer switches within each floor.

We made sure that depts on each floor were spread across both switches so if a switch goes at least the dept can carry on working with some of their pc's and phones.

The major advantages of this design

1) Spanning-tree is eliminated from the access-layer altogther.

2) Very quick failover and convergence. Because there are 2 equal cost paths a loss of one of the etherchannels (which in itself is unlikely) means that all traffic automatically gets sent over the other link.

Because of equal cost paths there is no need for EIGRP to query other routers.

Major disadvantage

1) You can't span vlans across floors which is not that much of a restriction within a campus setup but i would think long and hard before implementing the same in a data centre.

Jon

[lamav]

Jon, the way I look at it - and according to that White Paper - there is no need to configure HSRP in a routed access layer because the router is local. In other words, if that switch craps out, the hosts are going to be left disconnected from the network altogether, so there is no need to configure an alternate router. It doesnt buy you anything if youre hosts are dangling in oblivion.

Thats why I asked if the hosts were dual-homed/dual-NIC'ed to each access switch so that the secondary can take over automatically if the primary fails.

I do like your setup, though. What IGP are you using?

[Jon Marshall]

"there is no need to configure HSRP in a routed access layer because the router is local"

Yes precisely the reason why we don't bother with connecting the two access-layer switches together. If your switch goes and the host is singly honed then it's a goner anyway.

IGP - EIGRP unless i have misunderstood the question. Because we peer with MPLS provider using BGP, EIGRP is constrained to each major site and any remote sites connected to it. I like EIGRP, it's simple to configure and very fast to converge and as we are purely a Cisco network we have no issue using it.

Jon

[lamav]

Thats cool.

So, did you configure the access switches as EIGRP stubs and do all that jazz they recommend in that White Paper? They actually have a whole set of recommended configurations for the core, distro and access layers.

[Jon Marshall]

Yes, the access switches are configured as EIGRP stub routers and we only advertise out a summary address as we can summarise the voice and data vlans per floor.

I remember reading the white paper a while back but i'm going to have to give it a reread to answer the second part of your question.

Anything in particular you were interested in ?

Jon

[lamav]

Nah, no question in particular. the whole reason I created this thread was just to toss some ideas around and discuss routed access layers with someone who has actually implemented it, like you.

Youve been a great help and thanks for the engagement.

[Jon Marshall]

No problem, glad to have been of help.

Jon

[bill_murphy]

We are implementing the same L3 access layer model described in this document and I would like to pose a couple of questions to the group... First, we have a need for using VRF-Lite and thus some of our links must be trunks rather than routed links. How does the trunk requirement impact the convergence time of this network design? And finally, the document mentions setting carrier-delay to 0 msec. Since some of our links are trunks I assume I would set carrier delay on the physical interface, but the SVI also supports this command. Do I need to use carrier-delay on the SVI too? Thanks in advance for your feedback...