The Wayback Machine - https://web.archive.org/web/20131005062900/http://forums.juniper.

net:80/t5/TheRoutingChurn/Using-rib-groups-or-auto-export-for-route-leaking/…

SOLUTIONS PRODUCTS & SERVICES COMPANY PARTNERS SUPPORT

#TheRoutingChurn

BLOGS DISCUSSION FORUMS PROGRAMS & EVENTS

J-Net Blogs #TheRoutingChurn Using rib-groups or auto-export for route leaking Bl

Article Options

Announceme
Using rib-groups or auto-export for route leaking
by Gonzalo Gómez Herrero (gonzalo) 08-05-2013 03:34 AM - edited New feature:
icons to your

Top Tags

Route leaking across instances is a widely used technique in many networking environments to allow
certain end-to-end communication flows conditioned by policies, to implement deterministic flow redirection MPLS 6PE
rules or to influence route distribution and resolution, among others. mpls-vpn 6
junosphere
The underlying mechanism is based on being able to share routes across different Routing Information
labeled unica
Bases (RIBs).

Junos OS offers multiple options and alternatives to instantiate this concept. Two well-known data
structures to achieve that are rib-groups and auto-export in case of L3VPN routing and forwarding instances
(VRFs).
Community R
With this article, I am reviewing datapoints, similarities and differences between these both Junos OS
features, as a prelude for a particular use case in the next post, and I will be using a multi-VRF scenario as Event calenda
very simple scenario to illustrate all these topics. Technical web
Products
Junos OS rib-groups Training
rib-groups were defined at the very first Junos OS releases as a resource to be able to share routes Terms of Serv
across Routing Information Bases (RIBs). This feature groups more than a single routing table (no matter
if belonging to a VRF or not) to form a routing-table group, where different protocols can import routes
into (and can eventually export routes from). Labels

More details for rib-groups can be found under: http://www.juniper.net/techpubs/en_US/junos13.1/to 6PE (9)
pics/reference/configuration-statement/rib-groups-...
6VPE (4)
There are even more recent address translation features in Junos OS associated when grouping tables BGP (8)
from different families, as described in other posts in this blog, like 6PE and 6VPE over IPv4 BGP-LU - Part
BGP-LU (5)
I and 6PE and 6VPE over IPv4 BGP-LU - Part II, to perform not only route sharing across tables, but also
address translation when doing so. broadband (1

rib-groups are actually a rich and versatile functionality, with multiple options to fine tune, mainly via
import-policy. Among others, following distinctive aspects can be relevant for comparison:

• rib-groups are applied on a per protocol basis, not on a per table basis. Routes from the protocol About the Au
are imported into a group of tables. It is essential to determine which protocols routes are then
learned from, so as to construct a route sharing scheme to import routes into multiple RIBs. Gon
• rib-groups are a generic construct, beyond the VRF itself, to group routing tables. These RIBs can (gonzal
Juniper E
belong to the default routing instance, VRFs, virtual-routers etc. It is then itself independent of Route
Targets (RTs), which is an [RFC4364] VRF-only related concept
I am currently
• rib-groups create secondary route copies in RIBs that are exportable for protocols in the
EMEA Profes
corresponding instances from the routing-table group and also exportable for VRF routes when and have bee
adding the Route Distinguisher (RD) to advertise them via MP-BGP. This mechanism creates sibling (inter)network
 paths locally in other local tables and all these routes are then redistributed with MP-BGP. years. I love t
offers us the t
to be able to l
Considering an arbitrary example based on leaking across multiple IPv4 RIBs from different instances
every day: fro
and diverse PE-CE protocols with their policies, rib-groups can be depicted as in the following from custome
diagram, to interact at protocol level to import routes into arbitrary groups of routing tables: other colleagu
mistakes and
is the ongoing
ongoing learn
joining Junipe
worked in var
for system int
providers, so
'other side'. A
father of 2 an
Madrid. I like
and celtic mu
an amateur p
MTBiker, whe
spare time.
Juan Ant
Ven (anton)
Juniper Employe

Love to break
can remembe
hands-on exp
during my MS
ications and E
(MSEE); mov
space industr
critical system
ground segm
Became profe
consulting en
carriers in the
providing exp
living the Jun
ideas to pract
customer que
challenges. E
playing the gu

Latest Article

Inter-AS Optio
IPv6 L3VPNs
About route le
Using rib-grou
route leaking

Latest Comm

efuentes on:
auto-export fo
Gonzalo
(gonzalo) on
Note that some protocol export policies are actually looking to match into leaked routes, such as the IPv4 and IPv6
OSPFv2 export policies looking to match certain BGP routes in all instances but A. Also, bear in mind
ryantang on:
that there are as many routes advertised via MP-BGP as indirectly enforced by rib-groups when triggered blac
importing them in local VRFs.
Gonzalo
For instance, for this specific case using rib-groups, these would be the actual indicators when (gonzalo) on
applying them to an eBGP session as PE-CE protocol: IPv4 BGP-LU

[edit routing-instances]
Gonzalo
A { (gonzalo) on
instance-type vrf; in IPv6-only V
[...]
bgp { Gonzalo
export [ ... redist-ospf-direct-local ]; (gonzalo) on
group ebgp { Size to avoid
type external;
family inet {
unicast {
rib-group A-to-all; Archives
 } 09-29-2013 -
}
peer-as 65001; 09-01-2013 -
neighbor 10.100.0.1; 08-04-2013 -
}
} View Comple
}
}
B {
[...]
}
C {
[...]
}
[...]
Z {
[...]
}

and this is reflected in the following flags for local routes:

user@router> show route 0.0.0.0/0 exact extensive

A.inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)

