How is MPLS TE path weight calculated?

[steven.crutchley]

I'm trying to figure out how a TE Tunnel on Cisco IOS-XE gets its path weight value.

R1#sh mpls traffic-eng tun tu100

Name: R1_t100                             (Tunnel100) Destination: 3.3.3.3
  Status:
    Admin: up         Oper: up     Path: valid       Signalling: connected
    path option 1, type explicit VIA-XR3 (Basis for Setup, path weight 1)
  Config Parameters:
    Bandwidth: 0        kbps (Global)  Priority: 7  7   Affinity: 0x0/0xFFFF
    Metric Type: TE (default)
    Path-selection Tiebreaker:
      Global: not set   Tunnel Specific: not set   Effective: min-fill (default)
    Hop Limit: disabled
    Cost Limit: disabled
    Path-invalidation timeout: 10000 msec (default), Action: Tear
    AutoRoute: enabled  LockDown: disabled Loadshare: 0 [0] bw-based
    auto-bw: disabled
    Fault-OAM: disabled, Wrap-Protection: disabled, Wrap-Capable: No
  Active Path Option Parameters:
    State: explicit path option 1 is active
    BandwidthOverride: disabled  LockDown: disabled  Verbatim: disabled
  Node Hop Count: 1

  InLabel  :  -
  OutLabel : GigabitEthernet1.112, 24013
  Next Hop : 10.1.12.12
  RSVP Signalling Info:
       Src 1.1.1.1, Dst 3.3.3.3, Tun_Id 100, Tun_Instance 132
    RSVP Path Info:
      My Address: 10.1.12.1
      Explicit Route: 10.1.12.12 12.12.12.12 13.13.13.13*
      Record   Route:
      Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
    RSVP Resv Info:
      Record   Route:  10.1.12.12 10.12.13.13 10.3.13.3
      Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
  Shortest Unconstrained Path Info:
    Path Weight: 2 (TE)
    Explicit Route: 10.1.12.12 10.3.12.3 3.3.3.3

  History:
    Tunnel:
      Time since created: 4 hours, 21 minutes
      Time since path change: 5 minutes, 23 seconds
      Number of LSP IDs (Tun_Instances) used: 132
    Current LSP: [ID: 132]
      Uptime: 5 minutes, 23 seconds
      Selection: reoptimization
    Prior LSP: [ID: 131]
      ID: path option unknown
      Removal Trigger: configuration changed (severe)

Here the path weight is 1. Now I know that using autoroute announce the IGP will see the metric of any prefix downstream of the tunnel endpoint as that of the shortest IGP path and not necessarily the accumulated metric of the path the tunnel takes - hop by hop.

But I thought that the path weight would show the accumulated metric hop-by-hop. This is all assuming the default of using the TE metrics with in turn default to the IGP metrics. 

In the above output the path to IGP path to 3.3.3.3 is definitely more that 1. It is 3 hops away via OSPF and indeed the routing table shows it as it should (even though the tunnel itself doesn't take the unconstrained path, it still shows its metric as 3 - which is normal behaviour):

R1#sh ip ro 3.3.3.3
Routing entry for 3.3.3.3/32
  Known via "ospf 1", distance 110, metric 3, type intra area
  Last update from 3.3.3.3 on Tunnel100, 00:00:50 ago
  Routing Descriptor Blocks:
  * 3.3.3.3, from 3.3.3.3, 00:00:50 ago, via Tunnel100
      Route metric is 3, traffic share count is 1

But how does the tunnel figure that 1 is path weight? Am I misunderstanding what path weight is? 

For reference the tunnel config is:

interface Tunnel100
 ip unnumbered Loopback0
 mpls traffic-eng tunnels
 tunnel mode mpls traffic-eng
 tunnel destination 3.3.3.3
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng path-option 1 explicit name VIA-XR3
 tunnel mpls traffic-eng record-route

ip explicit-path name VIA-XR3 enable
 index 1 next-address loose 12.12.12.12
 index 2 next-address loose 13.13.13.13

(forgive the poor naming of the explicit-path list... I've been experimenting with different configurations to try and figure this out)

[Harold Ritter · Accepted solution]

Hi Steven,

This is normal behavior. The path weight is always set to cost to the first hop using the loose statement in the explicit path.

Regards,

[steven.crutchley]

Thanks mate! That makes sense and lines up with everything I'm seeing. I didn't see that mentioned in text I was working from but that's helped me immeasurably.

[steven.crutchley]

Actually sorry. I might have jumped the gun.

So that lab above, with a weight of 1, was a lab whereby I had converted the IGP from IS-IS to OSPF. I did this incrementally and found various problems getting tunnels to come up, resulting in me having to shut/unshut most of the interfaces in my lab. The resulting output it what you see above.

However, once I posted the above output, I saved my lab and reloaded it. And now, to make things more complicated, the weight is coming up as 2. All the settings are the same. 

Can I just clarify, is the path weight incremented once per loose hop in the explicit path set? Or would multiple loose hops (like in my example above) still result in the path weight being 1. 

My lab is showing a path weight of 2 now - which I hope means, 1 per loose hop (namely 12.12.12.12 and 13.13.13.13). I'm hoping that the original output above, was due to me not reloading the lab or re-optimizing the tunnel at the right time. 

I'll see if I can hunt down the Cisco documentation on it, but any further help would be appreciated

[Harold Ritter]

Hi Steven,

I ran a quick test and the path weight will be set to the cost to the fist hop using the loose statement. The remainder of the path cost will not be taken in consideration.

So in your case, if the cost to the first hop is 2, that is what will be set on the path weight.

Regards,