Routing

real meaning of rib grouo

Hi Rob,

 

Below is the flow of this policy:

 

The VPN routes are first matched with "term 1".

Term 1:
In this term the routes from BGP neighbor and having community either public(target:100:2) or private(target:100:1), are accepted and installed in vpnA.inet.0

Else

Term 2:
Routes from BGP neighbor having community public (target:100:2) are accepted and installed in vpnA.inet.0 and inet.0

Else

Term 3:
Reject all


You can also use "test policy" to verify how the policy evaluates for a given prefix.

 

Regards

Surya

Hi,

 

Quoting the previous post

 

Term 1:
In this term the routes from BGP neighbor and having community either public(target:100:2) or private(target:100:1), are accepted and installed in vpnA.inet.0

Else

Term 2:
Routes from BGP neighbor having community public (target:100:2) are accepted and installed in vpnA.inet.0 and inet.0

 

If this is the case, the Term 2 will never be matched because Term1 is super set of term 2

 

But, In reality ,as per the configurations

vpnA.inet.0 table will have all routes with communities private and public

inet.0 will have the routes with community public.

 

So, how does this happen?

We nee to understand the import-policy evaluation mechanism of BGP while having rib-groups configured.

 

" When BGP is configured with an import policy and a RIB group, the policy will be used twice. Firstly, it is used immediately on the received NLRI before it is added to the RIB and Secondly, it is used when adding the NLRI to any secondary RIBs of a RIB group. "

KB15282 describes this

http://kb.juniper.net/InfoCenter/index?page=content&id=KB15282

 

So in our case , the policy will be evaluated first time when route is recieved & installed in vpnA.inet.0.

Term 1 will be matched, and hence routes with "private " and "public" communities will be installed in vpnA.inet.0.

 

Again, when routes are installed in the secondary tables ( here inet.0) , the policy will be evaluated.

Term 1 is not a match since, it is nothing to do with vpnA.inet.0. So  Term 1 will be evaluated and matched.

Therefore, routes with community "public" will be installed in inet.0.

 

 

I created a test case to explain this mechanism.

 

[edit policy-options policy-statement test_ribgrp]
term 1 {
    from protocol bgp;
    to rib vpn-1.inet.0;
    then {
        community add first_comm;
        accept;
    }
}
term 2 {
    from protocol bgp;
    to rib inet.0;
    then {
        community add second_comm;
        accept;
    }
}
term 3 {
    then reject;
}

<policy-options>

community first_comm members 100:1;
community second_comm members 100:2;

 

<routing-options>

rib-groups {
    grp1 {
        import-rib [ vpn-1.inet.0 inet.0 ];
    }
}

 

<routing-instances>

vpn-1 {
...
....

    protocols {
        bgp {
            group CE4 {
                type external;
                import test_ribgrp;
                family inet {
                    unicast {
                        rib-group grp1;
                    }
                }
                ...........
            }
        }
    }
}

 

 

Checking a route recieved from the VPN CE

==========================

 

admin:R1# run show route 75.100.115.0/24 extensive    

inet.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden)
75.100.115.0/24 (1 entry, 1 announced)
TSI:
KRT in-kernel 75.100.115.0/24 -> {192.168.0.34}
Page 0 idx 0 Type 1 val 9128118
        *BGP    Preference: 170/-101
                Next hop type: Router, Next hop index: 1315
                Address: 0x8f997f0
                Next-hop reference count: 40
                Source: 192.168.0.34
                Next hop: 192.168.0.34 via em1.130, selected
                State: <Secondary Active Ext>
                Peer AS: 65100
                Age: 42:41
                Task: BGP_65100.192.168.0.34+179
                Announcement bits (3): 4-KRT 5-BGP RT Background 6-Resolve tree 2
                AS path: 65100 I
                Communities: 100:1 100:2            ==> route passed through twice, first time term1 , second time term 2
                Accepted
                Localpref: 100
                Router ID: 65.100.255.4
                Primary Routing Table vpn-1.inet.0

vpn-1.inet.0: 49 destinations, 51 routes (49 active, 0 holddown, 0 hidden)

