JunOS as PE with Route Reflector to learn

VPN
Contents
1 Configurations
G
1.1 Specific JunOS Routing tables
H
1.2 Role of inet.3
H
1.3 How to correct this behaviour :
H
1.3.1 First One : Static route
I
1.3.2 Second One : Change rib resolution for bgp.l3vpn.0
I
2 Ressources :
G
2.1 Links:
H
3 Update :
G
3.1 2012 / 09 / 30 :
H

This article will describe how to setup JunOS to use it as a PE with Route Reflector. Main advantage
to use RR to deploy MPLS VPN is to clearly simplify network design with only connection between
each PE to our RR. There is no need to configure full mesh between PE.
Configurations
Specific JunOS Routing tables
JunOS is based on many routing tables to work properly. You probably know inet.0 and inet6.0 wich
describe IPv4 and IPv6 routing informations. but there is also RT for MPLS, and Multicast
inet.0Default Internet Protocol version 4 (IPv4) unicast routing table
G
inet6.0Default Internet Protocol version 6 (IPv6) unicast routing table
G
instance-name.inet.0Unicast routing table for a particular routing instance
G
inet.1Multicast forwarding cache
G
inet.2Unicast routes used for multicast reverse path forwarding (RPF) lookup
G
inet.3MPLS routing table for path information
G
mpls.0MPLS routing table for label-switched path (LSP) next hops
G
You can find more informations on Juniper Website
Role of inet.3
Inet.3 is used to find informations about next-hop of routes learned in MP-BGP for any L3VPN/MPLS
. So if your inet.3 table is empy, there is no chance your routes become active.
tom@fw02.as73.inetsix.net> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State
Pending
bgp.l3vpn.0 5 0 0 0 0
0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn
State|#Active/Received/Accepted/Damped...
75.1.3.1 7300 1398 1532 0 0 11:25:01
Establ
bgp.l3vpn.0: 0/5/5/0
VPN-CLIENT1.inet.0: 0/5/5/0
And your VPN Routes look like :
tom@fw02.as73.inetsix.net> show route table VPN-CLIENT1 hidden extensive
VPN-CLIENT1.inet.0: 7 destinations, 7 routes (2 active, 0 holddown, 5 hidden)
10.101.1.0/24 (1 entry, 0 announced)
BGP Preference: 170/-101
Route Distinguisher: 75:22
Next hop type: Unusable
Address: 0x12f8d70
Next-hop reference count: 10
State: <Secondary Hidden Int Ext>
Peer AS: 7300
Age: 11 Metric: 0
Task: BGP_7300_7300.75.1.3.1+179
AS path: ? (Originator) Cluster list: 75.0.1.1
AS path: Originator ID: 75.2.1.2
Communities: target:65001:101
Import Accepted
VPN Label: 41
Localpref: 100
Router ID: 75.1.3.1
Primary Routing Table bgp.l3vpn.0
Indirect next hops: 1
Protocol next hop: 75.2.1.2
Push 41
Indirect next hop: 0 -
But if you look for protocol Next-Hop (75.2.1.2) you can find routes learn from your igp :
tom@fw02.as73.inetsix.net> show route 75.2.1.2
inet.0: 32 destinations, 32 routes (32 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
75.2.1.2/32 *[OSPF/150] 3d 10:49:06, metric 20, tag 0
> to 10.73.2.1 via fe-0/0/0.732
This is because your inet.3 is empty (or doesnt have any information to this specific destination)

How to correct this behaviour :
There is 2 method to activate you VPN routes learnd with BGP and without information in your
inet.3. You can see this behaviour when you create BGP session with directly connected interfaces.
The best way is to always use your loopback address to create your BGP Sessions (better
redundancy and the most easy way to identify your router).
First One : Static route
Not the best but the most simple : Create a static default route in your inet.3 table with next-hop set
to discard. By the way, route lookup return something and JunOS switch to inet.0 to define next-hop.
tom@fw02.as73.inetsix.net# show routing-options
rib inet.3 {
static {
route 0.0.0.0/0 discard;
}
}
If you want to pass your JNCIE, you cant use this method as it is forbidden to setup static route on
your lab. So you can prefer next configuration.
Second One : Change rib resolution for bgp.l3vpn.0
Another way, and probably the clearest one, is to change rib resolution for any routes inside your
bgp.l3vpn table. It is not so complicated and configuration is just one line :
tom@fw02.as73.inetsix.net# show routing-options
resolution {
rib bgp.l3vpn.0 {
resolution-ribs inet.0;
}
}
What Happens with this setup.
If you look for your BGP summary, you could see learned routes are now activated :
tom@fw02.as73.inetsix.net> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State
Pending
bgp.l3vpn.0 5 5 0 0 0
0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn
State|#Active/Received/Accepted/Damped...
75.1.3.1 7300 1465 1607 0 0 11:58:44
Establ
bgp.l3vpn.0: 5/5/5/0
VPN-CLIENT1.inet.0: 5/5/5/0
And your routes are correctly setup to your VRF :
tom@fw02.as73.inetsix.net> show route terse table VPN-CLIENT1
VPN-CLIENT1.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
A Destination P Prf Metric 1 Metric 2 Next hop AS path
* 10.101.1.0/24 B 170 100 0 >10.73.2.1 ?
* 10.101.2.0/24 B 170 100 0 >10.73.2.1 ?
* 10.101.3.0/24 B 170 100 0 >10.73.2.2 ?
* 10.101.4.0/24 D 0 >fe-0/0/0.104
* 10.101.4.254/32 L 0 Local
* 101.0.0.1/32 B 170 100 0 >10.73.2.1 ?
* 101.0.0.2/32 B 170 100 0 >10.73.2.1 ?

Ressources :
Links:
Discussion about L3VPN/MPLS with Route Reflector
G
JunOS Routing Table in Juniper Documentation and from another website
G
VPN Routing and VRF Informations
G

Update :
2012 / 09 / 30 :
If you deploy LDP on all core interfaces, it is not necessary to use these workarounds, it will be the
goal of another post.