Routing

 View Only
last person joined: 4 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  Filtering routes from IS-IS

    Posted 05-16-2017 08:06

    Is there a JunOS equivalent to Cisco's "no isis advertise prefix" or "advertise-passive-only"?

     

    Thank you.


    #is-is


  • 2.  RE: Filtering routes from IS-IS

    Posted 05-16-2017 08:33

    Hi, 

     

    Yes you can use policy to filter routes that are advised by ISIS: 

     

    Here we can see the downstream device is receiving the loopback (10.0.255.7/32) from the upstream node via ISIS:

     

    lab@srx-vpn> show route protocol isis    
    
    inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
    
    0.0.0.0/0          *[IS-IS/165] 2w0d 04:29:05, metric 30
                        > to 137.221.196.5 via ge-0/0/0.0
    10.0.255.7/32      *[IS-IS/18] 2w0d 04:29:05, metric 20
                        > to 137.221.196.5 via ge-0/0/0.0
    137.221.196.0/30   *[IS-IS/18] 2w0d 04:29:15, metric 20
                        > to 137.221.196.5 via ge-0/0/0.0

    Now let's create a policy to filter the prefix from being advertised in the ISIS process:

     

    [edit]
    lab@mx104-edge# show policy-options policy-statement isis-filter    
    from {
        protocol direct;
        route-filter 10.0.255.7/32 exact;
    }
    then reject;

    Apply the policy as an export policy under protocols isis:

     

    lab@mx104-edge# show protocols isis 
    export [ DEFAULT-TO-ISIS isis-filter ];
    level 1 disable;
    interface ge-0/0/1.0 {
        point-to-point;
    }
    interface lo0.0 {
        passive;
    }

    Now we can see the prefix 10.0.255.7/32 is filtered and no longer present on the downstream device whilst other ISIS routes are still present: 

     

    lab@srx-vpn> show route protocol isis    
    
    inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
    
    0.0.0.0/0          *[IS-IS/165] 2w0d 04:29:06, metric 30
                        > to 137.221.196.5 via ge-0/0/0.0
    137.221.196.0/30   *[IS-IS/18] 2w0d 04:29:16, metric 20
                        > to 137.221.196.5 via ge-0/0/0.0

    You can also filter at ingress.

     

    I hope this helps 🙂 

     



  • 3.  RE: Filtering routes from IS-IS

    Posted 05-16-2017 17:36

    It makes sense, but I don't understand what "DEFAULT-TO-ISIS" is, or what it is supposed to mean.



  • 4.  RE: Filtering routes from IS-IS
    Best Answer

    Posted 05-17-2017 01:23

    "DEFAULT-TO-ISIS" is simply another policy that I'm using to inject a default route into ISIS. For reference here is the policy:

     

    [edit]
    lab@mx104-edge# show policy-options policy-statement DEFAULT-TO-ISIS 
    term 1 {
        from {
            protocol aggregate;
            route-filter 0.0.0.0/0 exact;
        }
        then accept;
    }

    We can see the default route is present on the downstream device:

     

    lab@srx-vpn> show route protocol isis 
    
    inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
    
    0.0.0.0/0          *[IS-IS/165] 2w0d 21:22:28, metric 30
                        > to 137.221.196.5 via ge-0/0/0.0
    137.221.196.0/30   *[IS-IS/18] 2w0d 21:22:38, metric 20
                        > to 137.221.196.5 via ge-0/0/0.0

    Let's now remove the policy leaving only the isis-filter policy we created previously:

     

    [edit]
    lab@mx104-edge# show protocols isis 
    export isis-filter;
    level 1 disable;
    interface ge-0/0/1.0 {
        point-to-point;
    }
    interface lo0.0 {
        passive;
    }

    Checking on the downstream device we can now only see a single prefix is received:

     

    lab@srx-vpn> show route protocol isis    
    
    inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
    
    137.221.196.0/30   *[IS-IS/18] 2w0d 21:24:57, metric 20
                        > to 137.221.196.5 via ge-0/0/0.0

    I hope this is now clear 🙂 



  • 5.  RE: Filtering routes from IS-IS

    Posted 05-17-2017 03:39

    It is all clear now.  Thank you.



  • 6.  RE: Filtering routes from IS-IS

    Posted 05-17-2017 03:41

    No problem 🙂 



  • 7.  RE: Filtering routes from IS-IS

    Posted 03-20-2021 09:03
    Edited by Cristian Vladescu 03-20-2021 09:17
    @daniel.hearty But why does this not work for transient routes?
    If I have R1 --- R2 --- R3, and I want to stop redistributing routes from R1 to R3 at R2, policy statements seem to have no effect.
    I tried this:
    root# show policy-options
    policy-statement ban {
        to interface ge-0/0/1.0;
        then reject;
    }
    
    [edit]
    root# show protocols isis
    interface ge-0/0/0.0 {
        level 1 disable;
    }
    interface ge-0/0/1.0 {
        level 1 disable;
    }
    interface lo0.0 {
        level 1 disable;
    }
    export ban; <<<<<<<<<<<<<<<<
    
    [edit]
    root#​
    ​but I still see the route on R3:
    root# run show route 11.11.11.10
    
    inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
    
    11.11.11.8/30      *[IS-IS/18] 00:32:58, metric 30
                        >  to 100.10.10.5 via ge-0/0/1.0
    
    [edit]
    root#​


    ------------------------------
    Cristian Vladescu
    ------------------------------



  • 8.  RE: Filtering routes from IS-IS

    Posted 03-20-2021 11:25
    All needs to be controlled under a policy.

    # 1. First vMX5 is advertising all prefixes, including 10.100.15.0/24 which is a subnet belonging to a transit link/adjacency.
    
    [edit]
    jcluser@vMX5# run show isis database vMX5.00-00 detail    
    IS-IS level 1 link-state database:
    
    vMX5.00-00 Sequence: 0x6, Checksum: 0xc1d1, Lifetime: 989 secs
       IS neighbor: vMX5.02                       Metric:       10
       IP prefix: 10.100.15.0/24                  Metric:       10 Internal Up <<< !
       IP prefix: 10.100.100.5/32                 Metric:        0 Internal Up 
    
    # 2. We proceed to create a policy describing our intention to only advertise what it is contained in lo0.0 interface as below and reject anything else, we also apply the policy to the IS-IS process as an export policy.
    
    [edit]
    jcluser@vMX5# show | compare 
    [edit policy-options]
    +   policy-statement ADVERTISE-LOOPBACK-ONLY {
    +       term 1 {
    +           from interface lo0.0;
    +           then accept;
    +       }
    +       term 2 {
    +           then reject;
    +       }
    +   }
    [edit protocols isis]
    +   export ADVERTISE-LOOPBACK-ONLY;
    
    [edit]
    jcluser@vMX5# commit 
    commit complete
    
    # 3. If we check what's going on in the LSP, we will see that what we intended to do is the result, vMX5 advertises only it's lo0.0.
    
    [edit]
    jcluser@vMX5# run show isis database vMX5.00-00 detail             
    IS-IS level 1 link-state database:
    
    vMX5.00-00 Sequence: 0x7, Checksum: 0xb599, Lifetime: 1195 secs
       IS neighbor: vMX5.02                       Metric:       10
       IP prefix: 10.100.100.5/32                 Metric:        0 Internal Up​ <<< ! lo0.0 only being advertised.


    HTH,

    Elvin