Featured

VRF Table Label

Section 1: VRF Attachment Circuit Label Allocation

Under normal operation as attachment circuits are added to a VRF Junos will allocate each attachment circuit an additional VPN label when advertising associated IP prefixes into the core MP-BGP protocol.

In certain network deployments this default behaviour could create an unwanted depletion of VPN labels, due to label space limitations (on some hardware), or in other cases PE routers could be carrying large amounts of VRF tables or attachment circuits, which could require a significant amount of VPNv4 memory space.

The vrf-table-label command can help solve these issues, as it can be used to optimise the operation of VPN label allocation in MP-BGP.

Section 1.1: Per VRF Label Allocation

To solve these issues when vrf-table-label is introduced a single VPN label is applied to all prefixes exported from a given VRF into MP-BGP.

This method of label allocation can significantly reduce the amount of labels used on PE, regardless of the amount of prefixes or attachment circuits contained within a given VRF.

Section 2: Reference Topology

I am going to demonstrate how Junos handles this within the CLI, and will also show how the control plane responds to label allocation before vrf-table-label is introduced, and after it has been introduced.

The following topology will be used to demonstrate how this feature works. We will use two CEs deployed across remote PEs and will announce a loopback prefix via eBGP into the core PEs from each CE.

vrf-table-label-jpg

Section 2.1: Demonstrating The Default Behaviour

The outputs below shows an IP prefix announced by eBGP from CE1 in to DC1-PE1

Each output shows a different VPN label being allocated from the two attachment circuits that are used as next hops for each prefix.

The first prefix 20.20.20.20/32 is allocated VPN label 299904:

vpn-b.inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
* 20.20.20.20/32 (1 entry, 1 announced)
BGP group core-as1 type Internal
Route Distinguisher: 172.16.0.2:2
VPN Label: 299904
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1] I
Communities: target:1:2

The second prefix 12.12.12.12/32 is allocated VPN label 299888:

vpn-b.inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
* 12.12.12.12/32 (1 entry, 1 announced)
BGP group core-as1 type Internal
Route Distinguisher: 172.16.0.2:2
VPN Label: 299888
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1] I
Communities: target:1:2

Configuration

The example below shows vpn-b with the vrf-table-label command added to the configuration:

routing-instances {
vpn-b {
instance-type vrf;
interface ae0.20;
route-distinguisher 172.16.0.2:2;
vrf-target target:1:2;
vrf-table-label;
}
}

Once the command is applied the two prefixes are checked again to verify the changes in label allocation:

vpn-b.inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
* 20.20.20.20/32 (1 entry, 1 announced)
BGP group core-as1 type Internal
Route Distinguisher: 172.16.0.2:2
VPN Label: 16
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1] I
Communities: target:1:2

The second prefix 12.12.12.12/32 is also allocated the same label:

vpn-b.inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
* 12.12.12.12/32 (1 entry, 1 announced)
BGP group core-as1 type Internal
Route Distinguisher: 172.16.0.2:2
VPN Label: 16
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1] I
Communities: target:1:2

Finally the output below shows the LSI interface which also allows ingress packets to be passed twice through the PFE for additional processing:

lab@r1> show interfaces terse lsi
Interface Admin Link Proto Local Remote
lsi up up
lsi.0 up up inet
iso

Section 2: Additional Lookup Functionality

When adding vrf-table-label into the VRF configuration a software based LSI interface is created that can be used as additional means of passing a packet through the PFE.

The LSI interface can be used to provide an additional lookup process when a VPNv4 packet enters the PE from a remote site. This can be useful in scenarios where ingress firewall filters, CoS or additional policy or packet processing is required – to allow the LSI interface to provide a first lookup before ARP, or packet forwarding is carried out via a secondary pass through the PFE.

Note: On older Juniper routers a software lookup was used when a tunnel-services PIC was not present; the tunnel-service PIC provides a hardware based logical vt-interface for additional secondary look up capabilities. On newer MX routers however, the tunnel services is built into the line card and all of the processing is carried out within the PFE.

Section 2.1: Additional Security Functionality

