Routing

last person joined: 5 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.  Routing-Instance Communication

    Posted 11-02-2012 12:49

    Hi All

     

    I have simple configuration virtual router  i m able import routes ,but cant able to communicate

     

    root@R1# run show interfaces terse
    Interface               Admin Link Proto    Local                 Remote
    dsc                     up    up  
    fxp0                    up    up  
    fxp0.2                  up    up   inet     10.0.4.5/30     
    fxp0.3                  up    up   inet     10.0.4.14/30    
    fxp0.5                  up    up   inet     10.0.5.5/30     
    fxp0.12                 up    up   inet     10.0.5.1/24     
    fxp0.17                 up    up   inet     10.0.7.1/30     
     fxp0.34                 up    up   inet     10.0.4.1/30     

    **************************************Routing Instacne**************************************

     

    root@R1# show
    User-A {
        instance-type virtual-router;
        interface fxp0.2;
        interface fxp0.5;
        interface fxp0.34;
        routing-options {
            interface-routes {
                rib-group inet Inet;
            }
            static {
                rib-group Inet;
                route 0.0.0.0/0 next-hop 10.0.4.6;
            }
        }
    }
    User-B {
        instance-type virtual-router;
        interface fxp0.3;
    }
    User-C {
        instance-type virtual-router;
        interface fxp0.12;
    }
        *********************************************************rib-group*******************************************

    root@R1# show
    static {
        route 10.0.3.3/32 next-hop 10.0.4.13;
        route 10.0.6.2/32 next-hop 10.0.4.6;
    }
    rib-groups {
        Inet {
            import-rib [ User-A.inet.0 User-B.inet.0 ];
        }
    }

    **************************** Route *******************************

     

    .0.0.0/0          *[Static/5] 00:00:18
                        > to 10.0.4.6 via fxp0.2
    10.0.4.0/30        *[Direct/0] 01:13:31
                        > via fxp0.34
    10.0.4.1/32        *[Local/0] 01:13:31
                          Local via fxp0.34
    10.0.4.4/30        *[Direct/0] 01:16:56
                        > via fxp0.2
    10.0.4.5/32        *[Local/0] 01:16:56
                          Local via fxp0.2
    10.0.5.4/30        *[Direct/0] 01:14:43
                        > via fxp0.5
    10.0.5.5/32        *[Local/0] 01:14:43
                          Local via fxp0.5

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

    0.0.0.0/0          *[Static/5] 00:00:18
                        > to 10.0.4.6 via fxp0.2
    10.0.4.0/30        *[Direct/0] 00:00:18
                        > via fxp0.34
    10.0.4.1/32        *[Local/0] 00:00:18
                          Local via fxp0.34
    10.0.4.4/30        *[Direct/0] 00:00:18
                        > via fxp0.2
    10.0.4.5/32        *[Local/0] 00:00:18
                          Local via fxp0.2
    10.0.4.12/30       *[Direct/0] 01:16:56
                        > via fxp0.3
    10.0.4.14/32       *[Local/0] 01:16:56
                          Local via fxp0.3
    10.0.5.4/30        *[Direct/0] 00:00:18
                        > via fxp0.5
    10.0.5.5/32        *[Local/0] 00:00:18
                          Local via fxp0.5

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

    10.0.5.0/24        *[Direct/0] 01:16:56
                        > via fxp0.12
    10.0.5.1/32        *[Local/0] 01:16:56
                          Local via fxp0.12
    ************************************************************Output*************************************************

     

    root@R1# run ping 10.0.4.5 routing-instance User-B
    PING 10.0.4.5 (10.0.4.5): 56 data bytes
    ^C
    --- 10.0.4.5 ping statistics ---
    14 packets transmitted, 0 packets received, 100% packet loss

    [edit]
    root@R1# run ping 10.0.5.5 routing-instance User-B    
    PING 10.0.5.5 (10.0.5.5): 56 data bytes
    ^C
    --- 10.0.5.5 ping statistics ---
    88 packets transmitted, 0 packets received, 100% packet loss

    [edit]

     

     

     



  • 2.  RE: Routing-Instance Communication

     
    Posted 11-02-2012 13:26

    Hi,

     

    It fails as the source address of the PING request is not known to User-A instance and it has to rely on static route. Hence the ICMP recho reply would be send out on fxp0.2 which will not reach the source.

     

    Since you imported the routes from User-A into User-B, instance User-B will have a route to reach 10.0.4.5/10.8.5.5 but User-A will use static route to reach the source for this ICMP echo request as it doesn't have route to the source.

     

    Hence you need to modify your config to import User-B routes to User-A as well to have this working.

     

    User-B {
        instance-type virtual-router;
        interface fxp0.3;

        routing-options {
            interface-routes {
                rib-group inet InetB;
            }
    }

     

    rib-groups {
        Inet {
            import-rib [ User-A.inet.0 User-B.inet.0 ];
        }

        InetB {
            import-rib [ User-B.inet.0 User-A.inet.0 ];
        }
    }

     

    Regards

    Surya



  • 3.  RE: Routing-Instance Communication

    Posted 11-02-2012 13:36

    HI Surya

     

    Thanks for reply ,i need to know routes are exported from right--->left in rib-group ?

     

     

    Thanks



  • 4.  RE: Routing-Instance Communication
    Best Answer

     
    Posted 11-02-2012 13:40

    Hi,

     

    InetB {
            import-rib [ User-B.inet.0 User-A.inet.0 ];
        }

     

    If I take this as reference, then routes from UserB.inet.0 will be exported/copied to UserA.inet.0 (Left to Right). Did it answer your query?

     

    Regards

    Surya



  • 5.  RE: Routing-Instance Communication

    Posted 11-02-2012 18:32

    Hi ,

    It is better not to understand the rib-group mechanism as "copying from left to right".

    Actually, it depends on where you apply the rib-groups.

     

     

    <routing-instances User-B routing-options interface-routes> rib-group InetB


    rib-groups {
        InetB {
            import-rib [ User-B.inet.0 User-A.inet.0 ];
        }
    }

     

    The above, installs all interface routes of routing-instance User-B into tables User-B.inet.0 & User-A.inet.0.

     

    Even, if you configure the rib-group other way around, ( User-A.inet.0 in left ) and apply the  rib-group inetB to <routing-instances User-B routing-options interface-routes> ,the same results will ge achieved.

     

    rib-groups {
        InetB {
            import-rib [ User-A.inet.0 User-B.inet.0 ];
        }
    }

     

    So, copying from left table to right table is not true.

     

    The following explains mor about the operation.

     

    Consider the same example.

     

    rib-groups {
        InetB {
            import-rib [ User-B.inet.0 User-A.inet.0 ];
        }
    }

     

    <routing-instances User-B routing-options interface-routes> rib-group InetB
    As I mentioned,  this installs all interface routes of routing-instance User-B into tables User-B.inet.0 & User-A.inet.0.

     

    If you apply the same rib-group to

    <routing-instances User-A routing-options interface-routes> rib-group InetB

    This will install all interface routes of routing-instance User-A into tables User-B.inet.0 & User-A.inet.0

     

     

    However, the first table in the rib-group is considered as "primary" table and the rest of the table/ tables are considered as "secondary"  tables.

    Primary table is the table where the intended routes will be installed if we don't have a rib-group configured.

    for routes of instance User-B  => Primary table is User-B.inet.0

    for routes of instance User-A  => Primary table is User-A.inet.0

    We need to mention the primary table first ( at the left isde), because some protocols ( eg: ISIS)  will expect the correct order ( Primary should be first) otherwise it will give you a commit error. But in our case interface routes do not bother the order.

     

    In the following example i didn't define the inet.0 as a primary table for rib-group "test", when I apply this rib group to global ISIS routing instance.

    R1# commit check
    [edit  protocols isis]
      'rib-group'
        rib-group test: Primary routing table should be inet.0
    error: configuration check-out failed

     

     

    Also, if you want to import routes selectively to secondary tables , you can configure  "import-policy" with rib-group.

    This import policy will be applied to the secondary tables , but not to the primary table.

     

     

    [edit  routing-options]
    rib-groups {
          test {
              import-rib [ inet.0 VPN-1.inet.0 ];
              import-policy VPN1-import;
          }
      }

     

     

    Conclusion :

    1) when you apply rib-groups to a routing-protocol instance, it installs the routes from that protocol to the tables mentioned in the rib-groups.  ( Not from one table (left) to other tables (right))

    2) It is always best practice to define the primary table first and secondary table / tables then.

     

     

     

     



  • 6.  RE: Routing-Instance Communication

     
    Posted 11-02-2012 22:04

    Hi,

        Firstly you could not be able to commit when you don't have the primary routing-table in the rib-group.

    suryak@PE# show routing-options rib-groups
    INETAB {
        import-rib VR-1.inet.0;
    }

    suryak@PE# commit
    [edit routing-instances VR-2 routing-options interface-routes]
      'rib-group'
        INETAB: primary rib for instance VR-2 was not found in ribgroup configuration.
    error: configuration check-out failed


    And as per Juniper Documentation, the first is Primary Table and the additional ones are secondary.

    http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-routing/import-rib-edit-routing-options.html

    Going by this defination,  rib-group would be as:

    suryak@PE# show routing-options rib-groups
    INETAB {
        import-rib [ VR-2.inet.0 VR-1.inet.0 ];
    }

    So this means even without import-rib, the routes would have been installed in primary table (VR-2.inet.0) in any case as default, but because of rib-group usage, this routes are also exported to secondary table (VR-1.inet.0).
    Since it would be replica of VR-2.inet.0 going to VR-1.inet.0 for this rib-group, I would call it as COPY operation from left to right.

    Regards
    Surya



  • 7.  RE: Routing-Instance Communication

    Posted 11-02-2012 22:11

    Hi Surya,

     

    If you configure the rib-group as

     

    INETAB {
        import-rib [ VR-1.inet.0 VR-2.inet.0 ];
    }

    and apply this to VR-2 instance,

    You will get the same results ( VR-2 routes will be installed in VR-2 and VR-1 tables)

     

    In that case, we can't tell "copying from left to right "...

     

    But, In general if you define the primary first, you can tell like this, but to understand better, I believe we shouldn't encourage saying "copying from left to right" is correct.

     

    Regards,

    Moses N

     

     



  • 8.  RE: Routing-Instance Communication

     
    Posted 11-02-2012 22:34

    Hi Moses,

     

    Right, I am not denying that with swapped rib-group we may get the same result. But as you said, it would not work for protocols like ISIS. And even it is true for Static route as well.

    Except for interface routes, I believe almost all others expect rib-grop to have the first as primary and next as secondary. I am also thinking it might be a bug as while in case of interface routes.

     

    But again Juniper documents it clearly that first table is primary and next one as secondary. So strictly going by this defination, it would be left to right.

     

    Regards

    Surya



  • 9.  RE: Routing-Instance Communication

    Posted 11-02-2012 22:44

    Hi Moses/Surya


    Thanks for your  information ,I was about to ask the same thing but moses made it clear before i ask

     

     

     

    Thanks



  • 10.  RE: Routing-Instance Communication

    Posted 11-03-2012 04:43

    Hi Surya,

    As I said, if you specify the "primary" table first and secondary tables after that, then you can think like copying from "left to right".

     

    But, in actual Juniper operation,  rib-groups with import-rib imports route into multiple tables including the primary table.

     

    This is how Juniper documents always mention,

     

    http://kb.juniper.net/InfoCenter/index?page=content&id=KB16133&actp=RSS

     

    "Conversely, the import-rib command tells the router which tables to place information into. Unlink its counterpart, the import-rib statement can specify multiple route tables."

     

    http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/configuration-statement/rib-groups-edit-routing-options.html

    "Group one or more routing tables to form a routing table group. A routing protocol can import routes into all the routing tables in the group and can export routes from a single routing table."

     

    I've never seen Juniper documents mentioning as copying.

    Also, we should remember, we are sharing the routing information of that particular protocol and address family. Not the entire table.

     

    But, "copying from left to right"  may be an easy way of remembering this feature.

     

    Regards,

    Moses N