CHAPTER ONE ­ MPLS Fundamentals

Suppose you have two unequal cost paths. You want to load both links, but adjusting IGP metric
is all or nothing. This doesn’t work, and de­stabilises the network, moves the problem around:

This trial and error tuning is unscientific. ATM worked as an overlay network and allowed for
some TE functionality in terms of how VCs were switched, however ATM is complex, doesn’t
scale (n2 physical for mesh, n3 link state updates for IGP), has high cell overhead and is not well
integrated. Frame Relay was a similar overlay effort. MPLS came to the fore due to simplicity
and scalability, as well as forwarding speed* (*not relevant today).

#1 benefit: Seperates ROUTING and FORWARDING (ie: control and movement)

32­bit MPLS shim header:  NB: ‘bottom of stack’ bit, the innermost MPLS header has this bit set

LABEL SWITCHED PATHS
­ Uni­directional paths use labels for switching ­­­ locally significant
­ Ingress LSR slaps on MPLS label
­ Transit LSRs switch labels
­ Egress LSR (removes MPLS label and) forwards based on IP lookup
* Typically, penultimate router pops the label, PHP, but no speed adv. in JunOS
0 Explicit Null IPv4 Indicates label must be popped and IP forwarding used
1 Router Alert Pass to RE for further inspection; forwarding label underneath
2 Explicit Null IPv6 As above
3 Implicit Null ← never appears in encapsulation, is a placeholder for this func.

LABEL INFORMATION BASE mpls.0 table
Maps incoming labels to outgoing labels

INTERFACE CONFIGURATION
set interfaces xe­0/0/0 family mpls
and
set protocols mpls interface all
set protocols mpls interface fxp0.0 disable
or
set protocols mpls interface xe­0/0/0.0

CONFIGURE STATIC LSPs

LABEL RANGE 1,000,000 <> 1,048,575

PHP / EGRESS Simply configure a POP operation on the penultimate router
INET.3 ROUTING TABLE Only BGP is aware of it (by default)
By default, only BGP is aware of inet.3 and it resolves its next hops through it, inet.0 is fallback
IGP is unaware of inet.3 and forwards based on IP
How is this useful? Well, if you want to transit traffic from one edge of your network to another,
you can configure an LSP to do so. Traffic only enters at the ingress LSR. In this way you can
engineer the traffic over the desired links.

If route preference in inet.0 and inet.3 are the same, inet.3 is still preferred.
BGP prefixes are installed in inet.0 with a forwarding next­hop in inet.3
** The LSP does not get installed in inet.0, the BGP prefix does (it in turn uses the LSP)

Ingress routers perform lookups in inet.3 and inet.0; if inet.3 chosen, mpls.0 consulted for label
Transit routers perform label switching based on mpls.0 only (MPLS label)  LIB / Label Info.Base
Egress routers perform lookups in inet.3 or inet.0 (destination IP address)

DEFAULT BEHAVIOUR
­ Penultimate hop popping using IMPLICIT NULL
CHAPTER TWO ­ LABEL DISTRIBUTION PROTOCOLS

Label distribution protocols often referred to, erroneously, as signalling protocols
They dynamically establish LSPs by exchanging label information
JunOS supports two, LDP (MPLS specific) and RSVP (adapted for MPLS)

­ Comparison of LDP and RSVP

RSVP is used for
­ traffic engineering  (ie: can create LSPs diverging from IGP best path)
­ explicit path configuration
­ route recording
­ keepalive status for visibility/redundancy
(opaque objects provide functionality to adjunct protocols, eg: MPLS)
LDP
­ always follows IGP best path
­ executes hop­by­hop
­ does not support engineered paths
*** associates a set of dest. prefixes with a FEC (forwarding equivalence class)

RSVP
RSVP signalling is similar to ICMP, IGMP and allows for reservations/QoS
RSVP is a label distribution protocol which discovers paths using existing uni/multicast tables

Reservation: Specific sender and receiver
INGRESS LSR initiates connection with a PATH MESSAGE toward downstream
EGRESS LSR responds with a RESERVATION MESSAGE toward upstream
*** So whilst there is bi­directional communication, only a unidirectional path is setup
*** SOFT STATE:  Hello messages sent every 9 seconds to maintain the logical path
The path can change over the lifetime of the reservation
Messages
PATH Contain a destination address of the egress router
RESV Sent by egress router along reverse path to ingress, contains labels
PATHTEAR Sender ­> downstream ­> receiver; tear the path down, eg: timeout
PATHERR Travel upstream from receiver to sender; on error processing PATH msgs
RESVERR Travel downstream to receiver; on error processing RESV msgs