This command is also used to overcome a security feature within Junos that prevents a multiaccess VRF attachment circuit from being advertised into MP-BGP.

Under normal operation a PE router will only announce a multipoint LAN interface when it receives a dynamic route that uses that interface as a next-hop, or a locally configured static route that uses the multiaccess interface as its next hop.

In cases where there is no static or dynamic routing the vrf-table-label command can be added to the VRF configuration. This overrides this default security feature, and forces the interface to be exported into MP-BGP, without the need for a dependent route.

Implicit and Explicit Null

Section 1: Implicit Null (Penultimate Hop Popping)

By default as MPLS packets pass through an LSP the tail end MPLS router instructs the penultimate router to not push an MPLS Shim Label onto packets destined towards itself i.e the final hop of the LSP.

This behaviour is often referred to as Penultimate Hop Popping (or PHP) and is used to reduce label and control plane overhead by popping the MPLS Shim Label on the penultimate router, so the final PE router need only process the inner VPN label, before sending packets onward to an attached device.

The process works by the tail end router signalling downstream to the penultimate router a label value of 3. This label value is interpreted by the penultimate router as an instruction to not push an MPLS Shim Label onto packets destined for the final hop.

This action is the default behaviour in Junos, and applies to both LDP and RSVP signalled LSPs.

Section 1.1: Explicit Null

The opposite of the above would be to carry the MPLS Shim Label on packets destined for the final router within the LSP, which requires changes to the configuration.

In certain MPLS networks this requirement may be desirable, for example to maintain end to end QoS values that could be carried within the Shim Label, and thus to potentially use those QoS values to apply some sort of policy or action on the tail end PE.

When Explicit Null is configured a label value of 0 is signalled to the penultimate router, which instructs this downstream router to push an MPLS Shim Label onto packets that are destined for the final hop.

Section 2: Demonstrating on the CLI

We will first look at the configuration using LDP as the signalling protocol, using a simple topology of four MPLS enabled PEs signalling LSPs between to each other. Once that is understood we will follow with an example using RSVP.

Figure 1: Network Topology

lab-core

Section 2.1: LDP Configuration

By default Junos uses Implicit Null to signal MPLS LSP’s. The information in figures 2.1-2.2 show the LDP database from the perspective of DC-PE1; the LDP database is a reflection of the LDP control plane, so the reference to “output” refers to the label that the local PE is signalling downstream, and the reference to “input” refers to the label that the local PE has received from its LDP neighbour.

Under normal operation signalling between PE1 in DC1 and DC2 uses a label value of 3 for both input and output. This value instructs each PE to not push an MPLS Shim label onto packets being sent to and from each another.

Figure 2.1: Labels received from DC2-PE1

lab@lab-dc1-pe1> show ldp database 
Input label database, 172.16.1.1:0--172.16.2.1:0
Labels received: 2
  Label     Prefix
 299920      172.16.1.1/32
      3      172.16.2.1/32

Output label database, 172.16.1.1:0--172.16.2.1:0
Labels advertised: 2
  Label     Prefix
      3      172.16.1.1/32
 299952      172.16.2.1/32

Figure 2.1: Labels received from DC1-PE1

lab@lab-dc2-pe1> show ldp database    
Input label database, 172.16.2.1:0--172.16.1.1:0
Labels received: 2
  Label     Prefix
      3      172.16.1.1/32
 299952      172.16.2.1/32

Output label database, 172.16.2.1:0--172.16.1.1:0
Labels advertised: 2
  Label     Prefix
 299920      172.16.1.1/32
      3      172.16.2.1/32

Section 2.2: Changing LDP to Explicit Null

When enabled Explicit Null will pass a label value of 0 downstream from each tail end PE. Let’s now apply the relevant command to the LDP configuration on both DC1-PE1 and DC2-PE1 and see what happens to the LDP control plane; the command is applied directly under the LDP protocol heirarchy, which globally sets all configured LSP’s to Explicit Null.

set protocols ldp explicit-null

Figure 3.1: Labels received from DC1-PE1

As predicted once the above command has been applied we now see DC1-PE1 signalling and receiving a label value of 0.

