Juniper IS-IS Routing Policy

Note: This is Juniper Junos related article, and IS-IS is not on the CCIE R&S Blueprint anyway :)

This post is a bit of a recap on using IS-IS on Juniper routers.

To enable IS-IS, on the physical interfaces besides adding the inet family to enable IPv4 addressing, the iso family also requires enabling, this way IS-IS related frames will not be discarded by the router.  Once this is done, we need to set a NSAP address on one of the interfaces (typically this would be loopback0 unit 0) which specifies what IS-IS area this router lives in.  Unlike OSPF where area membership is on a link by link basis, an IS-IS router is normally a member of a single area.

Inter-area communications can occur on Level 2 routers, when Intra-Area communications can occur on Level 1 routers (IS-IS routers that are both Level 1 and Level 2 routers are much like an OSPF ABR)

In this topology we have 4 routers existing in two areas.  R1 and R2 are in area 12 while R3 and R4 are in area 34

R1(Area 12)--L1-(Area 12)R2(Area 12)--L2--(Area 34)R3(Area 34)--L1--(L1 Area 34)R4

To derive the System IDs I followed the general method to looking at the router id, inserted leading zeroes where necessary and removing the dots to the string is 12 characters long.

e.g. 1.23.123.4 would become 001023123004  then a dot would be added every 4th character resulting in a System ID of 0010.2312.3004  to generate the lo0.0 NSAP address we prepend the area and append the selector (00)

By Disabling IS-IS Level 2 on R1, R1 is a Level 1 only Router:

root@R1> show configuration | display set
set system host-name R1
set interfaces em1 vlan-tagging
set interfaces em1 unit 12 vlan-id 12
set interfaces em1 unit 12 family inet address 10.1.12.1/24
set interfaces em1 unit 12 family iso
set interfaces lo0 unit 0 family inet address 1.1.1.1/32
set interfaces lo0 unit 0 family iso address 12.0010.0100.1001.00
set routing-options router-id 1.1.1.1
set protocols isis level 2 disable
set protocols isis interface em1.12
set protocols isis interface lo0.0 passive

As R1 and R2 are both in the same IS-IS area, they will communicate (but only on Level 1 since R1 has disabled Level 2)

root@R2> show configuration | display set
set system host-name R2
set interfaces em1 vlan-tagging
set interfaces em1 unit 12 vlan-id 12
set interfaces em1 unit 12 family inet address 10.1.12.2/24
set interfaces em1 unit 12 family iso
set interfaces em1 unit 23 vlan-id 23
set interfaces em1 unit 23 family inet address 10.1.23.2/24
set interfaces em1 unit 23 family iso
set interfaces lo0 unit 0 family inet address 2.2.2.2/32
set interfaces lo0 unit 0 family iso address 12.0020.0200.2002.00
set protocols isis interface em1.12
set protocols isis interface em1.23
set protocols isis interface lo0.0 passive

R2 and R3 are in different IS-IS areas and therefore will not communicate on Level 1 however they will at Level 2

root@R3> show configuration | display set
set system host-name R3
set interfaces em1 vlan-tagging
set interfaces em1 unit 23 vlan-id 23
set interfaces em1 unit 23 family inet address 10.1.23.3/24
set interfaces em1 unit 23 family iso
set interfaces em1 unit 34 vlan-id 34
set interfaces em1 unit 34 family inet address 10.1.34.3/24
set interfaces em1 unit 34 family iso
set interfaces lo0 unit 0 family inet address 3.3.3.3/32
set interfaces lo0 unit 0 family iso address 34.0030.0300.3003.00
set routing-options router-id 3.3.3.3
set protocols isis interface em1.23
set protocols isis interface em1.34
set protocols isis interface lo0.0 passive

As R3 and R4 are both in the same IS-IS area, they will communicate (but only on Level 1 since R4 has disabled Level 2)


root@R4> show configuration | display set
set system host-name R4
set interfaces em1 vlan-tagging
set interfaces em1 unit 34 vlan-id 34
set interfaces em1 unit 34 family inet address 10.1.34.4/24
set interfaces em1 unit 34 family iso
set interfaces lo0 unit 0 family inet address 4.4.4.4/32
set interfaces lo0 unit 0 family iso address 34.0040.0400.4004.00
set routing-options router-id 4.4.4.4
set protocols isis level 2 disable
set protocols isis interface em1.34
set protocols isis interface lo0.0 passive



