Redistributing Static Routes into IS-IS

Problem

You have a single, low-speed link to a small customer and instead, of having the customer run IS-IS (or even RIP), you want to set up a static route to the customer.

Solution

Create a routing policy to redistribute static routes into IS-IS:

	[edit policy-options]
	aviva@RouterG# set policy-statement export-statics term 1 from protocol static
	aviva@RouterG# set policy-statement export-statics term 1 then accept
	aviva@RouterG# show
	policy-statement export-statics {
	 term 1 {

	 from protocol static;
	 then accept;
	}
	}

Then apply the policy to IS-IS:

	[edit protocols isis]
	aviva@RouterG# set export export-statics

 

Discussion

Routing policy is normally applied to BGP to filter the entries in the routing table rather than to IS-IS or another IGP. This is because the main purpose of an IGP is to determine the best route to a destination. However, occasionally you need to use routing policies with an IGP, generally to redistribute routes into that IGP from another protocol. For example, this might be done for a small customer who doesn't need to run a dynamic routing protocol, such as IS-IS, but just connect to you using a static route. You create a routing policy to redistribute these customer's routes into your IS-IS network. This recipe creates a simple routing policy to do this, accepting all static routes. For the policy to take effect, you must apply it to IS-IS.

RouterG has one configured static route:

	aviva@RouterG> show route protocol static table inet.0
	inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	192.168.12.1/32 *[Static/5] 00:10:41
	 > to 10.0.16.1 via fe-1/0/0.0

When the static route is redistributed into IS-IS, it is incorporated into the IS-IS link-state database and is marked as being an external prefix:

	aviva@RouterG> show isis database extensive
	IS-IS level 1 link-state database:
	RouterG.00-00 Sequence: 0xe5, Checksum: 0x912c, Lifetime: 492 secs
	 IP prefix: 10.0.1.0/24 Metric: 10 Internal Up
	 IP prefix: 10.0.16.0/24 Metric: 10 Internal Up
	 IP prefix: 192.168.12.1/32 Metric: 0 External Up
	 IP prefix: 192.168.19.1/32 Metric: 0 Internal Up
	 Header: LSP ID: RouterG.00-00, Length: 175 bytes
	 Allocated length: 1492 bytes, Router ID: 192.168.19.1
	 Remaining lifetime: 492 secs, Level: 1,Interface: 0
	 Estimated free bytes: 1317, Actual free bytes: 1317
	 Aging timer expires in: 492 secs
	 Protocols: IP, IPv6
	 Packet: LSP ID: RouterG.00-00, Length: 175 bytes, Lifetime : 1200 secs
	 Checksum: 0x912c, Sequence: 0xe5, Attributes: 0xb 
	 NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes
	 Packet type: 18, Packet version: 1, Max area: 0
	 TLVs:
	 Area address: 49.0020 (3)
	 Speaks: IP
	 Speaks: IPv6

	 IP router id: 192.168.19.1
	 IP address: 192.168.19.1
	 Hostname: RouterG
	 IP prefix: 10.0.1.0/24, Internal, Metric: default 10, Up
	 IP prefix: 10.0.16.0/24, Internal, Metric: default 10, Up
	 IP prefix: 192.168.19.1/32, Internal, Metric: default 0, Up
	 IP extended prefix: 10.0.1.0/24 metric 10 up
	 IP extended prefix: 10.0.16.0/24 metric 10 up
	 IP extended prefix: 192.168.19.1/32 metric 0 up
	 IP external prefix: 192.168.12.1/32, Internal, Metric: default 0, Up
	 IP extended prefix: 192.168.12.1/32 metric 0 up
	 Authentication data: 17 bytes
	 No queued transmissions
	…

The show isis database extensive command output shows that the metric for the static route redistributed into IS-IS is 0. To lower the preference for the route, change the metric in the routing policy to increase the cost. Here, we increase the metric to 500:

	[edit policy-options]
	aviva@RouterG# set policy-statement export-statics term 1 then metric 500

The policy now looks like this:

	aviva@RouterG# show
	policy-statement export-statics {
	 term 1 {
	 from protocol static;
	 then {
	 metric 500;
	 accept;
	 }
	 }
	}

Looking in the IS-IS link-state database shows that the metric value has changed from 0:

	aviva@RouterG> show isis database extensive
	IS-IS level 1 link-state database:
	RouterG.00-00 Sequence: 0xe5, Checksum: 0x912c, Lifetime: 492 secs
	 IP prefix: 10.0.1.0/24 Metric: 10 Internal Up
	 IP prefix: 10.0.16.0/24 Metric: 10 Internal Up
	 IP prefix: 192.168.12.1/32 Metric: 63 External Up
	 IP prefix: 192.168.19.1/32 Metric: 0 Internal Up

It's true that the metric has changed, but instead of being 500, it's 63. Looking in the routing table on the neighboring router shows that it has learned the static route:

	aviva@RouterA> show route
	inet.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	192.168.12.1/32 *[IS-IS/160] 00:14:56, metric 73
	 > via se-0/0/3.0

Again, we expect the metric to change from the default of 10 to 500, but it's showing a metric of 73. Why isn't the metric value changing to 500? The reason is because IS-IS uses two kinds of metrics, narrow and wide. By default, the JUNOS software uses the IS-IS narrow metrics, which are defined in the original IS-IS standards documents as 8-bit values. With narrow metrics, the router can't advertise a metric greater than 63. If it receives a metric value greater than 63, IS-IS clips it to 63. This is why the link-state database shows a metric of 63 and the neighbor's routing table shows a metric of 73 (the default metric of 10 plus 63). To resolve this problem, configure IS-IS to use wide metrics:

	[edit protocols isis]
	aviva@RouterG# set level 1 wide-metrics-only

Wide metrics, defined in RFC 3784, can be values greater than 63. Looking again at the link-state database shows that IS-IS is now advertising the metric value of 500:

	aviva@RouterG> show isis database extensive
	IS-IS level 1 link-state database:
	RouterG.00-00 Sequence: 0xe5, Checksum: 0x912c, Lifetime: 492 secs
	 IP prefix: 10.0.1.0/24 Metric: 10 Internal Up
	 IP prefix: 10.0.16.0/24 Metric: 10 Internal Up
	 IP prefix: 192.168.12.1/32 Metric: 500 External Up
	 IP prefix: 192.168.19.1/32 Metric: 0 Internal Up
	TLVs:
	…
	 IP external prefix: 192.168.12.1/32, Internal, Metric: 500, Up

The neighbor's routing table also reflects the change:

	aviva@RouterA> show route
	inet.0: 6 destinations, 7 
routes (6 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	192.168.12.1/32 *[IS-IS/160] 00:14:56, metric 500
	 > via se-0/0/3.0