Hello,
we are doing some tests on routerboards RB333 running routerOS 3.20.
What we would like to do is trying MPLS - VPLS in a TE tunnel with bandwidth reservation.
Our setup is similar to the one described in http://wiki.mikrotik.com/wiki/MPLS_TE_Tunnels
Our configuration has 100Mbps wired links between the boards.
We'd like to reserve 70Mbps to the flows traversing the tunnel.
Here is the configuration on one of our nodes.
/routing ospf instance set default mpls-te-area=backbone mpls-te-router-id=lobridge
/mpls traffic-eng interface add interface=ether3 bandwidth=125000000 -------->>>> is that true that this is in Bytes per second?
/mpls traffic-eng tunnel-path add use-cspf=yes name=dyn
/interface traffic-eng add name=te1 bandwidth=8750000 \ ------->>>> also this, I suppose...
primary-path=dyn from-address=10.255.255.4 to-address=10.255.255.5 disabled=no record-route=yes
We also see that everything seems to have been set up correctly:
interface traffic-eng monitor 0 once
tunnel-id: 2
primary-path-state: established
primary-path: dyn
secondary-path-state: not-necessary
active-path: dyn
active-lspid: 1
active-label: 29
explicit-route: "S:10.0.6.3/32,S:10.0.3.3/32,S:10.0.3.4/32"
recorded-route: "10.0.3.3[29],10.0.3.4[0]"
The problem is that we don't know how to put traffic on it...on VPLS tunnel we used a bridge from the ethernet interface to the tunnel endpoint, but if we try to do the same with TE tunnel, it seems to be impossible to add the interface "te1" to the bridge.
Any idea about this?
Thanks in advance,
Luca
Re: MPLS - problem with bandwidth reservation in TE tunnel
If remote ends of the VPLS are the same as TE tunnel endpoints, then VPLS traffic will be automatically forwarded to TE tunnel.
-
-
lucapilosu
just joined
- Posts: 6
- Joined:
Re: MPLS - problem with bandwidth reservation in TE tunnel
It is just what we tried, but in this case it seems that traffic doesn't flow across the te tunnel (we verified with winbox on the traffic tab of the interface menu...hope it's affordable...).If remote ends of the VPLS are the same as TE tunnel endpoints, then VPLS traffic will be automatically forwarded to TE tunnel.
I try to explain better my problem:my configuration is shown in the attached image, all nodes are running OSPF and MPLS. I have both a VPLS tunnel and a TE tunnel (between nodes D and C ).
I'm trying to send simultaneously two different traffic flows, one through the tunnel (D--->C) and the other on a normal LSP (A--->B) . The flows are both sent at 100Mbps (so I put 200Mbps over a 100Mbps link).
With the configuration previously posted, I see that I have not bandwidth reservation on the TE tunnel because at node C (TE tunnel endpoint) I receive about 50Mbps.
My expectation was to see 70Mbps (te1 bandwidth=8750000) at node C and <=30Mbps at node B (not TE receiver).
Thanks,
Luca
You do not have the required permissions to view the files attached to this post.
Re: MPLS - problem with bandwidth reservation in TE tunnel
Luca, bandwidth settings are used purely as path setup constraints - TE tunnels do not limit traffic to the specified bandwidth. It is responsibility of administrator to apply any limitations on traffic flow at ingress point, if necessary. From http://wiki.mikrotik.com/wiki/MPLS_TE_Tunnels:
You can check that VPLS traffic is forwarded over TE tunnel by monitoring VPLS interface:Note that constraints for path establishment are purely controlled by administrator - for example, bandwidth of link participating in RSVP TE network is set by administrator and does not necessarily reflect real bandwidth of the link. The same way bandwidth reserved for tunnel is set by administrator and does not automatically imply any limits on traffic sent over tunnel. Therefore at any moment in time, bandwidth available on TE link is bandwidth configured for link minus sum of all reservations made on link, not physically available bandwidth which can be either less (in case data is forwarded over tunnels with rate that exceeds bandwidth reserved for tunnel or if non-RSVP tunnel data is forwarded over link as well) or more (in case data is forwarded over tunnels with rate smaller than allocated for tunnel) than bandwidth available for reservations.
Code: Select all
[admin@R1] /interface vpls> monitor 0
remote-label: 24
local-label: 25
remote-status:
transport: te1
transport-nexthop: 1.1.1.2
imposed-labels: 30,24
-
-
lucapilosu
just joined
- Posts: 6
- Joined:
Re: MPLS - problem with bandwidth reservation in TE tunnel
Ok...but in this case probably I can't get what reservation means: let me explain what I've understood.
It's clear that constraints on the bandwidth of a link depend on actual resources, and if I try to reserve, let's say, 200Mbps on a 100Mbps link, my setup is wrong.
But if I know the available bandwidth (100Mbps), I would like to be sure that my RSVP TE path can use the amount of bandwidth I reserved, for instance, 70Mbps on a 100Mbps link as in my case. In this case, reservation means that I'm sure to obtain 70Mbps (if the link capacity is >=70M) or more, passing through the tunnel. Then other flows would share the remaining bandwidth (30M in my case).
In this scenario I don't need to do any shaping of my incoming traffic at the ingress point, otherwise I wouldn't need any reservation from the network!
What I'd like to understand is if this kind of reservation is only an open issue (that will be implemented soon) or if my interpretation is wrong (in this case, please help me
).
Do you have any roadmap for new MPLS features implementations (such as fast reroute and so on)?
Kindly regards,
Luca
It's clear that constraints on the bandwidth of a link depend on actual resources, and if I try to reserve, let's say, 200Mbps on a 100Mbps link, my setup is wrong.
But if I know the available bandwidth (100Mbps), I would like to be sure that my RSVP TE path can use the amount of bandwidth I reserved, for instance, 70Mbps on a 100Mbps link as in my case. In this case, reservation means that I'm sure to obtain 70Mbps (if the link capacity is >=70M) or more, passing through the tunnel. Then other flows would share the remaining bandwidth (30M in my case).
In this scenario I don't need to do any shaping of my incoming traffic at the ingress point, otherwise I wouldn't need any reservation from the network!
What I'd like to understand is if this kind of reservation is only an open issue (that will be implemented soon) or if my interpretation is wrong (in this case, please help me
).Do you have any roadmap for new MPLS features implementations (such as fast reroute and so on)?
Kindly regards,
Luca
Re: MPLS - problem with bandwidth reservation in TE tunnel
MPLS TE RSVP reservations serve only as an accounting mechanism in the MPLS TE module. This prevents link oversubscription by MPLS TE paths. MPLS TE reservations do not result in any QoS actions on the intermediate nodes.
-
-
lucapilosu
just joined
- Posts: 6
- Joined:
Re: MPLS - problem with bandwidth reservation in TE tunnel
So with TE tunnels I can control bandwidth reservation when more tunnels are sharing some links, but the effective traffic shaping must be done within the nodes. Is that right?MPLS TE RSVP reservations serve only as an accounting mechanism in the MPLS TE module. This prevents link oversubscription by MPLS TE paths. MPLS TE reservations do not result in any QoS actions on the intermediate nodes.
But how can I combine the traffic-eng information (reserved and available bandwidth) with the actual control of incoming flows? I mean, if I know that on an interface I have reserved 10Mbps and my incoming flow going through that interface is 20Mbps, how can I shape it (my goal, as you probably intended, is to do some QoS over MPLS-TE)?
One more question about TE tunnels: if a link belonging to a tunnel path goes down, is the path re-calculated automatically? If it is, how long does it take?
Thanks a lot,
Luca
Re: MPLS - problem with bandwidth reservation in TE tunnel
TE makes sure that over any link you do not setup tunnels such that their total bandwidth (configured) exceeds link bandwidth (configured). E.g. if you have configured interface with bandwidth 100Mbps, you will only be able to establish 3 tunnels with configured bandwidth 30Mbps through that link. And it does not matter if your link is actually capable of transmitting 100Mbps or if you are really sending 30Mbps over tunnels.So with TE tunnels I can control bandwidth reservation when more tunnels are sharing some links, but the effective traffic shaping must be done within the nodes. Is that right?
Any shaping should get done at TE tunnel ingress, because you can not shape MPLS switched traffic using means commonly used for shaping (marking packets in mangle and creating queues).
You have to make sure that you do not let in TE tunnel more traffic than you have configured - if you have configured your TE tunnel with 10Mbps, setup queues on ingress router (the one you configured TE tunnel on) such that no more than 10Mbps gets sent into tunnel.But how can I combine the traffic-eng information (reserved and available bandwidth) with the actual control of incoming flows? I mean, if I know that on an interface I have reserved 10Mbps and my incoming flow going through that interface is 20Mbps, how can I shape it (my goal, as you probably intended, is to do some QoS over MPLS-TE)?
If CSPF path goes down, yes it is recalculated automatically. Additionally - you can setup periodic reoptimization that will try to find better path by configuring "reoptimize-interval".One more question about TE tunnels: if a link belonging to a tunnel path goes down, is the path re-calculated automatically? If it is, how long does it take?
Thanks a lot,
Luca
Time it takes to detect that path is down varies based on configuration (explicit route configuration, whether CSPF is used and such) and the event that triggers this. The longest will take to detect loss of path by timeouting RSVP messages, this period depends on on interface refresh-time and k-factor. For default values of these settings (refresh-time 30s, k-factor 3) it will take ~160 seconds. But e.g. loss of running state for interface should propagate immediately.
Re: MPLS - problem with bandwidth reservation in TE tunnel
You can scale the IPSec implementation to more offices much easier than you can EoIP. I would recommend that approach.
Who is online
Users browsing this forum: No registered users and 19 guests