6

While studying MPLS I couldn't understand it's one basic functionality. Mpls creates tunnel interfaces or pseudowires between label edge routers. To achieve traffic engineering I can set different limits on different tunnels. But what decides which packet takes which tunnel. For instance at the ingress LER there are 3 tunnel interfaces with throughout 50,100,250 mbps respectively. If a packet now enters the mpls network what decides which tunnel it will use .

One option I saw was static which has obvious limitations.

Second option was route maps. Does this mean I can match source IP address and determine tunnel interface ?

Third option is auto and I couldn't understand how it works.

In general does any deep packet inspection technique be used ?

Thanks,

1
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin
    Jan 4, 2021 at 22:33

3 Answers 3

6

Traffic steering is actually the task that is beyond MPLS TE itself. TE tunnel just provides the path, and it's up to other protocols and techniques to steer actual traffic. The same is true for bandwidth reservation. TE just says "there are 300 mbps reserved", but nothing stops your client from sending more than that.

So, your options are policies, static routes and IGPs. If you want granular control you go with static routes and policies. If you just want to get fast restoration you go with announcing tunnels into IGP. Steering technique depends on your task.

2
  • what you said is correct. But I am trying to configure this on Quagga protocol suite and it has no options for Non -bgp access lists so I am not able to steer traffic And more importantly is mandatory to add policies in MPLS ? Cant RSVP identify flows my its won mapping rather than use some adimin configured lists ?
    – john
    May 1, 2017 at 7:10
  • I'm not familiar with MPLS technologies in Quagga, so I can't comment on options there. In general policies are not mandatory. RSVP is not responsible for identifying traffic. It's just signalling + label distribution. Traffic should be mapped to the tunnel by other means. So, if somewhat forces packet to be encapsulated with label that afterwards being swithed via "tunnel", then the job is done. But RSVP itself doesn't care.
    – ar_
    May 1, 2017 at 7:24
3

to expand on the previous answer -- policy is generally dictated by qos. an s/p will generally match on dscp or cos bits (cbts or pbts) to decide tunnel path. there are other ways, in which you can match by source/destination addresses, vrf, etc. they usually take the form of some sort of access-list applied as a policy to the tunnel-path. the policy can take the form as a route-map, depending on platform.

q.

0

If your tunnels follow the same path, but are defined in order to provide several QoS, you should look at Differentiated Service standards and how it integrates with MPLS and Traffic Engineering. Eg. E-LSP where the class of traffic is inferred from the MPLS EXP field, which can be itself inferred from the IP DSCP field at the MPLS network ingress. However in the example, you will have only one tunnel, where traffic classification and priorization is achieved.

If your tunnels follow different path, By default Cisco MPLS routers achieves a weighted load-balancing of the traffic across available path (considering that LSP Tunnels have the same ingress and egress). Weights can be inferred from bandwidth (eg. allocated with RSVP-TE), or administratively configured weights.

As you proposed, you can also use route-maps and ACLs to enforce given flows to be switched through a specific LSP tunnel. However I assume that to stay efficient, packet inspection won't be beyond layer 3 (IP source/destination, IP DSCP/TOS).

Considering your comments, if you need to implement it using BGP, you shoold look at Flowspec. This standards allows distributing filtering rules via BGP. You can configure the action to achieve to the filtered traffic, eg.:

  • redirecting to a specific Next Hop,
  • redirecting to a given VRF, where wo can configure the chosen Tunnel as Next Hop (by default or not)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.