cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1756
Views
5
Helpful
15
Replies

Access Layer Routing

Hello everyone,

We're running on a collapsed core network design and I'm looking to move routing down to the access layer.  I've attached a sample diagram of a small portion of the overall network to give you an idea of how things are connected.  Currently, all routing, ACLs, multicast, etc. is being handled in the core.  I would like to move as much of this down to the access layer as possible.  The problem I'm faced with is our phone system (non-Cisco).  We have two PBXs that are not running in an HA configuration and are in their own VLANs with routing between them.  We have phones that are registered to both PBXs that are physically located throughout our campus.  I'm afraid that if I move routing down to the access layer, I'm gonna lose communications between the phones and the VoIP system since traditional routing won't allow me to have the same subnet in two different locations for the same infrastructure.  The only thing I can think of is possibly establishing EIGRP neighbors for the phone network and then NAT'ing the phones behind their gateway.  Can someone shed some light on some real-world workable solutions?

Thanks!

TLock

1 Accepted Solution

Accepted Solutions

Okay, if you wanted to keep the core switches as they are then one approach is to buy new switches for your distribution switches.

Then in each building you connect your access switches to your distribution pair and then each distribution pair is connected to all core switches again using L3 links.

Key thing here is to connect every distribution switch to every core switch so there are no multiple hops as you have now.

That said if you are aggregating each buildings access switches onto a distribution pair you may only need two core switches, perhaps one in each location to protect against power failures etc.

That is a standard design for a multiple site campus but obviously that means purchasing a new pair of L3 switches per building.

And it's not entirely clear whether you have the cable runs to do this ie. perhaps you are using three simply because you cannot extend all access switches back to just a pair although if you did have a distribution pair per building they could presumably be located a lot closer to the core switches.

The alternative using L3 is to do as you are proposing now and simply accept some routing inefficiencies. Or if you could consolidate all your access switches onto just a pair of core/distro switches then that would solve your equal cost routes but I suspect you can't do that ?

All of the above however does not address what we started with in this thread and that is the key really. Is it really worth spending money on new kit etc. if you are then going to have compromise the design because you need to extend some vlans across all switches which would mean extending those vlans through the core which really isn't ideal.

There are a lot of different ways to approach this but before you can make any decisions you really need to decide on that issue. As you said in a previous post it would be good to be able to extend the vlans because of the vendor but is there any way you could test whether it would work in a lab type setup ?

Finally we haven't even talked about traffic patterns ie. where are the servers etc, how much throughput do you need which again has a big impact on the design.

Happy to answer any more queries etc. so please feel free to ask but it is a big subject so I don't want to bore you by babbling on :-)

Jon

 

View solution in original post

15 Replies 15

Jon Marshall
Hall of Fame
Hall of Fame

So you want move routing for vlans to the access switches ?

I'm not sure I understand the phone problem but I'm not a VOIP person. Why do the phones need to be in the same vlan throughout the campus ?

Can you explain a bit more about that.

What are the switches ie. models ?

You also have three switches in the core, how does this work in terms of routing for vlans ?

Jon

Hello Jon,

Thanks for your response.  To answer your questions our PBXs for both VLANs act as the DHCP server for our IP phones so placing them in the same subnet just works since our IP phones are scattered in various parts of the network.  We've constantly had to have our phone vendor fix numerous issues in order to get our VoIP system working properly.  I guess we can use our DHCP servers we use for PCs for our phones as well and configure the appropriate options.  As for our switches, we have 7 4510-Es that have PoE and some 2960s that have PoE since we still have classic 4506s in production but no PoE.  We're looking to replace the 4506s with PoE 4500-E chassis.  Lastly, our core switches operate in HA using HSRP configured with SVIs for each routable VLAN.  So all VLANs and SVIs are created on the core switches.  Hope this info helps and feel free to ask any further questions.

So is the issue with the phones DHCP rather than routing once they have an IP address ?

