1

Can someone please explain why do we need to enable 'wide-metric' for IS-IS if we are going to enable MPLS Traffic engineering on Juniper MX routers?

I mean what does traffic engineering has to do with wide-metric style for IS-IS? What extra information wide-metric starts to carry when enabled , which is required by TE and not supported by narrow metric style of IS-IS.

Thanks

2 Answers 2

3

I mean what does traffic engineering has to do with wide-metric style for IS-IS? What extra information wide-metric starts to carry when enabled , which is required by TE and not supported by narrow metric style of IS-IS.

In order for IS-IS to support traffic engineering, the "old-style" link-state PDU TLVs (Type-2 IS-Reachability and Type-128 IP-Reachability) were extended to what we call "new-style" (Type-22 Extended IS Reachability and Type-135 Extended IP Reachability). These extensions allow IS-IS to convey information related to traffic engineering (bandwidth, link protection, etc.) These new-style TLVs are defined in RFC5305 and RFC5307.

By default, Juniper will advertise both old-style and new-style TLVs (wide-metrics is on by default). By in large, this default was made for networks that were in the middle of transitioning to the new-style functionality.

Enabling wide-metrics-only simply tells IS-IS to suppress old-style TLVs.

To address your comment:

Please correct me If I am wrong. You mean that wide metric is required to populate the traffic engineering database in case of IS-IS?

Don't confuse wide-metrics with wide-metrics-only, as I stated before wide-metrics are enabled on Juniper by default, so if a device receives IS-IS PDUs with TE TLVs, it will populate the TED.

Though if you had a device that did not support wide-metrics and it received TE TLVs, it would ignore them, per IS-IS standard requirements.

2
  • Please correct me If I am wrong. You mean that wide metric is required to populate the traffic engineering database in case of IS-IS? Because in RFC you mentioned above defined TLVs which are carried by wide metric like Administrative color , Interface bandwidth reserved etc etc.
    – Nabeel
    Commented Jan 10, 2020 at 16:47
  • I'll update my answer to clarify. Commented Jan 10, 2020 at 16:55
1

All OSPF and IS-IS interfaces have a cost, which is a routing metric that is used in the link-state calculation. Routes with lower total path metrics are preferred over those with higher path metrics. Unlike OSPF, in which the link metric is calculated automatically based on bandwidth, there is no automatic calculation for IS-IS. All IS-IS links use a metric of 10 by default.

Normally, IS-IS metrics can have values up to 63. The total cost to a destination is the sum of the metrics on all outgoing interfaces along a particular path from the source to the destination. By default, the total path metric is limited to 1023. This metric value is insufficient for large networks and provides too little granularity for traffic engineering, especially with high-bandwidth links. A wider range of metrics is also required if route leaking is used.

IS-IS generates two type, length, and value (TLV) tuples, one for an IS-IS adjacency and the second for an IP prefix. To allow IS-IS to support traffic engineering, a second pair of TLVs has been added to IS-IS, one for IP prefixes and the second for IS-IS adjacency and traffic engineering information. With these TLVs, IS-IS metrics can have values up to 16,777,215 (224 – 1).

article

Your Answer

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

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