This article provides information about a scenario in which the import policy is used twice when the Border Gateway Protocol (BGP) is configured with an import policy and a RIB group.

When BGP is configured with an import policy and a RIB group, the policy is used twice.

The policy is first used on the received NLRI before it is added to the primary RIB. Then the already processed and installed NLRI is run through the policy again when the NLRI is added to any secondary RIBs of a RIB group.

Here is an example that explains this Junos OS behavior:

• The prefix 11.11.11/24 with community 100:1 is received from BGP peer 10.10.10.2:

lab@M10> show route receive-protocol bgp 10.10.10.2 extensive
    
inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
* 11.11.11.0/24 (1 entry, 1 announced)
     Accepted
     Nexthop: 10.10.10.2
     Localpref: 100
     AS path: I
     Communities: 100:1

• The BGP import policy and the RIB group are configured as follows:

routing-options {
    rib-groups {
        bgp {
            import-rib [ inet.0 test.inet.0 ];
        }
    }
    autonomous-system 100;
}

protocols {
    bgp {
        family inet {
            unicast {
                rib-group bgp;
            }
        }           
        group ibgp {
            type internal;
            local-address 10.10.10.1;
            import test-policy;
            neighbor 10.10.10.2;
        }
    }
}

policy-options {
    policy-statement test-policy {
        term 1 {
            from community 100:1;
            then {
                community add 100:2;
                community delete 100:1;
                accept;
            }
        }
        term default {
            then reject;
        }
    }
    community 100:1 members 100:1;
    community 100:2 members 100:2;
}
           
routing-instances {
    test {
        instance-type forwarding;
    }
}

• The prefix 11.11.11/24 is only added into inet.0.

lab@M10> show route 11.11.11/24 

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

11.11.11.0/24      *[BGP/170] 17:56:41, localpref 100, from 10.10.10.2
                      AS path: I
                    > via so-0/2/0.0

• In this example, the policy is removing community 100:1 in the first evaluation and in the second evaluation, the route no longer matches the term 1 and therefore, the route is not added to test.inet.0.

• To add the prefix 11.11.11/24 into inet.0 and test.inet.0, modify the policy as shown below:

policy-statement test-policy {
    term 1 {
        from community 100:1;
        then {
            community add 100:2;
            community delete 100:1;
            next term;
        }
    }
    term 2 {
        from community 100:2;
        then accept;
    }
    term default {
        then reject;
    }
}
community 100:1 members 100:1;
community 100:2 members 100:2;

lab@M10> show route 11.11.11/24    

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

11.11.11.0/24      *[BGP/170] 19:59:05, localpref 100, from 10.10.10.2
                      AS path: I
                    > via so-0/2/0.0

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

11.11.11.0/24      *[BGP/170] 00:00:03, localpref 100, from 10.10.10.2
                      AS path: I
                    > via so-0/2/0.0

2022/08/10: Added clearer symptoms and added a diagram to simplify explanation