If so can you not just use "ip helper-address x.x.x.x" under the SVI ie. you could still point them to the PBX servers to get IPs.

If you want the same vlan across multiple switches for the phones but you want to route all other vlans you can do this but I'm just trying to work out whether it is necessary.

If you think it is just let me know.

Regarding the core switches, so you have three switches and run HSRP between all of them ?

I was really just wondering why three and not two but it doesn't matter.

And you will simply use L3 routed links from your access switches to the core switches ?

And all your core switches will use L3 links to interconnect to each other.

If so I can't see an issue other than the outstanding one of the phones.

So do you need or want the same vlan across multiple access switches. Like I say there is a way to do that and still route all the other vlans but from your last reply I'm just not sure whether you need them or not.

Jon

 

I would like to have the same VLAN across the switches because I'm afraid that our vendor will try to point the finger back at us if something didn't work.  They've been known to do this in the past and each time, we showed them it wasn't on our end and they had to admit they had to make some changes.  So yes, please let me know how I can get the same VLAN across all the switches.  Thanks!

TLock

I have just typed out probably the longest answer I have ever done and this stupid website just errored on me and I lost it :-)

So basically you make the uplinks trunks and for each access switch you need two new vlans unique to that switch ie. you cannot reuse these vlans on other access switches. 

You then emulate point to point links using SVIs to peer on instead of L3 routed links.

On the trunk link you only allow the new vlans + the VOIP vlan eg. access switch connects to core1 and core2. New vlans are 3 & 4.

Create new vlans on access switch and vlan 3 on core 1, vlan 4 on core 2 plus the corresponding SVIs. You only need two useable IPs per vlan. So -

uplink to core 1 -> allowed vlans = vlan 3 + VOIP vlan

uplink to core2 -> allowed vlans = vlan 4 + VOIP vlan

Then you peer with a dynamic routing protocol between access switch and the core switches using the SVI IPs.

All vlans (except the VOIP vlan) are routed locally and for remote subnets they use the new vlans as transit.

Key thing is to only allow the vlans that need to be allowed on the trunk links and basically you have emulated using point to point links but using SVIs.

The main downside is you need two new vlans per access switch. This means a lot of new vlans on the core where you may hit STP issues if you are running a variant of PVST. Note I'm assuming all core switches will be L3 interconnected so STP isn't doing anything except for the VOIP vlan but it should still be running.

The VOIP vlan would have to be routed in the core. Which means if you want HSRP for it you need to run separate L2 links between the switches (in addition to the L3 links). The L2 links would be access ports in the VOIP vlan.

Finally, and this applies even if you had L3 routed links ie. you didn't need to span the VOIP vlan across multiple switches, you are not necessarily going to get the best use of your uplinks because you have three core switches eg.

ESW02 connects to CSW01 and CSW02

ESW05 connects to CSW02 and CSW03

that means for subnets on ESW05, ESW02 is always going to see CSW02 as the best path because it is a shorter number of hops away.

You could play with the metric to influence this but it is not ideal ie. if you only had two core switches this would not be a problem and each access switch would see equal cost paths.

But I suspect you cannot simply go down to two core switches.

Let me know what you think ie. queries, doubts, just don't like the idea :-)

Jon

 

Yeah I'm not sure if this solution will work for us but I can test it out in a limited lab environment to see how it works.  I think what makes a new design so difficult in our environment is the fact that we have end to end VLANs across our network so creating switch blocks while allowing devices that are part of the same VLAN to still be able to communicate complicates things.  The good news is that I'm not on any time limit; this is a project I've put on my list in order to have better network efficiency and traffic patterns.  Thanks Jon for your responses!

TLock

No problem

The only things I would add is that you are limited not just by needing vlans across all switches but by having three switches in your core.

This complicate things because using L3 does not necessarily mean a more efficient network in terms of traffic patterns because of what I mentioned about the routing.

The other thing is if you really do need multiple vlans across all your switches that might be a hint that L3 from the access layer is not really the way to go.

