Redistributing Static Routes into IS-IS

2017-11-03 09:05:07

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:

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:

The neighbor's routing table also reflects the change:

Категории