Routing

Hi All,

I typically handle routes bewteen  JUNOS virtual routing instances using the instance-import commands as I find it makes logical sense vs the whole rib-group thing.

recently I ran into a setup which uses the import-rib command extensively.  Perhaps someone can clear up some of my confusion.

Take the following basic example:

I have two routing tables.  The main inet.0 and a test.inet.0.  I would like to import the direct/local routes from both tables into each other.  As per all the docs and example online I would do the following to get routes from inet.0 to test.inet.0

interface-routes {
    rib-group inet IMPORT-PHY;
}
static {
    route 0.0.0.0/0 next-hop 70.11.11.11;
}
rib-groups {
    IMPORT-PHY {
        import-rib [ inet.0 test.inet.0 ];
    }
}

These commands were great as I see all the direct and local routes appear in my test.inet.0 table.  Now as far as I can tell I would read the import statement as saying.  Take routes FROM inet.0 and place them INTO test.inet.0

Now in my test.inet.0 table I did a test that should not have work but did.

root# show
test {
    instance-type virtual-router;
    interface lo0.100;
    routing-options {
        interface-routes {
            rib-group inet IMPORT-PHY;
        }
    }
}

 I simply just referenced the same import-rib statement.  Now I expected this to fail since the rule said take routes FROM inet.0 and put them into test.inet.0 but to my amazement the direct/local routes from test.inet.0 showed up in inet.0.

I am confused as to what the import-rib command is really doing.

Thanks for any tips!

Hi!

I feel what you are saying. In theory this shouldn't work, but on the other hand. This is the most used case in terms of leaking routes. That you want to routes bi-directionally between 2 tables.

I just tried it on my set-up and it also worked just like you tested!

It is explainable when you see that the routing-table in which the RIB-group is applied is used as the source, rather than the first that is configured. So in the case of the TEST routing-instance, the test.inet.0 is used as the source for the routes (Which would make sense! As you said it should fail otherwise).

Rick

Don't think of RIB groups as a copy function, but more like a mediator in sharing routing information between tables.  Your RIB group IMPORT-PHY is anchored by the RIB inet.0 (first listed under the import-rib).  This means it can olny be used in the main routing instance, where the primary route table is inet.0.

Think about it this way.  Your RIB group IMPORT-PHY basically says, any route destined for inet.0 share with test.inet.0.  This is the rule-set. 

rib-groups {
    IMPORT-PHY {
        import-rib [ inet.0 test.inet.0 ];
    }
}

Now we need an input.  This input comes from applying the RIB group to a protocol/interface-routes/etc.  You have applied the RIB-group to interfce-routes (in the main-instance).

interface-routes {
    rib-group inet IMPORT-PHY;
}

This takes the interface routes from the main-instance and applies the rules of the RIB group.  You are essentially telling the box to take the interface routes from the main instance that will be installed in the route table inet.0  and share them with the route table test.inet.0.

So why doesn't this work in under the VRF test? The key to the answer is with this part ---> import-rib [ inet.0 test.inet.0 ];

Because the interface lo0.100 is installed in the route table test.inet.0, the order of the import-rib statement is incorrect.  Since the first table listed is determined to be the primary table (where the routes would go normally), you need to create a RIB group that has test.inet.0 listed first.

rib-groups {
    IMPORT-PHY {
        import-rib [ inet.0 test.inet.0 ];
    }
 IMPORT-PHY-TEST {
        import-rib [ test.inet.0 inet.0 ];
    }
}

 Now...

test {
    instance-type virtual-router;
    interface lo0.100;
    routing-options {
        interface-routes {
  rib-group inet IMPORT-PHY-TEST;
        }
    }
}

This will do what you want.

hey jwparks thanks for a GREAT! explanation.  Any chance you can shed light on when/why/and how you would use export-rib?  Assume you are explaining this to a 6 year old 🙂

Thanks!

Great question - to which I don't have an answer.  Mainly because I've never used it.  Here is a thread that somewhat touches on it - but both fall short on a real explaination.