lab@lab-dc1-pe1> show ldp database 
Input label database, 172.16.1.1:0--172.16.2.1:0
Labels received: 2
  Label     Prefix
 299888      172.16.1.1/32
      0      172.16.2.1/32

Output label database, 172.16.1.1:0--172.16.2.1:0
Labels advertised: 2
  Label     Prefix
      0      172.16.1.1/32
 299920      172.16.2.1/32

Figure 3.1: Labels received from DC2-PE1

As expected the input and output labels are also reflected on DC2-PE1.

lab@lab-dc2-pe1> show ldp database 
Input label database, 172.16.2.1:0--172.16.1.1:0
Labels received: 2
  Label     Prefix
      0      172.16.1.1/32
 299920      172.16.2.1/32

Output label database, 172.16.2.1:0--172.16.1.1:0
Labels advertised: 2
  Label     Prefix
 299888      172.16.1.1/32
      0      172.16.2.1/32

Section 3.1: RSVP Configuration

For RSVP signalled LSP’s we will first observe the Implicit Null default behaviour, signalling a label value of 3.

Figure 4.1: Labels sent and received from DC1-PE1

From the output below we can see that the LSP from DC1-PE1 to DC2-PE1 is signalled with a label value of 3, indicated in the “Labelout” section – this is interpreted by the remote PE as Implicit Null.

In the opposite direction DC2-PE1 has established an LSP towards the local PE, informing the local PE that it will receive packets with Implicit Null applied (using a label value of 3), as indicated in the “Labelin” section.

lab@lab-dc1-pe1> show rsvp session    
Ingress RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
172.16.2.1      172.16.1.1      Up       0  1 FF       -        3 dc1-pe1-to-dc2-pe1
Total 1 displayed, Up 1, Down 0

Egress RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
172.16.1.1      172.16.2.1      Up       0  1 FF       3        - dc2-pe1-to-dc1-pe1
Total 1 displayed, Up 1, Down 0

Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

lab@lab-dc1-pe1> 

Figure 4.1: Labels sent and received from DC2-PE1

From the perspective of DC2-PE1 we effectively see the same behavior in reverse. The local PE is signally an LSP to DC1-PE1 with a label value of 3, meaning all packets entering this LSP with have Implicit Null applied.

The LSP arriving from DC1-PE1 is signalled with a Labelin value of 3, informing the local PE that Implicit Null is applied to packets arriving on the LSP.

lab@lab-dc2-pe1> show rsvp session 
Ingress RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
172.16.1.1      172.16.2.1      Up       0  1 FF       -        3 dc2-pe1-to-dc1-pe1
Total 1 displayed, Up 1, Down 0

Egress RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
172.16.2.1      172.16.1.1      Up       0  1 FF       3        - dc1-pe1-to-dc2-pe1
Total 1 displayed, Up 1, Down 0

Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

lab@lab-dc2-pe1> 

Section 2.2: Changing RSVP to Explicit Null

Let’s now apply the same command to the RSVP configuration on both DC1-PE1 and DC2-PE1 and observe the results; in the case of RSVP the command is applied under the MPLS protocol heirarchy, where all RSVP signalled LSP’s are configured in Junos.

set protocols mpls explicit-null

Figure 3.1: Labels received from DC1-PE1

As predicted once the above command has been applied we now see DC1-PE1 signalling and receiving a label value of 0.

lab@lab-dc1-pe1> show rsvp session    
Ingress RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
172.16.2.1      172.16.1.1      Up       0  1 FF       -        0 dc1-pe1-to-dc2-pe1
Total 1 displayed, Up 1, Down 0

Egress RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
172.16.1.1      172.16.2.1      Up       0  1 FF       0        - dc2-pe1-to-dc1-pe1
Total 1 displayed, Up 1, Down 0

Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Figure 3.1: Labels received from DC2-PE1

As expected the input and output labels are also reflected on DC2-PE1.

lab@lab-dc2-pe1> show rsvp session 
Ingress RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
172.16.1.1      172.16.2.1      Up       0  1 FF       -        0 dc2-pe1-to-dc1-pe1
Total 1 displayed, Up 1, Down 0

