Beruflich Dokumente
Kultur Dokumente
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 destabilises 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)
32bit MPLS shim header: NB: ‘bottom of stack’ bit, the innermost MPLS header has this bit set
LABEL SWITCHED PATHS
Unidirectional 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 xe0/0/0 family mpls
and
set protocols mpls interface all
set protocols mpls interface fxp0.0 disable
or
set protocols mpls interface xe0/0/0.0
CONFIGURE STATIC LSPs
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 nexthop 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 hopbyhop
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 bidirectional 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
RSVPHOP 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 RSVPHOP 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
Lbit 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 pathmtu:
set protocols mpls pathmtu rsvp mtusignaling
set protocols mpls pathmtu allowfragmentation
Operation: Ingress LSR requests MTU9192 in TSPEC
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 HMACMD5 + sequence numbers
set protocols rsvp interface ge0/0/0 authenticationkey 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 labelswitchedpath R1toR5 to 192.168.1.5
To configure ERO:
@R1#set protocols mpls path EROthroughR3 192.168.1.3 loose
And add it to the LSP:
@R1#set protocols mpls labelswitchedpath R1toR5 primary EROthroughR3
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 ConstraintBased Routed LDP (CRLDP)
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 labelswitchedpath name from SA to DA ldptunneling
In this way, LDP sees the tunnel as a single hop
AUTHENTICATION
HMACMD5 can be configured. Doing so on a live peering will reset it.
GRACEFULRESTART
Supported. Can be disabled entirely, or just helperdisable
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:
autopolicing (all) or policing filter example (per LSP)
RSVP available bandwidth is 100% of interface speed by default, tunable:
set protocols rsvp interface ge1/2/3 subscription value // 0 to 65,000
set protocols rsvp interface ge1/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 userspecified 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 ISIS levels or OSPF areas
ISIS 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 0240s)
set protocols mpls rsvperrorholdtime holdtime value
Further tiebreakers
Random Choose randomly (this is the default)
Leastfill Leastloaded link, ie: spread LSPs across all links (good for failures)
Mostfill Mostloaded, ie: consolidate: billing imp’c’ns good, small pipes used 1st
NB: After hopcount, bandwidth percentage is looked at, not absolute bps
set protocols mpls labelswitchedpath pathname leastfill|mostfill|random
Admin groups / link colours
031 named groups, usually given the names of colours
Like BGP communities, must be unique + identically configured on each router
32bit field, not numerical, but used as flags: each bit is a colour, on or off
Define:
set protocols mpls admingroups gold 1
…. bronze 2 // etc.
Assign:
set protocols mpls interface ge2/3/1 admingroup gold
set protocols mpls interface ge2/3/1 admingroup bronze // can assign multiple [ x y ]
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 labelswitchedpath green to 192.168.1.254
set protocols mpls labelswitchedpath green primary one bandwidth 35m // CSPF
set protocols mpls labelswitchedpath green primary one priority 6 6 // CSPF
set protocols mpls labelswitchedpath 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:
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 PREEMPTION
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 (preempted) to allow the higher priority LSP, 0 2, to be established.
Softpreemption is an option allowing the preempted LSP to gracefully switch over/cease.
FASTREROUTE
* 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 reroute, by default
The precomputed detour paths stored in the PFE can rival SONET APS switching times!
set protocols mpls labelswitchedpath somepath fastreroute
PROTECTED INTERFACE / LINK PROTECTION
On a perlink 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 ge1/2/3 linkprotection
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 (maxbypass statement).
PUTTING IT TOGETHER, LSP configuration is required as well:
set protocols mpls labelswitchedpath foo linkprotection|nodelinkprotection
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 (recomputation):
set protocols mpls labelswitchedpath foo optimizetimer seconds // 0 … 65535
* JunOS honours the interval with a randomisation factor to prevent sync issues
* Manual version is: clear mpls lsp optimize
New path tiebreaker priority: Optimize aggressive
Metric must be <= * use with care, causes churn...
If equal, must have fewer hops * honours IGP metric ONLY
Must not cause preemption
Does not worsen congestion
Reduces congestion by 10% or more
ADAPTATION
set protocols mpls labelswitchedpath foo adaptive
This configures the LSP to use a SEstyle 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 doublecount).
RESERVATION STYLES
* NOTE: pri and sec LSPs using adaptive will be doublecounted 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 endpoint /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 endpoint has a route in inet.0 but not inet.3, which can happen.
Traffic engineering bgpigp
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 trafficengineering bgpigp BGP + IGP
Other options: bgp = BGP, mplsforwarding = forwarding, not routing calc
MPLSforwarding 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 nexthops
You can apply ex. policy to the forwarding table (set routingoptions forwardingtable export foo)
You might do this to force a certain spread across LSPs, for fine control, eg:
from {
routefilter 10.10.10.0/24 exact;
}
then {
installnexthop lsp LSP1;
accept;
}
ISIS CSPF METRICS
CSPF metric follows IGP but ISIS has option ‘temetric’ to configure LSPonly metric
LSP METRICS
Can explicitly configure a metric under LSP itself
BANDWIDTH
Under LSP, can set ‘autobandwidth’ to set RSVP bandwidth reservation to peak
utilisation level as seen over last 24 hours (default).Resignalled w/ makebeforebreak, SE style
TTL OPTIONS
Default is to decrement payload TTL with each hop, for usual reasons of loop prev. + discovery
‘nodecrementttl’ 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
Interop version is ‘nopropagatettl’ 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.
Sideeffect: 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 endtoend 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 explicitnull RSVP
set protocols ldp explicitnull LDP
MPLS PING
ping mpls rsvp LSPtoR4 // 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 notetaking.
Good highlevel 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 providerprovisioned 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, nonIP 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 VPNspecific 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 MPBGP, using NLRI vpnipv4 (SAFI 128)
CONTROL FLOW
Routing exchange between CE and PE: independent at all sites (could be OSPF, RIP)
Routing exchange between PE and PE: MPBGP
LSP establishment between PE routers (RSVP or LDP signalling)
DATA FLOW Forwarding via MPLS LSPs
VPN TOPOLOGIES
Full mesh Partial mesh Hubandspoke …. 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
^ MPBGP RSVP/LDP ^
* 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
* MPBGP peerings between all PEs
* Participating PEs require a routinginstance of instancetype 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 VPNIPv4 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 inetvpn unicast NLRI must be enabled
routerefresh ..critical to L3 VPN functioning, and on by default, no config req’d
VRF CONFIGURATION
Minimum:
routedistinguisher eg: lo0:123, as in 10.10.10.1:555 // manually assigned..
vrftarget eg: target:ASN:123, as in target:65000:555 // BGP community
// can use policy also
*** Automatically assigned routedistinguisher:
set routingoptions routedistinguisherid 192.168.1.1 // Auto generate
*** When a user has multiple AS numbers, also tag with SoO community:
set policyoptions community SoO members origin:192.168.1.1:101
Under main config: interface lo0 unit 1 family inet address 192.168.20.3/32;
Under VRF config:
protocols ospf {
shamlink local 192.168.20.3;
area 0.0.0.0 {
shamlink remote 192.168.20.4 metric 1;
interface ge0/0/0;
interface lo0.1;
MPBGP 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: routinginstance 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 multiaccess VRF
Fix?
vrftablelabel or a tunnel interface can provide this functionality
ie: negates the need for CElearned route to be present
table label has a lot of limitations
tunnel is just a defined vtx/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 MPBGP between PEs
Verify inet.3 LSP to nexthop of learned routes (beware hidden routes when no LSP)
ping mpls l3vpn vpna 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 icmptunneling
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 CEtoPE routing simple
* Create BGP route reflectors
* Use BGPRFRSH ← 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 nonVPN duties
* LSPs to all PEs required for nexthop 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 routetarget // 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, ‘ldptunneling’ 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 nonVRF 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
InterVPN communication on a single PE
* Because import/export is coupled with MPBGP sessions with OTHER PEs…
* … ‘autoexport’ option under the VRF is required: policy will be parsed w/o BGP sess.
eg: set routinginstances vpna routingoptions autoexport
set routinginstances vpnb routingoptions autoexport
set routingoptions ribgroups atob import rib vpna.inet.0
set routingoptions ribgroups atob import rib vpnb.inet.0
== [ vpna.inet.0 vpnb.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