Route-Reflection in JunOS

Let’s talk about one important concept in Route-reflection configuration in Junos.

To start with, there are 2 main IPv4 routing-tables in Junos which are inet.0 and inet3.0. inet.0 is main global routing table and inet3.0 is used in MPLS Layer 3 VPN and this table stores the egress address of an MPLS label-switched path (LSP), the LSP name, and the outgoing interface name. Only BGP accesses the inet.3 routing table. BGP uses both inet.0 and inet.3 to resolve next-hop addresses.

Now let’s configure the Route-reflection in Network. We will using 2 PEs and 1 RR

MPLS Network_1

Config on PE1:

PE1-re0> show configuration protocols bgp
local-address 10.198.123.204;
group L3VPN-RRs {
type internal;
family inet-vpn {
unicast;
}
authentication-algorithm md5;
authentication-key-chain BGP-L3VPN-key-chain;
export L3VPN-Export;
vpn-apply-export;
neighbor 10.198.123.235;   <<<<<<<<<<<<<<———- Router ID of RR
}

Config on PE2:

PE-2-re0> show configuration protocols bgp
local-address 10.198.123.205;
group L3VPN-RRs {
type internal;
family inet-vpn {
unicast;
}
authentication-algorithm md5;
authentication-key-chain BGP-L3VPN-key-chain;
export L3VPN-Export;
vpn-apply-export;
neighbor 10.198.123.235;
}

Config on RR (relevant configs only):

RR.re0> show configuration logical-systems l3vpn-RR
interfaces {
lo0 {
unit 3 {
family inet {
filter {
input Protect-RE;
}
address 10.198.123.235/32;
}
}
}
}
protocols {
bgp {
local-address 10.198.123.235;
mtu-discovery;
log-updown;
family inet-vpn {
unicast;
}
group l3vpn-client-group {
type internal;
authentication-algorithm md5;
authentication-key-chain BGP-L3VPN-key-chain;
cluster 10.198.123.235;
neighbor 10.198.123.204;
neighbor 10.198.123.205;
}
.
.
.
.
routing-options {
graceful-restart {
restart-duration 500;
}
router-id 10.198.123.235;
autonomous-system 65004;
}

BGP is established between PEs and RR

PE-2-re0> show bgp summary | match 10.198.123.235
10.198.123.235       65004      19154     12204       0       5 3d 23:20:04 Establ

PE-1-re0> show bgp summary | match 10.198.123.235
10.198.123.235       65004     19154     12326       0       1 3d 23:20:38 Establ

RR-re0> show bgp summary logical-system l3vpn-RR | match 10.198.123.204
10.198.123.204       65004     12336     19179       0     34 3d 23:25:10 Establ

RR-re0show bgp summary logical-system l3vpn-RR | match 10.198.123.205
10.198.123.205       65004     12212     19179       0     10 3d 23:24:31 Establ

PE-1 is advertising routes towards RR with next-hop address as its own loopback. All well n good.

PE-1-re0> show route advertising-protocol bgp 10.198.123.235
Data-VPN.inet.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden)
Restart Complete
Prefix                          Nexthop             MED     Lclpref   AS path
* 10.12.204.128/32     Self                       100       I
* 10.12.240.0/30         Self                         100       65012 I
* 10.12.240.128/32     Self                        100       65012 I
* 10.204.12.0/30         Self                         100       I

M10i-L3VPN.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
Restart Complete
Prefix                         Nexthop            MED     Lclpref   AS path
* 10.0.0.240/30           Self                         100       65020 I
* 100.100.100.0/30   Self                         100       I

However wait a minute, we are not seeing any routes under BGP table on RR

RR-re0> show route receive-protocol bgp 10.198.123.204 logical-system l3vpn-RR
inet.0: 96 destinations, 96 routes (96 active, 0 holddown, 0 hidden)
Restart Complete
bgp.l3vpn.0: 89 destinations, 178 routes (0 active, 0 holddown, 178 hidden)
Restart Complete

Why is this??.. Now this is fundamentally an issue with how the things were setup.

As I mentioned above inet.3 table stores the egress address of an MPLS label-switched path (LSP) which is used by BGP table to resolve next-hop addresses which in our case is loopback ip of PEs however as RR is not in forwarding path there are no MPLS LSPs configured on it and in-turn no inet.3 table entries which is a problem and that’s why you can see all entries in output above are hidden as bgp table is not able to resolve the next-hop IPs in inet3 table.

So there are number of ways to resolve this and will be discussing two of them here. Simplest one and most widely used method is to configure a static route for loopback IP subnet under inet.3 rib as below.

[edit logical-systems l3vpn-RR routing-options]
RR.re0# load merge terminal relative
[Type ^D at a new line to end input]
rib inet.3 {
static {
route 10.198.123.0/24 {
discard;
metric 65535;
}
}
}
load complete
[edit logical-systems l3vpn-RR routing-options]
RR.re0# commit
re0:
configuration check succeeds
re0:
commit complete

Once you configure this, inet.3 table is populated with static entry and now BGP can use this to resolve the next-hop IP Address for each route and all entries are visible now in routing table.

RR.re0> show route logical-system l3vpn-RR table inet.3
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, – = Last Active, * = Both
10.198.123.0/24   *[Static/5] 00:00:08, metric 65535
Discard
[edit logical-systems l3vpn-RR routing-options]
RR.re0# run show route logical-system l3vpn-RR table bgp.l3vpn.0
bgp.l3vpn.0: 89 destinations, 178 routes (89 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, – = Last Active, * = Both
.
.
.
.
10.198.123.204:12:10.0.0.240/30
*[BGP/170] 4d 04:25:15, localpref 100, from 10.198.123.204
AS path: 65020 I, validation-state: unverified
to Discard
[BGP/170] 05:34:11, localpref 100, from 10.198.123.238
AS path: 65020 I, validation-state: unverified
to Discard
10.198.123.204:12:100.100.100.0/30
*[BGP/170] 4d 04:25:15, localpref 100, from 10.198.123.204
AS path: I, validation-state: unverified
to Discard
[BGP/170] 05:34:11, localpref 100, from 10.198.123.238
AS path: I, validation-state: unverified
to Discard
10.198.123.204:116:10.0.0.24/30
*[BGP/170] 4d 04:25:15, localpref 100, from 10.198.123.204
AS path: I, validation-state: unverified
to Discard
[BGP/170] 05:34:11, localpref 100, from 10.198.123.238
AS path: I, validation-state: unverified
to Discard

Another option is to let inet3.0 use the rib already calculated by inet.0 table by using the below command.

[edit logical-systems l3vpn-RR routing-options]
RR.re0# show
graceful-restart {
restart-duration 500;
}
router-id 10.198.123.235;
autonomous-system 65004;
resolution {
rib inet3.0 {
resolution-ribs inet.0;
}
}

Both of these methods are valid and it depends upon which one you want to use in your network. For 2nd method you can configure prefix-list to list down only the specific network you want to exchange.

So that’s all for today. I hope I was to make it easy for you to understand. Let me know in case you have any comments or queries. J

R
Mohit

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s