Egress RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
172.16.2.1      172.16.1.1      Up       0  1 FF       0        - dc1-pe1-to-dc2-pe1
Total 1 displayed, Up 1, Down 0

Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Manipulating the AS

Within Junos several tools are available to manipulate the AS Path, which can be useful when BGP is deployed as a PE to CE routing protocol across multiple VPN sites. Due to the built in loop prevention mechanisms of BGP a VPN site announcing a BGP route into a VRF may cause an AS loop to be detected if the route is advertised into the same AS number again in another VPN site. In order to overcome this limitation several features are available in Junos.

AS Override

AS Override is used by a BGP speaker (normally a PE router) to replace a remote AS number with the AS number of the local router receiving the route. The route is then advertised further downstream with two AS numbers in the path that are identical. This feature is often used in MPLS networks that are providing connectivity to a single AS that is distributed geographically across multiple VPN sites.

Depending on the requirements AS Override can be configured under the BGP global configuration, group configuration or neighbour configuration. The following configuration is an example of the group configuration overriding the remote AS of 2 with the local AS of 1.

protocols {
bgp {
group ASN1 {
neighbor 1.1.1.2 {
local-address 1.1.1.1;
family inet {
unicast;
}
as-override;
peer-as 2;
}
}
}
}

AS Loops

AS Loops is another approach that can be used to overcome the limitations of AS path loops when multiple VPN sites are announcing BGP routes from the same AS. The feature allows a CE device to accept a BGP route that has been advertised with the CE routers’ local AS in the path.

The following example demonstrates how the AS loops function is configured on the CE router. The command will instruct the CE to receive routes with its local AS in the path x amount of times.

protocols {
bgp {
group ASN2 {
neighbor 1.1.1.1 {
local-address 1.1.1.2;
family inet {
unicast;
}
autonomous-system loops 1;
peer-as 1;
}
}
}
}

Configuration is also required on the PE router, to allow the PE to announce a BGP route to a neighbour that is already in the AS path.

protocols {
bgp {
group ASN1 {
neighbor 1.1.1.2 {
local-address 1.1.1.1;
family inet {
unicast;
}
advertise-peer-as;
peer-as 2;
}
}
}
}

 

Internet Access Options

According to RFC4364 there are several methods for access the public internet using MPLS VPNs. Each approach utilities either “VRF aware” or “non VRF aware” procedures for delivering Internet access to a CE device.

Option 1.1 (Third Party Provider)

In this scenario the provider simply does not participate in any Internet gateway service and the access is provided by a third party network.

Option 1.2 (PE provides Layer 2 VPN towards Internet Gateway)

In this scenario a separate peering router is used to connect the providers network to the Internet. Access to the customer CE is provided using an MPLS layer 2 VPN, using CCC Ethernet encapsulation to present the attachment circuit to the CE. The attachment circuit does not necessarily need to be connected on a separate physical interface as it can be presented as a different logical interface over the customers existing circuit.

Option 2.1 (Separate interfaces for VPN and Internet Gateway)

In this scenario the CE router connects to the PE using two separate logical interfaces. The interface that connects to the Internet is part of the global routing table on both the CE and PE and thus makes it non VRF aware. A second VRF aware interface is also connected between the CE and PE to carry the customers VPN routes as part of their internal routing domain.

The PE carries all customer public routes within its global routing table and advertises them to the Internet. A default route, or full or partial Internet table is advertised from the PE to the CE over the non VRF aware interface. Using a rib-group (or static route with a next-hop table statement) each CE that requires Internet access exports the default route into the internal VPN and also in order to provide inbound routing from the Internet the customer public address space would be exported from the internal VPN into the CEs global routing table.

Option 2.2 (Internet routes within the VRF table on the PE)

In this scenario the CE router again connects to the PE using two separate logical interfaces, one non VRF aware and one VRF aware. All outbound traffic is carried over the VRF aware interface and when it arrives at the PE a default static route is configured to direct the outbound traffic to the global routing table using the next-hop table statement.