Soft State
Path State Block Stored in each hop
Reservation State Block Stored in each hop
PATH MESSAGE EXTENSIONS (these are all referred to as objects)
LABEL_REQUEST Request label mapping from downstream router
EXPLICIT_ROUTE_OBJECT Strict/loose list of hops to traverse
RECORD_ROUTE A list of hops visited
SESSION_ATTRIBUTE Characteristics of the session
CoS_FLOWSPEC Identify resources to be allocated
RSVP­HOP The IP of the interface sending the path msg
At next router, hop will be the previous hop IP

Example of LSP setup
­ We require an LSP to engineer traffic away from IGP best path to balance traffic
­ Path message sent including ERO toward egress router
­ Intermediate nodes see LABEL_REQUEST object, add label to the message
­ If at any point a node cannot alloc. a label, PathErr message is sent upstream
­ At the egress node, it notes it is the egress; RESV is sent upstream

RESV MESSAGES
­ Can have a reservation style that is FF, WF, or SE (fixed, wildcard, shared)
­ Like the PATH message, can contain RSVP­HOP and a RECORD_ROUTE
­ Propagate back toward sender, eg: R5 is egress, R4 + R3 + R2, transit, R1 ingress
­ R5 RESV ­> to R4 with implicit null label, R4 allocates a label and overwrites this field
­ R3 recv.s this new label, stores as outbound label for LSP toward R4, overwrites, etc.
­ R2 repeats toward R3

LABEL REQUEST OBJECT
­ L2 header contains MPLS payload, so cannot infer what actual traffic is
­ L3PID is the layer 3 protocol ID to signal which label range to use, eg: IPv4, ATM,
­ IPv4 uses value of 0x0800
­ This will determine which label is assigned.  JunOS by default requests ‘any label’

EXPLICIT ROUTE OBJECT
­ L­bit is loose bit
­ Intended for unicast applications only
­ Can cause loops to occur
­ Can specify IP prefixes, ASNUMs

RECORD ROUTE OBJECT
 ­ Can discover L3 routing loops
­ Can be used to later craft an ERO, and thereby ‘pin down’ the route
PATH MTU DISCOVERY
­ Supported under RSVP signalling, set protocols mpls path­mtu:
set protocols mpls path­mtu rsvp mtu­signaling
set protocols mpls path­mtu allow­fragmentation
­ Operation: Ingress LSR requests MTU9192 in T­SPEC
­ As the path message traverses, the smallest MTU found is kept
­ Egress LSR signals back (RESV message) this lower MTU
­ On fail, fallback MTU is 1500

AUTHENTICATION HMAC­MD5 + sequence numbers
set protocols rsvp interface ge­0/0/0 authentication­key foobar

GRACEFUL RESTART
­ By default, both graceful restart and helper mode enabled for RSVP when GR conf’d
­ Even without configuration, helper mode is enabled by default

Configuration

Add interfaces under protocols rsvp
Add family mpls under interfaces

To configure basic LSP:
@R1#set protocols mpls label­switched­path R1­to­R5 to 192.168.1.5

To configure ERO:
@R1#set protocols mpls path ERO­through­R3 192.168.1.3 loose

And add it to the LSP:
@R1#set protocols mpls label­switched­path R1­to­R5 primary ERO­through­R3

P2MP LSP Overview
Single ingress, multiple egress Similar to IP multicast
ADVANTAGES: Can add and remove branches on the fly
Supports link protection (backup LSP)
Router can be egress for one branch + transit another (same LSP)

USE CASE: Replace PIM in the core
Finally, bring it all together with a static route pointing to the multicast LSP
clear rsvp session Clear named session or all sessions
show rsvp session add switch ingress|egress|transit to filter
clear mpls lsp Can only clear INGRESS LSPs
show mpls lsp Used with ‘extensive’ gives great tshoot info
show rsvp interface Show interfaces’ op status and resv state and coloring/admin grp

LDP
Forwarding Equivalence Class:  IP packets that are forwarded in the same manner
Manages LSP to egress router
Associates the FEC with each LSP it creates
Creates an LSP tree for each FEC, one from every possible ingress to egress (mesh)