0.0.0.0/0 (1 entry, 1 announced)
TSI:
KRT in-kernel 0.0.0.0/0 -> {10.100.0.1}
Page 0 idx 1 Type 1 val 92928b0
Flags: Nexthop Change
Nexthop: Self
Localpref: 100
AS path: 65002 65001 I
Communities: target:65001:1
Path 0.0.0.0 from 10.100.0.1 Vector len 4. Val: 1
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 886
Address: 0x9264dd8
Next-hop reference count: 13
Source: 10.100.0.1
Next hop: 10.100.0.1 via ge-11/3/0.100, selected
State: <Active Ext>
Local AS: 65002 Peer AS: 65001
Age: 1:16:03
Task: BGP_65001_65002.10.100.0.1+57911
Announcement bits (2): 0-KRT 1-BGP_RT_Background
AS path: 65001 I
Accepted
Localpref: 100
Router ID: 10.100.0.1
Secondary Tables: B.inet.0 C.inet.0 D.inet.0 [...] Z.inet.0

B.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)

0.0.0.0/0 (1 entry, 1 announced)

TSI:
OSPF area : 0.0.0.0, LSA ID : 0.0.0.0, LSA type : Extern
KRT in-kernel 0.0.0.0/0 -> {10.100.0.1}
Page 0 idx 0 Type 1 val 9292ae0
Flags: Nexthop Change
Nexthop: Self
Localpref: 100
AS path: 65002 65001 I
Communities: target:65001:2
Path 0.0.0.0 from 10.100.0.1 Vector len 4. Val: 0
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 886
Address: 0x9264dd8
Next-hop reference count: 13
Source: 10.100.0.1
Next hop: 10.100.0.1 via ge-11/3/0.100, selected
State: <Secondary Active Ext>
Local AS: 65002 Peer AS: 65001
Age: 1:16:03
Task: BGP_65001_65002.10.100.0.1+57911
Announcement bits (3): 0-B-OSPF 1-KRT 2-BGP_RT_Background
AS path: 65001 I
Accepted
Localpref: 100
Router ID: 10.100.0.1
Primary Routing Table A.inet.0
[...]

Note that the above highlighted BGP_RT_Background bit refers to exporting such routes out of each VRF table
towards MP-BGP (adding RD):

user@router> show route advertising-protocol bgp 10.0.0.2 0.0.0.0/0 exact

A.inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)

Prefix Nexthop MED Lclpref AS path
0.0.0.0/0 Self 100 65002 65001 I

B.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)

 Prefix Nexthop MED Lclpref AS path
0.0.0.0/0 Self 100 65002 65001 I