Traffic arriving at the PE from the Internet is directed to the CE over the non VRF aware interface. Either a rib-group or static next-hop table configuration routes traffic towards the customer VPN table.

Option 2.3 (Single interface for VPN and Internet access)

In this scenario a single VRF aware interface is used between the CE and the PE. All public and private routes are carried within the VPN and if BGP is used between the CE and PE the public routes can be tagged with community so when they arrive at the PE they can be exported into the global routing table using a rib-group that matches on this community. All other private VPN routes are carried within the customer domain.

In order to carry outbound traffic outside of the customer VRF a default route with a next-hop table statement is configured on the PE. The next-hop table is configured as the global routing table which allows outbound traffic to reach the Internet.

Option 3 (Central hub site with separate interfaces for VPN and Internet gateway)

In this scenario a central CE router is used to connect a non VRF and a VRF interface to the PE router. For outbound traffic a default route is generated by the PE in its global routing table and sent to the central CE over the non VRF interface. The default route is then set a next-hop table from with the CEs VRF table; this default state route is also advertised to all route CEs within the VPN to provide outbound connectivity for the whole VPN domain.

Inbound traffic is routed to the PE within its global routing tables and customer Internet routes are advertised by the central CE towards the PE using the non VRF interface. The central CE then use the next-hop table statement to forward inbound Internet traffic into the VPN tables to provide connectivity for the rest of the VPN domain.

BGP Independent Domain

What Exactly Does This Feature Do?

Imagine a scenario where a service provider has a requirement to peer their PE to a remote device using iBGP, and this remote device could be a customer CE, or a third party router that needs to send traffic across the service provider core to another remote site.

As the customer routes are sent over the provider core, the service providers AS would be added to the AS path of the customer routes, before these routes are announced to the end site.

There are two issues with this setup. Firstly the BGP Split Horizon rule the would prevent the routes from being announced to the remote site, as the customer AS would already exist in the path. The second issue could be that the provider (or customer) may wish for the routes to announced transparently between the two end points, without the provider AS being seen in the path.

How To Implement An Independant Domain

The VRF on the PE router is configured with the CE routers AS number, however this AS is not carried within the AS path attribute when the customer prefixes are carried across the providers core.

The reason for the above is due to the customer AS being removed from the AS path attribute and added into another attribute called ATTRSET; this effectively means that the customer AS is carried independently through the providers core, and does not affect the AS path used within the providers MPLS network.

When the routes arrive at a remote PE that is configured with the BGP independent domain, the original customer AS is taken from the ATTRSET, and replaced back into the AS path.

Configuration Example

The configuration is applied to the customer VRF under the routing-options heirarchy. The “independent-domain” command is appended to the AS number of the VRF, which in this case is 65501.

The command should be applied at all PE routes that are forming part of the VPN, and independent domain.

routing-instances {
vpn-a {
instance-type vrf;
route-distinguisher 172.21.0.2:4;
vrf-import vpn-a-import;
vrf-export vpn-a-export;
routing-options {
autonomous-system 65501 independent-domain;
}
}
}

Wrapping It Up

This feature is a pretty straight forward way of getting around a problem, however in most operational scenario’s it would probably be more wise to use some sort of layer 2 connection and allow the customer to peer directly between the two end points.

If the remote device is a managed CE, then there might be a case to use BGP independent domain, however other methods offer similar solutions such as AS-override, which I’ll be discussing in another article.

 

VRF Table Label

This command is primarily used to overcome a security feature within Junos that prevents a multiaccess/broadcast attachment circuit from being advertised into MP-BGP. Under normal operation a PE router will only announce a multipoint interface when it receives a dynamic route that uses the link as a next-hop, or a locally configured static route that uses the multiaccess interface as its next hop.

In cases where there is no static or dynamic routing the vrf-table-label command can be added to the VRF configuration. This overrides the default security feature and forces the interface to be exported into MP-BGP without the need for a dependent route.

When the command is applied to a VRF it also adds a second behaviour that changes the way VPN labels are allocated in the core network; normally each prefix is given a different VPN label, however when vrf-table-label is applied a single VRF label is added to all exported prefixes, which has the benefit of optimising the amount of labels used in the provider network.