Group of prefixes ­­­> FEC ­­­> LSP to egress router
LSP follows the unicast routing path

MESSAGES
Discovery Locate potential LDP peers 224.0.0.2:646/udp
Session Manage TCP sessions Highest IP=> active node
hello interval, default is 5s/15s hold, can be asymmetric
IP used is global (Router ID) or per interface
Advertisement add/del/chg label mappings
Notification Either advisory information or notification, ie: teardown
JUNOS IMPLEMENTATION
Does not support Constraint­Based Routed LDP (CR­LDP)
Liberal label retention policy, each downstream peer will advertise all FECs
LSPs to /32 router IDs will be established by default
TUNNELING
LDP can be tunnelled over RSVP LSPs to allow engineering of LDP LSPs
Enable LDP on lo0.0 interface
set protocols mpls label­switched­path name from SA to DA ldp­tunneling
In this way, LDP sees the tunnel as a single hop
AUTHENTICATION
HMAC­MD5 can be configured. Doing so on a live peering will reset it.
GRACEFUL­RESTART
Supported. Can be disabled entirely, or just helper­disable
VERIFICATION
show ldp session detail show ldp interface show ldp neighbor
show route table inet.3 show route table mpls.0 show ldp database
// LSPs // labels // LDP labels
CHAPTER 3: CONSTRAINED SHORTEST PATH FIRST

Protection Paths ­­­ use the CSPF algorithm
* Fast Reroute
* Link Protection

Why do we need CSPF to implement these protection strategies?
­ RSVP and LDP path setup take time, during which packet loss will occur
­ RSVP without an ERO (which must be manually configured) will follow IGP shortest
  path, meaning no TE gains.
­ LSPs can be established using bandwidth reservations, but they aren’t policed unless:
auto­policing (all) or policing filter example (per LSP)
­ RSVP available bandwidth is 100% of interface speed by default, tunable:
set protocols rsvp interface ge­1/2/3 subscription value  // 0 to 65,000
set protocols rsvp interface ge­1/2/3.200 bandwidth value // bps value

Modified SPF algorithm, incorporating the TED   ­­­   Traffic Engineering Database
IGP topology information
Available bandwidth
Administrative groups / colour
=>
Optimal path and setup order according to user­specified constraints
Max hop count
Bandwidth
Strict or Loose ERO routing
Admin groups/colour
Priority
=> PRUNING process and SPF on remainder, which
== an ERO handed to RSVP for signalling setup
else no route to host error message

NB:  Traffic engineering info. is propagated through IGP if/w/ TE extensions enabled
TE information does not cross IS­IS levels or OSPF areas
IS­IS uses specific TLVs OSPF uses opaque LSA type 10
* bandwidth * colour * router ID
For OSPF routers not supporting TE extensions, these LSAs are silently dropped.
Bandwidth changes propagated based on a +/­ % change thresh., def=10%, configurable

NB: The TED will never allow a CSPF LSP to form over an existing LSP
Constrain a path with any of the following, algorithm selects a path in this order:
1. Bandwidth
2. Prune links which don’t have a required colour
Prune links which contain an excluded colour
3. Calculate SPF consistent with ERO
4. If equal cost paths exist, choose the one whose last hop address equals the LSP dest.
5. Least # of hops

NB:  If PathErr returned, path won’t be retried til hold timer expires (def=20s, configur’le 0­240s)
set protocols mpls rsvp­error­hold­time hold­time  value

Further tie­breakers
Random Choose randomly (this is the default)
Least­fill Least­loaded link, ie: spread LSPs across all links (good for failures)
Most­fill Most­loaded, ie: consolidate: billing imp’c’ns  good, small pipes used 1st

NB: After hop­count,  bandwidth percentage is looked at, not absolute bps

set protocols mpls label­switched­path pathname least­fill|most­fill|random

Admin groups / link colours
0­31 named groups, usually given the names of colours
Like BGP communities, must be unique + identically configured on each router
32­bit field, not numerical, but used as flags: each bit is a colour, on or off
Define:
set protocols mpls admin­groups gold 1
…. bronze 2  // etc.
Assign:
set protocols mpls interface ge­2/3/1 admin­group gold
set protocols mpls interface ge­2/3/1 admin­group bronze // can assign multiple [ x y ]