C.inet.0: 4 destinations, 6 routes (4 active, 0 holddown, 2 hidden)

Prefix Nexthop MED Lclpref AS path
0.0.0.0/0 Self 100 65002 65001 I

D.inet.0: 4 destinations, 6 routes (4 active, 0 holddown, 2 hidden)

Prefix Nexthop MED Lclpref AS path
0.0.0.0/0 Self 100 65002 65001 I

[…]
Z.inet.0: 12 destinations, 18 routes (12 active, 0 holddown, 6 hidden)
Prefix Nexthop MED Lclpref AS path
0.0.0.0/0 Self 100 65002 65001 I

Junos OS auto-export (or instance-import/export)

Another policy-based inter-instance export was then later created in Junos OS with the goal of maintaining
the same basic existing functionality while offering light-weighted configuration for inter-instance route
export.

This newer policy-based inter-instance export is based on constructing a VRF target tree when examining
vrf-import and vrf-export policies with given RT communities and, if this feature is enabled and a
certain instance refers to a given RT in its vrf-import policy, this is automatically added to the import list
of the RT itself and the route is imported. The symmetrical concept applies for vrf-export policies.

This provides a basic route sharing architecture for VRFs by means of having a module that tracks route
changes in routing tables that are exporters of a particular RT. When a route change occurs, the instance's
vrf-export policy will be applied to the route, not only with regards to its redistribution via MP-BGP, but
also for the sake of being imported to all local tables with matching RT in their vrf-import policy.

In this sense, only the primary route is then redistributed via MP-BGP, as opposed to rib-groups, as it is
understood that other local VRFs only need to import the RT-matching route.

auto-export is the external representation of this concept, which needs to be bound to matching RTs
in vrf-import and vrf-export policies. More details for this feature can be found under:
http://www.juniper.net/techpubs/en_US/junos13.1/topics/concept/auto-export-overview.html

auto-export is then a very intuitive and easy-to-configure feature, because multi-RT matching policies
are usually already in place for remote leaking purposes (that is, building extranets or hub-and-spoke
L3VPN setups). However, there are some aspects worth highlighting:

• auto-export is applied on a per table and not per protocol basis. Just matching RTs in both
directions is enough, no matter which protocols routes are learned from.
• auto-export is inherently tied to Route Targets (RTs). Junos OS offers similar but more generic
instance-import and instance-export data structures, applicable on a per instance basis
(thus, it is used with other instance types than VRFs as well), but they require in that case to explicitly
set instance names, rather than more generic RTs. The inter-instance route sharing graph needs to
be then explicitly derived from the instance-import and instance-export configuration, rather
than inherently constructed with RTs when evaluating vrf-import and vrf-export policies.
• auto-export creates secondary route copies in RIBs that are exportable for protocols in the
corresponding instances from the routing-table group. However, these secondary local copies are not
advertised via MP-BGP. There are no sibling paths but the primary table exported via MP-BGP.

Considering then the same route leaking example across multiple IPv4 RIBs from different instances and
diverse PE-CE protocols with their policies, auto-export would apply at the VRF table level:

auto_export_route_leaking.jpg

Using the very same example migrated to auto-export:

[edit routing-instances]
A {
instance-type vrf;
[...]
routing-options {
auto-export;
}
bgp {
export [ ... redist-ospf-direct-local ];
group ebgp {
type external;
family inet {
unicast;
}
peer-as 65001;
neighbor 10.100.0.1;
}
}
}
}
B {
[...]
routing-options {
auto-export;
}
}
C {
[...]
routing-options {
auto-export;
}
}
[...]
Z {
[...]
routing-options {
auto-export;
}
}

and this is reflected in the same flags for local routes, but an additional rt-export bit:

user@router> show route 0.0.0.0/0 exact extensive

A.inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)

