MPLS TE, Tunnel badwidth reservation?

[Vadym Belyayev]

Hello all,

I know, this question was asked a couple of times here, I read all the answers, however, I was unable to find the answer that satisfies me. Neither 3 books I read about MPLS TE helped to clarify this part, however, always complementing each other in explanation techniques..

The topology I am going to deploy the MPLS TE on top of is the following:

1) About 7 Cisco-6509 and 6513 switches.

2) The interconnection for now is partial mesh moving toward a full physical mesh.

3) The idea is to create full mesh of tunnels "all vs all", enable autoroute and load-balance across redundant fiber links as they are being added.

4) This will be complemented with QOS (dont know the exact model to apply yet) to make sure that flows I want to prioritize at the edge, cross the core without a delay.

5) The label procotol is RSVP without LDP. (Maybe in future if we decide to extend a broadcast domain or something else, well start looking how to implement it?

My question is the following:

I never could fully understand the use of tunnel bandwidth and ip rsvp bandwidth command.

Tell me if I correctly understand the use of them.

tunnel bandwidth - Tells the router how much of "ip rsvp bandwidth" which was previously reserved by this command, the tunnel can use. However, you can send as much traffic as you want through the tunnel regardless of the bandwidth you assigned to it. It is like an administrative feature, but since it only accomplishes administrative objective, why not to create a full mesh of of 0 bandwidth tunnels, load balance between them and let the router choose how to route traffic using FIFO mechanism, like in IP?? You receive a packet, look at the CEF table, choose a shortest route using autoroute feature, put a label and forward a packet.

Another use of this command that I noticed is that when you have insufficient bandwidth, it does not allow you to create a new tunnel, which could serve you as an indicator that you are running out of bandwidth (since before you created lets say 2 tunnels of x bandwidth over the same physical interface, supposing that your traffic patterns would require x bandwidth per every tunnel, you assigned all the available bandwidth to those tunnels, not allowing the new tunnel to converge, therefore the "alarming mechanism").

Probably when monitoring the MPLS TE network with SNMP of whatever it is useful to know how much bandwidth is assigned to each tunnel, but since the router can send whatever data through that tunnel, regardless of tunnel bandwidth parameter, I find no sense in it...

So what are the real benefits of using tunnel bandwith regardless of administrative control and accounting purposes? Does it really control the traffic patterns? If I create a full mesh of tunnel bandwidth 0 tunnels and dont use the ip rsvp bandwidth command, enable autoroute on tunnel, will they send traffic without any problems? Will everything work smoothly as before, but this time with tunnels?

ip rsvp bandwidth - again, looks like something administrative. What you put it, this command reflects in opaque LSA (max reservable bandwidth) for an area and provides the necessary info for the tunnel to complete the signalling, when it is looking for available bandwidth. However, what is the real purpose of it? Does it control anything, what is the real benefit that I get with ip rsvp?

Lets say that these commands help me to quickly deploy a tunnel in the network according to my traffic needs, so the tunnel bw and ip rsvp bw help the tunnel to find its way through the network quickly and dynamically.. Everything is clear, but the tunnels can send whatever volume of traffic they want, regardless of the paremeters, so my intelligent mechanism can find a path with available bandwidth, while some of the middle interfaces can be congested, correct?

I think these things are those that confuse me the most, cSPF, balancing, protection and other things are not that hard to understand, but this administrative and at first sign "useless" reservation just knocks me out..

The GNS3 lab I have set up only allows to send 5kb of data per second and as you understand, so there is no way to generate traffic with it an make tests..

Thanks as always!!

[Vinit Jain]

Hello,

let me first start by answering question on difference between Tunnel B/W and B/W allocated by RSVP

Tunnel b/w <= RSVP Allocated B/W

i.e. We can allocate the TE Tunnel b/w to a max value that is carved out by RSVP. i would encourage you to read the below post on CSPF Algorithm:

http://blog.codergenie.com/blog/post/2012/10/13/CSPF-The-TE-Algorithm.aspx

Secondly, i am not really a big fan of testing MPLS TE on tools like GNS3, Lot of times, the results are not convincing and you face other challenges when you want to try FRR by shutting down a link.

Coming back to RSVP, if we are not sure on how much b/w can be required by all the tunnels traversing through a link, we can always use "ip rsvp bandwidth" command which will allow 75% of interface b/w that can by allocated for RSVP.

If you are looking for QoS in your Core network, you can think of using CBTS (Class-Based Tunnel Selection). Along with that you can go for an option for TE Auto-Tunnels based on the setup that you are looking for (unless you are fine with manually configuring TE Tunnels where ever you need them - static tunnels are always my preference over Auto-Tunnels).

Obviously, we dont need MPLS LDP for TE but if you are planning to have PE to P Tunnel then MPLS IP over TE Tunnel will be required.

Hope this information helps. Please let me know if you have any questions.

Vinit

[Vadym Belyayev]

Vinit, thank you for your answer.

There are still points that need clarification:

1) Coming back to RSVP, if we are not sure on how much b/w can be required by all the tunnels traversing through a link, we can always use "ip rsvp bandwidth" command which will allow 75% of interface b/w that can by allocated for RSVP.
Why not to exclude ip rsvp and tunnel bandwidth from the config. Will I still be able to normally route traffic through different tunnels?