75.100.115.0/24 (1 entry, 1 announced)
TSI:
KRT in-kernel 75.100.115.0/24 -> {192.168.0.34}
Page 0 idx 0 Type 1 val 91281dc
    Nexthop: 192.168.0.34
    AS path: [3895077211] 3895077211 I
    Communities: 100:1
Path 75.100.115.0 from 192.168.0.34 Vector len 4.  Val: 0
        *BGP    Preference: 170/-101
                Next hop type: Router, Next hop index: 1315
                Address: 0x8f997f0
                Next-hop reference count: 40
                Source: 192.168.0.34
                Next hop: 192.168.0.34 via em1.130, selected
                State: <Active Ext>
                Peer AS: 65100
                Age: 42:41
                Task: BGP_65100.192.168.0.34+179
                Announcement bits (3): 0-KRT 1-rt-export 2-BGP RT Background
                AS path: 65100 I        
                Communities: 100:1  ==> route passed through once,  first time term1
                Accepted
                Localpref: 100
                Router ID: 65.100.255.4
                Secondary Tables: inet.0

bgp.l3vpn.0: 47 destinations, 47 routes (47 active, 0 holddown, 0 hidden)

192.168.255.1:100:75.100.115.0/24 (1 entry, 1 announced)
TSI:
Page 0 idx 0 Type 1 val 91284d0
        *BGP    Preference: 170/-101
                Next hop type: Router, Next hop index: 1315
                Address: 0x8f997f0
                Next-hop reference count: 40
                Source: 192.168.0.34
                Next hop: 192.168.0.34 via em1.130, selected
                State: <Secondary Active Ext>
                Peer AS: 65100
                Age: 42:41
                Task: BGP_65100.192.168.0.34+179
                Announcement bits (1): 0-BGP RT Background
                AS path: 65100 I
                Communities: 100:1 target:1111:100
                Accepted
                Localpref: 100
                Router ID: 65.100.255.4
                Primary Routing Table vpn-1.inet.0

hi,Surya,

there is a trick stuff here

process of import policy

 

RIB-IN table -------------import polic---------------- RIB-local (used for forwarding).

 

the first term ,it put matched prefix in to RIB- local

 

 

the second term I can't understand ,

it seems it take matched prefix in rib-local(vpn.inet.0) to inet.0.(not install this prefix in vpn.inet.0 again ,there is a to rib inet.0in term 2)  if you tried this policy with first term,this pe will not install any prefix in its vpn.inet.0 or inet.0

 

 

 

 

 

Hi,

 

My theory of the policy evalution was based on the assumption of rib-group as below:

 

show routing-options rib-groups
inet0 {
    import-rib [ VPNA.inet.0 inet.0 ];
}

 

Should had my statement as below:

 

Term 1

In this term the routes from BGP neighbor getting installed in vpnA.inet.0 and having community either public(target:100:2) or private(target:100:1), are accepted and installed in vpnA.inet.0

Else

Term 2:
Routes from BGP neighbor getting installed in inet.0 having community public (target:100:2) are accepted and installed in vpnA.inet.0 and inet.0

 

Else

 

Term 3:

Reject

 

Regards

Surya

Yes,

Anyway, we need to consider double execution of policies when BGP is configured with an import policy and a RIB group.

 

Regarding the Rob's question,

 

In polocy evaluation , if there is a match , then the rest of the policies will not be evaluated.

When first time the policy is evaluated, Term1 is a match so Term2 or Term3  will not be evaluated .

 

Regards,

Moses N

thx

That's expected, the reason being that the term 2 would be evaluated from vpnA.inet.0 table point of view. Since you have term 3 with all reject, no routes would be installed in vpnA.inet.0.
Once you remove term 3, then you should see it working (hopefully 🙂 )

Regards
Surya

Hi,

If you remove Term1 , no routes will be installed in either inet.0 or vpn.inet.0.

Because term2 is not a match for the firts time evaluation of the policy. Therefore Term 3 will be matched and routes will be rejected.

 

As, Surya mentioned, If you remove term3 then the BGP default polcy will accept the routes.

 

Regards,

Moses N