http://forums.juniper.net/t5/Routing/import-rib-VS-export-rib-in-RIB-group-Configuration/td-p/94202

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

I just tried to generate a quick example in my lab, but I couldn't figure out a good example to showcase it's use.

Hi Jwparks, I'm sorry to chime in.  Just a disclaimer that I'm new to Junos and just happen to see this thread because I'm researching on the use of RIB group too.

I thought Magraw's original question was due to the fact that he didn't need to do what you had suggested and achieved (by surprise) the same effect (of importing from test.inet.0 routes into inet.0). 

Could you please educate me too?  Thanks.

Good explanation,  personally there seem to be lack of documentation and examples for this area from Juniper.

Thanks

Hi all,

My case is similar, but I can't ping between routing-instances.

Goals:
Configure "source-address" on "system ntp" stanza (Junos version don't support RI). My loopback resides on global table (inet.0) and I need reach NTP server on RI: OAM (type virtual-router).

Topology:

                                 BGP: 172.31.20.92/30               

R1     <------------------------------------------------------------>     R2  
lo0.0 = 172.31.11.127/32                                                    lo0.0 = 172.31.20.253/32
RI:global (inet.0)                                                                  RI: OAM (OAM.inet.0)

Configuration (R1):
set interfaces lo0 unit 0 family inet address 172.31.11.127/32

set routing-options interface-routes rib-group inet IMPORT-NTP
set routing-options rib-groups IMPORT-NTP import-rib inet.0
set routing-options rib-groups IMPORT-NTP import-rib OAM.inet.0
set routing-options rib-groups IMPORT-NTP import-policy NTP-POLICY

set policy-options policy-statement NTP-POLICY term 1 from rib OAM.inet.0
set policy-options policy-statement NTP-POLICY term 1 from route-filter 172.31.11.127/32 exact
set policy-options policy-statement NTP-POLICY term 1 then accept
set policy-options policy-statement NTP-POLICY term LAST then reject

set routing-instances OAM protocols bgp group OAM type external
set routing-instances OAM protocols bgp group OAM export OAM-bgp_export
set routing-instances OAM protocols bgp group OAM neighbor 172.31.20.94 peer-as 65002
set routing-instances OAM protocols bgp group OAM neighbor 172.31.20.94 local-as 65001

The lo0.0 (directly on inet.0) is been imported to rib OAM.inet.0 and advertised to neighbor BGP configured on RI:OAM

R1> show route table inet.0 172.31.11.127/32 exact

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

172.31.11.127/32   *[Direct/0] 5d 05:32:55
                    > via lo0.0
     
---------------------------------------------

R1> show route table OAM.inet.0 172.31.11.127/32 exact

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

172.31.11.127/32   *[Direct/0] 06:06:12
                    > via lo0.0

--------------------------------------------

R1> show route advertising-protocol bgp 172.31.20.94

OAM.inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 172.31.11.127/32        Self                                    I

But from BGP neighbor I can't reach this IP. (source is a loopback on RI:OAM from neighbor). BGP peer is established by point-to-point interfaces (172.31.20.92/30):

R2> ping 172.31.11.127 routing-instance OAM
PING 172.31.11.127 (172.31.11.127): 56 data bytes
36 bytes from 172.31.20.93: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 0556   0 0000  40  01 fd37 172.31.20.94  172.31.11.127

36 bytes from 172.31.20.93: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 0565   0 0000  40  01 fd28 172.31.20.94  172.31.11.127

----------------------------------------------------------------

R2> ping 172.31.11.127 routing-instance OAM source 172.31.20.253
PING 172.31.11.127 (172.31.11.127): 56 data bytes
36 bytes from 172.31.20.93: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 070f   0 0000  40  01 fadf 172.31.20.253  172.31.11.127

36 bytes from 172.31.20.93: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 071e   0 0000  40  01 fad0 172.31.20.253  172.31.11.127