0.0.0.0/0 (1 entry, 1 announced)
TSI:
KRT in-kernel 0.0.0.0/0 -> {10.100.0.1}
Page 0 idx 1 Type 1 val 92928b0
Flags: Nexthop Change
Nexthop: Self
Localpref: 100
AS path: 65002 65001 I
Communities: target:65001:1
Path 0.0.0.0 from 10.100.0.1 Vector len 4. Val: 1
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 886
Address: 0x9264dd8
Next-hop reference count: 13
Source: 10.100.0.1
Next hop: 10.100.0.1 via ge-11/3/0.100, selected
State: <Active Ext>
Local AS: 65002 Peer AS: 65001
Age: 1:31:26
Task: BGP_65001_65002.10.100.0.1+57911
Announcement bits (2): 0-KRT 1-BGP_RT_Background 2-rt-export
AS path: 65001 I
Accepted
Localpref: 100
Router ID: 10.100.0.1

B.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)

0.0.0.0/0 (1 entry, 1 announced)

TSI:
OSPF area : 0.0.0.0, LSA ID : 0.0.0.0, LSA type : Extern
KRT in-kernel 0.0.0.0/0 -> {10.100.0.1}
Page 0 idx 0 Type 1 val 9292ae0
Flags: Nexthop Change
Nexthop: Self
Localpref: 100
AS path: 65002 65001 I
Communities: target:65001:2
Path 0.0.0.0 from 10.100.0.1 Vector len 4. Val: 0
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 886
Address: 0x9264dd8
Next-hop reference count: 13
Source: 10.100.0.1
Next hop: 10.100.0.1 via ge-11/3/0.100, selected
State: <Secondary Active Ext>
Local AS: 65002 Peer AS: 65001
Age: 1:16:03
Task: BGP_65001_65002.10.100.0.1+57911
Announcement bits (3): 0-B-OSPF 1-KRT
AS path: 65001 I
Accepted
Localpref: 100
Router ID: 10.100.0.1
Primary Routing Table A.inet.0
[...]

but note that the BGP_RT_Background bit only appears in the primary route, and thus affects exporting such only
routes out of the primary VRF table towards MP-BGP (adding RD):

user@router> show route advertising-protocol bgp 10.0.0.2 0.0.0.0/0 exact

A.inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)

Prefix Nexthop MED Lclpref AS path
0.0.0.0/0 Self 100 65002 65001 I
 Conclusions
As you have seen, both rib-groups and auto-export features share the same route sharing
fundamentals and offer some differently enriched alternatives for a multi-VRF environment. Generally
speaking, I personally find that using one or another is a tradeoff between simplicity provided by auto-
export and versatility implemented with rib-groups. Another relevant factor is their different behavior
with regards to route redistribution towards MP-BGP.

I would recommend to weigh these consequences of using one or the other feature for advanced
designs. In fact, this decision became a cornerstone in a use case that I had to evaluate for a project and
I am going to expose in the next post!

In the meantime, if you have any questions about them, please be my guest via comment posting or
tweeting back at @go_nzo

Everyone's Tags: leaking mpls-vpn routing View All (3)

Labels: leaking mpls-vpn routing

3 Comments (3 New) Permalink View Article Reactions 0

« Back to Blog « Newer Article Older Article »

Comments

by StuckInActive on 08-06-2013 12:19 AM Options

Great post! Both topics can be somewhat arcane to new Jubies. I also strenuously recommend the first chapter of
Network Mergers and Migrations for more great information on these 2 topics.

Permalink 0

by Gonzalo Gómez Herrero (gonzalo) on 08-06-2013 03:59 AM Options

Thanks for your feedback and appreciation, StuckInActive, and many thanks also for the book promotion!

Permalink 0

by efuentes on 09-23-2013 09:03 AM Options

Hi Gonzalo,

Here we have something different of your output.

We have auto-export in all vrfs of the same PE and it's working for 100.100.254.0/24 prefix (vrfa--->vrfb)

In the "vrfb" we have the BGP_RT_Background even though it is from a secondary table:

VRFA.inet.0: 322 destinations, 2457 routes (322 active, 0 holddown, 0 hidden)

