Core Vs Edge Routing Topology

Core vs. Edge Routing Topology

There isn’t a lot of talk about this; however, there is a lot of training material that references this debate and makes recommendations for edge based routing. For those not familiar with the topic I am talking about “Campus LANs” and not ISP networks where you essentially have to push routing to the edge for some customers. In my article I am talking about Core vs Edge in the aspect of where we perform all of our routing in a “Campus LAN”

In a common scenario you’ll find Layer 2 edge switches at the edge of a network serving end users and either a “Distribution layer” doing the IP routing OR a collapsed “Distribution/Core” that handles the IP routing between VLANS, applies QoS and ACLs. This is a common scenario because it is the easiest to maintain and doesn’t require the use of a Dynamic routing protocol in most situations since all your routing is done at the Distribution/Core layer. From here on out we’ll assume we have a collapsed Distribution/Core layer so we’re only dealing with an access layer and a distribution layer that handles IP services.

In this model you’ll have all your VLANs defined in both the distribution layer and the access layer with the only difference being your distribution layer is where you assign the SVI interface for each VLAN. From there, you can either statically setup your VLAN databases on each edge switch or you can enable MVRP for GVRP to populate the VLAN database from a “server” switch on to the other listening “client” switches. With this setup you can enable VLAN “pruning” because while you have have the VLAN defined in the VLAN database on the edge switch you may not have an access port assigned on the switch to a particular VLAN. The pruning will ensure that no traffic in that VLAN will traverse across the link because it will be in the “pruned” state.

In this scenario you’ll generally find Fiber optic links from the edge to the core (1G or 10Gbe) that are “aggregated/trunked” to the distribution layer for added bandwidth and redundancy and to also avoid a loop in your network. We could talk about setting up spanning-tree and having that work to our advantage with things like VRRP on dual redundant cores; however, this is outside the scope of this rather basic explanation of Core vs Edge routing.

Whenever you need to apply an ACL, routing change, or add a VLAN you do so at the distribution layer and that is it. If you move over to an edge switch and enable a VLAN and you have MVRP or GVRP enabled the “trunk” will automatically enable that VLAN to allow it to traverse across the link; however, you can forgo this and also statically allow it yourself if you don’t want to use a Multi-VLAN registration protocol. In this design you ensure that you always have a firm control over your VLANs, their links back to the distribution layer and a way to handle change control effectively and easily.

With Edge routing you would enable IP services on the edge switch just as you would with the distribution layer; however, this requires a lot more VLANs and a lot more IP based planning as you would require that the core not have too many entries in the routing table and instead would want to have summarized routes. In this scenario you’ll define in each switch (depending on the implementation and requirements) a unique set of VLANs per switch/area and assign the SVI to each of those VLANs. When you do this you’ll have to ensure that you have an IP schema that makes sense and can be summarized either manually or through a dynamic routing protocol. You’ll also need a unique VLAN per layer 3 aware edge switch to the distribution layer as that will perform your routing between broadcast domains that do no exist within the switch you have configured. So this “point to point” link should be a odd ball VLAN number and typically be a /30 because you only need two usable IP addresses.

From here you’re going to want to plan out how to IP each VLAN so that they are consecutive. This should be easy if you have all /24 networks; however, this becomes more complex when you introduce /23 and /22 subnets. I won’t get into detail with this but I would highly recommend you assign the IP address ranges of the largest networks FIRST to avoid wasted address space. If you’re using /24 subnets just ensure they are related in some way (e.g. the third octet should be .0, .1, .2 etc) and then you can summarize at the distribution layer. From this design you remove the responsibility of routing from the distribution/core device onto the edge devices. Therefore, any and all configuration for routing, ACLs and other parameters per subnet is configured on the appropriate switch(es) that contain those VLANs. Also, you’ll need to ensure that your dynamic routing protocol is functioning as designed and if you desire to not redistribuute some routes you’ll need to learn how to use route-maps and route-policies to block either the importing or exporting of those routes.

As you can see, the Edge solution is complex to implement and very complex to maintain. The argument that you get to relieve the pressure from the core/distribution layer is moot because of advances in switching and ASIC technology. A modern HP 8200 series, Juniper EX4200 (stacked) or Cisco 6500 series chassis has more than enough power to switch/route for hundreds of VLANs without breaking a sweat. With a Core routing design you restrict the administration to one device, especially with a Multi-VLAN registration protocol. Even without one, it doesn’t take much to implement a policy and a template to enable VLANs on switches and ensure they are allowed on those links. This is ideal for those who may not have the best network intelligence in house and need to keep things simple. However, if you’re advanced and have the in house expertise to handle and Edge routing scenario you’re likely to have an interesting setup that, once going, can be very easy to maintain given the expertise and updated documentation that must always be a living document.