Variations: include­any include­all exclude

LOGICAL OR LOGICAL AND LOGICAL OR

Changing the group forces immediate recomputation of its routing

Monitoring
show ted database extensive
show mpls interface
CHAPTER FOUR:   TRAFFIC PROTECTION & LSP OPTIMISATION

Without protection, when an LSP path has a failure, recomputation incurs packet loss
Protection methods minimise the down time.

T0 failure:  ResvTear travels toward ingress router

T1 failure: Path + Resv state blocks removed, LSP removed from inet.3/associated BGP routes
become inactive.

T2 failure: Ingress router sends a Path msg downstream to build a new LSP

T3 failure: packets continue to drop…

T4 failure: A new LSP eventually comes up, routing churn settles, packets are forwarded.

­­­­­­­­­­­­­­

Solution:  Primary and Secondary paths, for example:

set protocols mpls label­switched­path green to 192.168.1.254
set protocols mpls label­switched­path green primary one bandwidth 35m // CSPF
set protocols mpls label­switched­path green primary one priority 6 6 // CSPF
set protocols mpls label­switched­path green secondary two standby // build LSP in adv.
set protocols mpls path one 172.10.20.3 strict
set protocols mpls path two 172.23.34.2 strict
set protocols mpls path two 172.23.36.34 strict

Primary path will be used for forwarding, until a failure occurs. Secondary used until primary
becomes available. Multiple secondaries = sequential tries.

There are timers:

retry­timer 30s // interval between bring­up attempts

retry­limit 0 // how long to try…
revert­timer 60s // wait this long, revert back to pri, 0=non­revertive

FORCE SELECTION
select manual use this path if available, traffic will revert to this
select unconditional regardless of up/down or priority settings, USE THIS! (!)
PRIORITIES and PRE­EMPTION

SETUP PRIORITY HOLD PRIORITY
4 4
6 6
0 2

Lower is better, ie: the LSP with 4 4 will be setup first and will remain up ahead of the 6 6.
However, the 0 2 will be setup first and in the case that the other two have taken all resources,
they will be torn down (pre­empted) to allow the higher priority LSP, 0 2, to be established.

Soft­preemption is an option allowing the pre­empted LSP to gracefully switch over/cease.

FAST­REROUTE

* Only ingress LSR knows the TE constraints.
* Even with a backup LSP, the switchover causes traffic loss
* SOLUTION: transit LSRs can automatically detour the LSP as an interim solution
*** Ingress LSR will establish a ‘proper’ TE path, but in the meantime the detour catches ‘spill’

­­­ Must be enabled on the ingress LSR as part of the LSP definition
­­­ Transit LSRs will be allowed 6 additonal hops to re­route, by default
­­­ The precomputed detour paths stored in the PFE can rival SONET APS switching times!

set protocols mpls label­switched­path somepath fast­reroute

PROTECTED INTERFACE / LINK PROTECTION

On a per­link basis, LSPs can be rerouted around failures. The TED database and CSPF
constraints are honoured, and the reroute for, eg: R1 ⇔ R2 may go via another router but will
always include the ‘original’ two routers.

set protocols rsvp interface ge­1/2/3 link­protection

NODE PROTECTION

LSPs, as per link protection, must be tagged for node protection. Uses same mechanisms.
Relies on RSVP hello timers to detect failures. One bypass LSP is established around
downstream node, however you can specify more (max­bypass statement).

PUTTING IT TOGETHER, LSP configuration is required as well:
set protocols mpls label­switched­path foo link­protection|node­link­protection
OPTIMISATION

As the network changes, and LSPs have been up for days, weeks, months at a time, there may
be a new, more optimal path. You can set a periodic check (re­computation):

set protocols mpls label­switched­path foo optimize­timer seconds // 0 … 65535
* JunOS honours the interval with a randomisation factor to prevent sync issues
* Manual version is:  clear mpls lsp optimize

New path tie­breaker priority: Optimize aggressive
Metric must be <=  * use with care, causes churn...
If equal, must have fewer hops  * honours IGP metric ONLY
Must not cause pre­emption
Does not worsen congestion
Reduces congestion by 10% or more

ADAPTATION

set protocols mpls label­switched­path foo adaptive

This configures the LSP to use a SE­style reservation (shared explicit). This means the LSP
always holds on before cutover; it waits for the new LSP to be ready first.
NB:   This configuration knob also ensures that bandwidth reservations on both paths are
counted once (the transit traffic is on one LSP or the other, not both, so don’t double­count).

