Hi Guys

Is it possible to gaurantee a specific amount of bandwidth for a TE tunnel?

I have figured out how to limit bandwidth entering a tunnel but how do I do the opposite?

Thanks

It is best to think of TE tunnels as of "accounting" feature, not rate limiting feature.

When traffic is switched across tunnel, no limits are applied. In order to have "guarantee" you must properly configure you network. The rule of thumb - configure TE on core routers with proper bandwidth available over every link and do not allow more traffic in tunnel at ingress point than configured for tunnel. E.g. if you have 100Mbps link X and intend to MPLS switch 10 10Mbps tunnels over that link, if you guarantee at the ingress point, that none of tunnels will have more than 10Mbps entering, you automatically "guarantee" every tunnel 10Mbps over link X, simply because every tunnel will only use its share and not more. If you have mixed - non-TE and TE traffic sent over link, you have to properly limit non-TE traffic.

Hmmm so you saying that traffic needs to be limited at ingress....So there is absolutely no way that a MPLS router, that just acts a switching hop, can limit speeds for MPLS traffic? or give higher bandwidth to a specific tunnel?


There must be a way somehow

Hmmm so you saying that traffic needs to be limited at ingress....So there is absolutely no way that a MPLS router, that just acts a switching hop, can limit speeds for MPLS traffic? or give higher bandwidth to a specific tunnel?


There must be a way somehow

You are correct - there is no way for a "switching hop" to limit speed. This would also somewhat defeat the idea behind MPLS core, where its only task is to move data as fast as possible. I suppose you will not find such feature in other MPLS switching devices as well, especially taking into account that it is common to do forwarding in hardware. As to "higher bandwidth" - depends on what you mean by that. Prioritization (based on EXP bits) of traffic may affect bandwidth if there is contention, but that would still not be tunnel based and at this time only WMM uses EXP bits for assigning priorities.

hmmm ok thanks for clearing that up...

With WMM, doesn't it just give the higher priority traffic "better" access category? So if the link is saturated then WMM doesn't really make much of a benefit?? or am I wrong?

hmmm ok thanks for clearing that up...

With WMM, doesn't it just give the higher priority traffic "better" access category? So if the link is saturated then WMM doesn't really make much of a benefit?? or am I wrong?

It does put traffic in better access category. "Better" for AC means higher probability for AC to transmit when multiple ACs are competing for medium. So if link is saturated and multiple ACs have packets waiting for transmit, AC that has higher probability to transmit will in the end get more bandwidth (provided that packet sizes in ACs are the same). This is not what WMM is for (and I doubt this is what you need/useful for you), but this is how you can affect bandwidth using WMM on saturated links.

So if link is saturated and multiple ACs have packets waiting for transmit, AC that has higher probability to transmit will in the end get more bandwidth (provided that packet sizes in ACs are the same).

Thanks again for the info, could you please alloborate at what you mean by "provided that packet sizes in ACs are the same"

Surely VOIP would have a different packet size to HTTP for example? Or does it mean that I must just not use Nstreme?

thanks

So if link is saturated and multiple ACs have packets waiting for transmit, AC that has higher probability to transmit will in the end get more bandwidth (provided that packet sizes in ACs are the same).

Thanks again for the info, could you please alloborate at what you mean by "provided that packet sizes in ACs are the same"

Surely VOIP would have a different packet size to HTTP for example? Or does it mean that I must just not use Nstreme?

thanks

Device executes EDCF procedure for every AC that has packets waiting to get a chance to transmit a packet. This procedure is executed before transmitting every packet. If we consider that there is 1/3 probability that AC X will transmit a packet, and 2/3 probability that AC Y will transmit a packet, and packet sizes are the same in both ACs, X will get 1/3 of bw and Y will get 2/3. If packets in X are twice as big as in Y, both will transfer the same amount of data (still maintaining the proportion of transmitted packets - 1:2).

Remember that nstreme does not provide prioritization of packets - packets with all priorities are treated in FIFO manner.

I suppose that could work to a certain degree but certainly not effective enough for a large network...

I have an idea:

Lets say I have a routed network that carries both VOIP and DATA traffic
What about creating a pptp tunnel between each highsite with the IP range 10.0.0.1/24
I then run OSPF over these tunnels and then enable LDP and MPLS on each of the pptp tunnels. So I now have a routed network and an MPLS network.
I could then route all DATA traffic over the pptp/mpls tunnel and route VOIP normally.
Since PPTP and DATA traffic can both me queued, I can essentially apply QoS to the MPLS traffic?

I do not really need to use MPLS to switch traffic from point A-to-B as fast as possible. I merely want to be able to use basic MPLS VPN services, like VPLS, but still give priority to my VOIP.

What do you think?

I suppose that could work to a certain degree but certainly not effective enough for a large network...

I have an idea:

Lets say I have a routed network that carries both VOIP and DATA traffic
What about creating a pptp tunnel between each highsite with the IP range 10.0.0.1/24
I then run OSPF over these tunnels and then enable LDP and MPLS on each of the pptp tunnels. So I now have a routed network and an MPLS network.
I could then route all DATA traffic over the pptp/mpls tunnel and route VOIP normally.
Since PPTP and DATA traffic can both me queued, I can essentially apply QoS to the MPLS traffic?

I do not really need to use MPLS to switch traffic from point A-to-B as fast as possible. I merely want to be able to use basic MPLS VPN services, like VPLS, but still give priority to my VOIP.

What do you think?

Probably you do not even need to make setup this complicated - I think you can use LDP binding filters. See http://wiki.mikrotik.com/wiki/MPLSVPLS# ... _filtering

For example, you can distribute label bindings only for loopback addresses that are used as VPLS endpoints. That way MPLS will only be used for VPLS traffic.

would I still be able to setup a queue tree if I do not use a pptp tunnel but do use label bindings?

I thought that MPLS traffic cannot be mangled, hence for the pptp tunnel?