100.100.254.0/24 (6 entries, 1 announced)
TSI:
KRT in-kernel 100.100.254.0/24 -> {100.100.226.239, 100.100.226.237}
Page 0 idx 0 Type 1 val f927e90
Flags: Nexthop Change
Nexthop: Self <<<<<<<<<<<<
MED: 0
Localpref: 100
AS path: [65000] 65112 ?
Communities: target:65000:117
<snip>
Page 0 idx 1 Type 1 val f927de8
Nexthop: 100.100.226.237
AS path: [65000] 65000 ?
Communities:
Path 100.100.254.0 from 100.100.226.237 Vector len 4. Val: 0 1
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 1058217
Address: 0x150b5b48
Next-hop reference count: 132
Source: 100.100.226.237
Next hop: 100.100.226.239 via ae20.1992, selected
State: <Active Ext>
Peer AS: 65112
Age: 3d 6:32:04 Metric: 0
Task: BGP_65112.100.100.226.237+179
Announcement bits (4): 0-KRT 1-BGP_RT_Background 2-RT 3-rt-export <<<<<<<<<
AS path: 65112 ?
AS path: Recorded
Accepted Multipath
Localpref: 100
Router ID: 100.100.253.2

VRF B:
xxxxx.inet.0: 383 destinations, 2836 routes (383 active, 0 holddown, 0 hidden)
100.100.254.0/24 (5 entries, 1 announced)
TSI:
KRT in-kernel 100.100.254.0/24 -> {100.100.226.239, 100.100.226.237}
Page 0 idx 1 Type 1 val f925260
Nexthop: Self
AS path: [65000] 65000 ?
Communities:
Path 100.100.254.0 from 100.100.226.237 Vector len 4. Val: 1
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 1058217
Address: 0x150b5b48
Next-hop reference count: 132
Source: 100.100.226.237
Next hop: 100.100.226.239 via ae20.1992, selected
State: <Secondary Active Ext>
Peer AS: 65112
Age: 3d 6:32:04 Metric: 0
Task: BGP_65112.100.100.226.237+179
Announcement bits (3): 0-KRT 1-BGP_RT_Background 2-RT >>>>>>>>>>>????????(rt-export)
AS path: 65112 ?
AS path: Recorded
Communities: target:65000:117
<snip>
Primary Routing Table VRFA.inet.0

Our problem is different.

From other prefix the same config is not working from vrfb--->vrfa.
What I saw different in the outputs is regarding about rt-export (in the vrf which is the source) even though in the
config auto-export is there. I have opened a JTAC case about it.

VRFB.inet.0: 383 destinations, 2836 routes (383 active, 0 holddown, 0 hidden)

100.100.140.0/23 (6 entries, 1 announced)
TSI:
KRT in-kernel 100.100.140.0/23 -> {100.100.137.21}
Page 0 idx 0 Type 1 val f97e00c
Flags: Nexthop Change
Nexthop: Self <<<<<<<<<<<<<<<<<<<<<
MED: 0
Localpref: 100
AS path: [65000] 65112 ?
Communities: target:65000:117
Page 0 idx 1 Type 1 val f97df10
Nexthop: 100.100.137.21
AS path: [65000] 65000 ?
 Communities:
Path 100.100.140.0 from 100.100.137.21 Vector len 4. Val: 0 1
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 1124
Address: 0xe4d2ba8
Next-hop reference count: 21
Source: 100.100.137.21
Next hop: 100.100.137.21 via ae16.1646, selected
State: <Active Ext>
Peer AS: 65112
Age: 3d 5:37:10 Metric: 0
Task: BGP_65112.100.100.137.21+10521
Announcement bits (3): 0-KRT 1-BGP_RT_Background 2-RT <<<<<<<<<<<<<<<<rt-export???????????

As soon as we discover the issue , I will let you know.

Regards,
magda

Permalink 0

« Back to Blog « Newer Article Older Article »

You must be a registered user to add a comment here. If you've already registered, please log in. If you haven't registered yet,
please register and log in.
Post a Comment

About Juniper Resources Community Support Follow Us

Investor Relations How to Buy Forums Technical Documentation

Press Releases Partner Locator Blogs Knowledge Base (KB)
Newsletters Image Library Junos Central Software Downloads

Juniper Offices Visio Templates Social Media Product Licensing

Green Networking Security Center Developers Contact Support

Site Map / RSS Feeds / Careers / Accessibility / Feedback / Privacy & Policy / Legal Notices Copyright© 1999-2013 Juniper Netw