Again I was going to suggest perhaps VSS in the core and then you remove a lot of the STP issues but with three core switches you have issues again.

I did one pure L3 access layer implementation, funnily enough with VOIP, but that was before stacked switches/VSS running MEC so a major reason for doing it was to utilise both uplinks from each access switch and not have to run STP across the links.

But I had no need to extend any vlans between multiple access switches. If I had I may well have not gone down that route.

Jon

 

I understand completely.  I inherited this network so now I'm trying to get the best network design with what we have lol.  If we were to add a 4th core and did VSS, would I be able to get HA between two VSS instances?

TLock

As far as I know you can't run HA as such but you can obviously interconnect with them with L3 links.

I probably didn't' explain this properly but the number of switches in the core is not really an issue normally but that's because in campus setup each building block has it's own distribution pair of switches.

So if you wanted to do L3 from the access you connect to the distribution pair using L3 links and the distribution pair have no SVIs they simply route between the access and the core switches.

But in your proposed setup you have merged the access and distribution functions into the access layer switches.

Which means every separate access switch has to correct directly to the core and it also probably explains why you need more than two switches in the core.

I'm not saying it's wrong but it will mean as I say access switches seeing only one path to some of the destination networks even though they have two uplinks.

If this isn't a campus setup then it must mean you have an awful lot of access layer switches :-)

Jon

So it would probably be better for me to purchase 4500-X switches to aggregate my access layer switches so that I can truly route between access and core?  We have at least 1 access layer switch in each comm closet.  A closet with a 4500 switch only has that switch whereas a closet with a 2960 would have two.

TLock

Is this a campus environment ie. are there multiple buildings ?

Why do you have three core switches ie. -

is it because you need the number of ports

or

is a geographical distance thing ie,, are the core switches spread between buildings

really need to know the above before we could say what you need as you may not need to purchase new equipment.

Jon

There are multiple buildings but they're joined together if that makes sense.  2 of the core switches are in the same physical location while the 3rd is several hundred feet away.  There are two server rooms to which they connect to the core that's closest.  The core switches (as I'm sure you already know) are connected in a triangle using HSRP and Etherchannel layer 2 trunks between them.

TLock

Okay, if you wanted to keep the core switches as they are then one approach is to buy new switches for your distribution switches.

Then in each building you connect your access switches to your distribution pair and then each distribution pair is connected to all core switches again using L3 links.

Key thing here is to connect every distribution switch to every core switch so there are no multiple hops as you have now.

That said if you are aggregating each buildings access switches onto a distribution pair you may only need two core switches, perhaps one in each location to protect against power failures etc.

That is a standard design for a multiple site campus but obviously that means purchasing a new pair of L3 switches per building.

And it's not entirely clear whether you have the cable runs to do this ie. perhaps you are using three simply because you cannot extend all access switches back to just a pair although if you did have a distribution pair per building they could presumably be located a lot closer to the core switches.

The alternative using L3 is to do as you are proposing now and simply accept some routing inefficiencies. Or if you could consolidate all your access switches onto just a pair of core/distro switches then that would solve your equal cost routes but I suspect you can't do that ?

All of the above however does not address what we started with in this thread and that is the key really. Is it really worth spending money on new kit etc. if you are then going to have compromise the design because you need to extend some vlans across all switches which would mean extending those vlans through the core which really isn't ideal.

There are a lot of different ways to approach this but before you can make any decisions you really need to decide on that issue. As you said in a previous post it would be good to be able to extend the vlans because of the vendor but is there any way you could test whether it would work in a lab type setup ?

Finally we haven't even talked about traffic patterns ie. where are the servers etc, how much throughput do you need which again has a big impact on the design.

Happy to answer any more queries etc. so please feel free to ask but it is a big subject so I don't want to bore you by babbling on :-)

Jon

 

I greatly appreciate your feedback and responses.  I now have something to work with and some options to go on.  I'll test out these solutions in an emulated lab environment to see which option best works for the company.  Thanks again Jon!

TLock

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: