Traffic Flows: Using MPLS-TE and PBR – Part 2 – Why?

Just a bit of a discussion on the previous post.


Why would you use this, on a slightly more serious note than before – in all honesty I think you probably wouldn’t. But the point is it gives you the same kind of per-flow control that a lot of people seem to be looking forward to getting from SDN. It seems silly to me, but hey, if you want it, you can get it now.

The other point, is that by using MPLS-TE you only need to define the flow at its ingress point into the MPLS network. Using straight up vanilla PBR and you would have to configure all the links in the path.

Potentially in a very large scale data centre, you could – but I don’t see it happening. A more practical use case would be a large-scale MPLS WAN. If you have a large non-hierarchical WAN. Possibly you have a large number of links for redundancy but the layout does not use a nice campus-style 3 layer design due to geographic or optical fibre constraints. Due to the layout you will end up with some links completely underused – you could potentially tweak your per-link IGP metrics – but this might not even work depending on the topology.

Potentially you might have specific services that are bandwidth intensive – say, CCTV with offsite storage? Remote office data centre backups? Services that can be easily defined and may not be highly user-interactive so some added latency won’t be an issue.

But realistically, if you are that constrained for bandwidth, I think you will have other issues. Also remember if you are using all your redundant links – then they are no longer redundant links. It should be unnecessary for me to say that, but I often hear people complaining about spanning-tree blocked links, standby firewalls or backup Internet links complaining that they aren’t getting any use out of paid for resources. Well you are, it’s there if the primary breaks. If you use both (more than 50% anyway) and one breaks – then performance will degrade – which is not so good.

From Scratch #1: Configuring an Explicit Path using MPLS-TE

Here is a step by step configuration example to configure a specific path using MPLS-TE tunnels.

This was originally going to be a post about MPLS Fast Reroute. However two things happened, one the post became excessively long and two, I realised none of my simulated routers support MPLS FRR. Also, the Cisco Feature Navigator is lying to me again (FRR is supported on a 6500, FN claims this isn’t so.)

Continue reading



Tom has kindly asked that I contribute to Etherhex, which of course, I immediately accepted.

Tom and I used to work with each other and even despite moving to different places we are still drawn to asking questions around networking.

To begin with I want to focus my input to Etherhex around the day to day of what a network engineer in our position comes up against. In the line of work that we do we often have to have an understanding of the end app to both design and operate the network. Often the network is blamed which means we need to gather the appropriate information to see if it is us or not. For this I can not stress the benefit of having a solid Network Management System (NMS).

So, watch this space in the New Year!