Lets check the IS-IS interface state and adjacencies for each of the routers


root@R1> show isis interface
IS-IS interface database:
Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric
em1.12                1   0x2 R1.02             Disabled               10/10
lo0.0                 0   0x1 Passive           Passive                 0/0

root@R1> show isis adjacency
Interface             System         L State        Hold (secs) SNPA
em1.12                R2             1  Up                   21  8:0:27:9:ed:8

root@R2> show isis interface
IS-IS interface database:
Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric
em1.12                3   0x1 R1.02             R2.00                  10/10
em1.23                3   0x1 R2.00             R3.02                  10/10
lo0.0                 0   0x1 Passive           Passive                 0/0

root@R2> show isis adjacency
Interface             System         L State        Hold (secs) SNPA
em1.12                R1             1  Up                    6  8:0:27:e9:be:75
em1.23                R3             2  Up                    7  8:0:27:21:fd:cf

root@R3> show isis interface
IS-IS interface database:
Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric
em1.23                3   0x2 R3.00             R3.02                  10/10
em1.34                3   0x1 R4.02             R3.00                  10/10
lo0.0                 0   0x1 Passive           Passive                 0/0

root@R3> show isis adjacency
Interface             System         L State        Hold (secs) SNPA
em1.23                R2             2  Up                   23  8:0:27:9:ed:8
em1.34                R4             1  Up                    7  8:0:27:55:b6:d1

root@R4> show isis interface
IS-IS interface database:
Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric
em1.34                1   0x2 R4.02             Disabled               10/10
lo0.0                 0   0x1 Passive           Passive                 0/0

root@R4> show isis adjacency
Interface             System         L State        Hold (secs) SNPA
em1.34                R3             1  Up                   22  8:0:27:21:fd:


So we can see that the connectivity and adjacencies appear connect  (By the way if you saw L3 for some interfaces e.g. on R2 and R3 that is because they are operating at both L1 and L2)

R1 and R4 will appear to be existing in the equivalent of an OSPF totally stubby area

root@R1> show route table inet.0 terse

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 0.0.0.0/0          I  15         10            >10.1.12.2
* 1.1.1.1/32         D   0                       >lo0.0
* 2.2.2.2/32         I  15         10            >10.1.12.2
* 10.1.12.0/24       D   0                       >em1.12
* 10.1.12.1/32       L   0                        Local
* 10.1.23.0/24       I  15         20            >10.1.12.2

root@R4> show route table inet.0 terse

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 0.0.0.0/0          I  15         10            >10.1.34.3
* 3.3.3.3/32         I  15         10            >10.1.34.3
* 4.4.4.4/32         D   0                       >lo0.0
* 10.1.23.0/24       I  15         20            >10.1.34.3
* 10.1.34.0/24       D   0                       >em1.34
* 10.1.34.4/32       L   0                        Local

There is a default route installed by R1 due to R2 advertising its "Attached" status

root@R1> show isis database
IS-IS level 1 link-state database:
LSP ID                      Sequence Checksum Lifetime Attributes
R1.00-00                         0xc   0x3127      559 L1
R1.02-00                         0xb   0x4377      559 L1
R2.00-00                        0x11   0x7895      502 L1 L2 Attached
  3 LSPs

IS-IS level 2 link-state database:
  0 LSPs

And the same occurs for R4 due to R3 advertising its "Attached" status

root@R4> show isis database
IS-IS level 1 link-state database:
LSP ID                      Sequence Checksum Lifetime Attributes
R3.00-00                         0x8   0xfd36      486 L1 L2 Attached
R4.00-00                         0x5   0xc94a      488 L1
R4.02-00                         0x5   0x1039      488 L1
  3 LSPs

IS-IS level 2 link-state database:
  0 LSPs

R2 and R3 both have full routing table visibility

root@R2> show route table inet.0 terse

inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 1.1.1.1/32         I  15         10            >10.1.12.1
* 2.2.2.2/32         D   0                       >lo0.0
* 3.3.3.3/32         I  18         10            >10.1.23.3
* 4.4.4.4/32         I  18         20            >10.1.23.3
* 10.1.12.0/24       D   0                       >em1.12
* 10.1.12.2/32       L   0                        Local
* 10.1.23.0/24       D   0                       >em1.23
* 10.1.23.2/32       L   0                        Local
* 10.1.34.0/24       I  18         20            >10.1.23.3

root@R3> show route table inet.0 terse

inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 1.1.1.1/32         I  18         20            >10.1.23.2
* 2.2.2.2/32         I  18         10            >10.1.23.2
* 3.3.3.3/32         D   0                       >lo0.0
* 4.4.4.4/32         I  15         10            >10.1.34.4
* 10.1.12.0/24       I  18         20            >10.1.23.2
* 10.1.23.0/24       D   0                       >em1.23
* 10.1.23.3/32       L   0                        Local
* 10.1.34.0/24       D   0                       >em1.34
* 10.1.34.3/32       L   0                        Local

Enabling R1 to communicate with R4

root@R1> ping 4.4.4.4 source 1.1.1.1 count 3
PING 4.4.4.4 (4.4.4.4): 56 data bytes
64 bytes from 4.4.4.4: icmp_seq=0 ttl=62 time=2.672 ms
64 bytes from 4.4.4.4: icmp_seq=1 ttl=62 time=1.781 ms
64 bytes from 4.4.4.4: icmp_seq=2 ttl=62 time=1.719 ms

--- 4.4.4.4 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.719/2.057/2.672/0.435 ms

So far a long story without the promised policy configuration.

Firstly, lets decide that R4 should not have a default route installed installed in its routing table.  The way we do this is by telling the router not to pay attention to the attached bit in the LSA from the L2 router

root@R4> configure
Entering configuration mode

[edit]
root@R4# set protocols isis ignore-attached-bit

[edit]
root@R4# commit and-quit
commit complete
Exiting configuration mode

root@R4> show isis database
IS-IS level 1 link-state database:
LSP ID                      Sequence Checksum Lifetime Attributes
R3.00-00                         0x8   0xfd36      424 L1 L2 Attached
R4.00-00                         0x6   0xa46e     1182 L1
R4.02-00                         0x6    0xe3a     1182 L1
  3 LSPs

IS-IS level 2 link-state database:
  0 LSPs


So we're still receiving the Attached bit because we haven't stopped R3 from advertising it, we're just not actioning it..

root@R4> show route table inet.0 terse

inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 3.3.3.3/32         I  15         10            >10.1.34.3
* 4.4.4.4/32         D   0                       >lo0.0
* 10.1.23.0/24       I  15         20            >10.1.34.3
* 10.1.34.0/24       D   0                       >em1.34
* 10.1.34.4/32       L   0                        Local

Okay, so the default route is gone, however we no longer have routes beyond R3.  The way we can work around this is to do controlled leaking of routes from L2 to L1 using routing policy.

In this initial example we'll allow R1 lo0.0's IP address to leak from L2 to L1 and therefore visible by R4

root@R3> configure
Entering configuration mode

[edit]
root@R3# edit policy-options policy-statement R1toR4

[edit policy-options policy-statement R1toR4]
root@R3# set term 10 from protocol isis
root@R3# set term 10 from level 2
root@R3# set term 10 from route-filter 1.1.1.1/32 exact
root@R3# set term 10 to level 1
root@R3# set term 10 then accept
root@R3# set term 20 from protocol isis
root@R3# set term 20 from level 2
root@R3# set term 20 to level 1
root@R3# set term 20 then reject
[edit policy-options policy-statement R1toR4]
root@R3# up

[edit policy-options]

root@R3# show
policy-statement R1toR4 {
    term 10 {
        from {
            protocol isis;
            level 2;
            route-filter 1.1.1.1/32 exact;
        }
        to level 1;
        then accept;
    }
    term 20 {
        from {
            protocol isis;
            level 2;
        }
        to level 1;
        then reject;
    }
}




Specifically we're only allowing the L2 1.1.1.1/32 route to be send to L1.  So lets apply this to IS-IS

[edit policy-options]
root@R3# top

[edit]
root@R3# set protocols isis export R1toR4

[edit]
root@R3# commit and-quit
commit complete
Exiting configuration mode