RESERVATION STYLES

FF Fixed filter Default Bandwidth counted for each LSP

SE Shared explicitadaptive For make­before­break; shared resources

* NOTE: pri and sec LSPs using adaptive will be double­counted if the keyword is
specified under the path itself. For this to count as an SE reservation, apply at LSP level
CHAPTER 5:  MISCELLANEOUS MPLS FEATURES

Default routing table behaviour:
LSP end­point /32 is added to inet.3
Add additional prefixes using install <prefix> under LSP definition
Add keyword active to install this in inet.0 as well // CAUTION, LSP will override IGP

eg: If IGP inet.0 is being used instead of inet.3 / LSP, you might need to install a prefix
If LSP end­point has a route in inet.0 but not inet.3, which can happen.

Traffic engineering bgp­igp
LSP ­> inet.3 ­> usable only by BGP
To put all inet.3 ­> inet.0, and allow IGP to use LSPs, globally, then set:

set protocols mpls traffic­engineering bgp­igp BGP + IGP
Other options: bgp = BGP, mpls­forwarding = forwarding, not routing calc

MPLS­forwarding means all the benefits of inet.3 forwarding, but inet.0 is used for policy
If set, show route x.x.x.x will now show an @ and # routes for routing and forwarding

FORCE forwarding table next­hops

You can apply ex. policy to the forwarding table (set routing­options forwarding­table export foo)
You might do this to force a certain spread across LSPs, for fine control, eg:

from {
route­filter 10.10.10.0/24 exact;
}
then {
install­nexthop lsp LSP­1;
accept;
}

IS­IS CSPF METRICS
CSPF metric follows IGP but IS­IS has option ‘te­metric’ to configure LSP­only metric

LSP METRICS
Can explicitly configure a metric under LSP itself

BANDWIDTH
Under LSP, can set ‘auto­bandwidth’ to set RSVP bandwidth reservation to peak
utilisation level as seen over last 24 hours (default).Re­signalled w/ make­before­break, SE style
TTL OPTIONS
Default is to decrement payload TTL with each hop, for usual reasons of loop prev. + discovery
‘no­decrement­ttl’ hides topology, decrements TTL on egress only. MPLS=255@ingress
This is JunOS proprietary so may not work with others. Can be set per LSP or globally.

OR

Inter­op version is ‘no­propagate­ttl’ which must be configured under protocols mpls, every
LSR.  Affects LDP and RSVP LSPs globally. IP TTL dec’d at egress only.
MPLS=255@ingress.
Side­effect: MPLS cloud shows up as two hops from perspective of every IP packet transiting.
Caution: If you miss this option on an LSR in the path, TTL will increase! (ie: MPLS 255 → IP)

EXPLICIT NULL

You would use this when you need end­to­end CoS. In this way, the transit LSRs and the egress
LSR can use the same CoS config, as the MPLS header arrives at the egress LSR rather than
being PHP popped. Basically, signal 0 upstream rather than 3.
set protocols mpls explicit­null RSVP
set protocols ldp explicit­null LDP

MPLS PING
ping mpls rsvp LSP­to­R4 // MPLS ping requires that the endpoint lo0 has...
ping mpls ldp 192.168.1.4 // 127.0.0.1/32, which JunOS does automatically
CHAPTER 6:  VPN REVIEW

Just background reading, nothing of depth or relevance for note­taking.
Good high­level summary of the chapters to come, worth reading in full to see the scope.

Review Questions

Answers to Review Questions
1. A VPN is a private network that is constructed over a shared, public infrastructure such as
Frame Relay, an ATM network, or the Internet.

2. The primary difference is that the CPE VPN requires the customer equipment to create and
manage tunnels for the private IP traffic. A provider­provisioned VPN solution is a VPN that relies
on the provider’s equipment to create and manage tunnels for the private traffic using MPLS as
the enabling technology.

3. The first and most notable difference is with a Layer 2 VPN solution, the backbone routing is
the responsibility of the customer. With a Layer 3 VPN solution, the backbone routing is handled
by the provider. Another difference is that with a Layer 2 VPN solution, non­IP traffic can be
passed from site to site. With a Layer 3 VPN solution the traffic has to be IP.
CHAPTER 7:  LAYER 3 VPNs

