Junos OS

last person joined: 22 hours ago 

Ask questions and share experiences about Junos OS.
  • 1.  next-table may loop

    Posted 03-10-2014 00:11

    Help me to understand such situation. It is necessary translate a little of config from Screenos to Junos.

    Screenos issue:

    set vrouter "trust-vr"
    set route 217.118.52.149/32 vrouter "TrustGi-vr" preference 20
    
    set vrouter "TrustGi-vr"
    set route 172.30.2.8/29 vrouter "trust-vr" preference 20

     I would translate as here. Junos issue:

    set routing-instances trust-vr instance-type virtual-router
    set routing-instances trust-vr routing-options static route 217.118.52.149/32 next-table TrustGi-vr.inet.0
    
    
    set routing-instances TrustGi-vr instance-type virtual-router
    set routing-instances TrustGi-vr routing-options static route 172.30.2.8/29 next-table trust-vr.inet.0

     it seems that everything is logical and correct, but the error appears:

     

    [edit routing-instances vrf-trust routing-options static]
    root# commit check 
    error: [rib vrf-trust.inet.0 routing-options static]
    next-table may loop
    error: configuration check-out failed

     Chance of loops in screenos nobody cared. but in Junos felt that this possibility should be avoided. Tell me how to translate this preferably using Policy-Statements ( not rib-groups).

     



  • 2.  RE: next-table may loop

    Posted 03-10-2014 06:46

    Hello,

    You need to use "next-table" in one direction and Filter-Based Forwarding in another.

    Taking Your "trust-vr" & "TrustGi-vr" as an example:

     

    set routing-instances trust-vr instance-type virtual-router
    set routing-instances trust-vr routing-options static route 217.118.52.149/32 next-table TrustGi-vr.inet.0
    
    set routing-instances TrustGi-vr instance-type virtual-router
    set routing-instances TrustGi-vr forwarding-options family inet filter input sort-into-trustvr
    
    set firewall family inet filter sort-into-trustvr term 1 from destination-adress 172.30.2.8/29
    set firewall family inet filter sort-into-trustvr term 1 then routing-instance trust-vr
    set firewall family inet filter sort-into-trustvr term 2 then accept

     HTH

    Thanks
    Alex



  • 3.  RE: next-table may loop

    Posted 03-10-2014 09:26

    Hello, Alex ! I have performed the config that you suggest. But there is no the route  to network 172.30.2.8/29 . How would I add it. What  should I specify  as the next-hop to 172.30.2.8/29.

    Thanks!



  • 4.  RE: next-table may loop
    Best Answer

    Posted 03-12-2014 02:36

    Hello,

    You have several options here:

    1/ static 172.30.2.8/29 discard in TrustGi-vr

    The FBF takes place before route lookup so no issues here. I did this for quite a few customers.

     

    2/ leak 172.30.2.8/29 from whatever table it is in into TrustGi-vr. But then You don't need FBF.

    If You are not comfortable with RIB groups, You can use "instance-import"

    http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/configuration-statement/instance-import-edit-routing-options.html 

     

    3/ configure static 172.30.2.8/29 on upstream router to point to TrustGi-vr interface IP

     

    HTH

    Thanks

    Alex



  • 5.  RE: next-table may loop

    Posted 03-12-2014 05:52

    Hello! I understand that there are some options to resolve this situation. 
    Also, it seems to me , I have began understand technology of rib-groups and would apply it here.
    For this I need is likely to create another routing-instances (third).
    through which will Mapped routes. not between two directly (because there is loop occurs).



  • 6.  RE: next-table may loop

     
    Posted 03-10-2014 14:25

    Alex, thanks for your input.  didn't know FBF was needed in one of the directions to overcome the error.

     

     

    To use policy-statements exclusively,need to know if 217.118.52.149/32 is a static route configured on TrustGi-vr?  And if 172.30.2.8/29 is a static route or if it's a connected subnet on trust-vr.

     

    Assuming they're all static

     

     

    set policy-options policy-statement FROM_TrustGi-vr term 1 from instance TrustGi-vr
    set policy-options policy-statement FROM_TrustGi-vr term 1 from protocol static
    set policy-options policy-statement FROM_TrustGi-vr term 1 from route-filter 217.118.52.149/32 exact
    set policy-options policy-statement FROM_TrustGi-vr term 1 then accept
    set policy-options policy-statement FROM_TrustGi-vr term 2 then reject
    
    set policy-options policy-statement FROM_trust-vr term 1 from instance trust-vr
    set policy-options policy-statement FROM_trust-vr term 1 from protocol static
    set policy-options policy-statement FROM_trust-vr term 1 from route-filter 172.30.2.8/29 exact
    set policy-options policy-statement FROM_trust-vr term 1 then accept
    set policy-options policy-statement FROM_trust-vr term 2 then reject
    
    
    set routing-instances trust-vr instance-type virtual-router
    set routing-instances trust-vr routing-options instance-import FROM_TrustGi-vr
    set routing-instances trust-vr routing-options static route 172.30.2.8/29 next-hop x.x.x.x
    
    
    set routing-instances TrustGi-vr instance-type virtual-router
    set routing-instances TrustGi-vr routing-options instance-import FROM_trust-vr
    set routing-instances TrustGi-vr routing-options static route 217.118.52.149/32 next-hop x.x.x.x
    

     

    If 172.30.2.8/29 is a connected subnet,

     

    set policy-options policy-statement FROM_trust-vr term 1 from instance trust-vr
    set policy-options policy-statement FROM_trust-vr term 1 from protocol direct
    set policy-options policy-statement FROM_trust-vr term 1 from interface ge-0/0/x
    set policy-options policy-statement FROM_trust-vr term 1 then accept
    set policy-options policy-statement FROM_trust-vr term 2 then reject