[j-nsp] ISIS redistribution : protocol direct vs static

Mihai mihaigabriel at gmail.com
Sun Oct 21 10:24:39 EDT 2012


Hello,

  Sorry if this subject was already discussed but I didn't find it by now.
I am playing with ISIS and I noticed a difference between protocol 
direct and static when they are used in a redistribution policy:

- redistribution of static protocol into a L1 area will result in an 
external L1 route

- redistribution of direct protocol into a L1 area will result in an L1 
internal route

R3 and R1 have a L1 adjancency:

r3# run show isis adjacency

ge-1/1/7.31           mx5t-r1        1  Up                   21 
64:87:88:5e:a5:36

r3> show route protocol direct | match 10.0.3.
10.0.3.3/32        *[Direct/0] 1w4d 01:08:34

r3> show route protocol static

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

100.100.100.0/24   *[Static/5] 00:25:05
                       Discard

r3# show policy-options
policy-statement export-loopback {
     term 1 {
         from {
             protocol isis;
             level 2;
             route-filter 10.0.3.0/29 orlonger;
         }
         to level 1;
         then accept;
     }
     term 2 {
         from {
             protocol direct;
             route-filter 10.0.3.0/29 orlonger;
         }
         to level 1;
         then accept;
     }
     term 3 {
         from {
             protocol static;
             route-filter 100.100.100.0/24 exact;
         }
         to level 1;
         then accept;
     }
}

r1> show route protocol isis 10.0.3.3

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

10.0.3.3/32        *[IS-IS/15] 00:25:06, metric 10
                     > to 10.0.4.13 via ge-1/1/6.13

r1> show route protocol isis 100.100.100.0

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

100.100.100.0/24   *[IS-IS/160] 00:25:22, metric 10
                     > to 10.0.4.13 via ge-1/1/6.13


Is this the normal behavior?


More information about the juniper-nsp mailing list