CE At customer premises, can use any access tech or routing protocol
PE Maintain VPN­specific VRF forwarding/routing tables, MPLS + BGP w/ other PEs
P Provider core, forward (LSR) VPN data over established LSPs; VPN agnostic

When multiple VPNs are in use, how do you identify the correct VRF?
type admin assigned number   prefix
route distinguisher eg:      0       20965:111:10.10.10.0/24
     1       1.1.1.1:999:2.2.2.0/24

NB: Once placed in a VRF, the RD is dropped, IPv4 (32bit) remains

Routes are shared via MP­BGP, using NLRI vpn­ipv4 (SAFI 128)

CONTROL FLOW
Routing exchange between CE and PE: independent at all sites (could be OSPF, RIP)
Routing exchange between PE and PE: MP­BGP
LSP establishment between PE routers (RSVP or LDP signalling)

DATA FLOW Forwarding via MPLS LSPs

VPN TOPOLOGIES
Full mesh Partial mesh Hub­and­spoke   …. depends on policy application

ROUTE DISTRIBUTION BETWEEN PEs
Route target Identifies a set of VRFs to which a PE router distributes routes
Site of origin Identifies the specific site from which a PE learns a route

NB: route target, which identifies the VRF in which a given route belongs
ie: When looking at a received route, the route target determines which VRF it goes into
ie: When exporting, the route target is added (based on the source VRF)

If there is no matching target, the route is dropped. If dropped..and later required due to a
newly provisioned matching target, BGP route refresh is used to request the routes.

All l3vpn routes go into bgp.l3vpn.0 as well as their respective VRFs
LABEL ASSOCIATION

When routes are advertised, the advertising PE chooses the inner MPLS label (VRF label).
­­­ JunOS chooses one label per VRF, rather than one label per route
The receiving PE needs a valid LSP in inet.3 toward the advertising router’s RID, else drop route

ADVERTISING ROUTES TO CEs
Once the VRF is populated with routes from other PEs, the local PE can advertise to CE
­­­ Routing policy controls the exchange of information as usual

TRAFFIC
CE traffic hits the PE / ingress LSR, inner (vrf) label applied + outer (transit) label applied
   ^­­­ MP­BGP  RSVP/LDP ­­­^

LSRs swap labels ===> PHP  => Egress PE

^­­­ consults VRF label, => CE
CHAPTER 8:   BASIC LAYER 3 VPN CONFIGURATION

* IGP required, and for CSPF then TE extensions must be enabled
* iBGP and MPLS required (LDP (auto) or RSVP (manual)) on all PE and P routers
* MP­BGP peerings between all PEs
* Participating PEs require a routing­instance of instance­type vrf

RECAP OF ROUTING TABLES

inet.0 main / default instance
inet.3 RSVP and LDP routes; used by BGP only
mpls.0 label information base / MPLS switching table
bgp.l3vpn.0 stores all VPN­IPv4 unicast routes; routes resolved through inet.3
vpnname.inet.0 VRF for VPN, this is the routing table, a forwarding table is also held

BGP CONFIGURATION

family inet­vpn unicast NLRI must be enabled
route­refresh ..critical to L3 VPN functioning, and on by default, no config req’d

VRF CONFIGURATION

Minimum:
route­distinguisher eg: lo0:123, as in 10.10.10.1:555 // manually assigned..
vrf­target eg: target:ASN:123, as in target:65000:555 // BGP community
// can use policy also

*** Automatically assigned route­distinguisher:
set routing­options route­distinguisher­id 192.168.1.1 // Auto generate

*** When a user has multiple AS numbers, also tag with SoO community:
set policy­options community SoO members origin:192.168.1.1:101

*** Other corner­case options are: remove­private // remove private ASes

autonomous­system loops n // permit adv. to CE w/ CE AS
as­override // when CEs are same AS
    rewrite to PE AS
independent­domain  // ingress PE: CE BGP attributes only
domain­id   domain­id:1.1.1.1:0  // ext. community
OSPF betwen CE devices
Provider’s MPLS cloud can appear as a ‘sham link’, ie: P2P tunnel for OSPF packets