When adding vrf-table-label into the VRF configuration a software based LSI interface is created. This interface can be used to provide an additional lookup process when a VPNv4 packet enters the PE. This can be useful in scenarios where ingress firewall filters, CoS or additional policy is present, to allow the LSI interface to handle the first lookup before a second ARP lookup is carried out through the PFE.

On older Juniper routers the software lookup was used when a tunnel-services PIC was not present; the tunnel-service PIC provides a hardware based logical vt-interface for additional secondary look up capabilities. On newer MX routers tunnel services is built into the line card.

The example below shows a VRF with the command configured and the output showing the LSI interface

routing-instances {
green-vpn-a {
instance-type vrf;
interface ae0.20;
route-distinguisher 172.25.1.1:200;
vrf-target target:45501:200;
vrf-table-label;
}
}
lab123@r1> show interfaces terse lsi
Interface Admin Link Proto Local Remote
lsi up up
lsi.0 up up inet
iso

Understanding and configuring Rib Groups

Summary

RIB groups (or Routing Table Groups) are similar to the Auto Export feature, allowing a PE to share local routes across multiple VRFs (or RIBs).

The end goal of Auto Export and a Rib Group is the same however the latter is more flexible as it allows more specific configuration where by individual routes can be leaked between different VRFs based on configuration options and policy; this is more flexible and powerful than the more basic VRF import/export statements that Auto Export offers.

Rib Groups are also bound to specific routing protocols, static routes or directly connected routes, so by nature the policies for leaking routes are more structured and defined.

How to configure a Rib Group

The first configuration step should be applied at the global routing-options level to define a Rib Group name. Within that heirarchy statements are made to request which RIB (or VRF) routes are taken from and where they are placed. The “import-rib” statement is used for this by taking copies of routes from the first listed rib in the square brackets and placing those routes into the second listed rib in the square brackets.

Furthermore the optional import-policy statement allows the Rib Group to be linked to a policy that can be used to specify certain routes to be leaked; this is where the functionality of a Rib Group becomes more flexible, as Auto Export relies specifically on the policies applied within the VRF import/export statements; these statements are considered to be more fundamental to the structure of the wider VPN topology and therefore should be kept as simplistic as possible.

In the following configuration green-vpn-a.inet.0 will place a route into green-vpn-b.inet.0:

routing-options {
rib-groups {
green-a-to-b {
import-rib [ green-vpn-a.inet.0 green-vpn-b.inet.0 ];
import-policy rib-group-green-vpn-policy;
}
}
router-id 172.25.1.1;
autonomous-system 45501;
}

The import into green-vpn-a.inet.0 is also passed through a policy called rib-group-green-vpn-policy which has been explicitly configured to only leak a direct 1.1.1.1/32 route:

policy-options {
policy-statement rib-group-green-vpn-policy {
term a {
from {
protocol direct;
route-filter 1.1.1.1/32 exact accept;
}
}
term z {
then reject;
}
}
}

The Rib Group is then applied within the routing options hierarchy in the source VRF; which in this case is green-vpn-a. In addition to applying the rib group within the VRF the “interface-routes” statement is also added to instruct the PE to also copy directly connected routes within the source VRF that are associated as next hops to the routes being leaked. This is an important aspect of the configuration because without this statement the routes that are leaked would become hidden, because the protocol next-hop would not be available in the destination RIB.

Because rib groups operate at a protocol level the rib group must also be applied to the respective routing protocols that exist within the source VRF; this allows the routes to be ‘picked up’ from the source protocol and delivered into the rib group. In this configuration the rib group a-to-b is placed at the BGP inet unicast level and thus will match on all routes being received across this BGP neighbourship.

One important aspect of rib groups that differs from auto export is that the BGP split horizon rule is not considered when leaking routes. When configuring rib groups it’s considered best practice to change the vrf export policy on the destination table to stop the announcement of the leaked routes. This protects from any potential routing loops or sub optimal routing. It may not always be required, it depends on the VPN topology and requirements for applying route leaking.

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