Routing

Hi Experts

I have confusion regarding the import-rib and export-rib commands in RIB group configuration. As per my understanding from the documents, the export-rib commands specifies the name of table from which the routes will be exported whereas the import-rib command specifies the name of tables to which routes would be imported. This is as per KB16133

But many people says that in the import-rib command the first table specifies the source from which routes would be exported and the second table in the command specifies the destination to which routes would be imported.

could any body please explain which is true I mean export-rib command specifies the source table and import-rib command specifies the destination tables?

Thanks

Hi,

The first one as per KB16133 is correct.

With import-rib it is COPY operation wherein the contents from FIRST table is copied to the SECOND table.

For instance "import-rib [ inet.0 inet.2 ]" will copy protocol specific routes from inet.0 to inet.2

There is also another usage of import-rib where you specify only one table "import-rib inet.2". Typical usecase for this is to specify use of inet.2 table for RPF check in multicast.

Regards

Surya Prakash

Dear Surya

Thanks for the reply. Actually I am confuse about export-rib. When use export-rib then it specifies the source table and import-rib specifies the destination tables?

Similary when we use only import-rib (not export-rib) then first table specifies the source table and second table specifies the destination table?

Kindly correct me if I am right in understanding?

Hello there,

The source is always a protocol. Direct,static,aggregate,generate routes are also considered as coming from repective protocol (called "direct","static","aggregate" and "generate" 🙂

The import-rib is a group of 2 or more tables where 1st/leftmost listed is "primary" and 2nd & others are "secondary".

Regarding a popular assumption of "first table is source and second is destination" - I think this comes from "routing-options interface-routes" stanza where one usually specifies inet.0 as 1st/primary table and VRF/VR tables as 2nd/3rd/4th etc.And because all interface routes are always in inet.0, this creates assumption that interface-routes are exported from inet.0 to VR/VRF tables. This is a fair assumption since one cannot filter interface-routes on their way to inet.0 (to prevent shooting self in the foot 🙂 but the actual import is "from protocol" and "into primary table+secondary tables".

HTH

Rgds

Alex 

Hi,

Yes.

When you specify export-rib, it is the source table from where the routing information is advertised.

With import-rib having multiple tables, the first one is the source and second/subsequent are the destinations table.

Regards

Surya Prakash

If I answered your query, please accept it as Solution.

In case you liked it, Kudos would be appreciated.

Thanks for both.

Just last question. If I leak some routes from some VRF to inet.0 or viceversa then I need to leak the interface routes as well?

Yes, you'll have to leak the interface routes in order to have the next-hop reachable.

I have one question, is it posible to leak routes from VRF that were received via MP-BGP(from other PEs) to inet.0 and viceversa?

As far as I know, there's no way of doing this, at least I could not find.

Hi,

Since it is possible to leak the route from  CE into inet.0 table, this eventually make other PE receive VRF routes thorugh MP-BGP.

Ex:

routing-options {
    rib-groups {
        VPNA-to-INET0 {
            import-rib [ VPNA.inet.0 inet.0 ];
        }
    }
}
routing-instances {
    VPNA {
        ....................................
        ....................................
        ....................................
        ....................................
        protocols {
            bgp {
                group CE1 {
                    neighbor 172.168.1.2 {
                        family inet {  
                            unicast {
                                rib-group VPNA-to-INET0;
                            }
                        }
                    }
                }
            }
        }
        ....................................
        ....................................
        ....................................
}

Regards

Surya Prakash

Hello Surya, 

Let's assume the following topology: CE1-----PE1----PE2-----CE2

Your configuration will achieve leaking between VPNA.inet.0 and inet.0 for routes received from CE1 at PE1, the question is how to leak routers received by PE1 from CE2 via PE2?

Hi Dumitru,

I meant to have the configs on both PEs. When you have it with one PE, then we cannot leak the routes.

Regards

Surya Prakash

Thank you Surya, 

I was expected that this won't work because routes received from MP-BGP are different than those received via pure i/e-BGP sessions.

Hi Dumitru

Thanks for the reply. But I leaked the routes (coming from the CE to VRF) in to inet.0 and I am able to reach those routes from the inet.0 without leaking the interface routes. It that normal?

Hi, ginues

      Could you please show a example on export-rib configuration; It is really out of my reach. I do configure and try to figure it out  on olive. but I did not see any outcome (the routing table has noting changed). 

what I configured on the logical router.

[edit logical-systems r1]
lab@router# show routing-options
interface-routes {
    rib-group inet my_test;
}

rib-groups {
    my_test {
        export-rib inet.0;
    }
}

Could you explain a bit,  which part is wrong on the configuration.  many thanks. 

I don't agree when you say the first one is copied in the second.

For example, if you want to copy the direct routes from inet.0  into 2 routing-instances T1 and T2 (type fowarding), you can make this configuration :

rib-groups {     TX {         import-rib [ T1.inet.0 T2.inet.0 inet.0 ];     } }

You need to add inet.0 because the routes you have selected are in inet.0 and you want to keep a copy in it.

With this configuration, the routes appear correctly in T1, T2 and inet.0 routing tables.

The routes selected to be copied in the rib-group are configured here (for direct routes)  :

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

I agree with you.

Copying from first table to second  is a wrong concept.

Actually, the first table is the "Primary" table and the rest of the table/tables are secondary.

Primary table is the one to which the routes will be installed if we don't have the rib-groups configured.

As you mentioned,  rib-group configurations for static / direct routes might not need the Primary table configured correctly.

But, for OSPF , ISIS etc, you have to mention the Primary table first, otherwise it will give you an error when you commit.

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.

( I couldn't find this fact in any Juniper documents. This is based on my several testing)

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

Yes the accepted solution is not right

[edit]
lab@Amsterdam# show routing-options
rib-groups {
    test {
        import-rib [ inet.0 instA.inet.0 ];
    }
}

[edit]
lab@Amsterdam# show routing-instances instA       
instance-type virtual-router;
interface em3.0;
interface em4.0;
routing-options {
    interface-routes {
        rib-group inet test;
    }
}

[edit]
lab@Amsterdam# run show route

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

1.1.1.0/30         *[Direct/0] 00:11:03
                    > via em3.0
1.1.1.1/32         *[Local/0] 00:11:03
                      Local via em3.0
2.2.2.0/30         *[Direct/0] 00:11:03
                    > via em4.0
2.2.2.2/32         *[Local/0] 00:11:03

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

1.1.1.0/30         *[Direct/0] 00:11:34
                    > via em3.0
1.1.1.1/32         *[Local/0] 00:11:34
                      Local via em3.0
2.2.2.0/30         *[Direct/0] 00:11:34
                    > via em4.0
2.2.2.2/32         *[Local/0] 00:11:34
                      Local via em4.0

I kept the primary routing table in this case, "instA.inet.0" second. but yet the routes or shared between instances