Under main config: interface lo0 unit 1 family inet address 192.168.20.3/32;
Under VRF config:
protocols ospf {
sham­link local 192.168.20.3;
area 0.0.0.0 {
sham­link remote 192.168.20.4 metric 1;
interface ge­0/0/0;
interface lo0.1;

MP­BGP and OSPF REDISTRIBUTION
import and export policies are needed under protocols ospf and under VRF itself
OSPF to pick up BGP routes; BGP to pick up OSPF routes (then adv. as LSA type 3 or 5)
Type 3 Summary If LSA 1/2/3 received, domain ID matches/absent
Type 5 Summary If LSA 1/2/3 received, domain ID doesn’t match, or LSA 5

NOTE:  OSPF routes will be preferred over BGP routes due to preference
 Policy only affects active routes… therefore to ensure BGP *and* OSPF exchange:
You can override default OSPF preference and set to 180, for the VRF only
CHAPTER 9:  TROUBLESHOOTING L3VPNs

NB: routing­instance switch required for ping, traceroute, etc.

NB: VRF interface routes are not advertised between PE routers unless the
advertising
PE has >= 1 other route in the VRF that points to its local CE as the next hop !!
Why?
A security feature to prevent route injection, because IP II processor can’t
perform ARP request when Rx’ing labelled packet desting for multi­access VRF
Fix?
vrf­table­label or a tunnel interface can provide this functionality
ie: negates the need for CE­learned route to be present
table label has a lot of limitations
tunnel is just a defined vt­x/y/z under the VRF, w/ mpls + inet on unit 0

STEPS
Verify CE <> PE links *** Due to IP II ASIC limitations, best from local PE
Verify routes in VRF table
Verify routes in bgp.l3vpn.0 (in case remote PE routes had mismatched target)
Verify IGP in the core
Verify MP­BGP between PEs
Verify inet.3 LSP to next­hop of learned routes (beware hidden routes when no LSP)
ping mpls l3vpn vpn­a prefix 172.20.4/24

NB: Traceroutes will show core hops as timeouts as P routers cannot route back to VPN
The fix for this is: set protocols mpls icmp­tunneling
CHAPTER 10:   LAYER 3 VPN SCALING AND INTERNET ACCESS

SCALING
  * Observe PE limits wrt total number of routes, ie: full table not rec. . MX=1.5M route
  * Keep CE­to­PE routing simple
  * Create BGP route reflectors
  * Use BGP­RFRSH ← JunOS does this automatically w/o configuration
  * Use route reflection ← But not with a single point of failure! Normally P routers
  * Use route target filtering ← RRs will send only the requested routes

In combination:  P routers needn’t know about the VPNs and PEs know only what they need
P routers acting as RRs can use the ‘keep all’ switch to ensure all routes are kept in bgp.l3vpn.0
* no need for any VRFs
* best to have seperate RRs for VPN and non­VPN duties
* LSPs to all PEs required for next­hop resolution; LDP=auto, RSVP=config…

Route target filtering
* PEs receiving all routes from RRs to then discard unwanted? No, ask for specifics.
* set protocols bgp family route­target // all that is needed, automatic requests
* These requests end up on the RR in bgp.rtarget.0

LDP Tunnelling
* LDP should be enabled on lo0
* Under the RSVP LSP definition, ‘ldp­tunneling’ must be specified

INTERNET ACCESS
  * A simple default route to a P router with a full table is often sufficient
  * Private addressing obviously requires NAT, which the CE or PE can do
 Options
 * VRF and non­VRF interfaces can be used (two whole interfaces..)
 * Route leaking between VRF and main tables
 * Inside the VPN, a central CE can serve as the internet gateway (overhead..)
CHAPTER 11:   LAYER 3 VPNS ­ ADVANCED TOPICS

Inter­VPN communication on a single PE
* Because import/export is coupled with MP­BGP sessions with OTHER PEs…
* … ‘auto­export’ option under the VRF is required: policy will be parsed w/o BGP sess.
eg:  set routing­instances vpn­a routing­options auto­export
       set routing­instances vpn­b routing­options auto­export
       set routing­options rib­groups a­to­b import rib vpn­a.inet.0
       set routing­options rib­groups a­to­b import rib vpn­b.inet.0
== [ vpn­a.inet.0  vpn­b.inet.0 ] // A copied to B

Hub and spoke
HUB Two VRF instances required
Two VRF interfaces required (usually 1 phy w/ 2 logical)
Two route targets for clean seperation: // required if RR used
spoke sites advertise to spoke instance
spoke sites receive from hub instance