So are we now seeing this route on R4?

root@R4> show route table inet.0 terse

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 1.1.1.1/32         I  18         30            >10.1.34.3
* 3.3.3.3/32         I  15         10            >10.1.34.3
* 4.4.4.4/32         D   0                       >lo0.0
* 10.1.23.0/24       I  15         20            >10.1.34.3
* 10.1.34.0/24       D   0                       >em1.34
* 10.1.34.4/32       L   0                        Local

root@R4> ping 1.1.1.1 source 4.4.4.4 count 3
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=62 time=9.980 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=62 time=2.042 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=62 time=3.662 ms

--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.042/5.228/9.980/3.425 ms

What if we wanted R4 to be also able to reach R2? All we really need to do is to extend the R1toR4 policy on R3 to include R2 Lo0.0

Firstly we need to insert the entry between term 10 and term 20, so firstly we'll rename term 20 to term 30

root@R3> configure
Entering configuration mode

[edit]
root@R3# edit policy-options policy-statement R1toR4

[edit policy-options policy-statement R1toR4]
root@R3# rename term 20 to term 30

[edit policy-options policy-statement R1toR4]
root@R3# show
term 10 {
    from {
        protocol isis;
        level 2;
        route-filter 1.1.1.1/32 exact;
    }
    to level 1;
    then accept;
}
term 30 {
    from {
        protocol isis;
        level 2;
    }
    to level 1;
    then reject;
}

Now we'll add term 20 to allow 2.2.2.2/32

[edit policy-options policy-statement R1toR4]
root@R3# set term 20 from protocol isis level 2 route-filter 2.2.2.2/32 exact
root@R3# set term 20 to level 1
root@R3# set term 20 then accept

[edit policy-options policy-statement R1toR4]
root@R3# show
term 10 {
    from {
        protocol isis;
        level 2;
        route-filter 1.1.1.1/32 exact;
    }
    to level 1;
    then accept;
}
term 30 {
    from {
        protocol isis;
        level 2;
    }
    to level 1;
    then reject;
}
term 20 {
    from {
        protocol isis;
        level 2;
        route-filter 2.2.2.2/32 exact;
    }
    to level 1;
    then accept;
}

We have a slight problem here in that term 20 will be evaluated after term 30 because terms get evaluated in the order they appear in the configuration - term 30 will be evaluated and reject all L2 routes before term 20 can be evaluated.  Thankfully Junos gives up the tools to resolve this.

[edit policy-options policy-statement R1toR4]
root@R3# insert term 20 before term 30

[edit policy-options policy-statement R1toR4]
root@R3# show
term 10 {
    from {
        protocol isis;
        level 2;
        route-filter 1.1.1.1/32 exact;
    }
    to level 1;
    then accept;
}
term 20 {
    from {
        protocol isis;
        level 2;
        route-filter 2.2.2.2/32 exact;
    }
    to level 1;
    then accept;
}
term 30 {
    from {
        protocol isis;
        level 2;
    }
    to level 1;
    then reject;
}

[edit policy-options policy-statement R1toR4]
root@R3# commit and-quit
commit complete
Exiting configuration mode

Lets check that R4 can reach R2

root@R4> show isis route
 IS-IS routing table             Current version: L1: 26 L2: 0
IPv4/IPv6 Routes
----------------
Prefix             L Version   Metric Type Interface       NH   Via
1.1.1.1/32         1      26       30 int  em1.34          IPV4 R3             
2.2.2.2/32         1      26       20 int  em1.34          IPV4 R3             
3.3.3.3/32         1      26       10 int  em1.34          IPV4 R3             
10.1.23.0/24       1      26       20 int  em1.34          IPV4 R3           

root@R4> ping 2.2.2.2 source 4.4.4.4 count 3
PING 2.2.2.2 (2.2.2.2): 56 data bytes
64 bytes from 2.2.2.2: icmp_seq=0 ttl=63 time=9.064 ms
64 bytes from 2.2.2.2: icmp_seq=1 ttl=63 time=3.630 ms
64 bytes from 2.2.2.2: icmp_seq=2 ttl=63 time=3.649 ms

--- 2.2.2.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.630/5.448/9.064/2.557 ms

Success!