So the point of this post is to define a per-flow explicit path. Rather than just routing it one way or another using MPLS-TE, route some traffic one way and some another using some Policy Based Routing.
This post follows on from last weeks post which went through setting up explicit paths using MPLS-TE tunnels. If you aren’t familiar with MPLS-TE read that post. The topology for this post is the same, here it is again.
The configuration is actually quite simple. First you need a tunnel and then you map some traffic into it using PBR.
Here is the relevant configuration on Thor to set the tunnel up to force the traffic through Odin.
interface Tunnel10 ip unnumbered Loopback0 mpls ip mpls traffic-eng tunnels tunnel destination 192.0.2.3 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 1 explicit name ViaOdin tunnel mpls traffic-eng path-option 2 dynamic ! ip explicit-path name ViaOdin enable next-address 198.51.100.1 next-address 198.51.100.6 !
There are two things to notice. One is the lack of autoroute annouce. Nothing will be routed into this tunnel automagically by the IGP.
Also, there is a second dynamic path option, this is in case the primary path fails, then the tunnel will find it’s own way. Note it’s probably worth using the mpls traffic-eng reoptimize timers frequency command, as the default is 3600 seconds – 1 hour. That is, if your path fails over to the secondary path option, when your primary path returns it won’t be used for up to one hour by default.
The only new config to get some per-flow awesomeness going is some basic PBR. For this lab I have the following on Thor:
route-map TRAFFIC permit 10 match ip address FTP_ACL set interface Tunnel10 ! ip access-list extended FTP_ACL permit tcp any host 192.0.2.3 eq ftp permit tcp any host 192.0.2.3 eq ftp-data ! ip local policy route-map TRAFFIC !
The route-map looks for traffic matching the ACL, if it does then it maps it out the tunnel interface. The ACL matches all FTP traffic for Njords Loop0 interface, quite a simple example.
The policy is applied to local traffic. In an actual use case you would turn on PBR on the default gateway interface or something like that, or a point to point.
If you wanted to apply it to all traffic heading to a router, rather then defining the specific IP addresses which would be quite a pain in a real network. You could do the following.
First, have two tunnels.
interface Tunnel10 ip unnumbered Loopback0 mpls ip mpls traffic-eng tunnels tunnel destination 192.0.2.3 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng path-option 1 dynamic ! interface Tunnel20 ip unnumbered Loopback0 ip ospf cost 1 mpls ip tunnel destination 192.0.2.3 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 1 explicit name ViaOdin tunnel mpls traffic-eng path-option 2 dynamic !
Nothing too new or exciting here, tunnel 10 is dynamic and this time it is announced to the IGP. This means that tunnel 10 will be the outgoing interface for all traffic destined for Njord (and beyond) – Njord appears to be directly connected to this interface and this would be true even if this tunnel hopped over multiple links.
Next we simply change our route-map to match this interface and change our ACL to only look at the type of traffic – not the source or destination IP addresses. In this case I am now matching all HTTP traffic.
ip access-list extended HTTP_ACL permit tcp any any eq www ! route-map TRAFFIC permit 50 match ip address HTTP_ACL match interface Tunnel10 set interface Tunnel20 !
There ya go. Now all HTTP traffic from Thor to Njord will be routed through Odin. All other traffic goes direct.
Remember, the tunnels are unidirectional – return traffic will go direct unless you create the corresponding return tunnel and maps on the other end.
If you want to test it the above examples I used telnet 192.0.2.3 www and telnet 192.0.2.3 ftp on Thor, you can then watch the counters on your interfaces and route-maps increase.
So, where would you use this?
You wouldn’t. What the hell is wrong with you.