[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