Forwarding L2MPLS Traffic Over MPLS Traffic Engineering

Introduction
Forwarding l2mpls over traffic engineering tunnel is not a bit complex but a tricky one. This all depends over the requirement how the service provider wants to route the traffic of backhauls. In this test setup we have implemented the MPLS TE for a single customer rest of the traffic of backhaul will follow the traditional IGP path.
The two options available in pseudo wire to forward the l2mpls traffic over te tunnel.
a) preferred-path peer
b) preferred-path tunnel interface

In this test result, option a is used to route the only customer traffic. If option b is used with auto-route announce, in that case the full backhaul traffic follow the tunnel path which may create more problems.



How to use preferred-path peer option
To use this option a loopback 100 is created on R3 which is the tunnel tail-end router and is not announced in the IGP. The reason for not announcing in IGP is that because when the tunnel path will get disconnect, the traffic will fall to the normal IGP path. This could be disabled by using fallback option in preferred-path command.
On R1 a TEST pseudowire is created with preferred-path peer 4.4.4.4 and a static route is imposed on R1 for 4.4.4.4 with next hop as tunnel 10.

Configuration of R1
pseudowire-class TEST
encapsulation mpls
preferred-path peer 4.4.4.4

ip route 4.4.4.4 255.255.255.255 Tunnel10

interface Tunnel10
ip unnumbered Loopback0
tunnel destination 10.10.10.3
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng path-option 1 explicit name R3
no routing dynamic
end

ip explicit-path name R3 enable
next-address 192.168.1.9
next-address 192.168.1.5


Commands Need To Be Enabled On All RSVP Participating Interfaces

mpls traffic-eng tunnels
ip rsvp bandwidth 200 200

Global Config Commands

mpls traffic-eng tunnels

Commands for OSPF
router ospf 1
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0

Test Results

Download the full test results.

People who read this post also read :