2) Regarding QOS, I have read the following, but this is for tactical deployment, not strategic as in my case:

Diff-Serv TE? No. Because you might have both IP and MPLS TE traffic in the same
queue, administratively reserving space from a subpool can give you a false sense of security.
 

So what about a strategic deployment? Does is worth diffservTE? (I assume that DiffServ TE is the same that CBTS)

3) What about the other questions I asked about administrative function of tunnel bandwidth?

[Vinit Jain]

so to answer your first question, you can use a zero b/w tunnel. For that you dont need to configure "tu mpls tra band <>" command. but you will still need "ip rsvp band" which is again max of 75% of link b/w which should suffice.

The tunnel b/w is just to ensure the tunnel doesn't carry traffic exceeding the specified b/w. It all depends on what design requirements we have layed out.

Diffserv TE is diff: http://www.cisco.com/c/en/us/td/docs/ios/12_2s/feature/guide/fsdserv3.html

with CBTS, based on the dscp value, you decide which Tunnel to take to carry the traffic.

[Vadym Belyayev]

Vinit,

I have read that regardles of what bw parameter you put inte the tunnel config, you will be able to send any amount of traffic through that tunnel. So what is the point of having the tunnel bw?

I will leave the QOS aside for now, but I will check the document.

Regarding the CSPF you sent me, I took a look at it and I understand how it works, however, it is not related to tunnel bandwidth topic.

And again the same question, why do I need ip rsvp bandwidth, I created tunnel in lab and it worked, it however had 0 bw requierement?

[Vinit Jain]

yes, the tunnel will come up with 0 b/w but there is no guranteed b/w for the tunnel. If you run the command "show ip rsvp int", you will notice that RSVP is enabled no the interface. if you try to configure a b/w on the tunnel without configuring ip rsvp band command, the tunnel will come down. This behavior explains that RSVP is doing reservation. using the ip rsvp band command, we are reserving resources for TE. Otherwise there is no reserved b/w for TE.

[Vadym Belyayev]

Yes, but what is the difference between reserving 100 mb for the tunnel and in fact sending 300mb through it vs not reserving anything and sending whatever you want?

[Vinit Jain]

yes, you might be able to send that traffic but consider a simple scenario, there are two paths from router A to E

A->B->D->E and A->B->C->E

if the first path doesnt has 100 mbps of available reserved b/w to serve the tunnel, the Tunnel will not take that path it will take the other path. Thats were CSPF comes into play. it looks for minimal b/w requirements as specified .

The per interface configuration tells the network how much bandwidth is available on an interface, and the per-tunnel configuration at the headend tells the headend how much of the announced bandwidth to consume. its only with RSVP we can allocate the b/w throughout the network. with TE its about the minimum b/w that a Tunnel needs, if there is b/w available on the link, yes, we can use it but the use case of TE is when there is improper utilization of network resources.

if you are doing some testing, i would suggest, if you can use IXIA or some other traffic generator to simulate real time traffic (MPLS + IP) and design your network with multiple TE tunnels. GNS3 labs are not really good for real feature testing but just good for CCIE prep :).

[Vadym Belyayev]

Vinit, this still does not answer my question,

My scenario was different. In my scenario the 100mb tunnel comes up and sends 300mb of traffic through it. In your case the 100mb tunnel does not come up.

in VS scenario I talked about creating zero bw tunnel (no reservation, no requierement) and sending 300mb through that tunnel. If nothing blocks my traffic from passing through the interface, what is the difference between 2 scenarios?

Returning to my original question:

So what are the real benefits of using tunnel bandwith regardless of administrative control and accounting purposes? Does it really control the traffic patterns? If I create a full mesh of tunnel bandwidth 0 tunnels and dont use the ip rsvp bandwidth command, enable autoroute on tunnel, will they send traffic without any problems? Will everything work smoothly as before, but this time with tunnels?

[Vinit Jain]

MPLS-TE does not have any policy enforcing down to the data-plane, interfaces, forwarding.

So, no matter what, you can send any amount of traffic into any TE tunnel, regardless of the configured or signaled TE bandwidth.

MPLS TE bandwidth signaling is purely related to control plane signaling for TE.

[Vadym Belyayev]

And what is the purpose of control plane bandwidth reservation? What is the real benefit?
 

[Vinit Jain · Accepted solution]

it just helps a router know that a particular TE path has at least the reserved b/w for carrying the traffic (reserved in the sense that it has enough b/w). The control plane reservation is only from the network planning purposes. if the b/w is not available as part of the control plane reservation, it looks for an alternate path or brings down the TE tunnel based on the config. The data plane will not forward the traffic coz the control-plane doesn't has it signaled.

There is no ensurance wrt data plane. All the planning and BW steering only works really well if all traffic is on TE tunnels.

[Vadym Belyayev]

Thanks a lot Vinit!!! I think I understood what it is all about!!! Again, many many  thanks!!

[Vinit Jain]

It was a great discussion with you. Looking forward for more interesting discussions. 
 

Vinit

[Vadym Belyayev]

You clearly have set the pace in this discussion.

I am just a simple man making my way in the universe.