Configuring Juniper Networks Routers Student Guide, Volume 2

Product Family
Second Line of Product Family

Optional Third Line of Product Family
Optional Fourth Line of Product Family
Configuring Juniper Networks Routers

Student Guide, Volume 2
Release 6.a
Juniper Networks, Inc.

1194 North Mathilda Avenue
Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Part Number: xxx-xxxxxx-xx, Revision 1
Check with your manager for replacement boilerplate for each release.
Software documentation boilerplate located: \\neptune\techpubs\software\boilerplate-sw
Hardware documentation boilerplate located: \\neptune\techpubs\hardware\boilerplate-hw
Replace with the trademark information. The latest trademark information can be found on \\Neptune.
Table of Contents
List of Tables
15
List of Figures
17
Preface
21
Course Overview ........................................................................................................22

Objectives ...................................................................................................................22
Intended Audience ......................................................................................................23
Course Level...............................................................................................................23
Prerequisites................................................................................................................23
Course Agenda ...........................................................................................................23
Day 1 ...................................................................................................................23
Day 2 ...................................................................................................................24
Document Conventions ..............................................................................................26
Additional Information ...............................................................................................27
Education Services Offerings ..............................................................................27
About This Publication........................................................................................27
Technical Publications.........................................................................................27
Juniper Networks Support ...................................................................................27
Chapter 1
Module 1: Traffic Engineering Overview
29
Module Objectives......................................................................................................30
This Module Discusses........................................................................................30
Traffic Engineering Overview....................................................................................31
MPLS: The Concept ...................................................................................................32
Mechanism for Traffic Engineering ....................................................................32
Packet Analysis ...................................................................................................32
Handles Packets at Layer 2 through the Tunnel..................................................32
RFC Support........................................................................................................32
Early Internet ..............................................................................................................34
In the Early Days .................................................................................................34
IGP Metric-Based Forwarding ...................................................................................35
Forwarding Based on the IGP .............................................................................35
Drawbacks of IGP Metric Forwarding .......................................................................36
Some Drawbacks of IGP Forwarding..................................................................36
Additional Drawbacks of IGP Metrics .......................................................................37
Additional Drawbacks .........................................................................................37
Growth Requires Changes ..........................................................................................38
Growth of the Internet .........................................................................................38
Overlay Networks Are Born.......................................................................................39
Behavior of ATM Switches.................................................................................39
Overlay Networks................................................................................................39
ATM PVCs..........................................................................................................39
Benefits................................................................................................................40
:
Configuring Juniper Networks Routers - Stujdent Guide V2
Overlay Networks.......................................................................................................41
Overlay Network Blueprint .................................................................................41
Overlay Network Drawbacks .....................................................................................42
Scalability Issues .................................................................................................42
ATM PVCs Not Well Integrated.........................................................................42
More Overlay Network Drawbacks............................................................................43
ATM Cell Overhead ............................................................................................43
ATM SAR Speed.................................................................................................43
Routers Evolve ...........................................................................................................45
Routers Today .....................................................................................................45
Solution ...............................................................................................................45
Why Engineer Traffic? ...............................................................................................46
Purpose of Traffic Engineering ...........................................................................46
Review Questions .......................................................................................................47
This Module Discussed: ......................................................................................47
Lab 1: MPLS Setup Lab ............................................................................................48
Chapter 2
Module 2: Multiprotocol Label Switching Fundamentals
49
This Module Discusses:.......................................................................................50
MPLS Fundamentals ..................................................................................................51
Benefits of MPLS .......................................................................................................52
Virtual Circuits for IP..........................................................................................52
Faster Routers? ....................................................................................................52
Real Value of MPLS Today ................................................................................52
IGP-Based Traffic Engineering ..................................................................................53
IGP Routing and Traffic Engineering .................................................................53
Physical Next Hop and IP Prefixes .....................................................................53
MPLS-Based Traffic Engineering ..............................................................................54
Unidirectional Paths for Traffic Engineering ......................................................54
MPLS Traffic Engineering Paths ...............................................................................55
Label-Switched Paths and IP Addresses .............................................................55
MPLS Terminology ....................................................................................................56
MPLS Domains ...................................................................................................56
Label-Switching Routers ............................................................................................57
MPLS Performed by Label-Switching Routers...................................................57
Router = LSR.......................................................................................................57
MPLS Router Functions: Ingress ...............................................................................58
The Functions of the Ingress Router ...................................................................58
MPLS Router Functions: Transit................................................................................59
The Functions of the Transit Router....................................................................59
MPLS Router Functions: Penultimate ........................................................................60
The Function of the Penultimate Router .............................................................60
MPLS Router Functions: Egress ................................................................................61
The Functions of the Egress Router ....................................................................61
MPLS Labels ..............................................................................................................62
Assigned Manually or by Signaling Protocol......................................................62
Changing Labels by Segment..............................................................................62
Label Swapping ...................................................................................................62
Local Significance and Labels.............................................................................62
Labeled Packets ..........................................................................................................63
Labeled Packets ...................................................................................................63
IP Packet Restored at Egress ...............................................................................63
MPLS Shim Header Structure ....................................................................................64
4
The MPLS Header (Label) Structure ..................................................................64

Reserved MPLS Label Values.............................................................................65
MPLS Processing Example: Ingress...........................................................................66
Following the 134.112.1.5/32 Packet ..................................................................66
Ingress Node Pushes a Label...............................................................................66
MPLS Processing Example: Transit...........................................................................67
Transit Router Processing....................................................................................67
MPLS Processing Example: Egress ...........................................................................68
Penultimate and Egress Router Processing .........................................................68
Penultimate Hop Popping....................................................................................68
Egress Router.......................................................................................................68
Label Stacking ............................................................................................................70
Stacking for Scalability .......................................................................................70
Review Questions .......................................................................................................71
This Module Discussed: ......................................................................................71
Chapter 3
Module 3: RSVP-Signaled LSPs
73
This Module Discusses:.......................................................................................74
RSVP-Signaled LSPs Agenda ....................................................................................75
Static LSPs: Pros and Cons ........................................................................................76
Static LSP Advantages ........................................................................................76
Static LSP Disadvantages....................................................................................76
Static LSP Configuration............................................................................................78
Manual Configuration .........................................................................................78
Reserved Labels for Static LSPs .........................................................................78
Static LSP Label Mapping Example ..........................................................................79
Sample Static LSP Configuration........................................................................79
Static LSP Configuration Statements .........................................................................80
Static LSP Configuration Example .....................................................................80
Static LSPs and the Routing Table .............................................................................82
Static LSPs on the Ingress Router .......................................................................82
Static LSPs and the Forwarding Table .......................................................................83
Static LSPs on Transit Routers............................................................................83
Summary: Static versus Signaled LSPs......................................................................84
Static LSPs ..........................................................................................................84
Signaled LSPs......................................................................................................84
Signaled LSP Overview..............................................................................................86
Configured at Ingress Router Only......................................................................86
Controlling the Path of a Signaled LSP...............................................................86
LSP Signaling Options ...............................................................................................87
LSP Signaling Protocol Options..........................................................................87
JUNOS Software Support for LDP Signaling .....................................................88
RSVP Signaling ..........................................................................................................89
RSVP Background......................................................................................................90
RSVP Background ..............................................................................................90
RFC 2205 ............................................................................................................90
Basic RSVP Path Signaling ........................................................................................91
RSVP Data Flows................................................................................................91
RSVP Is a Soft State Protocol .............................................................................91
More RSVP Message Types.......................................................................................93
RSVP Message Types .........................................................................................93
Extended RSVP ..........................................................................................................94
Traffic Engineering Extensions to RSVP............................................................94
:
Now Positioned as a Router Signaling Protocol .................................................94

MPLS Extensions to RSVP ........................................................................................95
RSVP Message Objects.......................................................................................95
Explicit Route Objects................................................................................................96
Explicit Route Objects for Traffic Engineering ..................................................96
Label Objects ..............................................................................................................97
Requesting Labels ...............................................................................................97
Assigning Labels .................................................................................................97
The Record Route Object ...........................................................................................98
Record Route ObjectDownstream via Path Message......................................98
Record Route ObjectUpstream via Reservation Message...............................98
Session Attribute Object ...........................................................................................100
Session Attribute Object....................................................................................100
Tspec Object .............................................................................................................101
Tspec Object......................................................................................................101
RSVP Neighbor and Path Maintenance....................................................................102
Adjacency Maintenance ...........................................................................................103
Establishing an RSVP Adjacency .....................................................................103
Rapid Node-to-Node Failure Detection.............................................................103
Path Maintenance .....................................................................................................104
Path Refresh.......................................................................................................104
RSVP Message Aggregation ....................................................................................105
Aggregation of RSVP Messages .......................................................................105
RSVP Signaling Example: Path ...............................................................................106
Signaled Path from San Francisco to New York...............................................106
RSVP Signaling Example: Reservation ...................................................................107
Returning a Reservation Establishes LSP State ................................................107
Configuring RSVP-Signaled LSPs ...........................................................................108
Configuring Baseline MPLS Functionality ..............................................................109
Enabling Labeled Packets on Interfaces............................................................109
Configuring the MPLS Instance........................................................................109
Configuring RSVP....................................................................................................110
Configuring RSVP ............................................................................................110
Add RSVP Authentication........................................................................................111
Authentication Support......................................................................................111
Configuration Example .....................................................................................111
Minimal LSP Configuration Example ......................................................................112
Defining a Basic LSP ........................................................................................112
Adding a Bandwidth Reservation.............................................................................113
Adding a Bandwidth Reservation......................................................................113
RSVP Monitoring and Troubleshooting...................................................................114
Displaying RSVP Interface Information ..................................................................115
Displaying RSVP Interface Information ...........................................................115
Displaying RSVP Neighbors ....................................................................................117
Displaying RSVP Neighbors.............................................................................117
Displaying RSVP Statistics ...............................................................................118
Displaying RSVP Statistics ...............................................................................118
Displaying RSVP Session Status..............................................................................119
Displaying RSVP Session Status ......................................................................119
Troubleshooting LSP Problems................................................................................121
Troubleshooting LSP Problems.........................................................................121
Clearing LSPs ...........................................................................................................122
Clearing LSPs....................................................................................................122
Tracing RSVP...........................................................................................................123
RSVP Tracing....................................................................................................123
Review Questions .....................................................................................................124
This Module Discussed: ....................................................................................124
Lab 2: RSVP Signaling.............................................................................................125
Chapter 4
Module 4: LSPs and Routing Table Integration
127
Module Objectives....................................................................................................128
This Module Discusses:.....................................................................................128
Routing Table Integration.........................................................................................129
Mapping BGP Next Hops to LSPs ...........................................................................130
The Use of the inet.3 Routing Table .................................................................130
BGP Installs LSP as Next Hop..........................................................................130
Route Resolution Example .......................................................................................131
Route Resolution ...............................................................................................131
Unusable BGP Next Hop..........................................................................................132
Unusable BGP Next Hop...................................................................................132
The Problem .............................................................................................................133
Why the Route Is Hidden ..................................................................................133
One Solution: Next-Hop Self at NY.........................................................................134
LSP to New York Is Configured ..............................................................................135
LSP from San Francisco to New York Is Configured.......................................135
LSP to New York Is Established ..............................................................................136
Lowest Preference Wins ...........................................................................................137
BGP Installs LSP as Next Hop .................................................................................138
BGP Installs LSP as Forwarding Next Hop for 134.112/16 .............................138
Ingress Router Behavior ...........................................................................................139
Route Resolution at Ingress Router...................................................................139
Ingress Resolves BGP Next Hop..............................................................................141
BGP Resolves Its Next Hop Using Both Tables ...............................................141
Ingress Installs LSP for Forwarding .........................................................................142
BGP Selects inet.3 over inet.0...........................................................................142
LSP Installed as Forwarding Next Hop in inet.0...............................................142
Route Resolution Summary......................................................................................143
LSPs Are Installed in Ingress Routers inet.3 Table..........................................143
Only BGP Is Aware of inet.3 ............................................................................143
Routing Table Summary...........................................................................................144
Routing Tables Used in MPLS..........................................................................144
Effects of Passive IGP versus Next-Hop Self ..........................................................145
The Ramifications of a Passive IGP Solution ...................................................145
A Thought-Provoking Question ...............................................................................147
The 60,000-Dollar Question..............................................................................147
The Answer...............................................................................................................148
Traffic to 192.168.24.1......................................................................................148
Traffic to 192.168.24.5......................................................................................148
Lab 3: Routing Table Integration .............................................................................150
Chapter 5
Module 5: Named Paths and Routing Constraints
151
Explicit Route Objects..............................................................................................153
Explicit Route Objects: A Definition .......................................................................154

Explicit Route Objects Defined.........................................................................154
Path Contains All Hops Specified .....................................................................154
Loose and Strict Hops .......................................................................................154
Strict EROs ...............................................................................................................156
Strict EROs........................................................................................................156
Loose EROs ..............................................................................................................157
Loose Hops........................................................................................................157
Using Both Strict and Loose EROs ..........................................................................158
Combining Strict and Loose Hops ....................................................................158
A Little ERO Is Goodbut More Is Better .............................................................159
A Little Is Good.................................................................................................159
Partial ERO Example................................................................................................160
Partial ERO Example ........................................................................................160
ERO Processing Summary .......................................................................................161
RSVP Message Addresses to Local Router.......................................................161
Nonegress Router ERO Processing ...................................................................161
Named Path Configuration Example ........................................................................162
Named Path Configuration Example.................................................................162
ERO Case Study .......................................................................................................163
ERO Configuration Case Study ........................................................................163
Modifying Named Paths ...........................................................................................164
Ways to Modify Named Paths...........................................................................164
Confirming LSP Routing..........................................................................................166
Confirming LSP Routing...................................................................................166
Lab 4: Routing Constraints.......................................................................................169
Chapter 6
Module 6: Firewall Filters
171
Firewall Filters..........................................................................................................173
Firewall Filters ..................................................................................................173
Firewall Filters..........................................................................................................174
Actions...............................................................................................................174
Accept/Reject/Discard.......................................................................................174
Internet Processor II Filtering............................................................................174
Analysis .............................................................................................................174
Overview of Firewall Filter Syntax ..........................................................................175
Syntax ................................................................................................................175
Hierarchy Level .................................................................................................175
One or More Terms ...........................................................................................175
Actions and Modifiers .......................................................................................176
One Filter per Unit, per Direction .....................................................................176
Current Firewall Filter Syntax ..................................................................................177
Current and Old Firewall Syntax.......................................................................177
How Filters Are Evaluated .......................................................................................178
Single Terms......................................................................................................178
Multiple Terms ..................................................................................................178
Overview of Match Conditions ................................................................................179
Firewall Match Conditions ................................................................................179
The from Statement Sets Match Conditions......................................................179
Match Condition Categories..............................................................................179
8
Numeric Range Filter Match Condition ...................................................................181

Numeric Matches...............................................................................................181
Format ...............................................................................................................181
Keywords...........................................................................................................181
Address Filter Match Condition ...............................................................................183
IP Prefixes .........................................................................................................183
Keywords...........................................................................................................183
Longest Match ...................................................................................................183
Bit-Field Match Condition........................................................................................184
Matching on Bits ...............................................................................................184
Symbolic Names................................................................................................184
Bit Matching......................................................................................................184
Logical Operators ..............................................................................................185
Bit-Field Match Examples........................................................................................186
Bit-Field Match Conditions...............................................................................186
Firewall Actions Overview.......................................................................................188
Firewall Actions ................................................................................................188
Action Statements.....................................................................................................189
Action Statements..............................................................................................189
Reject Message Options ...........................................................................................191
Reject Options ...................................................................................................191
Action Modifiers.......................................................................................................192
Counters.............................................................................................................192
Logging .............................................................................................................192
Sampling............................................................................................................193
Applying Firewall Filters..........................................................................................194
Applying Filters.................................................................................................194
Common Filters .................................................................................................194
Input and Output................................................................................................194
Protecting the Routing Engine ..........................................................................194
Transit versus Routing Engine Filters ......................................................................195
Protecting the Routing Engine ..........................................................................195
Careful!..............................................................................................................196
Default Discard All............................................................................................196
Sample Topology......................................................................................................197
Example.............................................................................................................197
Spoof Prevention ......................................................................................................198
Stopping Spoofs ................................................................................................198
Inbound Spoof Prevention ........................................................................................199
Inbound Spoofs..................................................................................................199
Remember to Apply! .........................................................................................199
Pop Quiz! ..................................................................................................................200
Quiz ...................................................................................................................200
Preventing Fragmentation Exploits ..........................................................................201
Problems with Fragments ..................................................................................201
Securing the FTP/WWW Server ..............................................................................203
Server Security ..................................................................................................203
Outgoing Service Restriction....................................................................................204
Restricting Services ...........................................................................................204
Rate Policing.............................................................................................................205
Filters Identify Traffic for Rate-Limiting..........................................................205
Rate Limits ........................................................................................................205
Excess Traffic....................................................................................................206
Rate Policing Example .............................................................................................207
Example.............................................................................................................207
Interface-Based Policers .......................................................................................209
Two-Level Policers ...........................................................................................209
Viewing Interface Policers .......................................................................................210
Viewing Policers (Part 1) ..................................................................................210
Firewall-Related Operational Commands ................................................................211
Internet Processor II Operational Commands ...................................................211
Displaying Counter and Policer Statistics ................................................................212
Displaying Counter and Policer Statistics .........................................................212
Displaying Entries in the Kernel Cache ...................................................................213
Displaying Entries in the Kernel Cache ............................................................213
View Firewall-Related Syslog Entries .....................................................................214
Displaying Firewall-Related Syslog Entries .....................................................214
Clearing Firewall Filter Counters .............................................................................215
Clearing Firewall Filter Counters......................................................................215
Lab 5: JUNOS Software Firewall Filters .................................................................217
Chapter 7
Module 7: Multicast Theory
219
IP Multicast Agenda .................................................................................................221
Traffic Flow ..............................................................................................................222
Address Types and Traffic Flow .......................................................................222
IP Multicast Addressing ...........................................................................................223
Multicast Addresses...........................................................................................223
Registered Groups .............................................................................................223
Scoped Range ....................................................................................................223
IP Multicast-to-Ethernet Mapping............................................................................224
Address Mapping...............................................................................................224
IP Multicast-to-Ethernet Mapping Example.............................................................225
Address Mapping Example ...............................................................................225
Multicast Components ..............................................................................................226
Sources and Group Members ............................................................................226
Host Protocols ...................................................................................................226
Routing Protocols ..............................................................................................226
Other Multicast Features ...................................................................................227
The IGMP Protocol ..................................................................................................228
Operation and Software Support for IGMP.......................................................228
IGMP ........................................................................................................................229
IGMP .................................................................................................................229
IGMP Message Exchange .................................................................................229
JUNOS Software Support..................................................................................229
Multicast Groups and Routing..................................................................................230
Group Membership Protocols versus Multicast Routing Protocols ..................230
IGMP Versions ........................................................................................................231
IGMP Version 1 ................................................................................................231
IGMP Version 2 ................................................................................................231
IGMP Version 3 ................................................................................................232
IGMP Version 2.......................................................................................................233
IGMP Version 2 ................................................................................................233
Querier Election.................................................................................................233
Leave-Group Message.......................................................................................233
10
IGMPv2 Join Process ...............................................................................................234

Joining a Multicast Group .................................................................................234
IGMPv2 Query-Response Process ...........................................................................235
Query-Response Model .....................................................................................235
IGMPv2 Group Leave ..............................................................................................237
IGMPv2 Group Leave .......................................................................................237
IGMPv3 and SSM ....................................................................................................238
IGMPv3 and SSM .............................................................................................238
Multicast Routing .....................................................................................................240
Multicast Routing ..............................................................................................240
Multicast Routing Protocol Characteristics ..............................................................241
Multicast Routing Differs from Unicast Routing..............................................241
Reverse-Path Forwarding ..................................................................................241
Distribution Trees..............................................................................................241
Reverse-Path Forwarding .........................................................................................242
Reverse-Path Forwarding ..................................................................................242
The RPF Check (1 of 2)............................................................................................243
The RPF Check: Part 1 ......................................................................................243
The RPF Check (2 of 2)............................................................................................244
The RPF Check: Part 2 ......................................................................................244
Dense-Mode Routing Protocols................................................................................245
Dense-Mode Routing Protocol Behavior ..........................................................245
Source-Based Distribution Tree ........................................................................245
Dense-Mode Protocols ......................................................................................245
PIM Dense Mode Operation.....................................................................................246
PIM Dense Mode Operation..............................................................................246
Pruning Unwanted Traffic ........................................................................................247
Pruning Unwanted Traffic.................................................................................247
After the Prune..........................................................................................................248
After the Prune ..................................................................................................248
A Shortest-Path Tree ................................................................................................249
Source Distribution Tree ...................................................................................249
PIM Sparse Mode .....................................................................................................250
PIM Independence.............................................................................................250
PIM Sparse Mode Trees ....................................................................................250
Design Considerations.......................................................................................250
Sparse-Dense Mode...........................................................................................251
PIM Sparse Mode: The Shared Tree ........................................................................252
PIM Sparse Mode: The Shared Tree .................................................................252
PIM Sparse Mode: Switch to SPT (1 of 3) ...............................................................253
PIM Sparse Mode: Switch to SPT (Part 1)........................................................253
PIM Register Messages ............................................................................................256
PIM Register Messages .....................................................................................256
The Result.................................................................................................................257
When All Is Said and Done ...............................................................................257
Joining a Shared Tree Example: Step 1....................................................................258
Joining a Shared Tree Example.........................................................................258
Joining a Shared Tree Example: Step 2....................................................................260
Traffic Flows Over the Shared Tree..................................................................260
Analyzing Join State: Shared Tree ...........................................................................261
11
Shared-Tree Join State.......................................................................................261

Joining the Shortest-Path Tree..................................................................................263
Joining the SPT .................................................................................................263
Traffic Flows over the SPT ......................................................................................264
Traffic Now Follows the SPT............................................................................264
Sydney after Joining the SPT ..................................................................................265
Sydney after Joining the SPT ............................................................................265
Confirming SPT State: Sao Paulo ...........................................................................266
Confirming Sao Paulo Is on the SPT.................................................................266
Confirming RPF State: Sao Paulo ............................................................................267
Confirming the RPF State on the Sao Paulo Router .........................................267
PIM RP Discovery Options ......................................................................................268
PIM RP Discovery Options ...............................................................................268
Determining the RP ..................................................................................................269
Dynamic RPs .....................................................................................................269
Auto-RP ....................................................................................................................270
Dynamic RP Assignment ..................................................................................270
Dense Groups Needed .......................................................................................270
Failover Capabilities..........................................................................................270
Mapping Agents ................................................................................................271
Bootstrap Router (1 of 2)..........................................................................................272
Priority for Becoming the Bootstrap Router .....................................................272
Mechanism to Select the RP..............................................................................272
Bootstrap Router (2 of 2)..........................................................................................273
Bootstrap Mechanism........................................................................................273
Load Balancing..................................................................................................273
SAP and SDP Protocols............................................................................................275
SAP and SDP Protocols ....................................................................................275
Overview of SDP and SAP.......................................................................................276
Session Description Protocol.............................................................................276
Session Announcement Protocol.......................................................................276
Displaying Session Details .......................................................................................277
Displaying Session Details ................................................................................277
Module Review.........................................................................................................278
Chapter 8
Module 8: Multicast Configuration and Monitoring
279
Multicast Support .....................................................................................................281
JUNOS Software Multicast Support .................................................................281
Configuring Multicast...............................................................................................282
Configuring IGMP....................................................................................................283
IGMP Configuration..........................................................................................283
PIM Configuration: General .....................................................................................285
PIM Configuration: General..............................................................................285
PIM Configuration: RP Properties ...........................................................................287
General PIM Configuration: RP Properties.......................................................287
Configuration Example: Static RP ...........................................................................289
Static RP Configuration Example .....................................................................289
Configuration Example: Auto-RP ............................................................................290
Auto-RP Configuration Example ......................................................................290
Configuration Example: Bootstrap ...........................................................................292
Bootstrap Configuration Example.....................................................................292
12
Monitoring Multicast Operation ...............................................................................294

Multicast Operational Commands.....................................................................294
Obtaining IGMP Interface Information ....................................................................295
Displaying the IGMP Interface .........................................................................295
Displaying IGMP Group Information ......................................................................296
Displaying IGMP Group Information ...............................................................296
Displaying IGMP Statistics ......................................................................................297
Displaying IGMP Statistics ...............................................................................297
Displaying the Bootstrap Router ..............................................................................298
Displaying the Bootstrap Router .......................................................................298
Determining RP Status .............................................................................................299
Determining RP Status ......................................................................................299
Viewing Extended RP Information ..........................................................................300
Viewing Extended RP Information ...................................................................300
Displaying PIM Interfaces........................................................................................301
Displaying Interfaces Running PIM..................................................................301
Displaying PIM Neighbors .......................................................................................302
Listing PIM Neighbors ......................................................................................302
Displaying PIM Join State ........................................................................................303
Displaying PIM Join States ...............................................................................303
Examining Source RPF State ...................................................................................304
Displaying Source RPF State ............................................................................304
Displaying PIM Statistics .........................................................................................305
Displaying PIM Message Types........................................................................305
Viewing Usage Statistics ..........................................................................................307
Viewing Usage Statistics...................................................................................307
Displaying Multicast Routing Table.........................................................................308
Displaying Multicast Routes .............................................................................308
Displaying Outgoing Interface Lists.........................................................................309
Displaying Next-Hop ID to Outgoing Interface List Mappings........................309
Confirming Presence of Tunnel Services PIC ..........................................................310
Verifying Tunnel Services PIC Presence ..........................................................310
No Configuration Needed..................................................................................311
Module Review.........................................................................................................312
Labs 6 and 7: IP Multicast ........................................................................................313
Index ........................................................................................................................315
13
14
List of Tables
Table 1:
Table 2:
Table 3:
Table 4:
Table 5:
Table 6:
Keywords Used with Numeric Match Conditions..................................181

Bit-Field Logical Operators....................................................................185
Bit-Field Match Conditions Used in a Firewall Filter ............................186
Text Synonyms Used in a Firewall Filter ...............................................187
Filter Actions ..........................................................................................189
Action Modifiers.....................................................................................189
: List of Tables
15
16
: List of Tables
List of Figures
Figure 1:
Figure 2:
Figure 3:
Figure 4:
Figure 5:
Figure 6:
Figure 7:
Figure 8:
Figure 9:
Figure 10:
Figure 11:
Figure 12:
Figure 13:
Figure 14:
Figure 15:
Figure 16:
Figure 17:
Figure 18:
Figure 19:
Figure 20:
Figure 21:
Figure 22:
Figure 23:
Figure 24:
Figure 25:
Figure 26:
Figure 27:
Figure 28:
Figure 29:
Figure 30:
Figure 31:
Figure 32:
Figure 33:
Figure 34:
Figure 35:
Figure 36:
Figure 37:
Figure 38:
Figure 39:
Figure 40:
Figure 41:
Figure 42:
Figure 43:
Figure 44:
IGP Metric-Based Forwarding .................................................................35

Drawbacks of IGP Metric Forwarding .....................................................36
Overlay Networks.....................................................................................41
IGP-Based Traffic Engineering ................................................................53
MPLS-Based Traffic Engineering ............................................................54
MPLS Traffic Engineering Paths .............................................................55
MPLS Terminology ..................................................................................56
Label-Switching Routers ..........................................................................57
MPLS Router Functions: Ingress .............................................................58
MPLS Router Functions: Transit..............................................................59
MPLS Router Functions: Penultimate ......................................................60
MPLS Router Functions: Egress ..............................................................61
Labeled Packets ........................................................................................63
MPLS Shim Header Structure ..................................................................64
MPLS Processing Example: Ingress.........................................................66
MPLS Processing Example: Transit.........................................................67
MPLS Processing Example: Egress .........................................................68
Label Stacking ..........................................................................................70
Static LSP Label Mapping Example ........................................................79
Static LSP Configuration Statements .......................................................80
Static LSPs and the Routing Table ...........................................................82
Static LSPs and the Forwarding Table .....................................................83
Basic RSVP Path Signaling ......................................................................91
RSVP Signaling Example: Path .............................................................106
RSVP Signaling Example: Reservation .................................................107
Displaying RSVP Session Status............................................................119
Troubleshooting LSP Problems..............................................................121
Route Resolution Example .....................................................................131
Unusable BGP Next Hop........................................................................132
BGP Next Hop Problem .........................................................................133
One Solution: Next-Hop Self at NY.......................................................134
LSP to New York Is Configured ............................................................135
LSP to New York Is Established ............................................................136
Lowest Preference Wins .........................................................................137
BGP Installs LSP as Next Hop ...............................................................138
Ingress Router Behavior .........................................................................139
Ingress Resolves BGP Next Hop............................................................141
Ingress Installs LSP for Forwarding .......................................................142
Effects of Passive IGP versus Next-Hop Self ........................................145
Strict EROs .............................................................................................156
Loose EROs ............................................................................................157
Using Both Strict and Loose EROs ........................................................158
Partial ERO Example..............................................................................160
Named Path Configuration Example ......................................................162
: List of Figures
17
Figure 45:
Figure 46:
Figure 47:
Figure 48:
Figure 49:
Figure 50:
Figure 51:
Figure 52:
Figure 53:
Figure 54:
Figure 55:
Figure 56:
Figure 57:
Figure 58:
Figure 59:
Figure 60:
Figure 61:
Figure 62:
Figure 63:
Figure 64:
Figure 65:
Figure 66:
Figure 67:
Figure 68:
Figure 69:
Figure 70:
Figure 71:
Figure 72:
Figure 73:
Figure 74:
Figure 75:
Figure 76:
Figure 77:
Figure 78:
Figure 79:
Figure 80:
Figure 81:
Figure 82:
Figure 83:
Figure 84:
Figure 85:
Figure 86:
Figure 87:
Figure 88:
Figure 89:
Figure 90:
Figure 91:
Figure 92:
Figure 93:
Figure 94:
Figure 95:
Figure 96:
Figure 97:
Figure 98:
18
: List of Figures
ERO Case Study .....................................................................................163

Modifying Named Paths .........................................................................164
Confirming LSP Routing........................................................................166
Bit-Field Match Examples......................................................................186
Transit versus Routing Engine Filters ....................................................195
Sample Topology....................................................................................197
Spoof Prevention ....................................................................................198
Inbound Spoof Prevention ......................................................................199
Pop Quiz .................................................................................................200
Preventing Fragmentation Exploits ........................................................201
Securing the FTP/WWW Server ............................................................203
Outgoing Service Restriction..................................................................204
Rate Policing Example ...........................................................................207
Interface-Based Policers .........................................................................209
Viewing Interface Policers .....................................................................210
Traffic Flow ............................................................................................222
IP Multicast Addressing .........................................................................223
IP Multicast-to-Ethernet Mapping..........................................................224
IP Multicast-to-Ethernet Mapping Example...........................................225
Multicast Groups and Routing................................................................230
IGMPv2 Join Process .............................................................................234
IGMPv2 Query-Response Process .........................................................235
IGMPv2 Group Leave ............................................................................237
IGMPv3 and SSM ..................................................................................238
The RPF Check (1 of 2)..........................................................................243
The RPF Check (2 of 2)..........................................................................244
PIM Dense Mode Operation...................................................................246
Pruning Unwanted Traffic ......................................................................247
After the Prune........................................................................................248
A Shortest-Path Tree ..............................................................................249
PIM Sparse Mode: The Shared Tree ......................................................252
PIM Sparse Mode: Switch to SPT (1 of 3) .............................................253
PIM Register Messages ..........................................................................256
Receiver and RPT on SPT (Result) ........................................................257
Joining a Shared Tree Example: Step 1..................................................258
Joining a Shared Tree Example: Step 2..................................................260
Analyzing Join State: Shared Tree .........................................................261
Joining the Shortest-Path Tree................................................................263
Traffic Flows over the SPT ....................................................................264
Sydney after Joining the SPT .................................................................265
Confirming SPT State: Sao Paulo ..........................................................266
Confirming RPF State: Sao Paulo ..........................................................267
Overview of SDP and SAP.....................................................................276
Displaying Session Details .....................................................................277
Configuring IGMP..................................................................................283
PIM Configuration: General ...................................................................285
PIM Configuration: RP Properties .........................................................287
Configuration Example: Static RP .........................................................289
Configuration Example: Auto-RP ..........................................................290
Configuration Example: Bootstrap .........................................................292
Displaying the Bootstrap Router ............................................................298
Determining RP Status ...........................................................................299
: List of Figures
Figure 99: Viewing Extended RP Information ........................................................300

Figure 100:Displaying PIM Interfaces .....................................................................301
Figure 101:Displaying PIM Neighbors ....................................................................302
Figure 102:Displaying PIM Join State .....................................................................303
Figure 103:Examining Source RPF State .................................................................304
Figure 104:Viewing Usage Statistics .......................................................................307
Figure 105:Displaying Multicast Routing Table ......................................................308
Figure 106:Displaying Outgoing Interface Lists ......................................................309
Figure 107:Confirming Presence of Tunnel Services PIC .......................................310
: List of Figures
19
20
: List of Figures
: Preface
Preface
Course Overview on page 22
Objectives on page 22
Intended Audience on page 23
Course Level on page 23
Prerequisites on page 23
Course Agenda on page 23
Document Conventions on page 26
Additional Information on page 27
21
Course Overview
Configuring Juniper Networks Routers (CJNR) Volume 2 is an instructor-led course that covers the configuration and support of MPLS, firewall filters, multicast, and class of service on Juniper Networks
M-series and T-series platforms. This class is a combination of lecture
and lab with ample time for hands-on exposure to the JUNOS software
configuration and operational-mode troubleshooting.
Objectives
After successfully completing this volume, you will be able to:
Describe the concept of traffic engineering and how to configure
MPLS on a Juniper Networks M-series or T-series platform;
Describe how packet filtering can control the flow of IP packets and
provide security within the Juniper Networks M-series and T-series
platforms and;
Configure and monitor IP multicasting on a Juniper Networks
M-series or T-series platform.
22
Course Overview
: Preface
Intended Audience
The primary audiences for this course include the following:
Personnel who are unfamiliar with Juniper Networks M-series and
T-series platform configuration;
Internet engineers; and
Network operations center engineers.
The secondary audiences for this course include the following:
Juniper Networks and partner sales representatives;
Juniper Networks and partner systems engineers; and
Juniper Networks employees (such as hardware engineers, software
engineers, TAC engineers).
Course Level
CJNR Volume 2 is an intermediate-level course designed to provide a
strong product knowledge foundation, and to prepare students for the
more advanced courses available in the Juniper Networks training curriculum.
Prerequisites
The prerequisites for CJNR Volume 2 are:
Configuring Juniper Networks Routers Volume 1 or the equivalent
experience.
Course Agenda
Day 1
The Concept of MPLS
The Need for Traffic Engineering
Overlay Networks and Their Drawbacks
Traffic Engineering: A Definition
Module 2: MPLS Fundamentals

MPLS vs. IGP Traffic Engineering
MPLS Terminology
MPLS Labels
MPLS Processing Examples
Intended Audience
23

Static vs. Signaled LSPs
Signaled LSP Overview
RSVP Signaling
RSVP Extensions That Support MPLS Traffic Engineering
Path and Neighbor Maintenance
Configure RSVP Signaling
Monitor RSVP-Signaled LSPs
Module 4: LSP and Routing Table Integration

Mapping Next Hops to LSPs
Default Ingress Router Behavior
Using Next-Hop Self vs. a Passive IGP
Overview of LSP Integration Options
Module 5: Named Paths and Routing Constraints

Explicit Route Objects
Strict and Loose Hops
Named Path Configuration
Confirming LSP Routing
Day 2
Module 6: Internet Processor II Firewall Filters
Overview of Firewall Filter Syntax
Match Conditions
Actions
Applying Firewall Filters
Filter Examples
Rate Policing
Operational Analysis of Counters and Policers

The benefits of Multicast
Multicast Addressing
IGMP
Multicast Routing
Dense and Sparse Mode Operation
RP Discovery Options
SAP and SDP
24
Course Agenda
: Preface
Module 8:Multicast Configuration and Monitoring

JUNOS Software Multicast Support
Configuring Multicast
Auto-RP and Bootstrap
Monitor Multicast operation
Confirming Presence of Tunnel Services PIC
Course Agenda
25
Document Conventions
The following table lists the syntax-related style conventions used throughout this
document:
Style
Description
Usage Example
Arial
Lab instructions and

descriptive text.
If told to do so by your instructor, enter the

following commands to restore the factory
default configuration.
Courier New
Operational displays and

noncommand-related
syntax.
commit complete
Exiting configuration mode
Courier New italic

underline
A syntax variable that the

You will now apply your
reader is expected to define ospfexport-policy to the OSPF
locally.
routing instance as an export policy.
Courier New bold
Command syntax is
displayed in bold to
differentiate commands
from descriptive text.
erx1:isp-1#configure terminal
Or
The user can display interface status with

the show interfaces command and
Please note that the Courier
may make use of the extensive switch, as
New bold style can be
needed, to obtain additional information.
combined with other styles
as needed, for example, to
indicate a command that
involves the use of a locally
defined named variable.
26
Courier New italic
Predefined syntax variYou will now apply the ospf-test-polables such

icy to the OSPF routing
as named
instance as an export
policies or
policy.
passwords.
Courier New italic

underline
You will now apply your

A syntax variable that the
ospfexport-policy
reader is
expected to
to the OSPF routing
define
instance as an export
locally.
policy.
Document Conventions
: Preface
Additional Information
Education Services Offerings
You can obtain information on the latest Education Services offerings, course
dates, and class locations from the World Wide Web by pointing your Web
browser to: http://www.juniper.net/training/.
About This Publication

The Configuring Juniper Networks Routers Student Guide was developed and
tested using software Release 6.13R1.3. Previous and later versions of software
may behave differently so you should always consult the documentation and
release notes for the version of code you are running before reporting errors.
This document is written and maintained by the Juniper Networks Education
Services development team. Please send questions and suggestions for
improvement to mailto:training@juniper.net.
Technical Publications
You can print technical manuals and release notes directly from the Internet in a
variety of formats:
1. Go to http://www.juniper.net/support/.
2. On the left side of the page, click the Technical Documentation button to be
directed to the technical documentation area of the Juniper Networks
Website.
3. Locate the specific software or hardware release and title you need, and
choose the format in which you want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks
sales office or account representative.
Juniper Networks Support

For technical support, contact Juniper Networks at support@juniper.net, or at
1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the
United States).
27
28
Chapter 1: Module 1: Traffic Engineering Overview
Chapter 1
29
Module Objectives
After successfully completing this module, you will be able to:
Describe the basic concept of MPLS
Explain the evolution of traffic engineering
Explain why IGP-based traffic engineering is problematic
List some of the drawbacks to ATM-based overlay networks
This Module Discusses
30
Module Objectives
The concept of Multiprotocol Label Switching (MPLS);
Traffic engineering need and evolution; and
Problems with IGP-based traffic engineering and overlay networks
Traffic Engineering Overview
Where we are going...
The concept of MPLS
Traffic engineering definition
IGP-based traffic engineering
The overlay network
Router evolution
Traffic Engineering Overview
31
MPLS: The Concept
MPLS is a mechanism for engineering traffic, independent of routing tables
MPLS performs analysis of a packets destination just once (at ingress), then
places it in a preconfigured tunnel
At each hop through the tunnel, MPLS handles the packet at Layer 2 only
JUNOS software supports multiple RFCs and Internet drafts related to MPLS
Mechanism for Traffic Engineering

Today, MPLS is essentially a mechanism for adding traffic engineering to
best-effort IP internetworks. MPLS acts totally independently of the normal routing
tables, which continue to exist and function as before.
Packet Analysis
MPLS performs a complete analysis of the packets destination just once, at the
ingress point where the packet enters the MPLS domain. An MPLS domain is a
coordinated group of routers all running MPLS. Once MPLS analyzes the packets
destination, it gives the packet a label and places it in a tunnel that is configured
ahead of time through one of several methods.
Handles Packets at Layer 2 through the Tunnel

MPLS routers handle the packet at each hop along the way to the destination.
However, in contrast to pure IP routing, the MPLS-labeled packet is forwarded
based only on Layer 2 (data link layer) information and never needs to be
subjected to the full independent routing function at each hop. Therefore, much
more control over traffic exists because MPLS makes routing decisions only at the
ingress router, and other routers within the MPLS domain do not repeat (and
duplicate, or override) these decisions.
RFC Support
JUNOS software supports the following list of RFCs and Internet drafts related to
MPLS:
32
MPLS: The Concept
ICMP Extensions for Multiprotocol Label Switching, Internet draft

draft-ietf-mpls-icmp-01.txt
RFC 3031, Multiprotocol Label Switching Architecture
A Framework for Multiprotocol Label Switching, Internet draft

draft-ietf-mpls-framework-05.txt
RFC 3032, MPLS Label Stack Encoding
RFC 2702, Requirements for Traffic Engineering Over MPLS
IS-IS Extensions for Traffic Engineering, Internet draft

draft-ietf-isis-traffic-02.txt
Traffic Engineering Extensions to OSPF, Internet draft

draft-katz-yeung-ospf-traffic-01.txt
Calculating IGP Routes over Traffic Engineering Tunnels, Internet draft

draft-hsmit-mpls-igp-spf-01.txt
MPLS: The Concept
33
Early Internet
Early 1990s
T1 and T3 links between routers connected Internet core
Only a handful of routers and links to manage and configure
Humans could do the work manually
IGP metric-based traffic control was sufficient
In the Early Days

In the early 1990s, ISP networks were composed mainly of routers interconnected
by leased lines running the T1 (1.5 Mbps) and T3 (45 Mbps) speeds (or E1 at 2
Mbps and E3 at about 34 Mbps outside North America).
Traffic engineering on this Internet with low and fairly uniform link speeds was
simpler thenmetric-based control was adequate because Internet backbones
were much smaller in terms of the number of routers, number of links, and amount
of traffic. Also, in the days before the tremendous popularity of the any-to-any
WWW, the Internets topological hierarchy forced traffic to flow across more
deterministic paths. Current events on the network (for example, John Glenns
return to space and the Starr Report on President Clinton) did not create
temporary hot spots.
When events did shift traffic flows significantly, the network was simple enough to
allow for manual shifting of traffic by adjusting to metrics assigned to links.The
metrics supplied by the IGP itself, especially a link-state IGP, was enough to
control the flow of traffic and provide at least some measure of traffic engineering.
34
Early Internet
IGP Metric-Based Forwarding
Traffic sent to A or B follows path with lowest metrics
A
1
Figure 1: IGP Metric-Based Forwarding
Forwarding Based on the IGP

This slide shows metric-based traffic engineering in action. When sending large
amounts of data to Network A, traffic is routed through the top router because it
has a lower overall cost (2, as opposed to 3, through Router C). Note that not only
the traffic destined for Router A follows the upper path, but also all traffic for
Router B and any routers downstream from Router B.
IGP Metric-Based Forwarding
35
Drawbacks of IGP Metric Forwarding
Redirecting traffic flow to A via C causes traffic for B to move also!
Some links become underutilized or overutilized
A
1
Figure 2: Drawbacks of IGP Metric Forwarding
Some Drawbacks of IGP Forwarding

At some point, sending all of the traffic for Routers A and B and points beyond
through the top-most router might not be the best idea. For example, a lot of local
traffic to the top router might exist, and this traffic might delay the traffic to Routers
A and B while the path through Router C is underutilized. Whatever the actual
cause, you might want to route at least some of the traffic to some destinations
over the lower links and through Router C. Suppose traffic for Router A needs to
be rerouted onto this lower path.
Rerouting traffic for Router A by raising metrics along the current path, as shown
in the slide, has the desired effect. Traffic to Router A follows the path with cost 3
instead of cost 5. But forcing the traffic to use Router C, by raising the metric on
the upper path, has the unintended effect of causing traffic destined for Router B
to do the same and flow through Router C.
Because IGP route calculation was topology driven and based on a simple
additive metric, such as the hop count or an administrative value, the traffic
patterns on the network were not taken into account when the IGP calculated its
forwarding table. As a result, traffic was not evenly distributed across the
networks links, causing inefficient use of expensive resources. Some links
became congested, while other links remained underutilized. This result might
have been satisfactory in a sparsely connected network, but in a richly connected
network (that is, bigger, more thickly meshed, and more redundant), you must
control the paths that traffic takes to balance loads. In other words, you need more
control for realistic traffic engineering than the usual IGP method of sending all
traffic to a group of destinations over the same, single best path.
36
Drawbacks of IGP Metric Forwarding
Additional Drawbacks of IGP Metrics
Adjusting an IGP metric might destabilize the network
Moves problem around
Some links underutilized
Some links overutilized
Lacks control
All traffic flows via the IGP shortest path
Additional Drawbacks
This simplistic changing of IGP metric to force traffic path movements has more
drawbacks than just moving the traffic to downstream destinations along with the
target to the new path. Adjusting metrics manually can have a severe destabilizing
effect on a network, especially a large one. As ISP networks became more richly
connected, it became more difficult to ensure that a metric adjustment in one part
of the network did not cause problems in another part of the network. Adjusting
metrics just tended to move problems around. The low-cost links and paths
became saturated, while the higher-cost links and paths remained almost devoid
of traffic.
There was little to no real control over the process. All traffic followed the path with
the lowest IGP metric because no other standard mechanism to distribute traffic
flow existed. There were no rules and few guidelines to follow about which metrics
to adjust and by how much to adjust them. Traffic engineering based on metric
manipulation offered a trial-and-error approach, rather than a scientific solution to
an increasingly complex problem.
Additional Drawbacks of IGP Metrics
37
Growth Requires Changes
Mid-1990s
ISPs became uncomfortable with size of Internet core
Large growth spurt imminent
Routers too slow
IGP metric engineering too complex
IGP routing calculation was topology driven, not traffic driven
Router-based cores lacked predictability
Growth of the Internet

Despite the obvious drawbacks to manual traffic engineering through IGP metric
adjustments, metric-based traffic controls continued to be an adequate traffic
engineering solution until the mid-90s. At this point, some ISPs reached a size at
which they did not feel comfortable moving forward with either metric-based traffic
controls or router-based cores.
Many ISPs accurately foresaw the big jump in Internet popularity and traffic that
came in the late 1990s. This time period saw the rise of the entire dot com
industry and the rise of the Internet as a dominating force in business and leisure.
With this increased load, traditional software-based routers had the potential to
become traffic bottlenecks under heavy load because their aggregate bandwidth
and packet-processing capabilities were limited.
It became increasingly difficult to ensure that a metric adjustment in one part of a
huge network did not create a new problem in another part. Manual traffic
engineering by adjusting IGP metrics became too complex as routers came to be
more highly meshed with more and more links running at a wider range of
speedsfrom 1.5 Mbps (or even 64 Kbps) all the way up to 2.4 Gbps and beyond.
IGP metrics work by basing route calculations on the topology of the network and
not the actual traffic flow on the network. With IGPs, only one best way to get
somewhere can exist. Once that way was figured out, the job of the IGP was over.
But at this point, the task of traffic engineering is just beginning.
Finally, router-based cores did not offer the high-speed interfaces or deterministic
performance that ISPs required as they planned to grow their core networks.
Something new was clearly needed.
38
Growth Requires Changes
Overlay Networks Are Born
ATM switches offered performance and predictable behavior
ISPs created overlay networks that presented a virtual topology to the edge
routers in their networks
Using ATM virtual circuits, the virtual network could be reengineered without
changing the physical network
Benefits
Full traffic control
Per-circuit statistics
More balanced flow of traffic across links
Behavior of ATM Switches

Asynchronous Transfer Mode (ATM) switches offered a solution when ISPs
required more bandwidth to handle increasing traffic loads. The ISPs that
migrated to ATM-based cores discovered that ATM permanent virtual circuits
(PVCs) offered precise control over traffic flow across their networks. ISPs came
to rely on the high-speed interfaces, deterministic performance, and PVC
functionality that ATM switches provided.
Overlay Networks
Around 1994 or 1995, Internet traffic became so high that ISPs had to migrate
their networks to support trunks that were larger than T3 (45 Mbps). Fortunately,
OC-3 ATM interfaces (155 Mbps) became available for switches and routers. To
obtain the required speed, ISPs had to redesign their networks so that they could
use higher speeds supported by a switched core. ATM overlays could be used to
connect routers.
ATM PVCs
An ATM-based core fully supports traffic engineering because it can explicitly map
PVCs. Mapping PVCs is done by provisioning an arbitrary virtual topology on top
of the networks physical topology. PVCs are mapped from edge to edge to
distribute traffic across all links precisely so that they are utilized evenly. This
approach eliminates the traffic magnet effect of least-cost routing, which results in
overutilized and underutilized links. The traffic engineering capabilities supported
by ATM PVCs made the ISPs more competitive within their market, so they could
provide better service to their customers at a lower cost.
39
Benefits
Per-PVC statistics provided by the ATM switches facilitate monitoring traffic
patterns for optimal PVC placement and management. Network designers initially
provision each PVC to support specific traffic engineering objectives, and then
they constantly monitor the traffic load on each PVC. If a given PVC begins to
experience congestion, the ISP has the information it needs to remedy the
situation by modifying either the virtual or physical topology to accommodate
shifting traffic loads.
40
Overlay Networks
Blueprint:
ATM core ringed by routers
PVCs overlaid onto physical network
Physical
View
Logical
View
A
B
A
C
B
Figure 3: Overlay Networks
Overlay Network Blueprint

In an ATM overlay network, routers surround the edge of the ATM cloud. The ATM
core network is ringed by the routers. Each router communicates with every other
router by a set of PVCs that are configured across the ATM physical topology. The
PVCs function as logical circuits, providing connectivity between edge routers.
The routers do not have direct access to information describing the physical
topology of the underlying ATM infrastructure. The routers have knowledge only of
the individual PVCs that appear to them as simple point-to-point circuits between
two routers. The slide shows how the physical topology of an ATM core differs
from the logical IP overlay topology.
The distinct ATM overlay and underlying IP networks meet when the ATM PVCs
are mapped to interfaces on a router. Logical interfaces on a router are associated
with ATM PVCs, and then the routing protocol works to associate IP prefixes
(routes) with the logical units (or subinterfaces) instead of merely the physical link.
Integrating the ATM PVCs into the IP network by running the IGP across each of
the PVCs to establish peer relationships and exchange routing information
completes the process of linking IP routes over an ATM core network. Between
any two routers, the IGP metric for the primary PVC is set so that it is preferred
more than any backup PVC. This setting guarantees that the backup PVCs are
used only when the primary PVC is not available. Also, if the primary PVC
becomes available after an outage, traffic automatically returns to the primary
PVC from the backup.
Overlay Networks
41
Overlay Network Drawbacks
Growth in full mesh of ATM PVCs stresses everything
With 5 routers, adding 1 requires only 10 new PVCs
With 200 routers, adding 1 requires 400 new PVCs
From 39,800 to 40,200 PVCs total
Router IGP runs out of steam
Practical limitation of atomically updating configurations in each switch

and router
Not well integrated
Network does not participate in path selection and setup
Scalability Issues
A network that deploys a full mesh of ATM PVCs exhibits the traditional n2
problem for the number of links to be maintained (n x (n-1))/2). For relatively small
or moderately sized networks, this problem is not a major issue. However, for core
ISPs with hundreds of attached routers, the challenge is quite significant. For
example, when expanding a network from five to six routers, an ISP must
increase the number of simplex PVCs from 20 to 30. However, increasing the
number of attached routers from 200 to 201 requires the addition of 400 new
simplex PVCsan increase from 39,800 to 40,200 PVCs. These numbers do not
include backup PVCs or additional PVCs for networks running multiple services
that require more than one PVC between any two routers.
The full-mesh n2 problem causes several operational challenges:
New PVCs must be mapped over the physical topology;
New PVCs must be tuned so that they minimally impact existing PVCs;
The large number of PVCs might exceed the configuration and

implementation capabilities of the ATM switches; and
The configuration of each switch and router in the core must be modified.
ATM PVCs Not Well Integrated

ATM PVCs are not integrated with the IGP either. Thus, deploying full-mesh PVCs
also stresses the IGP. This stress results from the number of peer IGP
relationships that must be maintained, the challenge of processing n3 link-state
updates in the event of a failure, and the complexity of performing the Dijkstra
calculation over a topology containing a significant number of logical links. Any
time the topology results in a full mesh, the impact on the IGP is a suboptimal
topology that is extremely difficult to maintain. As an ATM core expands, the n2
stress on the IGP compounds.
42
Overlay Network Drawbacks
More Overlay Network Drawbacks
ATM cell overhead
Approximately 20% of bandwidth
OC-48 link wastes 498 Mbps in ATM cell overhead
OC-192 link wastes 1.99 Gbps
ATM SAR speed
OC-48 SAR
Trailed significantly behind the router curve
OC-192 SAR continues the trend
Few sources exists, not yet widely deployed
Very difficult to build
Lagged OC192c router interfaces by ~ 2.5 years
ATM Cell Overhead

ATM cell overhead (often called the ATM cell tax) is introduced when
packet-oriented protocols, such as IP, are carried over an ATM infrastructure. ATM
overhead is never less than about 10% and sometimes as high as 62% (a 40-byte
TCP/IP acknowledgement packet requires 106 bytes of ATM on the wire when
using
AAL 5 and multiprotocol encapsulation). Assuming 20% overhead for ATM
running on a 2.488-Gbps OC-48 link, 1.99 Gbps is available for customer data,
and 498 Mbpsalmost a full OC-12is required for the ATM overhead. On a
10-Gbps OC-192 interface, some 1.99 Gbpsalmost a full OC-48 of the links
capacityis consumed by ATM overhead!
ATM SAR Speed

A related issue is the need to create the ATM cells in the first place. Because ATM
cells are used only between the routers while IP packets are used within the
routers, each ATM router interface must segment and then reassemble the
packets into ATM cells using a special chipset with segmentation and reassembly
(SAR) functionality. ATM router interfaces have not kept pace with the latest
increases in optical bandwidth, however. The fastest commercially available ATM
SAR functionality is currently OC192c/STM-64. This functionality was
demonstrated at a trade show in November 2002. In contrast, Juniper Networks
shipped the industry's first OC192c/STM-64 SONET interfaces with the M160
platform back in April of 2000. All signs indicate that OC-768 (40 Gbps) router
interfaces will soon be available. Time can only tell if OC-768c ATM SAR
functionality is even possible, let alone commercially viable.
43
The limits in SAR scaling mean that ISPs attempting to increase the speed of their
networks using the IP-over-ATM model must purchase large ATM switches and
routers with a large number of slower ATM interfaces. This necessity dramatically
increases the expense and complexity of growing the network, which only
compounds as ISPs migrate to OC-192c and then on to OC-768c. Studies
suggest that ATM cells are unnecessary above OC-12c speeds (about 622 Mbps)
because serialization delays are only significant at lower speeds. ATM works best
when bandwidth is restricted and links speeds are somewhat slow.
44
Routers Evolve
Current generation of routers have:
High-speed, wire-rate interfaces
Deterministic performance
Software advances
Solution
Fuse best aspects of ATM PVCs with high-performance routing engines
Use low-overhead circuit mechanism
Automate path selection and configuration
Implement quick failure recovery
Routers Today
To sum up, there are many disadvantages of continuing the IP-over-ATM model
when other alternatives are available. Routers today are as fast, if not faster, than
the speediest ATM switch. High-speed interfaces, deterministic performance, and
traffic engineering using PVCs no longer distinguish ATM switches from Internet
backbone routers. Furthermore, the deployment of a router-based core solves a
number of inherent problems with the ATM model: the complexity and expense of
coordinating two sets of equipment, the bandwidth limitations of ATM SAR
interfaces, the cell tax, the n2 PVC problem, the IGP stress, and the limitation of
not being able to operate over a mixed-media infrastructure.
Solution
The current best solution to the router traffic engineering problem is to combine
the best features of PVC mapping to high-performance routers without requiring
ATM. JUNOS software fuses the best aspects of ATM PVCs with
high-performance packet forwarding.
Using a low-overhead, circuit-switching protocol with automatic path selection and
maintenance, you can optimize the entire network core by distributing traffic
engineering chores to each router. Also, quick failover and recovery mechanisms
exist that you can implement when reliability is paramount.
Routers Evolve
45
Why Engineer Traffic?
A major goal of Internet Traffic Engineering is to facilitate efficient and reliable

network operations while simultaneously optimizing network resource
utilization and performance
RFC 2702, Requirements for Traffic Engineering over MPLS
Purpose of Traffic Engineering

Faced with the ever-growing Internet, fuller router meshes, and more diverse link
speeds, RFC 2702, Requirements for Traffic Engineering over MPLS, was issued
in September, 1999.
This RFC is an informational RFC and did not bind anyone to doing something
specific with MPLS. It basically says that if you want to use MPLS for traffic
engineering, heres what MPLS should be able to do.
The abstract of this RFC states:
This document presents a set of requirements for Traffic Engineering over
Multiprotocol Label Switching (MPLS). It identifies the functional capabilities
required to implement policies that facilitate efficient and reliable network
operations in an MPLS domain. These capabilities can be used to optimize the
utilization of network resources and to enhance traffic oriented performance
characteristics.
The slide shows the twin goals of traffic engineering as stated in the RFC. Traffic
engineering should make sure network operations are efficient and reliable, but at
the same time, make sure that network resource utilization and performance are
optimal.
Because engineering traffic is all about control, performance can be diminished or
improved as a result of the added control you now have over packet flow.
46
Why Engineer Traffic?
Review Questions
What is the definition of traffic engineering?
Why is IGP-based engineering problematic?
List two potential drawbacks to an ATM overlay network.
This Module Discussed:
The basic concept of MPLS;
The evolution of traffic engineering;
Why IGP-based traffic engineering is problematic; and
The drawbacks of ATM-based overlay networks.
Review Questions
47
Lab 1: MPLS Setup Lab

Lab Objective:
Configure a baseline topology for use in subsequent MPLS labs.
48
Lab 1: MPLS Setup Lab
Chapter 2: Module 2: Multiprotocol Label Switching Fundamentals
Chapter 2
Module 2: Multiprotocol Label Switching

Fundamentals
49
Module Objectives
Explain the benefits and applications for MPLS
Describe MPLS-based traffic engineering
Define the terms LSR, ingress, egress, and LSP
Describe the push, pop, and swap label operations
Explain penultimate hop popping
Describe MPLS flow and packet processing from ingress to egress router
Explain label stacking
This Module Discusses:
50
Module Objectives
Review of MPLS, the benefits of MPLS, and how MPLS is used for Internet
traffic engineering;
Fundamentals of MPLS and MPLS terminology;
Label operations;
Penultimate hop popping (PHP);
End-to-end packet flow through a label-switched path (LSP); and
Label stacking.
MPLS Fundamentals
The benefits of MPLS-based traffic engineering
MPLS terminology
MPLS labels
Label stacking
End-to-end packet flow through a label-switched path (LSP)
MPLS Fundamentals
51
Benefits of MPLS
Low-overhead virtual circuits for IP
Originally designed to make routers faster
Fixed label lookup faster than longest match used by IP routing
Not true anymore
Value of MPLS is now in traffic engineering
Same forwarding mechanism supports multiple applications on one

integrated network
Virtual Circuits for IP

In a very real sense, MPLS provides low-overhead virtual circuits similar to ATM
PVCs and SVCs to an IP network using native IP protocols.
Faster Routers?
MPLS was originally designed to make IP routers as fast as ATM switches for
handling traffic. It is still commonly believed that MPLS somehow significantly
enhances the forwarding performance of label-switching routers. However, it is
more accurate to say that exact-match lookups, such as those performed by
MPLS and ATM switches, historically have been faster than the longest-match
lookups performed by IP routers. In any case, recent advances in silicon
technology allow ASIC-based route-lookup engines to run just as fast as MPLS or
ATM virtual path identifier/virtual circuit identifier (VPI/VCI) lookup engines, so
MPLS is no longer seen as just a faster way of routing.
Real Value of MPLS Today

The real benefit of MPLS is that it provides a clean separation between routing
(that is, control) and forwarding (that is, moving data). This separation allows the
deployment of a single forwarding algorithmMPLSthat can be used for
multiple services and traffic types. In the future, as ISPs must develop new
revenue-generating services, the MPLS forwarding infrastructure can remain the
same, while new services are built by simply changing the way packets are
assigned to an LSP. For example, packets can be assigned to a label-switched
path based on a combination of the destination subnetwork and application type,
a combination of the source and destination subnetworks, a specific
quality-of-service (QoS) requirement, an IP multicast group, or a virtual private
network (VPN) identifier. In this manner, new services can be migrated easily to
operate over the common MPLS forwarding infrastructure.
52
Benefits of MPLS
IGP-Based Traffic Engineering
Standard IGP routing
IP prefixes are bound to a physical next hop
Typically based on IGP view of shortest path
192.168.1/24
134.112/16
New York
San
Francisco
Figure 4: IGP-Based Traffic Engineering
IGP Routing and Traffic Engineering

The slide shows the basics of traffic engineeringor rather, attempted traffic
engineeringwith only an IGP to adjust in an IP router environment. This sample
network, which forms the basis for a series of slides on the fundamentals of
MPLS, uses only standard routing based on an IGP for now.
Physical Next Hop and IP Prefixes

Note that the IP prefixes are totally bound to a physical next-hop destination. This
next-hop resolution usually is based solely on the IGP shortest path calculation.
That is, only the topology counts when link metrics are used as the basis of
next-hop calculations. Thus, once the San Francisco router determines that the
shortest path to the New York router lies through the router at the top center of the
network, all prefixes associated with New York use this same route. Consider
traffic for 192.168.1/24 and 134.112/16 in this simple example. Traffic to both
destinations is longest-matched to the same physical next hop, regardless of any
consideration of traffic loads on the link, link bandwidth, delay, application needs,
or the amount of traffic on the other links through the networks collection of
routers. Any attempt to adjust the IGP metric to send the traffic for one prefix (for
example, 192.168.1/24) over other links through other routers also causes the
traffic for 134.112/16 to follow right along. This example is more like traffic
structuring than true traffic engineering.
IGP-Based Traffic Engineering
53
MPLS-Based Traffic Engineering
Engineer unidirectional paths through your network without using the IGPs
shortest path calculation
IGP Shortest Path

New York
San
Francisco
JUNOS Traffic Engineered Path
Figure 5: MPLS-Based Traffic Engineering
Unidirectional Paths for Traffic Engineering

Without MPLS, in the traditional Layer 3 forwarding paradigm, as a packet travels
from one router to the next, the router at each hop makes an independent
forwarding decision for every packet. The router analyzes the IP network layer
header and chooses the next hop based on this analysis and on information
contained in the routing table.
In an MPLS-based traffic engineering environment, the router performs the
analysis of the packet header just onceright before the packet enters the
engineered path. Based on this mapping, the router assigns the packet a label,
which is a short, fixed-length value placed at the front of the packet. Routers in the
traffic engineering path use labels as lookup indexes into the label forwarding
table. For each label, this table stores forwarding information, such as the egress
interface and label operation.
An MPLS label-switched path (LSP) is unidirectional. That is, the presence of an
MPLS path from San Francisco to New York in no way implies that a reverse path
from New York to San Francisco exists (although, of course, one might). This
gives the network operations group maximum control over the engineered paths.
The MPLS path exists and is used independently from the IGPs shortest path
considerations and calculations. Thus, traffic for prefixes not included in the MPLS
path are still routed to New York using the IGP shortest path and conventional
longest-match lookups.
54
MPLS-Based Traffic Engineering
MPLS Traffic Engineering Paths
IP prefixes can now be bound to an MPLS path called a label-switched path
192.168.1/24
New York
San
Francisco
134.112/16
Figure 6: MPLS Traffic Engineering Paths
Label-Switched Paths and IP Addresses

Once the MPLS path is established from San Francisco to New York, certain IP
prefixes can be bound to the label-switched path (LSP).
The slide shows that traffic for prefix 192.168.1/24 continues to use the IGP
shortest path to New York while traffic for prefix 134.112/16 is mapped to the LSP.
Such control is not possible with IGP metric manipulation alone.
Note that MPLS supplies a mechanism for sending some traffic to some prefixes
using the MPLS LSP, while traffic to other prefixes continues to use the IGP
metric. But MPLS does not supply the rationale for doing so. Why would an ISP
with an MPLS domain send traffic for 192.168.1/24 to New York one way and
traffic for 134.112/16 to New York another way? MPLS does not know and really
does not care. MPLS is a tool for implementing traffic engineering, but does not
perform traffic engineering itself.
Perhaps the MPLS path for 134.112/16 follows an underutilized series of links to
New York and so has lower delay than traffic sent to 192.168.1/24 in New York,
and the customer using the 134.112/16 address space has paid a premium for
such a lower delay service. Perhaps 134.112/16 traffic lies outside the ISPs
cloud, and the goal is simply to get this transit traffic through the network without
slowing the ISPs own internal traffic flows, such as to 192.168.1/24. Whatever the
case, MPLS supplies the method for traffic engineering, not the reasons behind
traffic engineered paths.
MPLS Traffic Engineering Paths
55
MPLS Terminology
Label-switched path (LSP)
Unidirectional path through network
New York
San
Francisco
Figure 7: MPLS Terminology
MPLS Domains
Just as in any other technology, MPLS has a specialized terminology all its own.
An MPLS domain is the collection of routers running MPLS under the control of a
single administrator.
An LSP (label-switched path) is a one-way (unidirectional) flow of traffic, carrying
packets from beginning to end. Packets must enter the LSP at the beginning
(ingress) of the path, and can only exit the LSP at the end (egress). Packets
cannot be injected into an LSP at an intermediate hop.
Generally, an LSP remains within a single MPLS domain. That is, the entrance
and exit of the LSP, and all routers in between, are ultimately in control of the
same administrative authority. This ensures that MPLS LSP traffic engineering is
not done haphazardly or at cross purposes but is implemented in a coordinated
fashion.
56
MPLS Terminology
Label-Switching Routers
Label-switching router (LSR) performs:
MPLS packet forwarding
LSP setup
All M-series and T-series platforms support LSR capability
Simply called routers in this course
New York
San
Francisco
Figure 8: Label-Switching Routers
MPLS Performed by Label-Switching Routers

Another key MPLS term is the label-switching router (LSR). An LSR understands
and forwards MPLS packets, which flow on, and are part of, an LSP.
In addition, an LSR participates in constructing LSPs for the portion of each LSP
entering and leaving the LSR. For a particular destination, an LSR can be at the
start of an LSP, the end of an LSP, or in the middle of an LSP. An individual router
can perform one, two, or all of these roles as required for various LSPs. However,
a single router cannot be both entrance and exit points for any individual LSP
(why add a label to a packet and take it right off in the same box?).
Router = LSR
This course uses the terms LSR and router interchangeably because all Juniper
Networks M-series and T-series platforms are capable of being LSRs.
Some MPLS documents use the term label edge router (LER) for the LSRs that
stand at the edge, or entrance and exit, of an MPLS domain. This distinction is not
particularly helpful in all but the smallest MPLS domains, and we do not use the
term LER in this course. All routers configured to run MPLS are simply LSRs.
Label-Switching Routers
57
MPLS Router Functions: Ingress
Ingress router
Packets enter LSP at ingress
Also called a head-end router
Upstream from other routers
Performs label push operation
New York
Ingress
San
Francisco
Figure 9: MPLS Router Functions: Ingress
The Functions of the Ingress Router

Each router in an MPLS path performs a specific function and has a well-defined
role based on whether the packet enters, transits, or leaves the router.
At the beginning of the tunnel, the ingress router encapsulates an IP packet that
will use this LSP to New York by adding the 32-bit MPLS shim header and the
appropriate data link layer encapsulation before sending it to the first router in the
path. Only one ingress router in a path can exist, and it is always at the beginning
of the path. All packets using this LSP enter the LSP at the ingress router.
In some MPLS documents, this router is called the head-end router, or the label
edge router (LER) for the LSP. In this course, we call it simply the ingress router
for this LSP.
An ingress router always performs a push function, whereby an MPLS label is
added to the label stack. By definition, the ingress router is upstream from all
other routers on the LSP.
58
MPLS Router Functions: Ingress
MPLS Router Functions: Transit
Transit router
There can be zero or more transit routers
Perform label swap operations
Forward traffic to next hop in LSP
New York
San
Francisco
Transit
LSRs
Figure 10: MPLS Router Functions: Transit
The Functions of the Transit Router

An LSP might have one or more transit routers along the path from ingress router
to egress router. A transit router forwards a received MPLS packet to the next hop
in the MPLS path. Zero or more transit routers in a path can exist. In a fully
meshed collection of routers forming an MPLS domain, because each ingress
router is connected directly to an exit point by definition, every LSP does not need
a transit router to reach the exit point (although transit routers might still be
configured, based on traffic engineering needs).
MPLS processing at each transit point is a simple swap of one MPLS label for
another. In contrast to longest-match routing lookups, the incoming label value
itself can be used as an index to a direct lookup table for MPLS forwarding, but
this is strictly an MPLS protocol implementation decision.
The MPLS protocol enforces a maximum limit of 253 transit routers in a single
path.
MPLS Router Functions: Transit
59
MPLS Router Functions: Penultimate
Penultimate router
Second-to-last router
Normally pops the label stack
Unlabeled packets sent to egress
New York
San
Francisco
Penultimate
Figure 11: MPLS Router Functions: Penultimate
The Function of the Penultimate Router

The second-to-last router in the LSP often is referred to as the penultimate
hopa term that simply means second to the last. In most cases the penultimate
router performs a label pop instead of a label swap operation. This action results
in the egress router receiving an unlabeled packet that then is subjected to a
normal longest-match lookup.
Penultimate hop popping (PHP) facilitates label stacking and can improve
performance on some platforms because it eliminates the need for two lookup
operations on the egress router. M-series and T-series platforms perform equally
well with, or without, PHP. Label stacking makes use of multiple MPLS labels to
construct tunnels within tunnels. In these cases, having the penultimate node pop
the label associated with the outer tunnel assure that downstream nodes will be
unaware of the outer tunnels existence.
PHP behavior is controlled by the egress node by virtue of the label value that it
assigned to the penultimate node during the establishment of the LSP. By
assigning an implicit null label (label 3 for IPv4) PHP behavior is indicated.
Assigning the explicit null label (label 0 for IPv4) indicates that PHP should not be
performed and that the egress node expects to received packets with label 0
attached.
PHP is the default on a Juniper Networks M-series or T-series router. You can
configure M-series and T-series routers to signal ultimate hop popping when
needed to interoperate or accommodate an MPLS EXP-based class-of-service
(CoS) scheme.
60
MPLS Router Functions: Penultimate
MPLS Router Functions: Egress
Egress router
Packets exit LSP at egress
Also called tail-end router
Downstream from other routers
Forwards packets based on IP address
Egress
New York
San
Francisco
Figure 12: MPLS Router Functions: Egress
The Functions of the Egress Router

The final type of router defined in MPLS is the egress router. Packets exit the LSP
at the egress router and revert to normal, IGP-based, next-hop routing outside the
MPLS domain.
At the end of an LSP, the egress router removes the MPLS encapsulation header
and forwards the packet toward its final destination using the normal IP forwarding
table. Only one egress router can exist in a path. In many cases, the use of PHP
eliminates the need for MPLS processing at the egress node.
The egress router is sometimes called the tail-end router, or label edge router
(LER). We do not use these terms in this course. By definition, the egress router is
located downstream from every other router on the LSP.
MPLS Router Functions: Egress
61
MPLS Labels
Assigned manually or by a signaling protocol in each LSR during path setup
Labels change at each segment in path
LSR swaps incoming label with new outgoing label
Labels have local significance
Assigned Manually or by Signaling Protocol

MPLS labels are assigned manually (as in a PVC switching environment) or set
up by a signaling protocol (as in an SVC switching environment) running in each
LSR along the path of the LSP. Once the LSP is set up, the ingress router and all
subsequent routers in the LSP do not examine the IP routing information in the
labeled packetthey use the label to look up information in their label forwarding
tables.
Changing Labels by Segment

Much as with ATM VCIs, MPLS label values change at each segment of the LSP.
A single router can be part of multiple LSPs. It can be the ingress or egress router
for one or more LSPs, and it also can be a transit router of one or more LSPs. The
functions that each router supports depend on the network design.
Label Swapping
The LSRs replace the old label with a new label in a swap operation and then
forward the packet to the next router in the path. When the packet reaches the
LSPs egress point, it is forwarded again based on longest-match IP forwarding.
Local Significance and Labels

There is nothing unique or special about most of the label values used in MPLS.
We say that labels have local significance, meaning that a label value of 10254,
for example, identifies one LSP on one router, and the same value can identify a
different LSP on another router.
62
MPLS Labels
Labeled Packets
MPLS header is prepended to packet with a push operation at ingress node
Label is added immediately after Layer 2 encapsulation header
L2
L2 Header
Header
MPLS Header
IP
IP Packet
Packet
Figure 13: Labeled Packets
Packet is restored at the end of the LSP with a pop operation
Normally the label stack is popped at penultimate node
Labeled Packets
MPLS is responsible for directing a flow of IP packets along a predetermined path
across a network. This path is the LSP, which is similar to an ATM PVC in that it is
unidirectional (or simplex). That is, the traffic flows in one direction from the
ingress router to an egress router. Duplex traffic requires two LSPsthat is, one
path to carry traffic in each direction. An LSP is created by the concatenation of
one or more label-switched hops that direct packets between LSRs to transit the
MPLS domain.
When an IP packet enters a label-switched path, the ingress router examines the
packet and assigns it a label based on its destination, placing a 32-bit (4-byte)
label in front of the packets header immediately after the Layer 2 encapsulation.
The label transforms the packet from one that is forwarded based on IP
addressing to one that is forwarded based on the fixed-length label. The slide
shows an example of a labeled IP packet. Note that MPLS can be used to label
non-IP traffic, such as in the case of a Layer 2 VPN.
MPLS labels can be assigned per interface or per router. JUNOS software
currently assigns MPLS label values on a per-router basis. Thus, a label value of
10234 only can be assigned once by a given Juniper Networks M-series or
T-series platform. Multicast and IPv6 labels are assigned independently of unicast
packet labels. JUNOS software currently does not support labeled multicast or
IPv6, except in the context of a Layer 2 or Layer 3 VPN.
IP Packet Restored at Egress

At egress the IP packet is restored when the MPLS label is removed as part of a
pop operation. The now unlabeled packet is routed based on a longest-match IP
address lookup. In most cases, the penultimate (or second to last) router pops the
label stack in penultimate hop popping. In some cases, a labeled packet is
delivered to the ultimate router (the egress LSR) when the stack is popped, and
the packet is forwarded using conventional IP routing.
Labeled Packets
63
MPLS Shim Header Structure
Label (20 bits)
L2
L2 Header
Header
MPLS Header
CoS S
TTL
IP
IP Packet
Packet
32 bits
Figure 14: MPLS Shim Header Structure
MPLS header consist of four fields
Labelused to associate packet with an LSP
Experimental bitscarry packet queuing priority (CoS)
Stacking bit
Time to livelimits packet lifetime within LSP
In most cases, the IP TTL is copied into the MPLS TTL
Some label values are reserved
The MPLS Header (Label) Structure

The 32-bit MPLS header consists of the following four fields:
64
20-bit label: Identifies the packet to a particular LSP. This value changes as
the packet flows on the LSP from LSR to LSR.
Class of service (experimental): Indicates queuing priority through the

network. This field was initially just the CoS field, but lack of standard
definitions and use led to the current designation of this field as experimental.
In other words, this field was always intended for CoS, but which type of CoS
is still experimental. At each hop along the way, the CoS value determines
which packets receive preferential treatment within the tunnel.
Bottom of stack bit: Indicates whether this MPLS packet has more than one
label associated with it. The MPLS implementation in JUNOS software
supports unlimited label stack depths for transit LSR operations. At ingress up
to three labels can be pushed onto a packet. The bottom of the stack of MPLS
labels is indicated by a 1 bit in this field; a setting of 1 tells the LSR that after
popping the label stack an unlabeled packet will remain.
Time to live: Contains a limit on the number of router hops this MPLS packet
can travel through the network. It is decremented at each hop, and if the TTL
value drops below 1, the packet is discarded. The default behavior is to copy
the value of the IP packet into this field at the ingress router.
Reserved MPLS Label Values

Labels 0 through 15 are reserved according to the procedures outlined in RFC
3032, MPLS Label Stack Encoding.
A value of 0 represents the IPv4 explicit null label. This label value is legal
only when it is the sole label stack entry. It indicates that the label stack must
be popped, and the forwarding of the packet must then be based on the IPv4
header.
A value of 1 represents the router alert label. This label value is legal
anywhere in the label stack except at the bottom. When a received packet
contains this label value at the top of the label stack, it is delivered to a local
software module for processing. The label beneath it in the stack determines
the actual forwarding of the packet. However, if the packet is forwarded
further, the router alert label should be pushed back onto the label stack
before forwarding. The use of this label is analogous to the use of the router
alert option in IP packets. Because this label cannot occur at the bottom of the
stack, it is not associated with a particular network layer protocol. Essentially,
label value 1 gives MPLS modules in different routers a way to communicate
with each other.
A value of 2 represents the IPv6 explicit null label. This label value is legal
only when it is the sole label stack entry. It indicates that the label stack must
be popped, and the forwarding of the packet then must be based on the IPv6
header.
A value of 3 represents the implicit null label. This is a label that an LSR can
assign and distribute, but it never actually appears in the encapsulation.
When an LSR would otherwise replace the label at the top of the stack with a
new label, but the new label is implicit null, the LSR pops the stack instead of
doing the replacement. Although this value might never appear in the
encapsulation, it must be specified in the label signaling protocol, so a value is
reserved.
Values 415 are reserved for future use.
65
MPLS Processing Example: Ingress
An IP packet destined to 134.112.1.5/32 arrives at San Francisco
San Franciscos route to 134.112/16 points to the New York LSP
Ingress node pushes label 1965 onto packet and forwards it down the LSP
owards Santa Fe
134.112/16
IP
New York
134.112.1.5
San
Francisco
1965
1965
IP
1026
Santa Fe
0 = UHP
or
3 = PHP
Miami
Figure 15: MPLS Processing Example: Ingress
Following the 134.112.1.5/32 Packet

Consider the network in the slide as an example of an MPLS domain based on
Juniper Networks M-series and T-series platforms. In this simple network, an LSP
is set up from San Francisco to New York through Santa Fe and Miami for IP
prefix 134.112/16. The LSP is represented by the label values shown for each
LSP segment on the slide. In this example, we see that the link from Miami to New
York can either perform ultimate hop popping (UHP) or penultimate hop popping
(PHP). These concepts are discussed in later slides; for now suffice it to say that
PHP is signaled with the assignment of a label with value 3 while UHP is signaled
with a label assignment of 0.
Ingress Node Pushes a Label

An IP packet destined for one of the 134.122/16 IP prefixes arrives at the San
Francisco router. The ingress node (San Francisco), performs a conventional
longest-match lookup on the IP address. However, due to the activation of MPLS
in this domain, and the presence of an LSP to New York, the next hop associated
with packets destined to 134.122/16 is the LSP to New York.
The ingress LSR assigns an MPLS label, in this case with the value of 1965, to
packets entering the New York LSP. The labeled packet is then sent down the
LSP towards the Santa Fe LSR.
In MPLS terminology the ingress router is said to have pushed a label onto the
packet. Up to three labels can be pushed onto an IP packet at ingress with
M-series platforms. Labels are treated as a last-in, first-out stack. So the last label
pushed onto the packet is the first one popped off the packet. The S bit in the
MPLS shim header is used to support label stacking; the last label has its S bit set
to 1 while all other labels have their S bit set to a 0.
66
MPLS Processing Example: Ingress
MPLS Processing Example: Transit
Santa Fe forwards the packet using the MPLS forwarding table
Transit LSR performs a label swap operation replacing label 1965 with
1026
Packet sent downstream towards Miami
134.112/16
New York
San
Francisco
1026
1965
IP
1026
IP
Santa Fe
Miami
1026
Figure 16: MPLS Processing Example: Transit
Transit Router Processing

Look at what happens when the MPLS data unit (IP packet plus MPLS label)
arrives in at the Santa Fe router. Because the packet arrives with an MPLS label
instead of an IP packet header, and the Santa Fe router is a transit router on the
LSP, the Santa Fe router forwards the packet using its MPLS forwarding table.
The MPLS forwarding table is installed in the PFE using the entries contained in
the mpls.0 routing table. In this case, the arriving label value of 1965 is swapped
(a pop of the old label followed immediately by a push of the new label) for label
value 1026. The MPLS data unit is sent onto the MPLS next hop in Miami, based
on the mpls.0 switching table. Again, a direct link from Santa Fe to Miami must
exist.
MPLS Processing Example: Transit
67
MPLS Processing Example: Egress
Packet arrives at Miami (the penultimate router) with label 1026
Miami performs PHP (typical)
New York (egress router) makes a standard IP forwarding decision
134.112/16
New York
IP
San
Francisco
1026
Label Stack
Popped (PHP)
IP
Santa Fe
Miami
Figure 17: MPLS Processing Example: Egress
Penultimate and Egress Router Processing

At the final hop of the MPLS path, the router forwards the IP packet to New York,
the egress router on this LSP. The packet arrives at the Miami router with an
MPLS label value of 1026. This transit router is special in MPLS due to its direct
attachment to the ultimate or egress router. In MPLS terms, Miami is the
penultimate router on this LSP.
Penultimate Hop Popping

The penultimate router can either pop the label stack, or swap it with a special
label value of 0. Any MPLS router that receives an MPLS data unit with the explicit
null label (label 0) must pop the label and route the packet according to the IGP
routing table entry for that prefix.
Egress Router
Thus, New York, the egress (ultimate) router, either receives an unlabeled packet,
or it pops the MPLS header and makes a regular IP forwarding decision based on
the IP destination address in the packet header. The egress router controls PHP
behavior by choosing to assign either label 0 (do not perform PHP) or the implicit
null label 3 (perform PHP). At this point, the packet has made its way from San
Francisco to New York using the LSP. Sometimes you must be very precise about
where a router stands from downstream egress to upstream ingress. For the sake
of completeness, the following MPLS terms apply to the routers on this LSP:
68
New York is the egress router (the ultimate router on this LSP);
Miami is a transit router (the penultimate);
Santa Fe is a transit router; and
San Francisco is the ingress router.
69
Label Stacking
1) Packet enters
LDP tunnel with
LDP label push
3) Packet leaves
outer tunnel with
RSVP label pop
2) Packet enters
RSVP engineered
core with RSVP
label push
5) Packet leaves
MPLS domain
RSVP LDP
IP
4) Packet
restored with
LDP label pop
PE 1
LDP
IP
IP
LDP
IP
IP
IP
PE 2
Outer Tunnel
(RSVP-signaled LSP)
Inner Tunnel
(LDP-signaled LSP)
Figure 18: Label Stacking
Stacking for Scalability

MPLS supports a tunnels-within-tunnels concept through the use of stacked
labels. This capability is similar to ATMs use of virtual paths (VPs) and virtual
channels (VCs). In essence, label stacking allows an LSR to switch a bundle of
individual LSPs without having to carry state information about the individual
LSPs that comprise the bundle.
The slide shows an example of label stacking based on the concept of tunneling
LDP-signaled LSPs within an RSVP-signaled traffic engineered LSP. The use of
PHP ensures that no router along that path has to perform more than one label
operation on any given packet and keeps the knowledge of the outer tunnel
hidden to its users.
70
Label Stacking
Review Questions
How does MPLS provide traffic engineering?
What label operation is performed by each of the following:
Ingress?
Transit?
Penultimate hop?
Egress?
Does the MPLS shim header support CoS?
What is the benefit of stacked labels, and how might they be used?
The benefits and applications for MPLS;
MPLS-based traffic engineering;
The terms LSR, ingress, egress, and LSP;
Push, pop, and swap label operations;
Penultimate hop popping;
MPLS packet flow and processing from ingress to egress router; and
Label stacking.
Review Questions
71
72
Review Questions
Chapter 3: Module 3: RSVP-Signaled LSPs
Chapter 3
73
Module Objectives
Compare static and signaled LSPs
Describe RSVP path signaling
Describe the function of RSVP hellos, path refresh, and message

aggregation
Configure a simple RSVP-signaled LSP
List operational commands used to monitor RSVP signaling and LSP

status
74
Module Objectives
Static versus signaled (dynamic) LSPs;
RSVP signaling;
RSVP state maintenance;
Signaled LSP configuration; and
Monitoring and troubleshooting signaled LSPs.
RSVP-Signaled LSPs Agenda
Where are we going...
Static versus signaled LSPs
LSP signaling options
RSVP signaling
Configuring RSVP-signaled LSPs
Monitoring and troubleshooting RSVP-signaled LSPs
RSVP-Signaled LSPs Agenda
75
Static LSPs: Pros and Cons
Pros:
No signaling protocol required
Less router resources consumed
Cons:
Manual configuration is prone to error
No keepalive used for operational indications
No protection
Problems show up as black-holed traffic
Static LSPs do not support fast reroute or secondary LSPs
Static LSPs affect internal and external destinations equally
Static LSPs are installed in the main routing table (inet.0)
Engineering to internal destinations might not always be wanted
Static LSP Advantages

When using static LSPs in MPLS, you must configure the ingress, transit (if any),
and egress routers manually. During this process you manually map/assign the
label values used in the various push and swap operations.
Static LSPs consume less router resources. However, the tradeoff is simplicity
versus added functionality gained by using signaled LSPs.
Static LSP Disadvantages

Static LSPs simply have too many drawbacks to allow their use in large-scale
MPLS deployments. The primary problems with static LSPs is their lack of
keepalive indication and their need for complex manual configuration, which is
prone to error. The latter issue is especially painful when coupled with the former
issue, because the lack of operational status makes the fault analysis of
configuration mistakes quite difficult.
This lack of operational status also means that automatic failover onto a backup
LSP is not possible. Finally, there is little operational visibility for the LSP, making
it difficult to tell how many routes are bound to the LSP.
Static LSPs show up as a static route in the main routing table (inet.0). Because
entries in inet.0 are visible to all protocols, and because static LSPs have a low
global preference (making them more preferred), internal and externally destined
traffic might begin using the static LSP as soon as it is defined. This behavior is in
stark contrast to the way dynamic LSPs are installed only in the inet.3 routing
table, where they are only used for BGP next-hop resolution, by default.
76
Static LSPs are prone to human error and can be difficult to troubleshoot because
most problems simply result in a common black-hole symptom, which makes it
difficult to isolate the problem to a particular LSR. Due to these limitations, static
LSPs are not an ideal choice for large-scale MPLS traffic engineering.
77
Static LSP Configuration
Requires manual configuration at ingress and transit nodes
Ingress node: Manually define the destination, label to push, and next hop
Transit nodes: Manually map ingress interface/labels to label operations

(pop or push), and next-hop addresses
Egress node: No explicit configuration for static LSPs needed
Must support mpls family and the MPLS instance on interface
Labels 161023 and 10,00099,999 reserved for statically assigned LSPs
Do not assign the same label more than once on any given chassis!
Manual Configuration
Static LSPs require manual configuration at the ingress, transit (if any), and
egress routers. For the ingress node, you must define the static LSPs destination
address, the egress interface, and the label to be pushed onto the packet. The
configuration of transit nodes entails the mapping of ingress interface and label to
a label operation (swap, pop, swap-push), and an outgoing next-hop/label
combination. Explicit configuration to support a static LSP is normally required at
the egress node because it knows to pop label 0 a priori if PHP behavior is not in
effect. All routers which touch the static LSP in any way must have baseline MPLS
functionality enabled. This baseline functionality enables the transmission and
reception of labeled packets and is needed whether you are deploying static or
signaled LSPs.
Once configured, the static LSP appears in the egress routers inet.0 table as a
static route to the IP address on egress router (with a preference of 5). Note that
the LSP does not appear in the inet.0 routing table of any other routers along
the LSPs path; inet.0 entries on transit and egress routers are completely
useless because a packet can only enter an LSP at the egress node.
Reserved Labels for Static LSPs

JUNOS software reserves the label values 161023 and 10,00099,999 for static
labels; note that you can also assign values above 1023 and below 10,000 (but
not below 16) for static LSPs if needed.
JUNOS software treats MPLS labels as unique on a per-chassis basis. You must
take care to ensure that you do not manually assign the same label more than
once on a given chassis, unless of course, you like to deal with really difficult
troubleshooting scenarios. For example, using the same incoming label on
independent interfaces of a trasit LSR results in a type of LSP merging where the
forwarding table in effect combines the two incoming LSPs and installs both of
their respective next hops into the forwarding table for load balancing!
78
Static LSP Configuration
Static LSP Label Mapping Example
Static LSP from San Francisco to New York
Next hop must point to directly connected neighbor at remote end of each
link
Interface name is allowed for point-to-point interface types
Labels can only be assigned once per chassis!
134.112/16
New York
San
Francisco
202
10.0.5.4
303
10.0.1.2
10.0.3.39
Figure 19: Static LSP Label Mapping Example
Sample Static LSP Configuration

To create a static LSP from San Francisco to New York, you must configure each
router along the LSPs path. You must configure information such as LSR function
(push, pop, or swap), the label values, the incoming interface, and the forwarding
next hop for the packet. The next hop can be an interface name for point-to-point
interfaces or a directly connected IP address; the latter is required for
multi-access interface types. The slide shows the label values that were chosen
for each segment of the static LSP. Note that JUNOS software treats MPLS labels
as unique on a per-chassis basis. You must take care to ensure that you do not
manually assign the same label more than once on a given chassis, unless of
course, you like to deal with really difficult troubleshooting scenarios.
The static LSP configuration for each LSR is shown on the next slide. In addition
to the configuration needed for the static LSP itself, you must be sure to enable
the reception and transmission of labeled packets on each interface that supports
the static LSP, and you must enable the MPLS instance for each such interface.
Static LSP Label Mapping Example
79
Static LSP Configuration Statements

mpls {
static-path inet {
134.112/16 {
next-hop 10.0.1.2;
push 202;
}
}
}
mpls {
{
interface name
label-map 202 {
next-hop 10.0.3.39;
swap 303;
}
}
}
mpls {
interface name {
label-map 303 {
next-hop 10.0.5.4;
swap 0;
}
}
}
134.112/16
New York
San
Francisco
202
10.0.5.4
303
10.0.1.2
10.0.3.39
Note: The mpls family and MPLS instance must also be enabled on each transit interface
Figure 20: Static LSP Configuration Statements
Static LSP Configuration Example

The slide shows the configuration of the static LSP on all LSRs except the egress
node. The next-hop address specifies the interface address of the next router in
the path. Because you manually specify the forwarding information, be careful
when selecting the next hop. If there are parallel paths between any two points,
the next-hop address must specify exactly the correct interface to use. For this
reason, we strongly discourage the use of loopback addresses as next hops.
(Point-to-point interfaces allow an interface name to be used as the next hop.)
Only the ingress router references the IP prefix of 134.112/16. This is an important
point on this slide that we emphasize, as the concept of IP lookup occurring only
at the ingress LSR applies to both signaled and static LSPs. The transit LSRs are
configured to swap a given label on a given ingress interface with the label value
specified. Although not shown, static LSP configuration can be assigned a static
EXP coding (for CoS) and can make use of double/triple label push operations.
The New York router needs no static LSP configuration. All that is required at the
egress node is baseline MPLS functionally consisting of the mpls family and
MPLS instance support for each interface involved in MPSL processing. Note that
this baseline functionality is required at all LSRs. The use of PHP, or the explicit
null label as shown on the slide, ensures that the egress router knows how to
process the packet a priori. Whenever MPLS is enabled on an interface, JUNOS
software automatically adds an entry for the explicit null label into the MPLS
forwarding table for that interface.
80
You must enable baseline MPLS functionality on each LSR, in addition to the
static LSP configuration shown on the slide. Baseline MPLS functionality consists
of adding the mpls family to the logical unit of transit interfaces that handle the
static LSP in addition to enabling the MPLS instance for each such interface at the
[edit protocols mpls] hierarchy.
81
Static LSPs and the Routing Table

Static LSPs are installed in the main routing table on
ingress router:
user@host> show route 134.112/16
inet.0: 1 destination, 1 route (1 active,0 holddown,0 hidden)
+ = Active Route, - = Last Active, * = Both
134.112/16
*[Static/5] 00:00:02
> to 10.0.1.2 via so-3/2/0.0, Push 202
[OSPF/10] 01:01:07, metric 3
> via so-3/2/0.0
Figure 21: Static LSPs and the Routing Table
Static LSPs on the Ingress Router

Use the show route command to view static LSPs. The slide shows how a static
LSP for IP prefix 134.112/16 is installed in the inet.0 routing table on the ingress
router. Note that the static LSP is assigned a default preference value of 5, which
is the same preference as any other static route. The next-hop address and
interface are also listed, but you can tell easily that this is an LSP instead of a
normal IP static route because of the presence of the Push keyword and the
MPLS label value associated with the LSP. The slide shows how the presence of
the static LSP in the inet.0 routing table has eclipsed the existing IGP route to
the same destination. Because the LSP has a lower preference, which makes it
more preferred, traffic to the 134.112/16 prefix will be forwarded over the LSP. In
this example, the static LSP and IGP forwarding next hops are the same. While
this is certainly possible, there is no mandate that LSP forwarding adhere to the
path taken by the IGP. In fact, the whole concept of traffic engineering is about
controlling how data flows across your network independent of the IGPs view of
the optimal path between any two points.
Note that the inet.0 table lists only the next hop for the LSP and not the entire
path to the egress. You must examine the inet.0 table at the ingress node,
along with the mpls.0 table at each transit node to determine the end-to-end path
for a static LSP.
82
Static LSPs and the Routing Table
Static LSPs and the Forwarding Table

Static LSPs use mpls.0 table on transit routers:
user@host> show route table mpls
mpls.0: 4 destinations, 4 routes (4 active,0 holddown,0 hidden)
lab@San_Jose-3> show route table mpls.0
mpls.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
0
1
2
202
*[MPLS/0] 00:16:14, metric 1

Receive
*[MPLS/0] 00:16:14, metric 1
Receive
*[MPLS/0] 00:16:14, metric 1
Receive
*[Static/5] 00:00:09
> to 10.0.3.39 via at-3/1/1.0, swap 303
Figure 22: Static LSPs and the Forwarding Table
Static LSPs on Transit Routers

This slide shows how the mpls.0 forwarding table houses LSP switching
information on transit routers (the entries on the other routers would be similar, but
never identical). Use the show route table mpls command to display this
information.
The fist three entries are the automatically configured entries for MPLS label
values 0, 1, and 2. The static LSP-related information relates to the label 202
entry. For this entry the outgoing interface and next-hop address are listed, along
with the indication that incoming label 202 should be swapped with label 303.
Recall from Module 2 that labels 0 and 2 are the explicit null labels for IPv4 and
IPv6 respectively. Label 1 indicates a packet that must be processed by the
receiving router (router alert). Labels 1, 2, and 3 are automatically added to the
MPLS switching table whenever MPLS is enabled on a router interface.
Static LSPs and the Forwarding Table
83
Summary: Static versus Signaled LSPs
Static LSPs:
Are nailed up
Use manually assigned MPLS labels
Require configuration on ingress and transit routers
Prone to provisioning errors
Installed in the inet.0 table where they are available for all traffic
Signaled LSPs:
Are signaled by RSVP or LDP with dynamic label assignment
Require configuration on ingress router only
Are installed in the inet.3 table for BGP use only
Support operational status indications and advanced features like traffic

protection
Static LSPs
You can configure MPLS using static LSPs or signaled LSPs, or both. However,
there are distinct advantages to using signaled LSPs only.
Static LSPs are essentially nailed up, manually configured PVCs. They must have
manually assigned MPLS label values, and you must make sure that the values
match up across the segments that make up an LSP. Because you must configure
these values on each router along the LSP path from ingress to egress, this task
is not only labor intensive but prone to human error and scaling issues.
Static LSPs are installed in the main routing table (inet.0) where they can be
used to forward all types of traffic.
Signaled LSPs
In contrast, signaled LSPs are established with the aid of signaling protocols like
RSVP or LDP. Signaled LSPs use dynamically assigned MPLS labels, and you
only have to explicitly configure signaled LSPs on the ingress router!
Signaled LSPs are installed in the a special routing table (inet.3) where they are
only used for the resolution of BGP next hops, by default. Subsequent chapters
detail MPLS and routing table integration.
84
While the advantages of signaled LSPs are legion, perhaps the most important
advantage is the their inherent keepalive functionality that allows the LSPs
operational status to be accurately and easily ascertained. Armed with this
knowledge, you can configure signaled LSPs to failover to secondary paths or to
make use of advanced traffic protection features like fast reroute or link bypass.
The added visibility associated with signaled LSPs also makes it easy to
determine exactly how a signaled LSP has been routed and how many routes are
currently bound to the LSP.
85
Configured at ingress router only
Signaling protocol established required state in transit and egress routers

automatically
Path through network chosen at each hop using routing table, by default
RSVP allows specification of transit points
Strictmust visit directly connected node
Loosemust visit node, routed according to IGP (routing table)
Configured at Ingress Router Only

Once you have struggled with the labors of manual LSP configuration, you can
really appreciate the fact that a signaled LSP requires explicit configuration at the
ingress LSR only. Once you have told the ingress node what is wants, the
signaling protocol gets to work and establishes the required LSPs state in the
transit and egress routers that makes up the LSPs path. This behavior and the
need to configure at the ingress node only are quite similar to legacy virtual circuit
technologies like X.25, Frame Relay, or even ATM.
Controlling the Path of a Signaled LSP

But how does the ingress router know which routers should be involved in the
LSPs path? In the most basic case, the path through the network can be chosen
at each hop by just looking in the routing table. This behavior is possible because
the collection of routers comprising the MPLS domain run an IGP that provides
routing to internal destinations.
You can achieve true MPLS traffic engineering by adding additional conditions to
this lookup process. One such approach makes use of explicit route objects
(EROs). EROs are covered in a later module in this course. For now suffice it to
say that there are two types of EROs, strict and loose:
Strict EROs must point to a directly connected downstream router.
Loose EROs identify LSRs that are not necessarily directly connected. A
loose ERO relies on the underlying IGP to route between loose transit points.
Other path control mechanisms, like constrained shortest path first (CSPF), are
beyond the scope of this course.
86
LSP Signaling Options
JUNOS software uses RSVP for traffic engineering
Internet standard for reserving resources
Extended to support:
Explicit path configuration
Path numbering
Route recording
Provides keepalive status for:
Visibility
Redundancy
JUNOS software also supports LDP signaling
LDP does not support engineered paths
LSP Signaling Protocol Options

A signaled LSP is unusable until it is actually established by the signaling
component. The signaling component, which is responsible for establishing LSPs
and label distribution, relies on a signaling protocol such as the Resource
Reservation Protocol (RSVP) or the Label Distribution Protocol (LDP).
JUNOS software uses RSVP as the primary signaling protocol for the following
several reasons:
RSVP was designed to be the resource reservation protocol of the Internet

and provide a general facility for creating and maintaining distributed
reservation state across a set of multicast or unicast delivery paths (RFC
2205). Reservations are an important part of traffic engineering, so it made
sense to continue to use RSVP for this purpose rather than reinventing the
wheel.
RSVP was explicitly designed to support extensibility mechanisms by allowing

it to carry what are called opaque objects. Opaque objects make no real
sense to RSVP itself but are carried with the understanding that some adjunct
protocol (such as MPLS) might find the information in these objects useful.
This encourages RSVP extensions that create and maintain distributed state
for information other than pure resource reservation. The designers believed
that extensions could be developed easily to add support for explicit routes
and label distribution.
With the proper extensions, RSVP provides a tool that consolidates the
procedures for a number of critical signaling tasks into a single message
exchange:
87
Extended RSVP can establish an LSP along an explicit path that would
not have been chosen by the IGP;
Extended RSVP can distribute label-binding information to LSRs in the

LSP;
Extended RSVP can reserve network resources in nodes comprising the

LSP (the traditional role of RSVP); and
Extended RSVP permits an LSP to be established to carry best-effort

traffic without making a specific resource reservation.
Thus, RSVP provides MPLS-signaled LSPs with a method of support for explicit
routes (go here, then here, finally here), path numbering through label
assignment, and route recording (where the LSP actually goes from ingress to
egress, which is very handy information to have).
RSVP also gives MPLS LSPs a keepalive mechanism to use for visibility (this
LSP is still here and available) and redundancy (this LSP appears deadis
there a secondary path configured?).
JUNOS Software Support for LDP Signaling

LDP supports a set of destinations (that is, route prefixes and router addresses)
with each data link layer LSP. This set of destinations is called the forward
equivalence class (FEC). These destinations all share a common data LSP path
egress and a common unicast routing path. The LDP signaling protocol always
establishes LSPs that follow the contours of the IGPs shortest path. Traffic
engineering is not possible with LDP.
88
Extensions do not make the enhanced version of RSVP incompatible with

existing RSVP implementations. An RSVP implementation can differentiate
between LSP signaling and standard RSVP reservations by examining the
contents of each message.
RSVP Signaling
Background
RSVP path signaling
Extended RSVP
MPLS extensions to RSVP
RSVP Signaling
89
RSVP Background
RSVP:
A generic QoS signaling protocol
An Internet control protocoluses IP as its network layer
Designed originally for host-to-host usage
Not a data transport protocol
Not a routing protocol
Uses the IGP to determine paths
Defined in RFC 2205
RSVP Background
The Resource Reservation Protocol (RSVP) is a generic signaling protocol
designed originally to be used by applications to request and reserve specific
quality-of-service (QoS) requirements across an internetwork. Resources are
reserved hop by hop across the internetwork; each router receives the resource
reservation request, establishes and maintains the necessary state for the data
flow (if the requested resources are available), and forwards the resource
reservation request to the next router along the path. As this behavior implies,
RSVP is an internetwork control protocol, similar to ICMP, IGMP, and routing
protocols.
RSVP does not transport application data, nor is it a routing protocol. It is simply a
signaling protocol. RSVP uses unicast and multicast IGP routing protocols to
discover paths through the internetwork by consulting existing routing tables.
RFC 2205
The current document describing RSVP is RFC 2205, Resource Reservation
Protocol (RSVP)Version 1 Functional Specification.
90
RSVP Background
Basic RSVP Path Signaling
Simplex flows
Ingress router initiates connection
Soft state
Path and resources are maintained dynamically
Can change during the life of the RSVP session
Path message sent downstream
Reservation message sent upstream
Ingress
Path State
Egress
PATH
Sender
Resv State
Path State
PATH
Router
RESV
Resv State
Path State
PATH
Router
RESV
Resv State
Path State
Receiver
RESV
Resv State
Figure 23: Basic RSVP Path Signaling
LSP established after path and resv messages are exchanged between
ingress and egress nodes
RSVP Data Flows

RSVP requests resources for unidirectional (simplex) data flows. Each reservation
is made for a data flow from a specific sender to a specific receiver. While RSVP
messages are exchanged between the sender and receiver, the resulting path
itself is unidirectional.
Although the application data flow is from the sender to the receiver, the
reservation itself is initiated by the receiver. The sender notifies the receiver of a
pending flow and characterizes the flow, and the receiver is responsible for
requesting the resources. This design choice was made to accommodate
heterogeneous receiver requirements and for multicast flows in which multiple
receivers join and leave a multicast group.
RSVP Is a Soft State Protocol

RSVP requests made to routers along the transit path cause each router either to
reject the request for lack of resources or establish a soft state. This is in contrast
to a hard state, which is associated with virtual connections that remain
established for the duration of the data transfer. Soft state means that the logical
path set up by RSVP is not associated necessarily with a physical path through
the internetwork. The logical path might change during its lifetime as the result of
the senders changing the characterization of the traffic, causing the receiver to
modify its reservation request, or causing the failure of a transit router.
91
Refreshing the soft state periodically maintains it. In standard RSVP

implementations, sending path (downstream) and reservation (upstream)
messages along the path accomplishes this refreshing. JUNOS software also
uses the hello extension to maintain state and detect node failures; by default,
hello messages are sent every three seconds. The hello protocol can detect state
changes within seconds, instead of several minutes as with standard RSVP
implementations. The hello protocol is fully backward-compatible with older RSVP
implementations. If a neighboring node does not support hello messages, JUNOS
software RSVP uses standard soft-state procedures.
Note that path messages are sent all the way to the egress before they trigger the
generation of a reservation message in the upstream direction. Messages are not
paired in time on the link.
92
More RSVP Message Types
Other RSVP messages
PathTear
ResvTear
Sent to ingress router
ResvErr
Sent to ingress router
PathErr
Sent to egress router
ResvConf
RSVP Message Types

In addition to the fundamental path and reservation messages, RSVP includes
several other message types that have specific uses:
Path teardown (PathTear) messages delete the path state from nodes that
receive them. The sender, or a node whose path state has timed out,
originates the path teardown message. It always travels downstream toward
the receiver.
Reservation teardown (ResvTear) messages delete the reservation state from

nodes that receive them. The receiver or a node whose reservation state has
timed out originates the reservation teardown message. It always travels
upstream toward the sender.
Path error messages (PathErr) report errors in processing path messages

and travel upstream to the sender along the reverse route as the path
messages. Path error messages only report errors; they do not modify the
path state of any node they pass through.
Reservation error (ResvErr) messages report errors in the processing of

reservation messages and travel hop by hop downstream to the receiver. Like
path error messages, reservation error messages only report errors and do
not modify the reservation state of any node they pass through.
Reservation confirmation (ResvConf) messages are sent by each node in the

path to the receiver if the receiver requests a reservation confirmation in its
reservation message.
More RSVP Message Types
93
Extended RSVP
Extensions added to support establishment and maintenance of LSPs
Hello protocol
Label distribution
RSVP is now used now for router-to-router connectivity
Traffic Engineering Extensions to RSVP

RSVP has been extended in several ways to support the establishment and
maintenance of MPLS LSPs. For example, a hello mechanism has been added to
RSVP to speed up node-to-node failure detection, and a label object has been
added so that RSVP can signal label bindings.
Now Positioned as a Router Signaling Protocol

Extended RSVP is well suited as a router-to-router signaling protocol. Recall that
in its original form RSVP was intended as a host-to-host signaling protocol. This
change in signaling role makes ongoing sense as RSVP becomes the signaling
protocol of choice for MPLS traffic engineering.
We discuss RSVP extensions in support of traffic engineering in subsequent
pages.
94
Extended RSVP
MPLS Extensions to RSVP
Path and reservation message objects
Explicit route object (ERO)
Label request object
Label object
Record route object
Session attribute object
Tspec object
RSVP Message Objects

The way that RSVP is extended for support of MPLS LSPs and traffic engineering
includes not only a change in role for RSVP to router-to-router signaling, but
entirely new message content (called objects in RSVP) for MPLS signaling. These
objects are included in the exchange of the path and reservation messages as
they thread their way back and forth from ingress router to egress router in the
MPLS domain. These MPLS objects are:
Explicit route object (ERO): Used to tell downstream routers how to set up the
LSP to the destination. The ERO can be either strict or loose.
Label request object: Used to request a label on a segment from the

downstream router in the downstream path message.
Label object: Used to report the label value chosen in the reservation
message sent to the upstream router.
Record route object: Used to record the actual sequence of routers and IP
addresses that the LSP uses to reach the destination.
Session attribute object: Used to carry the control information for the LSP as it
is set up as well as the name for the LSP.
Tspec object: Adapted to carry the details of the LSP for link management.
The role of each of these objects is very important in MPLS. We detail each object
in the following series of slides.
MPLS Extensions to RSVP
95
ERO:
Adds a routing constraint to the LSPs path
Allows the path to deviate from the IGPs shortest path
Used to engineer traffic
Without EROs, the LSP is routed according to the IGPs shortest path
Explicit Route Objects for Traffic Engineering

The use of explicit route objects (EROs) allows you to force the RSVP-signaled
LSP to visit certain nodes along its path to the egress router. The lack of ERO
support in the LDP protocol means that you cannot truly traffic engineer LDP
paths; the paths always follow the same contour as the IGPs view of the
least-cost path.
We cover ERO types and their use in detail in a subsequent chapter. Note that the
result of CSPF calculation is a complete list of EROs that define the LSP path
from ingress to egress.
96
Label Objects
Label request object
Added to path message at ingress LSR
Requests that each LSR provide label to upstream LSR
Label object
Carried in reservation messages along return path upstream
Provides label to upstream LSR
Requesting Labels
The ingress LSR can add the label request object to the path message to request
that intermediate routers provide a label binding for the path. The object provides
an indication of the network layer protocol to be carried over the path, permitting
non-IP network layer protocols to be sent down the path. When a path message
containing a label request object arrives at an LSR, the LSR allocates a label and
stores it as part of the path state. When the corresponding reservation message
arrives, the label is placed in its label object. (Path messages flow all the way
downstream from ingress to egress before being turned around and flowing
upstream as reservation messages.)
Assigning Labels
The label object is carried in reservation messages sent upstream from egress to
ingress. The label object carries a label value, and when an LSR receives a
reservation message, it uses the label value as the outgoing label value
associated with the sender. The LSR allocates a new label value or uses the label
value allocated and stored in the path state information as a result of the label
request object that passed through earlier, and it places this label value in the
label object of the reservation message to be sent to the next upstream hop. In
this way, the label object supports the distribution of labels from downstream
nodes to upstream nodes.
Label Objects
97
The Record Route Object
RRO in path messages:
Ingress LSR adds to path message
Adds outgoing IP address of each hop in the path
In downstream direction
Loop detected
Sends routing problem, loop detected path error message
Drops path message
RRO in resv messages:
Egress LSR adds to reservation message
Adds outgoing IP address of each hop in the path
In upstream direction
Loop detected
Sends routing problem, loop detected reservation error message
Drops reservation message
Record Route ObjectDownstream via Path Message

Both path and reservation messages can make use of the record route object
(RRO) during LSP establishment. When the RRO is present in a path message,
each node along the downstream path to the egress LSR records its outgoing IP
address in the RRO.
RROs are intended to provide a loop detection mechanism for LSPs. If the RRO
finds itself recording the same IP address over again, this indicates that the path
message itself is looping in the network. Naturally, a looping LSP set up with such
a sequence of MPLS routers is not a good thing. Thus, if the RRO detects a loop,
it sends a routing problem, loop detected path error message to the ingress LSR
and drops the path message. Recovery from such an error is up to the ingress
router, which typically resignals the LSP every 30 seconds.
The RRO provides useful troubleshooting information in that you do not have to
guess about the exact routing of the LSP and the specific nodes that it crosses.
The information contained in the RRO is available at all points along the LSP path.
Record Route ObjectUpstream via Reservation Message

The egress router can add the record route object to the reservation message to
allow the sender to receive information about the path that the LSP traverses.
98
In contrast to the RRO in the path message, each node along the upstream path
to the ingress router records its outgoing IP address in the RRO (so when the
process is complete, full IP address information about the LSP is available at the
ingress router).
RROs used in reservation messages provide the same loop detection mechanism
for LSPs as the RRO used in the path message.
Generally speaking, the reservation message follows the same path as the path
message, as each router must return the reservation to the previous next hop
associated with the path state block.
99
Session Attribute Object
Session attribute object:
Ingress router adds to path message
Controls LSP
Priority
Preemption
Fast reroute
Identifies session
ASCII character string for LSP name

The ingress router can add the session attribute object (SAO) to the path
message. This object is used to signal the LSPs priority, preemption, and desire
for fast-reroute protection. We do not discuss the details of these specific features
in this course.
The session attribute object also caries an ASCII string used to identify the
session name associated with each LSP. The string can be up to 32 characters
long and is coded with the lsp-session-name that is specified when
configuring a label-switched-path at the [edit protocols mpls]
hierarchy.
100
Tspec Object
Contains link management configuration
Requested bandwidth
Minimum and maximum LSP packet size
Tspec Object
The Tspec object is not unique to MPLS. In RSVP, the Tspec object carries all the
link management information necessary to handle the resource reservations
needed. Thus, the Tspec object is essential for MPLS traffic engineering because
this is how resource requirements are communicated along the LSP set up with
RSVP.
The Tspec allows RSVP to indicate requested bandwidth as well as the minimum
and maximum LSP packet size to be used over the LSP. Routers can use this
information to determine if they have the resources available to grant to the new
LSP. If the resources are not available, the LSP is not set up.
Resource reservations are not service guarantees. In other words, a request for
100 Mbps of bandwidth for an LSP does not subtract 100 Mbps of bandwidth from
a link and dedicate this bandwidth to the LSP. Bandwidth reservations are used to
determine only if the LSP can be set up and do not imply any performance
guarantees on the network. Put another way, RSVP is only the messenger, it does
not provide any policing functions on the LSPs that it signals.
Tspec Object
101
RSVP Neighbor and Path Maintenance
Adjacency maintenance
102
Hello extension
Path maintenance
Message aggregation
RSVP Neighbor and Path Maintenance
Adjacency Maintenance
RSVP extension defines a hello mechanism
Hello message
Hello request message
Hello acknowledge message
Provides rapid node-to-node failure detection
Asynchronous updates
9-second default update timer
63-second default dead timer
[edit protocols rsvp interface interface-name]

user@host# set hello-interval seconds
Establishing an RSVP Adjacency

Once an LSP is established, there might be long periods of time when little to no
traffic flows on the LSP (for example, late nights and weekends). But for traffic
engineering purposes, some method should exist for verifying the continued
connectivity of the LSP from ingress to egress routers. Rather than build such
mechanisms into MPLS, the decision was made to put such adjacency
maintenance into RSVP. Path maintenance is, after all, a function associated with
the signaling plane.
JUNOS software hello support is optional and is backward compatible with RSVP
implementations that do not support hello messages.
Rapid Node-to-Node Failure Detection

The soft state of RSVP reservations makes end-to-end failure detection relatively
slow (as long as 2.6 minutes with default settings). The new hello protocol allows
you to reduce this time to tens of seconds.
The hello mechanism allows for rapid node-to-node (router-to-router) LSP failure
detection. The updates are asynchronous, meaning the time intervals used by the
hellos can be varied from link to link. The default intervals are 9 seconds for the
update timer (interval to send hellos) with a neighbor being declared down after
the loss of 2 x keep-multiplier + 1 consecutive hello packets. The default value for
the keep-multiplier is also 3.
You can modify the default hello interval with a set hello-interval
seconds command at the [edit protocols rsvp interface
interface-name] hierarchy. A setting of 0 disables hello exchanges on a
given interface; the valid range for the hello-interval is 0 through 60
inclusive.
You should configure the hello-interval and keep-multiplier to balance
protocol overhead against the need to rapidly detect neighbor failures.
Adjacency Maintenance
103
Path Maintenance
Periodic state refresh maintains path state:
Maintains reservation of each LSP
Path/resv refresh sent every 45 seconds, by default
Configured refresh time x 1.5
Operates node to node, not end to end
Refresh timer is configurable

[edit protocols rsvp]
user@host# set refresh-time seconds
Refresh timer works with the keep-multiplier to determine when LSP

state is aged out
Approximately 2.6 minutes with default parameters
Path Refresh
Conventional RSVP uses path and reservation refresh messages to maintain the
resource reservations on the LSP. By default, JUNOS software sends RSVP
refresh messages every 45 seconds. You can change this interval as needed;
normally you increase the refresh interval when all nodes also support the hello
extension because the hello protocol will detect path failures before the RSVP
refresh mechanism does anyway. Path maintenance exchanges consist of path
and reservation messages that essentially renew the LSP on a
segment-by-segment basis.
In contrast to the path and reservation messages used to establish an LSP,
refresh messages are exchanged between adjacent nodes only; end-to-end
signaling is not necessary for path maintenance.
All interfaces use a single refresh timer, but the timers are independent in each
router. You can change the refresh message interval with a set refresh-time
seconds command issued at the [edit protocols rsvp] hierarchy. Refresh
messages are sent based on the configured refresh time multiplied by 1.5. The
result is that a default 30-second refresh timer yields refresh messages every 45
seconds.
Valid refresh values range from 1 through 65535. Use the formula lifetime =
(keep-multiplier + 0.5) x (1.5 x refresh time) to determine when an LSPs state is
no longer valid. You can change the keep-multiplier value from its default
value of 3 with a set keep-multiplier value command entered at the [edit
protocols rsvp] hierarchy.
When plugged into the above formula, the default keep-multiplier value of 3
combined with the default 30-second refresh-time results in path failure
detection in approximately 157 seconds or 2.6 minutes:
(3 + 0.5) x (1.5 x 30) = 3.05 x 45 = 157.5
104
Path Maintenance
RSVP Message Aggregation
Message aggregation:
Bundles up to 30 RSVP messages within single PDU
Controls
Flooding of path teardown or path error messages
Periodic refresh messages (path and reservation)
Enhances protocol efficiency and reliability
Aggregation is disabled, by default
Enabled on a per-interface basis

[edit protocols rsvp interface interface-name]
user@host# set aggregate
Aggregation of RSVP Messages

Naturally, when many LSPs pass through a given router, the overhead generated
by all the path and reservation refresh message exchanges can be considerable.
The same is true of many other types of RSVP messages that must be generated
when a link or router fails. To cut down on all this hop-by-hop overhead, RSVP
allows for message aggregation. With aggregation, RSVP can bundle up to 30
RSVP messages into a single RSVP data unit.
This feature significantly reduces the overhead and protocol traffic associated with
the flooding of path teardown and path error messages, the periodic refresh
message pairs (path and reservation), and the hello protocol. Thus, message
aggregation enhances the efficiency and reliability of the RSVP protocol.
By default, RSVP message aggregation is disabled. It is enabled on an
interface-by-interface basis. You enable RSVP message aggregation with the set
aggregate command at the [edit protocols rsvp interface
interface-name] hierarchy. As with the hello protocol, RSVP aggregation is
backwards compatible with RSVP implementations that do not support the option.
RSVP Message Aggregation
105
RSVP Signaling Example: Path
RSVP sets up path from San Francisco to New York
Seattle
San
Francisco
(Ingress)
Path
New York
(Egress)
Path
Path
Miami
Figure 24: RSVP Signaling Example: Path
Signaled Path from San Francisco to New York

Before you can use an MPLS LSP, the path must be established between the
ingress router (San Francisco in this example) and the egress router (New York in
this example).
The RSVP signaling protocol establishes the path through each router and can
reserve bandwidth along the path when wanted. The RSVP path message flows
from the ingress router to the egress router. The receipt of the path messages
causes the egress router to return a reservation message, which flows back to the
ingress router setting up the LSP from end to end.
The routing of the path message can be controlled. In this example, you can
assume that the RSVP-signaled LSP will follow the IGPs shortest path between
the ingress and egress nodes.
106
RSVP Signaling Example: Path
RSVP Signaling Example: Reservation
The resv message visits each router on the path in reverse order
Labels assigned hop to hop in the upstream direction
Seattle
San
Francisco
(Ingress)
1000
00
RES
V
3
100232
RESV
RES
V
New York
(Egress)
Miami
LSP Established!
Figure 25: RSVP Signaling Example: Reservation
Returning a Reservation Establishes LSP State

As the path message makes it way to the egress router (essentially verifying
connectivity from ingress to egress routers), each node allocates the label that it
plans to assign to its upstream neighbor. Labels are actually assigned for each
LSP segment as the reservation message makes its way from the egress node to
the ingress node. In effect, the downstream router tells the upstream router what
label value it expects to see for traffic associated with this LSP.
In this example, the egress router (New York) assigns Label 3 to the last leg of the
path. Label 3 is a reserved label that tells Miami, which functions as the
penultimate router in this example, to pop the MPLS header from the packet and
send the resulting IP packet to New York. Label 3 never appears in an MPLS
header or in the mpls.0 table, hence the name implicit null. Put another way, the
egress node has signaled a desire for penultimate hop popping (PHP) by virtue of
its assigning label 3 to the penultimate LSR. PHP is the default behavior for
JUNOS software as it helps to support label stacking and can reduce the
processing burden of the egress router.
The slide goes on to show how the penultimate node assigns label value 100232
to its upstream neighbor, who in turn assigns label 100000 to the ingress node.
The LSP is officially established once an associated label has been assigned on
each LSP segment.
RSVP Signaling Example: Reservation
107
Configuring RSVP-Signaled LSPs
108
Configuring RSVP-Signaled LSPs
Baseline MPLS instance and interface support
Configuring RSVP
Defining a signaled LSP
Configuring Baseline MPLS Functionality
Add labeled packet support on interfaces
Add the mpls family to each logical interface you intend to use for MPLS
edit interfaces]
user@host# set interface-name unit unit family mpls
Configure the MPLS instance on the router
List each MPLS-enabled interface, or use the all keyword
Remember to disable routers out-of-band interface when using

interface all
[edit protocols]
user@host# set mpls interface all
[edit protocols]
user@host# set mpls interface fxp0 disable
MPLS instance automatically installs labels 0, 1, and 2 into the mpls.0

switching table
Enabling Labeled Packets on Interfaces

To enable MPLS on a Juniper Networks M-series or T-series platform, you must
add the mpls family on each logical interfaces expected to handle labeled traffic.
An interface is not listed in the output of a show mpls interface command if
the mpls family is not present. Be sure to add the family to the correct logical unit.
Configuring the MPLS Instance

You must also configure an MPLS instance within the router so that labeled traffic
can be processed approximately. This instance must reference each interfaces
expected to handle labeled traffic. Use the set mpls interface all
statement at the [edit protocols] hierarchy to enable the MPLS instance for
all interfaces with the mpls family. For added control you can also list each
interface explicitly, making sure that you specify any nondefault logical unit
numbers that might be in use. When using the interface all shortcut, we
recommend that you explicitly disable the routers out-of-band interface, even if
the mpls family has not been added to the fxp0 interface.
Note that the baseline MPLS configuration does nothing more than enable the
MPLS software on the specified interfaces and on the router. This configuration
alone does not establish any LSPs, but it does make this router capable of acting
as a transit LSR for a static LSP. We cover configuring the RSVP signaling
protocol on a subsequent page. When the mpls family and MPLS instance are
properly configured, the interface is listed in the output of a show mpls
interface command:
user@host> show mpls interface
Interface
State
Administrative groups
at-0/1/0.100
Up
<none>
so-0/2/0.0
Up
<none>
ge-0/3/0.0
Up
<none>
Configuring Baseline MPLS Functionality
109
Configuring RSVP
To configure RSVP:
Enable RSVP on all interfaces

user@host# set protocols rsvp interface all
If wanted, enable/disable RSVP-specific interfaces
user@host# set interface fxp0 disable
Limit percentage of interface bandwidth reservable by RSVP

user@host# set interface so-1/2/3 percentage range
Configure interface or logical unit bandwidth

user@host# set interface so-1/2/3.2 bandwidth value
Configuring RSVP
RSVP is disabled by default in JUNOS software. To configure RSVP, issue
statements at the [edit protocols rsvp] hierarchy level of the configuration.
To enable RSVP on all interfaces, issue a set protocols rsvp interface
all command at the [edit] hierarchy. When using the interface all
declaration, you might want to explicitly disable RSVP on one or more specific
interfaces with a set interface interface-name disable statement. It is
common to see RSVP disabled on the routers fxp0 out-of-band management
interface, for example.
By default, an RSVP interface allows 100% of its physical bandwidth to be
reserved by LSPs. You can use the percentage keyword in association with an
interface name to enable underbooking or overbooking of the interfaces
bandwidth. Use the bandwidth command to configure the reservable bandwidth
associated with an interfaces logical units. Adjusting bandwidth allows you to
control the amount of RSVP bandwidth that is reservable on a logical unit, as
opposed to the physical device, by making the logical interface appear to have
more or less bandwidth than the physical device itself.
Adding RSVP to the MPLS baseline configuration allows the router to function as
a transit or egress LSR in support of RSVP-signaled LSPs. Additional
configuration is needed for the router to function as an ingress LSR. We detail this
configuration on a subsequent page.
110
Configuring RSVP
Add RSVP Authentication
RSVP exchanges can be authenticated on a

per-interface basis
Control plane authentication is current best practice
Configuration example:
user@host# set interface fe-0/0/0 authentication-key test
user@host# show
interface fe-0/0/0.0 {
authentication-key "$9$uh0c0EyMWxdwgX7"; # SECRET-DATA
}
Authentication Support
You can authenticate RSVP protocol exchanges on a per-interface basis. Adding
authentication helps to ensure that only trusted neighbors participate in setting up
reservations. By default, RSVP authentication is disabled.
RSVP uses HMAC-MD5 authentication, which is defined in RFC 2104, HMAC:
Keyed-Hashing for Message Authentication. This scheme produces a message
digest (similar to a cyclical redundancy check (CRC) used for error detection with
a data link layer frame) based on a secret authentication key and the message
contents. (The message contents also includes a sequence number that guards
against replay attacks.) The computed digest is transmitted with along with the
RSVP messages. After you configure authentication on an interface, all received
and transmitted RSVP messages require authentication. All routers connected to
the same IP subnet must use the same authentication scheme and password.
MD5 authentication also provides protection against forgery and message
modification. However, it does not provide confidentiality because all messages
are sent in clear text. Thus, it does not prevent replay attacks.
Configuration Example
The slide shows the configuration syntax used to enable RSVP message
authentication on the routers fe-0/0/0 interface using a key value of test. The
authentication key can be up to 16 contiguous digits or letters. Separate decimal
digits with periods. Separate hexadecimal digits with periods and precede the
string with 0x. If you include spaces in the password, enclose the entire password
in quotation marks ( ).
Add RSVP Authentication
111
Minimal LSP Configuration Example
Configure a signaled LSP from San Francisco to Miami that follows the IGPs
shortest path
This configuration is required on ingress router only
CSPF is disabled to avoid the need for a traffic engineering database

[edit protocols]
lab@San_Jose-3# show mpls
label-switched-path to-miami {
to 192.168.5.1;
no-cspf;
}
Defining a Basic LSP

This slide shows a basic MPLS configuration for an ingress node. This example
sets up a signaled LSP called to-miami that terminates at the router with a host
ID of 192.168.5.1. Normally, LSPs are built to a routers loopback address for
maximum stability.
A signaled LSP requires configuration on the ingress router only. RSVP takes
care of all the details associated with establishing LSP state in transit and egress
nodes.
The example on the slide configures an LSP that follows the IGPs preferred path.
With a few additions, you can expand this statement to include loose or strict
routing in the form of named paths and EROs. The no-cspf statement disables
the default behavior of online path computation using the contents of a traffic
engineering database (TED) and the constrained shortest path first (CSPF)
algorithm.
Note that a TED is built with extensions to the IGP. OSPF requires explicit
configuration for traffic engineering support to use these extensions, while the
IS-IS protocol builds a TED by default. By disabling CSPF you ensure that the
absence of a TED will not adversely affect the establishment of your LSP.
CSPF provides capabilities similar to the ATM Forums Private
Network-to-Network Interface (PNNI) signaling protocol. A complete treatment of
CSPF and the TED are beyond the scope of this course.
112
Minimal LSP Configuration Example
Adding a Bandwidth Reservation
LSP setup fails if any router/link cannot reserve the requested bandwidth
Example below requires that 15 Mbps of bandwidth be reservable on all

egress interfaces that service the LSP
[edit protocols]
user@host# show mpls
to 192.168.5.1;
bandwidth 15m;
no-cspf;
}

This example on the slide shows a modified configuration that instructs RSVP to
reserve bandwidth along the LSPs path. If the path message encounters a router
that cannot honor the bandwidth request, the LSP fails and the ingress node tries
again in 30 seconds (by default). The use of CSPF in conjunction with a TED
ensures that a path with sufficient bandwidth is available in the network before the
ingress router even attempts to signal the LSP.
113
RSVP Monitoring and Troubleshooting
114
JUNOS software RSVP monitoring commands:
show rsvp interface
show rsvp neighbor
show rsvp session
show mpls lsp
Clearing LSPs
RSVP tracing
RSVP Monitoring and Troubleshooting
Displaying RSVP Interface Information
The show rsvp interface command lists interfaces configured to run

RSVP
Interface bandwidth, reservable bandwidth, high-water mark, etc.
Adding the detail switch provides RSVP messages statistics
user@host> show rsvp interface

RSVP interface: 3 active
Active Subscr- Static
Available
Reserved
Highwater
Interface
State resv
iption BW
BW
BW
mark
at-0/1/0.100Up
0
100% 1Mbps
1Mbps
0bps
0bps
ge-0/3/0.0 Up
0
100% 1000Mbps
1000Mbps
0bps
0bps
so-0/2/0.0 Up
0
100% 155.52Mbps 155.52Mbps 0bps
0bps

The show rsvp interface command provides useful information about the
interfaces configured to run RSVP, the number of reservations currently on those
interfaces, and the amount of bandwidth that has been reserved as well as the
amount that is still reservable. In this example, we configured unit 100 on the
at-0/1/0 interface with a static bandwidth value of 1Mbps, while we left the
RSVP reservation percentage at the default 100%. This technique we used limits
the amount of RSVP bandwidth that is reservable on a per-logical unit basis.
The show mpls interface command often yields invaluable clues as to why
you cannot establish an LSP. For example, it is possible to enable RSVP on an
interface that is not enabled for MPLS operation. Such an interface will be listed in
the show rsvp interface command but will be absent in the output of a show
mpls interface command. In almost all cases, you will want to enable MPLS
on any interface that is also enabled for RSVP.
Adding the detail switch results in RSVP message statistics, as shown in the
truncated capture below:
user@host> show rsvp interface detail
RSVP interface: 3 active
at-0/1/0.100 Index 67, State Ena/Up
NoAuthentication, NoAggregate, NoReliable, NoLinkProtection
HelloInterval 9(second)
Address 10.0.0.1, 192.168.0.1
ActiveResv 0, PreemptionCnt 0, Update threshold 10%
Subscription 100%, StaticBW 1Mbps, AvailableBW 1Mbps
ReservedBW [0] 0bps[1] 0bps[2] 0bps[3] 0bps[4] 0bps[5] 0bps[6] 0bps[7]
0bps
PacketType
Total
Last 5 seconds
Sent
Received
Sent
Received
Path
0
0
0
0
PathErr
0
0
0
0
PathTear
0
0
0
0
Resv
0
0
0
0
ResvErr
0
0
0
0
ResvTear
0
0
0
0
115
Hello
Ack
. . .
116
0
0
0
0
0
0
0
0
Displaying RSVP Neighbors
The show rsvp neighbor command lists known RSVP neighbors
Neighbors only listed after exchange of path/reservation signaling
Hello protocol does not result in a neighbor listing
Once detected, neighbors are never removed
The Up/Dn count indicates the neighbors current status

user@host> show rsvp neighbor
RSVP neighbor: 1 learned
Address
Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd
10.0.1.1
0 1/0
48
9
8/8
5

Use the show rsvp neighbor command to display a list of known RSVP
neighbors. A neighbor is only listed when at least one path or reservation
message has been exchanged with that neighbor. The hello protocol does not
function to discover RSVP neighbors. Recall that the hello protocol is optional and
that it cannot be used for neighbor discovery because of the requirement that
hello messages be unicast. In contrast, IGPs make use of broadcast or multicast
transmissions to facilitate automatic neighbor discovery.
Once an RSVP neighbor is detected, the subsequent failure of that neighbor does
not cause its listing to be removed from the output of a show rsvp neighbor
command. Rather than being removed from the listing, a neighbor that is down
has its down counter incremented. To determine the current state of a known
neighbor, you must compare the up/down counters to see which is higher. In the
example on the slide, the neighbor is currently up because the up count is higher
than the down count. Adding the detail switch provides additional information
about each neighbor:
user@host> show rsvp neighbor detail
RSVP neighbor: 1 learned
Address: 10.0.1.1 via: so-0/2/0.0 status: Up
Last changed time: 6:32, Idle: 0 sec, Up cnt: 1, Down cnt: 0
Message received: 12
Hello: sent 46, received: 46, interval: 9 sec
Remote instance: 0x643232d8, Local instance: 0x6438a41b
Refresh reduction: not operational
117
Displaying RSVP Statistics

user@host> show rsvp statistics
PacketType
Total
Sent
Received
Path
21
0
PathErr
0
0
PathTear
0
0
Resv FF
0
15
Resv WF
0
0
Resv SE
0
0
ResvErr
0
0
ResvTear
0
0
ResvConf
0
0
Ack
0
0
SRefresh
0
0
Hello
58
59
EndtoEnd RSVP
0
0
Errors
Rcv pkt bad length
Rcv pkt unknown type
Rcv pkt bad version
Rcv pkt auth fail
Rcv pkt bad checksum
Rcv pkt bad format
Memory allocation fail
No path information
. . .
Total
0
0
0
0
0
0
0
0
Sent
Last 5 seconds
Received
1
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Last 5 seconds
0
0
0
0
0
0
0
0

The show rsvp statistics command displays a variety of information about
the types and numbers of RSVP messages sent and received. Use the clear
rsvp statistics command to clear the statistics.
118
Displaying RSVP Session Status

z The show rsvp session command displays ingress,
egress, and transit sessions
Add the detail switch to display record-route and
bandwidth information
user@host> show rsvp session detail

Ingress and egress nodes
Ingress RSVP: 1 sessions
192.168.24.1
LSP status and routes bound to
From: 192.168.0.1, LSPstate: Up, ActiveRoute: 1
the LSP
LSPname: to-amsterdam, LSPpath: Primary
Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 100000
Reservation type and labels
Resv style: 1 FF, Label in: -, Label out: 100000
assigned
Time left:
-, Since: Thu Sep 25 13:52:13 2003
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 1493 protocol 0
PATH rcvfrom: localclient
PATH sentto: 10.0.1.1 (so-0/2/0.0) 31 pkts
Record-route information
RESV rcvfrom: 10.0.1.1 (so-0/2/0.0) 25 pkts
Record route: <self> 10.0.1.1 10.0.24.2
Total 1 displayed, Up 1, Down 0
Egress RSVP: 0 sessions
Transit RSVP: 0 sessions
Figure 26: Displaying RSVP Session Status

One of the most useful RSVP-related operational-mode commands is the show
rsvp session command combined with the detail switch. By default, the
command displays information about all RSVP sessions, whether they are
ingress, egress, or transit sessions. You can add switches to display information
for each type of session, as well as for LSPs that are up or down, as shown in this
edited capture:
user@host> show rsvp session ?
Possible completions:
<[Enter]>
Execute this command
bidirectional
RSVP sessions that are bidirectional
brief
Display brief version of information
bypass
Show RSVP sessions used for protecting other LSPs
detail
Display detailed version of information
down
Label-switched paths that are in down state
egress
RSVP sessions that end at this router
ingress
RSVP sessions that originate from this router
interface
Show sessions on a particular interface
lsp
Show RSVP sessions used to set up LSPs
name
Show a particular RSVP session name
nolsp
Show RSVP sessions not used to set up LSPs
statistics
Display packet statistics
terse
Display terse version of information
transit
RSVP sessions that transit this router
unidirectional
RSVP sessions that are unidirectional
up
Label-switched paths that are in up state
119
Besides the LSP state, you also can view the source and destination nodes, label
assignment, reservation style, the LSPs path (thanks to the RRO), and the values
associated with the Tspec object. LSPs that are down do not display a complete
record-route object. The information about where the path message was sent can
lead you to the malfunctioning node, as it indicates which router was the next in
line to handle the signaling message.
120
Troubleshooting LSP Problems
The show mpls lsp extensive command is useful

for troubleshooting LSP establishment problems
user@host> show mpls lsp extensive
Ingress LSP: 1 sessions
192.168.24.1
From: 192.168.0.1, State: Up, ActiveRoute: 1, LSPname: to-amsterdam
ActivePath: (primary)
Primary path
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary
State: Up
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node):
10.0.1.1 10.0.24.2
11 Sep 25 14:27:49 Selected as active path
LSP re-established
10 Sep 25 14:27:49 Record Route: 10.0.1.1 10.0.24.2
9 Sep 25 14:27:49 Up
8 Sep 25 14:27:37 No Route toward dest[5 times]
No IGP route to
7 Sep 25 14:27:11 Deselected as active
destination
6 Sep 25 14:27:11 No Route toward dest[2 times]
5 Sep 25 14:27:11 Down
4 Sep 25 13:54:19 Selected as active path
LSP up, then down
3 Sep 25 13:54:19 Record Route: 10.0.1.1 10.0.24.2
2 Sep 25 13:54:19 Up
1 Sep 25 13:52:13 Originate Call
. . .
Figure 27: Troubleshooting LSP Problems

The show mpls lsp command provides information similar to the output of the
show rsvp session command. This command is particularly useful when
combined with the extensive switch due to its display of primary/secondary
status and the historical log of the LSPs signaling activity. CSPF-related problems
often show up here with a no route to host error, while RSVP-related commands
show no sessions due to the
CSPF path calculation failure. When a CSPF calculation fails, there is no need to
bother RSVP for signaling services.
The example on the slide indicates that the to-amsterdam LSP is bouncing, and
that for some period of time there was no IGP route to the egress point.
121
Clearing LSPs
Two options:
clear rsvp session session-name
Command affects all sessions involving the local router (ingress,

egress, and transit) when a specific name is not given
clear mpls lsp session-name
Clears all the local routers ingress sessions when a specific name is
not given
The optimize or optimize-aggressive switch clears ingress
LSP only when a better path is available (requires CSPF)
Clearing LSPs
Two commands are available in JUNOS software to clear LSPs. These are the
clear rsvp session and clear mpls lsp commands. Both commands
clear all ingress LSPs when issued without a specific LSP name provided as an
argument.
The clear rsvp session command clears all RSVP sessions that touch a
given router when a specific session name is not provided as an argument.
Maybe you did want to clear all 10,000 LSPs that ingressed, egressed, and
transited this router, but then again, maybe not. We generally recommend that
you use the clear mpls lsp command to avoid the inadvertent clearing of
ingress, egress, and transit sessions.
You can issue the clear mpls lsp command with the optimize or
optimize-aggressive switch. In the case of the former, the LSP is only
cleared if the CSPF algorithm can satisfy the stringent reoptimization rules that
are designed to prevent LSP thrashing. With aggressive reoptimization the LSP is
cleared and reestablished if there is a metrically shorter path now available.
122
Clearing LSPs
Tracing RSVP
A typical RSVP tracing configuration:

user@host# show
traceoptions {
file rsvp-trace;
flag error detail;
flag path detail;
flag resv detail;
flag pathtear detail;
flag resvtear detail;
}
Monitor the resulting rsvp-trace log file using monitor start

log-file-name or the show log log-file-name commands
RSVP Tracing
To perform debugging functions on the RSVP process, use the JUNOS software
traceoptions function. The trace output (debug information) is directed to the
named log file, which is stored in the /var/log directory on the routers hard
drive. You can view the log file using the monitor start or show log
operational-mode commands.
In addition to specifying the trace file name, you also must tell the router what
information you want to trace. You accomplish this by specifying one or more
flag keywords.
While you can only direct tracing to a single file, you can trace many options by
using the flag keyword multiple times. In addition, you can add granularity by
using the detail, receive, and send flag modifiers.
Available tracing flags for RSVP include:
all
error
error
event
lmp
packets
path
pathtear
resv
resvtear
route
state
Trace
Trace
Trace
Trace
Trace
Trace
Trace
Trace
Trace
Trace
Trace
Trace
everything
error conditions
error conditions
RSVP related events
RSVP-LMP related interactions
all RSVP packets
RSVP path messages
RSVP PathTear messages
RSVP Resv messages
RSVP ResvTear messages
routing information
state transitions
Tracing RSVP
123
Review Questions
List three ways in which static LSPs differ from RSVP-signaled LSPs.
What is the difference between RSVP hello messages and RSVP refresh
messages?
How would you configure an interface to allow RSVP bandwidth

over-subscription?
What is the difference between the clear rsvp session and clear
mpls lsp commands?
List and describe two commands that you can use to monitor and
troubleshoot RSVP-signaled LSPs.
124
Review Questions
Static and signaled LSPs;
RSVP path signaling;
The function of RSVP hellos, path refresh, and message aggregation;
Basic RSVP-signaled LSP configuration; and
Operational commands used to monitor RSVP signaling and LSP status.
Lab 2: RSVP Signaling

Lab Objective:
Configure RSVP and establish a signaled LSP.
125
126
Chapter 4: Module 4: LSPs and Routing Table Integration
Chapter 4
Module 4: LSPs and Routing Table

Integration
127
Module Objectives
After successfully completing this module, you will be able to
Describe the contents of the inet.3 routing table
Explain how BGP makes use of the inet.3 table
Describe why setting next-hop self versus using a passive IGP can have
a dramatic impact on LSP usage
128
Module Objectives
A review of MPLS, the benefits of MPLS, and how MPLS is used for Internet
The fundamentals of MPLS and the basic components of an MPLS domain;
MPLS labels and the structure of the MPLS header information;
Static LSPs versus signaled LSPs;
The effect of MPLS on routing table interactions, such as which routing

protocols use the MPLS routing and label tables; and
Configuring MPLS for both static and signaled LSPs.
Routing Table Integration
Mapping next hops to LSPs
Route resolution example
Route resolution summary
The ramifications of using next-hop self versus passive IGP
Routing Table Integration
129
Mapping BGP Next Hops to LSPs
Routes associated with signaled LSPs are installed in the inet.3 routing
table
Only BGP can view the contents of inet.3
BGP tries to resolve its next hop through LSPs in inet.3
BGP installs an LSP as the physical next hop for transit destinations
Internal destinations are not associated with a BGP next hop and
therefore do not use LSPs by default
The Use of the inet.3 Routing Table

Which types of traffic should see and use established LSPs? In the JUNOS
software implementation of MPLS, the default behavior makes BGP the only
protocol that is aware of the presence of LSPs, and only then when BGP attempts
to resolve the next hops associated with advertised prefixes.
Because MPLS LSPs are often used to engineer and direct transit traffic across
an ISPs backbone, the default behavior results in internal traffic, which is not
associated with a BGP next hop, continuing to use IGP forwarding. The result is
that transit traffic associated with a BGP next hop that resolves through the
inet.3 table is subjected to LSP forwarding while all other traffic remains
unaware of the LSPs presence. To maintain this separation from the normal IGP
routing table, LSPs are normally installed in the inet.3 table only.
BGP Installs LSP as Next Hop

When attempting to resolve the BGP next hop associated with a given prefix, BGP
first looks in the inet.3 table. If the next hop can be resolved in the inet.3
table, the resulting LSP is installed into the forwarding table as the next hop for
that BGP prefix. If the next hop cannot be resolved in inet.3, BGP next attempts
to resolve the next hop through the main inet.0 table.
130
Mapping BGP Next Hops to LSPs
Route Resolution Example
VT
YankeeNet
AS2
IBGP
Boston
134.112/16
EBGP
Denver
DC
192.168.1.1
192.168.4.1
NY
SF
134.112/16
192.168.24.1
192.168.16.1
CoreNet
AS 64512
134.112/16
EBGP
Hawaii
AlohaNet
AS 33
Maui
Figure 28: Route Resolution Example
Route Resolution
The example in the next series of slides shows how a router uses the information
learned by BGP to direct transit traffic onto an LSP. We begin by examining how
traffic is forwarded to the 134.112/16 network from the perspective of CoreNet.
Things start with the 134.112/16 prefix being learned by the New York router
through its EBGP session to YankeeNet. The San Francisco router then learns
about 134.112/16 through its IBGP session to New York. The San Francisco
router installs the prefix as active and readvertises the prefix to the Hawaii router,
again using EBGP.
In this example, routers in AlohaNet begin sending traffic to 134.112/16 prefixes
through San Francisco. When this transit traffic arrives at the San Francisco
router, it must decide how to forward this transit traffic to 134.112/16.
Route Resolution Example
131
Unusable BGP Next Hop
VT
YankeeNet
AS2
IBGP
134.112/16
.1
Denver
10.0.1/30
.1
192.168.1.1
.1
.2
DC
192.168.4.1
AS64512
.1
10.0.2
4/30
.2
.2
10
.0.
29
/30
.2
0
.16/3
10.0
Boston
EBGP
134.112/16
NY
192.168.24.1
SF
192.168.16.1
lab@SF> show route 134.112/16 all

inet.0: 1 destinations, 1 routes (0 active, 0 holddown, 1 hidden)
134.112.0.0/16
[BGP/170] 00:00:10, MED 0, localpref 100, from 192.168.24.1

AS path: 2 ?
Unusable
Figure 29: Unusable BGP Next Hop

This example backs up the process a bit and looks at a common problem with
BGP routes: unusable next hops. This discussion helps reinforce the interaction of
BGP and LSP routing table integration. Note that the previous slide shows the
San Francisco router advertising the 134.112/16 prefix to a router in AlohaNet. A
route with an unusable next hop cannot be active and, therefore, cannot be
exported from the routing table.
A look at the routing table on the San Francisco router reveals that the router has
learned the 134.112/16 through BGP, but it also shows that the route cannot be
used. The route learned from the New York router to 134.112/16 is hidden, which
is why the all switch was added to the show route command in the example.
More investigation is necessary to determine why.
132
The Problem
VT
YankeeNet
AS2
IBGP
Boston
.1
.2
10.0
30
.16/
Denver
.1
10.0.1/30
192.168.1.1
.2
DC
.1
10.0.2
192.168.4.1
AS64512
.1
4/30
.2
.2
10
.0.
29
/30
134.112/16
NY
EBGP
134.112/16
192.168.24.1
SF
192.168.16.1
lab@SF> show route 134.112/16 all extensive

134.112.0.0/16 (1 entry, 0 announced)
BGP
Preference: 170/-101
Next hop type: Unusable
Local AS: 64512 Peer AS: 64512
Age: 13 Metric: 0
Metric2: 0
AS path: 2 ?
Protocol next hop: 10.0.29.1
Localpref: 100
Router ID: 192.168.24.1
Figure 30: BGP Next Hop Problem
Why the Route Is Hidden

An extensive view of the 134.112/16 prefix at the San Francisco router shows
that the next hop for this route is unusable, even though the correct next hop for
the route is listed. At this point, it appears that the San Francisco router does not
know how to get to the next hop 10.0.29.1 connected to New York.
The problem here is that the 10.0.29/30 prefix used to support the EBGP peering
session between New York and Boston is not advertised by CoreNets IGP. Put
simply, the problem is that San Francisco does not have a route to 10.0.29/30.
Once again, there is still no MPLS traffic engineering in this example.
The Problem
133
One Solution: Next-Hop Self at NY

VT
BGP next hop changed

YankeeNet
AS2
IBGP
134.112/16
Boston
.1
.2
10.0
.1
30
.16/
Denver
.1
10.0.1/30
192.168.1.1
.2
DC
192.168.4.1
.1
10.0.2
4/30
AS64512
fe-0/0/0.0
.2
.2
10
.0.
29
/30
192.168.24.1
NY
192.168.24.1
EBGP
134.112/16
10.0.29.1
SF
192.168.16.1
lab@SF> show route 134.112/16 extensive
BGP
next hop
134.112.0.0/16 (1 entry, 1 announced)

*BGP
Source: 192.168.24.1
Nexthop: 10.0.16.2 via fe-0/0/0.0, selected
Local AS: 64512
Peer AS: 64512
Age: 53 Metric: 0
Metric2: 30
AS path: 2 ?
Localpref: 100
Router ID: 192.168.24.1
Figure 31: One Solution: Next-Hop Self at NY
Setting Next-Hop Self Is a Viable Solution

This slide solves the 134.112/16 hidden route problem at San Francisco through a
next-hop self policy applied at the New York router. A next-hop self solution is one
of several viable ways to correct unreachable BGP next hops.
Setting next-hop self on the New York router results in the route advertisement for
134.112/16 arriving at the San Francisco router with a BGP next hop that
represents the New York routers loopback address. The San Francisco router
can resolve the New York routers loopback address because the IGP running
throughout the AS advertises that information.
At this stage, transit connectivity to 134.112/16 destinations is now provided by
CoreNet. This connectivity is based on IGP forwarding, however.
As before, no MPLS traffic engineering features are enabled at this point.
134
One Solution: Next-Hop Self at NY
LSP to New York Is Configured
VT
IBGP
YankeeNet
AS2
134.112/16
Boston
.1
SF
192.168.16.1
.1
10.0.1/30
.2
DC
192.168.4.1
.1
10.0.2
4/30
AS64512
.0 .
Denver
192.168.1.1
.2
.2
10
.2
0
.16/3
10.0
29
/3 0
.1
NY
EBGP
134.112/16
192.168.24.1
[edit]
lab@SF# show protocols
rsvp {
interface all;
}
mpls {
label-switched-path to_ny {
to 192.168.24.1;
no-cspf;
}
interface all;
}
. . .
Figure 32: LSP to New York Is Configured
LSP from San Francisco to New York Is Configured

Now that we applied next-hop self to the BGP route making it usable. The sample
network is ready for MPLS traffic engineering to enter the fray.
The key aspects of the configuration at San Francisco that define an
RSVP-signaled LSP to New York are shown on the slide. Once established, the
LSP is the preferred route to 134.112/16 because BGP looks up a prefix in the
inet.3 table (for LSPs) before looking in the inet.0 table (used by IGPs) and
because LSPs are preferred over IGP routes due to route preference.
LSP to New York Is Configured
135
LSP to New York Is Established
VT
YankeeNet
AS2
IBGP
Boston
134.112/16
.1
.1
10.0.1/30
.2
DC
192.168.4.1
AS64512
.1
10.0.2
4/30
.0 .
Denver
192.168.1.1
10
.2
0
.16/3
10.0
29
/30
.1
.2
.2
NY
EBGP
134.112/16
192.168.24.1
SF
192.168.16.1
lab@SF> show mpls lsp extensive

Ingress LSP: 1 label-switched paths
192.168.24.1
From: 192.168.16.1, State: Up, ActiveRoute: 1, LSPname: to_ny
ActivePath: (primary)
LoadBalance: Random
*Primary
State: Up
4 Nov 4 23:05:48 Selected as active path
3 Nov 4 23:05:47 Record Route: 10.0.16.2 S 10.0.1.2 S
10.0.24.2 S
2 Nov 4 23:05:47 Up
1 Nov 4 23:05:47 Originate Call
Figure 33: LSP to New York Is Established
LSP Establishment Is Confirmed

In the example on the slide, the LSP is established over the preferred IGP path.
The absence or presence of traffic engineering does not alter the way that LSPs
are integrated into the routing table. Besides, in the sample network, there is only
one path for the LSP to take.
In this example, the LSP is signaled using RVSP; we could also use LDP
signaling with much the same result. The output of a show mpls lsp
extensive command confirms proper establishment of the to_ny LSP.
136
LSP to New York Is Established
Lowest Preference Wins
VT
YankeeNet
AS2
IBGP
Boston
.1
.1
10.0.1/30
.2
DC
192.168.4.1
.1
10.0.2
4/30
AS64512
.1
SF
Denver
192.168.1.1
10
.2
30
.16/
10.0
.0 .
29
/3 0
134.112/16
.2
.2
NY
EBGP
134.112/16
192.168.24.1
fe-0/0/0.0
192.168.16.1
lab@SF> show route 192.168.24.1

192.168.24.1/32
*[IS-IS/18] 00:26:50, metric 30, tag 2

> to 10.0.16.2 via fe-0/0/0.0

192.168.24.1/32
*[RSVP/7] 00:00:53, metric 30

> to 10.0.16.2 via fe-0/0/0.0, label-switched-path to_ny
Figure 34: Lowest Preference Wins
Comparing Route Preferences

The slide shows that once the LSP to New York is established, information about
the route to the New York routers loopback address (the next hop for the
134.112/16 prefix) is present in not one but two routing tables. These are inet.0,
used by all routing protocols, and inet.3, which is used by LDP and RSVP
(which install the information in inet.3) and BGP, which uses the information in
inet.3.
But what ensures that BGP resolves its next hop through the LSP to New York
instead of the IGP route? The answer is simple: the preference assigned to LSPs
is lower than the preference assigned to IGP routes. This causes the router to
prefer LSPs over IGP routes. Should preferences be set the same, entries in the
inet.3 table are preferred over entries in the inet.0 table.
A key point on the slide is that both the IGP and MPLS routes are active, albeit in
separate tables. The result is that traffic addressed to 192.168.24.1 uses the IGP
route, while traffic associated with a BGP next hop of 192.168.24.1 uses the LSP.
Lowest Preference Wins
137
VT
YankeeNet
AS2
IBGP
10.0
.1
Denver
.1
.2
fe-0/0/0.0
DC
192.168.4.1
AS64512
.1
10.0.2
29
/30
10.0.1/30
192.168.1.1
10
.0.
.2
0
.16/3
Boston
.1
134.112/16
4/30
.2
.2
NY
EBGP
134.112/16
192.168.24.1
SF
192.168.16.1
lab@SF> show route 134.112/16

134.112.0.0/16
*[BGP/170] 00:00:31, MED 0, localpref 100, from 192.168.24.1

AS path: 2 ?
> to 10.0.16.2 via fe-0/0/0.0, label-switched-path to_ny
Figure 35: BGP Installs LSP as Next Hop
BGP Installs LSP as Forwarding Next Hop for 134.112/16

It helps to keep in mind that the goal of this whole exercise is not to use the LSP to
reach the New York routers loopback address; the goal is to direct transit traffic
associated with the 134.112/16 prefix onto an LSP for transport across the
CoreNet AS.
The slide shows that the BGP route to 134.112/16 is present in the inet.0
routing table as a BGP route. However, the results of BGP next-hop resolution
through the inet.3 table results in the to_ny LSP being installed as the
forwarding next hop for traffic associated with the 134.112/16 prefix.
138
Ingress Router Behavior
RSVP/LDP:
Signal LSPs to egress router
Install IP prefix to egress router into the inet.3 routing table
Specifies LSPs egress interface and label assigned by the

downstream router
OSPF
IS-IS
IP
Routing Table
(inet.0)
BGP
RSVP
LDP
MPLS
Routing Table
(inet.3)
IP Forwarding Table
Figure 36: Ingress Router Behavior
Route Resolution at Ingress Router

The previous example demonstrated how signaled LSPs are installed in the
inet.3 routing table. Both RSVP and LDP install the IP prefix to the egress
router into the inet.3 table on the ingress router.
The next-hop data for entries in the inet.3 table consist of the LSPs egress
interface and the label value assigned by the LSPs first downstream router.
Note that the various routing protocols continue to use the inet.0 IP routing
table to determine the current active route to IP destinations.
A sample inet.3 entry that shows the next-hop forwarding information for an
LSP is shown here. Note the presence of a label push operation and egress
interface:
user@host> show route table inet.3 detail
192.168.24.1/32 (1 entry, 1 announced)
State: <FlashAll>
*RSVP
Preference: 7
Next hop: via so-0/2/0.0 weight 1, selected
Label-switched-path to-amsterdam
Label operation: Push 100080
State: <Active Int>
Local AS: 64512
Age: 2:19:06
Metric: 2
Task: RSVP
139
Announcement bits (1): 1-Resolve inet.0

AS path: I
140
Ingress Resolves BGP Next Hop
BGP performs recursive lookup to resolve BGP next hop
BGP also looks in the inet.3 MPLS routing table
BGP looks in the inet.0 IP routing table
BGP selects route with lowest preference
OSPF
IS-IS
BGP
IP
Routing Table
(inet.0)
RSVP
LDP
MPLS
Routing Table
(inet.3)
Contains IP prefix
to egress router
with LSP next hop.
Only BGP uses this
routing table
IP Forwarding Table
Figure 37: Ingress Resolves BGP Next Hop
BGP Resolves Its Next Hop Using Both Tables

BGP must resolve a protocol next hop to a forwarding next hop in a process
known as a recursive route lookup. The goal of this process is to resolve the
advertised BGP next hop to a directly connected forwarding next hop.
BGP uses both the inet.0 and inet.3 tables when attempting to resolve a
next-hop address. When the same prefix appears in both inet.0 and inet.3
tables, as is the case of this example, BGP chooses the route with the lowest
preference. This results in the selection of the LSP when default preference
values are at play. In the event of a preference tie, entries in inet.3 are preferred
over inet.0 entries.
Ingress Resolves BGP Next Hop
141
Ingress Installs LSP for Forwarding

BGP favors routes in inet.3
MPLS preference is better than IS-IS and OSPF
For preference ties, BGP selects inet.3
LSP to egress router copied to inet.0 as a forwarding next hop
Specified LSPs egress interface and label to push
OSPF
IS-IS
BGP
inet.0
RSVP
LDP
inet.3
to: 134.112/16
192.168.24.1 to_ny
192.168.24.1 to_ny
Push label x
Push label x
IP Forwarding Table
134.112/16 to_ny Push label x
Figure 38: Ingress Installs LSP for Forwarding
BGP Selects inet.3 over inet.0

By default, BGP prefers LSP-based resolution of a BGP prefixs next hop. If there
is a preference tie between inet.3 and inet.0, BGP selects the inet.3 route
over the inet.0 route.
LSP Installed as Forwarding Next Hop in inet.0

The LSPs forwarding information is copied into inet.0 when BGP can resolve
its next hop though the LSP. A key point is that the LSP itself is not installed into
inet.0. Rather, the BGP prefix is installed into inet.0 with a forwarding next
hop that points to the LSP. Thus, traffic not associated with the BGP next hop in
question continues to be unaware of the LSPs presence. The slide shows how
the forwarding table is ultimately configured to forward over the LSP for traffic
associated with the BGP prefix 134.112/16.
142
Ingress Installs LSP for Forwarding
Route Resolution Summary
LSPs installed in ingress routers inet.3 table
Points to the IP addresses specified as egress
Normally identifies the egress routers loopback address
Address appears as if it were directly connected
When LSP is up, next hop is usable and attractive to BGP
When LSP is down, LSP next hop is unusable
Can still use normal IP routing to reach next hop
Only BGP is aware of LSPs
Other protocols can use this information with additional configuration
LSPs Are Installed in Ingress Routers inet.3 Table

In summary, LSPs appear in the ingress routers inet.3 table. The next-hop
address points to the egress router as if it were directly connected and not at the
end of an LSP passing through many transit points. Normally the LSPs egress
address is specified as the egress routers loopback address, which also serves
as the router ID.
When the LSP is up, this next hop is usable by BGP for next hop route resolution.
When the LSP is down, the next hop referenced by the LSP is unusable. Packets
still can use normal IGP routing information to resolve the next hop, however.
Only BGP Is Aware of inet.3

Only BGP pays attention to the entries housed in inet.3 and only then when it is
resolving a BGP next hop. LSPs are hidden from the main IP routing table, which
allows non-BGP traffic to continue to use the IGP forwarding path.
Note that the examples we discuss in this section are based on the default LSP
routing table integration behavior. With additional configuration, the presence of
LSPs can be made known to non-BGP traffic. The decision to traffic engineer
internal traffic requires careful consideration because MPLS, and even basic
router troubleshooting, might be complicated when pings and traceroutes begin
using LSPs.
Route Resolution Summary
143
Routing Table Summary
MPLS uses three tables:
inet.0
Can install additional prefixes per LSP with

install prefix active;
inet.3
MPLS routing table
Houses signaled LSPs at ingress node
Primary IP unicast routing table
Can install additional prefixes per LSP with

install prefix;
mpls.0
MPLS label-switching table
Used by transit and egress routers
Routing Tables Used in MPLS

In summary, three tables are important when you configure MPLS along with
normal routing protocols. These are inet.0, inet.3, and mpls.0:
inet.0: The primary IP unicast routing table. Normally, IGPs only look in this
table to resolve next hops. You can allow IGPs to access LSP information
available in inet.3 on an LSP-by-LSP basis by installing LSP prefixes into
inet.0 using the install prefix active CLI configuration command in
the configuration for that LSP.
inet.3: The MPLS routing table. All signaled LSPs are installed in this table
where only BGP can find them. You can add prefixes associated with the LSP
to the inet.3 table by using the install prefix CLI configuration
command in the configuration for that LSP. This knob is useful when you want
BGP to use the LSP and next-hop self is not in effect at the egress node.
mpls.0: The MPLS label switching table. Transit and egress routers use the
contents of this table to swap and pop labels as needed when handling the
LSP.
A full discussion of the various options available in JUNOS software for LSP
routing table integration is beyond the scope of this course.
144
Routing Table Summary
Effects of Passive IGP versus Next-Hop Self
Passive IGP
No Next hop self!
IBGP
VT
YankeeNet
AS2
Boston
134.112/16
10.0
Denver
SF
10.0.1/30
.2
.1
DC
192.168.4.1
10.0.2
4/30
.2
AS64512
.1
192.168.16.1
.1
192.168.1.1
.2
10
.0.
29
/30
.2
30
.16/
.1
NY
EBGP
134.112/16
192.168.24.1
fe-0/0/0.0
lab@SF> show route 134.112/16 extensive

LSP no longer used!
134.112.0.0/16 (1 entry, 1 announced)

*BGP
Source: 192.168.24.1
Nexthop: 10.0.16.2 via fe-0/0/0.0, selected
Local AS: 64512
Peer AS: 64512
Age: 53 Metric: 0
Metric2: 30
AS path: 2 ?
Localpref: 100
Router ID: 192.168.24.1
Figure 39: Effects of Passive IGP versus Next-Hop Self
The Ramifications of a Passive IGP Solution

The examples shown thus far made use of a next-hop self policy on the LSPs
egress node to accommodate resolution of the BGP next hop associated with
routes advertised by YankeeNet. This slide details the dramatic impact of
choosing a passive IGP vs. a next-hop self policy solution when the default
routing table integration behavior is at play.
In this example, the LSP egress is still New Yorks 192.168.24.1 loopback
address. The issue is that the BGP next hop associated with the 135.112/16 prefix
is now 10.0.29.l. This prefix is resolvable by the IGP due to the use of a passive
IGP instance in the interface that supports the EBGP peering session to Boston.
The result is that BGP can no longer resolve its next hop through the LSP installed
in the inet.3 table. The San Francisco router therefore resolves the BGP next
hop through the inet.0 table. Therefore, transit traffic associated with the
134.112/16 prefix is no longer subjected to LSP forwarding! This is a significant
point because the lack of LSP forwarding might violate service level agreements
and can result in performance problems relating to a lack of capacity on the IGPs
preferred links. Many would consider a passive IGP or next-hop self solution as
equally workable. While this is true, you must consider the impact these choices
have on LSP routing table integration. Full treatment of these options is beyond
the scope of this course; they are mentioned here for the sake of completeness.
To resolve this issue, you can use the install prefix command to install
specific prefixesin this case, the 10.0.29/30 route, into inet.3. Another option
is to deploy traffic engineering shortcuts. This option installs prefixes
downstream from the egress router into the inet.3 table.
145
Remember this rule: Only BGP prefixes that have the LSP destination address as
the BGP next hop are resolvable through an LSP. In other words, the LSP egress
address must equal the BGP next-hop address for LSP forwarding of transit traffic
to occur.
146
A Thought-Provoking Question
user@host> show route 192.168.24.1
192.168.24.1/32
*[OSPF/10] 03:43:14, metric 2

> via so-0/2/0.0

192.168.24.1/32
*[RSVP/7] 03:43:15, metric 2

> via so-0/2/0.0, label-switched-path to-amsterdam
user@host> show route 192.168.24.5

192.168.24.0/24
*[BGP/170] 03:48:01, localpref 100, from 192.168.24.1

AS path: I
> via so-0/2/0.0, label-switched-path to-amsterdam
How will traffic be forwarded to 192.168.24.1 and 192.168.24.5?
The 60,000-Dollar Question

Can you describe how traffic destined to 192.168.24.1 and 192.168.24.5 will be
forwarded, given the operational output shown on the slide?
A Thought-Provoking Question
147
The Answer
Traffic to 192.168.24.1 is forwarded by the IGP

user@host> traceroute 192.168.24.1
traceroute to 192.168.24.1 (192.168.24.1), 30 hops max, 40 byte packets
1 10.0.1.1 (10.0.1.1) 0.756 ms 0.604 ms 0.532 ms
2 192.168.24.1 (192.168.24.1) 0.718 ms 0.711 ms 0.682 ms
Traffic to 192.168.24.5 is forwarded over the LSP

user@host> traceroute 192.168.24.5
traceroute to 192.168.24.5 (192.168.24.5), 30 hops max, 40 byte packets
1 10.0.1.1 (10.0.1.1) 0.964 ms 0.790 ms 0.714 ms
MPLS Label=100080 CoS=0 TTL=1 S=1
2 10.0.24.2 (10.0.24.2) 0.600 ms !N 0.585 ms !N 0.549 ms !N
Traffic to 192.168.24.1
Because the 192.168.24.1 route is not a BGP route, there is no BGP next hop
associated with this prefix. Traffic to 192.168.24.1 uses IGP forwarding because
the presence of the LSP that terminates at the 192.168.24.1 address is not known
to the IGP.
Traffic to 192.168.24.5
In contrast, the longest match for the 192.168.24.5 address is the 192.168.24/24
prefix that is learned through BGP. The BGP next hop for this route equals the
LSPs egress address allowing the BGP next hop to be resolved through the
inet.3 table. Traffic to 192.168.24.5 is forwarded over the LSP.
The presence of LSP forwarding is clearly indicated by the presence of MPLS
label values in the output. We expect the destination unreachable message seen
in the last hop in this example because the 192.168.24/24 route at New York is
configured with a reject next hop.
148
The Answer
Review Questions
What is the purpose of inet.3?
Why can the use of a passive IGP affect whether traffic is mapped to an LSP?
Will internal traffic ever map to an LSP by default?
A review of MPLS, the benefits of MPLS, and how MPLS is used for Internet
The fundamentals of MPLS and the basic components of an MPLS domain;
MPLS labels and the structure of the MPLS header information;
Static LSPs versus signaled LSPs;
The effect of MPLS on routing table interactions, such as which routing

protocols use the MPLS routing and label tables; and
Configuring MPLS for both static and signaled LSPs.
Review Questions
149
Lab 3: Routing Table Integration

Lab Objective:
Experiment with LSP routing table integration.
150
Lab 3: Routing Table Integration
Chapter 5: Module 5: Named Paths and Routing Constraints
Chapter 5
Module 5: Named Paths and Routing

Constraints
151
Module Objectives
Describe how you can use EROs to influence the path of an LSP
Explain the difference between loose and strict hops
Describe how JUNOS software uses named paths to contain one or more
EROs
Configure an LSP with a named path to control its routing
Use operational commands to verify the LSPs path
152
Module Objectives
ERO-based routing constraints;
Loose versus strict hops;
Configuring routing constraints with named paths;
Monitoring and troubleshooting constrained routing LSPs.
ERO functions and types
ERO examples
Configuring named paths and EROs
Modifying named paths
153
Explicit Route Objects: A Definition
Explicit route objects (EROs) are defined in MPLS extensions to RSVP
Allow the ingress node to control the routing of the LSP independently of
the IGPs preferred path
Routing constraints accommodate different forwarding paths for labeled

versus unlabeled traffic
Path message must visit all ERO hops specified, in the sequence that they
are listed
This is the essence of traffic engineering
Resv message is routed back along the same path to establish the LSP
Two ERO types are defined:
Loose
Strict
Explicit Route Objects Defined

RFC 3209, RSVP-TE: Extensions to RSVP for LSP Tunnels, defines support for
explicit route objects (EROs) that force the routing of an LSP over one or more
transit points. With EROs the LSP can be routed over a path that the IGP would
not have chosen. EROs support affords RSVP true traffic engineering capabilities.
Path Contains All Hops Specified

When a path message contains an ERO, the routing of the path is based on the
ordered list of nodes specified in the ERO object. Each node in the ERO list must
be visited by the path message in the order in which the nodes are listed.
Loose and Strict Hops

There are two types of EROs defined: loose and strict. A loose ERO relies on the
underlying IGP to route the message to the next loose hop in the ERO list. Loose
hops need not point to a directly connected neighbor.
In contrast, a strict ERO must identify a directly connected neighbor. A path
message that contains a complete listing of strict EROs can succeed even in the
absence of an IGP because the top of the ERO stack points to a directly
connected neighbor at each node processing the path message.
154
Some versions of JUNOS software allow a strict hop that points to a directly
connected neighbors loopback address. Generally speaking, you should always
specify a physical address when using a strict hop to avoid interoperability
problems with other vendors and to prevent problems relating to specific JUNOS
software versions. Although not covered in this class, note that a successful
CSPF calculation always results in a complete sequence of strict EROs that
defines the path between ingress and egress nodes. As a result, you can specify
a strict hop that points to a loopback address in all versions of JUNOS software
when CSPF is used; this is because the actual ERO list carried in the resulting
RSVP path message is populated by the CSPF algorithm, which uses only strict
hops.
155
Strict EROs
Next hop must be directly attached to previous hop

Some JUNOS software versions permit specification of a neighbors
physical or loopback address
Recommendation is to use physical interface addresses for strict

hops
ERO
Egress
LSR
B strict
C strict
E strict
D strict
F strict
Strict
Figure 40: Strict EROs
Strict EROs
This slide shows how a strict listing of EROs identifies a set of directly connected
routers through which the LSP must pass in sequence as it makes its way towards
the destination. By adding the ERO list to an RSVP path message, the ingress
node can control the routing of the LSP in a manner that is independent of
conventional IP routing.
When the local router sees a strict ERO at the top of the ERO list, that ERO must
point to a directly attached neighbor; if not, a path error is declared, and the LSP
setup fails. In most cases, a strict ERO identifies a physical interface by the IP
address associated with the downstream neighbor. Some versions of JUNOS
software permit the specification of a directly attached neighbors loopback
address as a strict ERO. Because this behavior can be dependant on the version
and was not shared by other vendors, current best practice avoids the use of
loopback addresses for strict EROs.
The standards bodies are currently defining procedures for using EROs across
unnumbered interfaces. Currently, only loose hops are supported in the presence
of unnumbered interfaces.
156
Strict EROs
Loose EROs
Routers consult the routing table at each hop to determine the best path to the
next transit point
IGP controls path routing between loose hops
ERO
Egress
LSR
D loose
A
Ingress
LSR
Loose
Figure 41: Loose EROs
Loose Hops
In contrast to a strict ERO, a loose ERO does not require that the local router be
directly connected to ERO specified at the top of the list.
On the slide, the loose ERO is interpreted by the downstream RSVP routers as I
dont care how you get to Router D from here, or how you get to the egress router
from Router D, just make sure that this LSP passes through Router D on the way
to the egress router.
So how are loose EROs honored without the guidance of strict path information?
At each step along the path, the RSVP routers consult their routing tables to
determine the IGPs best path and corresponding next hop to the loose transit
point (Router D). When the path message arrives at Router D, the ERO stack is
popped, resulting in an ERO list. At this point Router D, and all routers that lie
downstream towards the egress node, forward the path message towards the
egress node by consulting the IGPs preferred route to the LSP egress point.
Loose routes have the advantage of not requiring a direct link to the ERO-listed
router, which can lessen the amount of configuration and the need for a detailed
knowledge of the path to a given destination. The use of the IGPs shortest path
between loose hops means that you lose some traffic engineering control,
however.
Because the path message is routed according to the IGPs preferred path once
the ERO list is exhausted, you must use care to ensure that the path message will
not be routed back across any nodes or links that have already handled that path
message. A routing loop is declared, and the LSP is torn down when the RRO
indicates a path message has been directed back to a node that has already
processed that message.
Loose EROs
157
Using Both Strict and Loose EROs
ERO
Strict
Egress
LSR
C strict
D loose
F strict
A
Ingress
LSR
Loose
Figure 42: Using Both Strict and Loose EROs
Combining Strict and Loose Hops

You can combine strict and loose ERO directives in the same ERO list. This ability
provides maximum flexibility and control over the routing of RSVP-signaled LSPs.
This is because you can specify loose hops when you are not concerned with the
exact specifics of the LSPs routing. You can use strict hops when the LSPs
routing must be tightly controlled.
As before, strict routes require a direct link to the next router on the list, but loose
hops do not. In other words, if Router F is not directly connected to Router D, the
LSP setup fails due to the specification of a strict hop between Routers D and F. In
contrast, a direct connection from Router C to Router D is not required because
the Router D transit point is identified as a loose hop.
Note that in this example Router C likely has two equal-cost IGP paths to Router
D. In this case, the choice of one path over the other does not affect LSP
establishment. The next series of pages shows how insufficient use of ERO
directives can result in problems with LSP establishment.
158
Using Both Strict and Loose EROs
A Little ERO Is Goodbut More Is Better
Beware...
The IGP routes the LSP according to its view of the least-cost path in the
absence of ERO
Between loose hops
When the ERO runs out
Insufficient ERO can cause the IGP to route LSP back onto itself
Record-route object loop detection causes the LSP to fail
Configuring partial ERO requires a detailed knowledge of the underlying

IGP metrics
A Little Is Good...
Because the IGP controls the routing of path messages between loose hops or
when the ERO list runs out, you can get into trouble when an insufficient amount
of ERO is defined. In such cases the IGPs view of the best path can result in the
path message being routed back onto itself. This causes LSP setup to fail with a
routing loop detected error message in the output of a show mpls lsp
extensive command.
A Little ERO Is Goodbut More Is Better
159
Partial ERO Example
Can this LSP be established?
mpls {
to 192.168.5.1;
primary use-fargo;
no-cspf;
}
path use-fargo {
10.0.1.1 strict;
10.0.1.2 strict;
}
}
10.0.1.2
20
10.0.1.1
IGP
Metrics
30
1
30
Fargo
50
San
Francisco
30
10
192.168.5.1
5
30
30
Miami
Figure 43: Partial ERO Example
Partial ERO Example

This slide provides an example of how insufficient ERO can cause path
establishment problems. In this example, when the path message hits the Fargo
node (10.0.1.2), the ERO list is empty. Because the path message now lacks an
explicit route object, the IGP now takes over the routing of the path message
towards the egress node. Note that the path message is destined for the loopback
address assigned to the Miami router in this example.
Based on the IGP metrics shown, do you feel that this LSP will be established?
If you answered no, then pat yourself on the back for being correct. In this
example, the relatively high metric value (50) assigned to the Fargo-Miami link
results in the path message being sent from Fargo back to the San Francisco
router. The San Francisco router detects a loop through the record-route object
(RRO), and LSP establishment fails.
You can easily solve this problem with the addition of a strict ERO that forces the
path message to use the Fargo-Miami link. The additional ERO effectively
removes the IGPs routing decisions from the equation. Note that adding a loose
ERO identifying the egress routers loopback address does not address the
problem. This is because the IGP at Fargo prefers the lower metric path back
through San Francisco when routing to the loopback address of Miami.
160
Partial ERO Example
ERO Processing Summary
If destination address of RSVP message matches local router:
Local router is the egress node
End ERO processing
Send reservation message along the reverse path to ingress
Else, examine ERO
If first subobject does not match local node, then generate error
If there is no second subobject, then ERO processing is complete;

remove ERO from path message
Determine next hop to address in second subobject
Local router might or might not be the egress node
If ERO object is strict, verify that physical next hop is directly

connected, else declare an error
Pop/rewrite ERO stack and forward to physical next hop
RSVP Message Addresses to Local Router

If the destination address of the RSVP path message belongs to the local router,
this router is the egress router, and there is no need to process the ERO list
further (its job is done, and the ERO list should now be empty anyway). In this
case, the egress router should generate a resv message back towards the ingress
router. Recall that while LSPs are unidirectional, the signaling protocol operates
bidirectionally between ingress and egress nodes.
Nonegress Router ERO Processing

If the destination address of the RSVP path message does not belong to the local
router, the router examines the first ERO subobject. This entry must match the
local router or an error is declared, and LSP establishment fails.
The router next evaluates the second ERO subobject; if this object also matches
the local node, the ERO stack is popped, and the process is repeated (the second
subobject has now become the first subobject). If the second subobject does not
match the local node, the routing table is consulted to determine the physical next
hop used when forwarding towards the address identified in the second
subobject.
If the second subobject indicates a strict hop, the forwarding next hop in the
routing table must point to a directly connected link associated with that address.
If this is not the case, a routing error is declared, and ERO processing stops.
Before forwarding the path message to the downstream node, the first subobject
is either popped or replaced as needed so that the first subobject in the ERO
correctly matches the downstream node. Recall that a node declares an error
when the first ERO subobject in the list does not match the local router.
ERO Processing Summary
161
Named Path Configuration Example

[edit]
user@host# show protocols mpls
to 192.168.5.1;
no-cspf;
primary use-fargo;
}
path use-fargo {
192.168.1.2 loose;
10.0.3.39 strict;
}
interface all;
interface fxp0.0 {
disable;
}
Named path referenced within LSP definition
Loopback addresses preferred for loose hops

Strict hops must point to directly connected neighbor;
the default is strict when a hop type is not specified
Figure 44: Named Path Configuration Example

The configuration example on the slide builds on the configuration of a basic
RSVP-signaled LSP by linking the LSP to a named path containing ERO
information. This example forces the LSPs routing through 192.168.1.2 (Fargo)
using a loose hop, and then requires that the LSP be forwarded directly to
10.0.3.39 (Miami) with a strict hop. In this example, the router with address
192.168.1.2 must have an interface associated with a direct route to 10.0.3.39, or
LSP establishment fails because the strict hop cannot be honored.
The example on the slide shows how an LSP is associated with a named path
using the primary or secondary keyword in the LSPs definition. The argument
to a primary or secondary keyword is a user-defined variable, normally in the
form of a name, that links the LSP to a path definition. The related path contains a
listing of loose and/or strict ERO hops that become the ERO in the resulting path
message. Note that the named path can be empty, in which case you have a
primary or secondary LSP path with a null ERO list.
Current best practice uses the loopback address of the target router when
configuring a loose hop. This way, if an interface or link fails, the ERO can still be
honored as long as a route to the nodes loopback address is still available. For
strict hops you should use the IP address associated with the directly connected
neighbors interface.
You can configure complete (strict) and incomplete (loose) path information in the
named path (in this example, use-fargo). With a complete path, you specify
every router hop between ingress and egress, preferably using strict hops. With
an incomplete path, you specify only a subset of router hops using the loose
attribute. With incomplete paths, each router must determine only enough
information to reach the loose hop currently at the top of the ERO list. It might be
necessary to traverse a number of routers to reach the next (loose) hop.
162
ERO Case Study
Establish an LSP between San Francisco and Miami that transits Fargo
Ensure that interface or link failure at San Francisco does not prevent
establishment of the LSP
192.168.1.2
Fargo
San
Francisco
192.168.5.1
10.0.3.39
Miami
Figure 45: ERO Case Study
ERO Configuration Case Study

In the example on the slide, you must establish an LSP from San Francisco to
Miami with the requirement that the LSP must pass through the Fargo router. A
key aspect of the case study is the stipulation that the failure of any interface or
link at the San Francisco router cannot prevent successful establishment of the
LSP. By using a loose ERO, the LSPs routing can adapt to changes in network
conditions, such as the link failure shown on the slide. A strict ERO between the
ingress and first-hop LSRs does not satisfy the requirements of this case study
because a failure of the associated interface or link results in a failure of the LSP.
With a loose transit point, the path message can be rerouted around topology
failures while still satisfying the ERO, assuming, or course, that the Fargo router
remains reachable from San Francisco. A working configuration for the case study
LSP is shown here:
[edit protocols]
mpls {
to 192.168.5.1;
primary use-fargo;
no-cspf;
}
path use-fargo {
192.168.1.2 loose;
}
}
Note that the path information identifies the IP address of the Fargo station as a
loose hop. The keyword primary and associated use-fargo argument link the
LSP to the ERO listing.
ERO Case Study
163
Modifying Named Paths
The CLIs rename and insert commands allow easy modification of named
paths
[edit protocols mpls path SJ-pri]

user@host# show
10.0.2.1 strict;
10.0.24.2 strict;
10.0.31.2 strict;
10.0.13.1 strict;
10.0.15.2 strict;
user@host# insert 10.0.13.1 before 10.0.2.1
user@host# show
10.0.13.1 strict;
10.0.2.1 strict;
10.0.24.2 strict;
10.0.31.2 strict;
10.0.15.2 strict;
Figure 46: Modifying Named Paths
Ways to Modify Named Paths

You can use the JUNOS software rename and insert commands to easily
modify existing ERO or to add additional ERO as needed.
In this example, we use the insert command to resequence the ERO list by
placing 10.0.13.1 before 10.0.2.1. The rename command is handy for correcting
mistakes. In the example, the 10.0.15.2 address was incorrectly entered as
10.0.15.22; this mistake is corrected with the CLIs rename function:
user@host# show
10.0.13.1 strict;
10.0.2.1 strict;
10.0.24.2 strict;
10.0.31.2 strict;
10.0.15.22;
user@host # rename 10.0.15.22 to 10.0.15.2
user@host # show
10.0.13.1 strict;
10.0.2.1 strict;
164
10.0.24.2 strict;
10.0.31.2 strict;
10.0.15.2;
165
Use the show rsvp session detail or show mpls lsp extensive
command to confirm LSP routing
Both commands display the results of the record-route object
The show RSVP session detail command also displays the

LSPs current ERO
user@host> show rsvp session detail ingress

Ingress RSVP: 1 sessions
192.168.28.1
LSPname: to-lo, LSPpath: Primary
Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 100224
Resv style: 1 FF, Label in: -, Label out: 100224
Time left:
-, Since: Thu Oct 2 12:28:01 2003
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 6 receiver 1505 protocol 0
PATH rcvfrom: localclient
Explct route: 10.0.1.1 10.0.24.2
Record route: <self> 10.0.1.1 10.0.24.2 10.0.29.1
Figure 47: Confirming LSP Routing

Use the show rsvp session detail or the show mpls lsp extensive
commands to display the contents of the record-route object (RRO). By examining
the contents of the RRO, you can confirm the routing of a given LSP.
The output of the show rsvp session detail command displays the LSPs
current ERO list. The example on the slide shows that the ERO for the ingress
session to 192.168.28.1 contains two ERO entries: 10.0.1.1 and 10.0.24.2. The
contents of the RRO confirms that the LSP was routed according to the ERO
directives in that both of the ERO addresses are present in the RRO list.
Previous pages noted that the ERO list is manipulated by each router processing
the path message. This behavior is evident in the capture shown below. This
capture was taken at the first downstream router (10.0.1.1) handling the to-lo
LSP. Note that the ERO now contains a single entry as a result of this router
popping the ERO stack:
user@10.0.1.1> show rsvp session transit detail
Transit RSVP: 1 sessions
192.168.28.1
LSPname: to-lo, LSPpath: Primary
. . .
166
Resv style: 1 FF, Label in: 100224, Label out: 100080

. . .
PATH rcvfrom: 10.0.1.2 (so-0/3/0.0) 72 pkts
Adspec: received MTU 1500 sent MTU 1500
Explct route: 10.0.24.2
Record route: 10.0.1.2 <self> 10.0.24.2 10.0.29.1
167
Review Questions
What is the difference between strict and loose ERO route constraints?
How do you configure an LSP to include routing constraints?
Why can specifying less than a complete list of ERO hops lead to LSP
establishment problems?
168
Review Questions
ERO-based routing constraints;
Loose versus strict hops;
Configuring routing constraints with named paths;
Lab 4: Routing Constraints

Lab Objective:
Perform traffic engineering using named paths and EROs to control the routing of
an LSP.
169
170
Chapter 6: Module 6: Firewall Filters
Chapter 6
Module 6: Firewall Filters
171
Module Objectives
Describe JUNOS software firewall filter syntax and how you can add or
manipulate terms
Describe three possible firewall filter match conditions and three actions
you can associate with a match condition
Explain the difference between Routing Engine and transit firewall filters
Configure a multiterm firewall filter
Use show commands to monitor and troubleshoot firewall filters
172
Module Objectives
JUNOS software firewall filter syntax;
Applying transit versus Routing Engine firewall filters;
Configuring a firewall filter; and
Firewall Filters
Firewall filter overview and syntax
How firewall filters are evaluated
Match conditions
Match actions and modifiers
Applying firewall filters
A firewall filter example
Firewall Filters
In the following section, we discuss the concept of the JUNOS Internet software
implementation of firewall filters. The topics included are:
How JUNOS software supports packet filtering, including transit filters and
filters to protect the routing engine.
Components of a packet filter, such as terms, match conditions, and actions.
The different conditions that a filter can match:
Numeric range matching (that is, for TCP/UDP port numbers);
Address filter matching (that is, for specific source/destination

addresses); and
Bit-field matching (that is, for TCP connection states).
The actions that can be taken on packets that match a JUNOS packet filter,
such as discard, reject, and logging, counting, and sampling.
How and where to apply the filter, as an input or output filter.
The process through which packet filters are evaluated through terms, match
conditions, and on to actions.
Firewall Filters
173
Firewall Filters
Filter packets are based on their contents and perform an action on packets
that match the filter
Filters can accept/reject/discard packets based on:
Address field
Protocol type
Port type
Bit fields
Internet Processor II ASIC-based filtering for transit traffic
Filters can trigger statistical analysis actions for network planning and
troubleshooting
Actions
On all M-series and T-series routers, you can control the packets destined to or
sent by the Routing Engine. On routers equipped with an Internet Processor II
ASIC only, you can also control packets passing through the router.
Accept/Reject/Discard
You can use the filters to accept, reject, or discard the packets that pass from the
routers physical interfaces to the Routing Engine. Such filters are useful in
protecting the IP services that run on the Routing Engine, such as Telnet, SSH,
and BGP, from denial-of-service (DoS) attacks . You can define input filters, which
affect only inbound traffic destined for the Routing Engine, and output filters,
which affect only outbound traffic sent from the Routing Engine. Filters can accept
or reject packets based on the contents of the packets address field(s), protocol
type, port type and number, or even bit fields in the packet header.
Internet Processor II Filtering

With the Internet Processor II ASIC, you also can use filters on traffic passing
through the router to provide protocol-based firewalls, to thwart DoS attacks, to
prevent spoofing of source addresses, to create access control lists, and to
implement rate limiting (policing). (To determine whether a router has an Internet
Processor or an Internet Processor II ASIC, use the show chassis hardware
command.)
Analysis
You can configure firewall filters to trigger sampling for statistical analysis on
transit interfaces. You can use these statistics for network planning or
troubleshooting.
174
Firewall Filters

[edit firewall family inet]
filter filter-name {
term term-name {
from {
match-conditions;
}
then {
action;
action-modifiers;
term implicit-rule {
then discard;
}
}
}
Syntax similar to policy statements
Defined under [edit firewall family] hierarchy level
Named filters, one or more terms
Terms processed sequentially
All packets match a term when a from condition is not specified
Implicit discard all for packets that do not match any term
Actions: accept, reject, and discard
Modifiers: log, count, sample, etc.
One filter per logical unit, per direction; the same filter can be used on many
interfaces
Syntax
A JUNOS software filter consists of one or more named terms, similar to a policy
statement. Each term (this keyword is required) has a set of match conditions
preceded by the keyword from, and a set of actions or action modifiers preceded
by the keyword then.
Hierarchy Level
Firewall filters are defined under the [edit firewall family
family-name] section of the configuration hierarchy.
One or More Terms

Firewall filter terms (at least one term is required) are processed sequentially. If
there is no from condition, then all packets match. If no packets match any term,
the default action is to discard the packet silently! Take care to make sure wanted
packets are not discarded. Use the CLIs insert, copy, and rename functions to
assist in the management of your multiterm firewall filters.
175
Actions and Modifiers

A filter can accept a packet for normal forwarding, discard a packet silently, or
reject a packet while sending an ICMP notification to the source IP address. You
can modify these actions by using count to increment a counter, log to save the
packet header to the routing daemon cache, syslog to log an alert to a log file,
loss-priority to set the packet loss priority (PLP) bit, sample to sample
traffic (when sampling is enabled), policer to rate limit matching traffic, or
forwarding-class to set the output queue (03) to which the packet is
queued.
One Filter per Unit, per Direction

You can configure one firewall filter per logical unit on a physical interface, but one
in each direction (input and output). You can use the same filter on many
interfaces.
176
Current Firewall Filter Syntax
Additional level of hierarchy added to support multiple protocol families
Support for the inet, inet6, and mpls families
Policers are now defined independent of a firewall filter at the [edit

firewall] hierarchy
Old style syntax is officially supported in Release 5.7 but might be depreciated
at a later time
Policer definition within firewall filter is hidden
Family inet policers can still be defined at the [edit firewall]

hierarchy using the hidden policer keyword
This chapter demonstrates the new syntax style
Current and Old Firewall Syntax

Juniper Networks modified JUNOS software firewall filter syntax to make use of
the family keyword to accommodate the addition of support for IPv6 and MPLS
filtering. The support of interface policers also triggered the change to policer
definitions not contained within a given firewall filter.
At one point, the old-style firewall filter syntax was being depreciated, but at the
time of this writing, both the old and new firewall filter syntax is officially supported
by the CLI. In effect, omitting the new family keyword results in a default
association with the inet family.
Note that the policer keyword is now hidden within a firewall filter; you should
now define policers at the [edit firewall] hierarchy using the new syntax, or
when dealing strictly with the inet family, at the [edit firewall filter
filter-name] hierarchy using the hidden policer keyword.
The examples in this module make use of the latest firewall filter and policer
syntax to prepare you for the future and to maintain alignment with the current
documentation set.
Current Firewall Filter Syntax
177
How Filters Are Evaluated
Single-term filters
If the packet matches all the conditions, the action in the then statement
is taken
If the packet does not match all the conditions, it is discarded
Multiple-term filters (terms evaluated sequentially)
JUNOS software sequentially evaluates the packet against the conditions

in each term's from statement, beginning with the first term:
If the packet matches, the action in the then statement is taken

If a packet passes through all the terms in the filter without matching
any of them, it is discarded
Single Terms
When a firewall filter consists of a single term, the filter is evaluated as follows: if
the packet matches all the conditions, the action in the then statement is taken; if
the packet does not match all the conditions, it is discarded.
Multiple Terms
When a firewall filter consists of more than one term, the filter is evaluated
sequentially. First, the packet is evaluated against the conditions in the from
statement in the first term. If the packet matches, the action in the then statement
is taken. If it does not match, it is evaluated against the conditions in the from
statement in the second term. This process continues until either the packet
matches the from condition in one of the subsequent terms or there are no more
terms.
If a packet passes through all the terms in the filter without matching any of them,
it is discarded.
If a term does not contain a from statement, the packet is considered to match,
and the action in the terms then statement is taken.
If a term does not contain a then statement, or if you do not configure an action in
the then statement (that is, the packet is just logged or counted), and if the
packet matches the conditions in the terms from statement, the packet is
accepted.
178
How Filters Are Evaluated
Overview of Match Conditions
Firewall match conditions
Generally, each term in a filter has a match condition
Terms without a from statement match all traffic
The from statement specifies the conditions the packet must match for
the action to be taken
Multiple match conditions possible per term
All conditions in the from statement must match (logical AND)
Several categories of match conditions
Numeric-range filter
Address filter
Bit-field filter
Firewall Match Conditions

The from statement in a firewall term specifies the match criteria. Specifying an
action without a from condition creates a term that matches all possible traffic.
The from Statement Sets Match Conditions

In the from statement in the firewall filter term, you specify conditions that the
packet must match for the action in the then statement to be taken. All conditions
in the from statement must match for the action to be taken. The order in which
you specify match conditions is not important because a packet must match all the
conditions in a term for a match to occur. If you specify no match conditions in a
term, that term matches all packets.
Match Condition Categories

An individual condition in a from statement can contain a list of values. For
example, you can specify numeric ranges or multiple source or destination
addresses. When a condition defines a list of values, a match occurs if one of the
values in the list matches the packet.
You can negate individual conditions in a from statement. When you negate a
condition, you define an explicit mismatch. If a packet matches a negated
condition, it is immediately considered not to match the from statement, and the
next term in the filter is evaluated. If one exists or if there are no more terms, the
packet is discarded.
Match conditions are grouped into the following categories depending upon how
you specify the condition:
Numeric-range filter match conditions;
Address filter match conditions; and

179
180
Bit-field filter match conditions.
Numeric Range Filter Match Condition
Match packet fields that can be identified by a numeric value
Port and protocol numbers
Specify a keyword that identifies the condition and a value that a field in a
packet must match
source-port 1024-65535
source-port smtp
Keywords identifying available fields:
destination-port, dscp, fragment-offset, icmp-code,

icmp-type, interface-group, packet-length, port,
precedence, protocol, source-port
Numeric Matches
Numeric range filter conditions match packet fields that can be identified by a
numeric value, such as port and protocol numbers. For numeric range filter match
conditions, you specify a keyword that identifies the condition and a single value
or a range of values that a field in a packet must match.
Format
The keyword identifies the condition and a value that must match follows. Some
common numeric values have predefined symbolic names (for example, Telnet =
TCP port 23) or text synonym. In these cases, you can use either the numeric or
the symbolic name as a match condition.
Keywords
The table shows the keywords used with numeric match conditions. In some case,
there might be a symbolic name for the numeric valuethat is, configuring
source-port telnet is the same as configuring source-port 23.
Table 1: Keywords Used with Numeric Match Conditions
181
182
Keyword
Description
destination-port
number
Value of TCP or UDP destination port field
dscp number
Differentiated Services code point
fragmentation-offset
number
Fragmentation field
icmp-code number
ICMP code field
icmp-type number
ICMP type field
interface-group
group-number
Interface group on which packet was received
packet-length bytes
Number of bytes in packet length field
port number
TCP or UDP
precedence ipprecedence-field
Value in IP packet precedence field
protocol number
IP protocol field value
source-port number
Value of TCP or UDP source port field
Address Filter Match Condition
IP source and destination prefixes
Keywords available
address prefix (source or destination)
destination-address prefix
source-address prefix
Address matches are longest or
IP Prefixes
Address-related key words match prefix values in a packet, such as IP source and
destination prefixes. For address-related match conditions, you specify a keyword
that identifies the field (source, destination, or neither for both) and one or more
prefixes of that type that a packet must match.
Keywords
You can use three keywords with the firewall filter IP address match condition:
address (matches either source or destination IP address in the packet);
destination-address (matches only the destination field in the IP packet); or
source-address (matches only the source address in the IP packet).
With a single prefix, a match occurs if the value of the field matches the prefix, for
example: destination-address 10.0.0.0/8;. With multiple prefixes, a
match occurs if any of the prefixes in the list matches:
destination-address {
10.0.0.0/8;
192.168.0.0/32;
}
Longest Match
Multiple prefixes are matched based on the usual longest-match rules, a kind of or
condition. In other words, only one prefix in a list produces a match.
Address Filter Match Condition
183
Bit-Field Match Condition
Match on specific bits in certain packet fields
You can specify bit fields with symbolic names or numeric values
Bit matching for IP options, fragment flags, and TCP flags
Note: Specification of a bit field does NOT imply the corresponding

protocol
Grouping (), negation (!), and support for logical AND (& or +), logical OR (|
or ,) functions
Matching on Bits
Bit-field match condition filters match on packet fields if particular bits in those
fields are set or not set. You can match on the IP options, TCP flags, and IP
fragmentation fields. For bit-field filter match conditions, you specify a keyword
that identifies the field and tests to determine that the option is present in the field.
Symbolic Names
Bit field matches can use symbolic names for the most common bit configurations.
Generally, you specify the bits tested using keywords. Bit-field match keywords
always map to a single bit value. You also can specify bit fields as hexadecimal or
decimal numbers.
Bit Matching
To specify the bit-field value to match, enclose the value in quotation marks
(double quotes). For example, a match occurs if the RST bit in the TCP flags field
is set as:
tcp-flags
rst;
To negate a match, precede the value with an exclamation point. For example, a
match occurs only if the RST bit in the TCP flags field is not set:
tcp-flags
!rst;
You must take care when it comes to bit matching when a specific protocol is not
specified. In other words, just using tcp-flags in no way assures that only IP
packets with TCP segments inside will be examined by the firewall filter. If an IP
packet containing OSPF information (for example) happens to have the right
combination of bits where the TCP flags would be in a TCP segment, an
unintended match will occur.
The general syntax for bit-field match conditions is:
fragmentation-flags keyword or number
ip-options keyword or number
tcp-flags keyword or number
184
Logical Operators
Bit matching supports several logical operators as a match condition in a firewall
filter. These operators have a distinct precedence from high to low when they are
combined in the same match condition.
The following table lists the bit-field logical operators from highest precedence to
lowest:
Table 2: Bit-Field Logical Operators
Logical Operator
Description
()
Grouping of bit-field match conditions
Negation of bit field
& or +
Logical AND between bit-field matches
| or ,
Logical OR between bit-field matches
185
Bit-Field Match Examples

IP Options
loose-source-route (131)
Strict-source-route
record-route
router-alert (148)
Timestamp
(7)
( 137)
(68)
TCP Flags
ack (0x10)
fin (0x01) push (0x08)
rst (0x04)
syn (0x02) urgent (0x20)

Example: tcp-flags (0x01 & 0x02) is equal to tcp-flags 0x03
Text Synonyms
first-fragment (matches offset = 0, MF = 1)
tcp-established: Equivalent to (ack | rst)
tcp-initial: Equivalent to (syn & !ack)
Figure 48: Bit-Field Match Examples
Bit-Field Match Conditions

The following table lists the bit-field match conditions you can use with variables in
a firewall filter:
Table 3: Bit-Field Match Conditions Used in a Firewall Filter
186
Match Condition
Description
Conditions with variables

fragment-flags
number
IP fragment flags. Also recognizes text synonyms

dont-fragment (0x4000), more-fragments
(0x2000), and reserved (0x8000).
ip-options number
IP options. Also recognizes text synonyms loosesource-route (131), record-route (7),

router-alert (148), strict-source-route
(137), or timestamp (68).
tcp-flags number
TCP flags. This should be used with the protocol

tcp match condition to make sure that only packet
containing TCP are tested for a match.
Also recognizes text synonyms ack (0x10), fin
(0x01), push (0x08), rst (0x04), syn (0x02) and
urgent (0x20).
The following table lists the various text synonyms that you can use in a firewall
filter:
Table 4: Text Synonyms Used in a Firewall Filter
Match Condition
Description
Text Synonyms
first-fragment
First fragment of a fragmented packet. This condition

does not match unfragmented packets.
is-fragment
This condition matches if the packet is a fragment.
tcp-established
This condition matches TCP packets other than the first

packet of a connection exchange. This is a text synonym
for (ack | rst). This condition should be used with
protocol tcp.
tcp-intial
This condition matches first TCP packet of a connection.

This is a text synonym for (syn & !ack).
This should be used with protocol tcp.
187
Firewall Actions Overview
Overview
Actions fall into two categories
Actions: accept, discard, and reject
Action modifiers: count, sample, and log/syslog
Default action is discard
Use of an action modifier creates an implicit accept (a sampled

packet automatically is accepted unless an explicit reject is included
in the term)
Firewall Actions
When a match occurs, various JUNOS software can perform actions and action
modifiers on the packet.
A packet can only be acted upon once; once JUNOS software performs a
terminating action, that packet will not be subject to any further term processing.
JUNOS software supports a wide variety of possible actions when matches occur.
We discuss in the following pages the actions shown on this slide.
188
Firewall Actions Overview
Action Statements
Three action statements:
accept: The packet is accepted for forwardingno other term is

analyzed
reject message-type: The packet is rejected, and the corresponding

ICMP message is generated; no other term is analyzed
discard: The packet is silently discarded, and no other term is analyzed
Provides better securityvery useful for DoS attacks due to address

spoofing or the use of zombies
Action Statements
In the then statement of a firewall filter term, you specify the action to take if the
packet matches the conditions in the from statement. In addition, you can specify
action modifiers, as in the example here.
filter filter-name {
term term-name {
then {
action;
action-modifiers;
}
}
}
You can specify zero or one then statement in a filter term. If you omit the then
statement or do not specify an action, the packets that match the conditions in the
from statement are accepted. This default accept with a match but no then
action behavior can be contrasted with the default discard action when there is no
match, regardless of action.
You can specify one of the following filter actions:
Table 5: Filter Actions
Action
Description
accept
The packet is accepted and is sent to its destination.
discard
The packet is not accepted and is not processed further (silent discard).
reject
The packet is not accepted, and an ICMP rejection message is returned.
In the filter action statement, you can also specify one or more of the following
action modifiers. The packets are still accepted, rejected, or discarded, but these
actions also are performed regarding the packet.
Table 6: Action Modifiers
Action Statements
189
190
Action Statements
Action Modifier
Description
alert
Log an alert for the packet.
count
Count the packet.
log
The packets header information is stored on the Routing

Engine or sent to a server.
output-queue
Set the output queue to a specified value.
losspriority
Set the packet loss priority (PLP) bit to the specified value.
sample
Traffic is sampled. Use only if you enabled traffic sampling.
Reject Message Options
Based on configuration, the reject action generates one of the following:
administratively-prohibited (default)
bad-host-tos, bad-network-tos
host-prohibited, host-unknown, host-unreachable
network-prohibited, network-unknown, network-unreachable
port-unreachable
precedence-cutoff, precedence-violation
protocol-unreachable
source-host-isolated, source-route-failed
tcp-reset
Generates a TCP reset segment when the rejected traffic is TCP, or

else no response is generated
Reject Options
If you specify reject as the match action, the sender of a packet will receive an
ICMP administratively prohibited message. However, if your goal is to
keep unauthorized traffic out of your network, you might not want to inform a
potential intruder that you use firewall filters to block traffic. As a result, you can
use the reject action to return ICMP messages other than
administratively prohibited.
Such alternative messages can be helpful if a suspected hacker is monitoring
ICMP return messages for helpful information. In many cases,
administratively prohibited is a clear sign to a hacker that a firewall filter
has been reached.
All of the possible ICMP message types are listed on the slide. For example, this
reject action generates a port unreachable ICMP message sent back to
the source:
then {
reject port-unreachable;
}
Note that this ICMP message could be generated for the IP addresses or other
match conditions listed in the from statement. The port might actually be up and
running.
Reject Message Options
191
Action Modifiers
counter-name
The corresponding counter is incremented
Clear with clear firewall [all | counter-name |

filter-name]
Logging
View with show firewall filter-name
The packet sample is logged to the routing daemon cache
View with show firewall log
No clear commanddisplays most recent entries first
Also can log to syslog with syslog action
Sampling
Packets are sampled and written to a file based on sampling settings
Specified under the forwarding-options hierarchy
Local ASCII files and cflowd version 5|8 export
Counters
Counters run in the Internet Processor II ASIC at wire speed and completely
independently from the CPU. You can configure them to run full time to track
particular traffic types or you can configure them to run part time to explore or
track the state of the network.
You can configure filters that target the exact nature of traffic on a network and, by
counting different packets, provide visibility into the packet types traversing the
system. For example, you can configure a filter that counts all packets sourced
from a range of specific /24 IP address prefixes entering a network by way of a
peering connection.
Logging
Logging is used for instant notification of ongoing network events. Logging
examines every packet that matches the filter and displays the matches in real
time on the console. The router does not log data on the hard disk; you can
access the logged data only by using the routers CLI.
192
Action Modifiers
Sampling
Statistical sampling examines a user-specified percentage of the traffic traversing
the system. Understanding the amount of different types of network traffic allows
for planning future capacity, network design, and deployment for both internal
circuits (intradomain) and external circuits (interdomain), as well as for
determining whether you must establish new peering relationships. Sampling
theory shows that statistical sampling can be quite accurate if you select the
sampling parameters properly.
Action Modifiers
193

interfaces {
interface-name {
unit logical-unit-number {
family inet {
filter {
input filter-name;
output filter-name;
}
}
}
}
Filters must be applied to an interface to take effect
A common filter can be applied to multiple (or even all) interfaces
Each interface can support two filters per logical unitone input and one
output
Apply the filter to the loopback interface for Routing Engine protection
Applying Filters
Finally, to use a JUNOS software filter, you must apply it to an interface. You can
apply a filter to either input or output interfaces or groups of interfaces, and you
can apply the same filter to more than one interface or to a group of interfaces.
If you apply a filter to an interface, the Internet Processor II ASIC checks every
packet received or forwarded on that interface against the match conditions in
each term in the filter. If the packet matches all the conditions in a term, the
actions listed in the then statement for that term are executed, and no more
terms are checked. When developing filter terms that count or log packets, make
sure these packets are not accepted or rejected by previous terms.
Common Filters
You can apply very common filters to multiple, or even every, interface on the
router.
Input and Output

Each logical unit on a physical interface can have only one input and output filter.
Protecting the Routing Engine

To enable a firewall filter to filter traffic to or from the Routing Engine, apply the
filter to the loopback interface (lo0) of the routing engine. Normally, this filter is
applied as an input filter to lo0.
194
Transit versus Routing Engine Filters

z
Apply filters to lo0 for

added Routing Engine
protection
Remember to
accommodate your
routing and remote access
protocols!
FPC z
n
JUNOS software does not

support sampling on lo0
Routing
Engine
lo0
FPC
0
0
1
2
3
Input
IP II
Output
Packet
Forwarding
Engine
0
1
2
3
Figure 49: Transit versus Routing Engine Filters
Apply filters to PFE ports for transit filtering, sampling, and cflowd export
Protecting the Routing Engine

Transit firewall filters act on the packets that flow directly from one interface to
another on the router. These filters can protect sites from unauthorized access
and other threats. But what about protecting core routers from unauthorized
management access and other harmful effects? This is the idea behind applying a
firewall filter to the Routing Engine.
Traditionally, two types of tools are used in a layered fashion to protect core
routers. The first line of defense is the routers remote access management policy,
which is essentially an IP address list. Management access to the router (for
example, using Telnet or SNMP) requires an allowed source IP address. After the
source IP address is verified, a second tool, such as passwords or one-time
passwords, provides a second layer of security.
The Internet Processor II ASIC also adds a third layer of security to protect
against attacks to the core. Applying filters that perform source address
verification at ingress points of a network ensures that hackers cannot spoof the
source address of network operations center (NOC) systems at the ingress edge
of the network.
The overall benefits of applying a firewall filter to lo0 on the Routing Engine and
other interfaces are:
The added security to protect routers from unauthorized access;
Permanent filters do not impact forwarding performance; and
Hardware filtering does not impact the Routing Engine.
195
Careful!
Firewall filters applied to the Routing Engine lo0 must be configured carefully to
allow routing protocol and other forms of necessary information to reach the
Routing Engine. The default silent discard can be the cause of unintentional
effects. Also, only PFE transit filters can sample traffic and generate cflowd
information export.
Default Discard All

Each firewall filter has an implicit discard action at the end of the filter, which is
equivalent to the explicit filter term:
term implicit-rule {
then discard;
}
Therefore, if a packet matches none of the terms in the filter, it is discarded.

Naturally, you must ensure that a firewall filter behaves as intended. In some
cases, you might want to override the default discard by adding a last term to
accept all packets that do not match a firewall filters series of match conditions:
term override-discard {
then accept;
}
(Theoretically, a null term should have the same effect because the default from
behavior is to match all packets, and the default then behavior is to accept all
packets. However, the CLI does not allow the configuration of such a null term in a
firewall filter. Explicitly configuring an action is always the preferred method.)
196
Sample Topology
Subscriber
Location
Provider
192.168.0/24
.2
FTP/
WWW
Server
.10
ge-0/1/0
Traffic
Generator
.1.0
.2
.0.0
ge-7/1/0
Premise
Router
Inbound
Internet
(10/24)
.1
Hub
.100
Power
User
Outbound
Note the directionality associated with the
terms inbound and outbound.
Figure 50: Sample Topology
Example
To illustrate some firewall filter configuration examples, we use the following
sample topology. The topology consists of a subscriber location with a connection
to the Internet. There are multiple types of users and IP services on the customer
side of a premise router. The premise router does no filtering in the following
examples. The premise router connects to the Internet using a Juniper Networks
M-series router that implements different firewall filters.
The IP addresses and router interfaces used in these examples appear in the
figure. Note the directions associated with the terms inbound and outbound in the
figure. The firewall filter uses the terms input and output not from the perspective
of the site, but of the router (technically, the Internet Processor II chip in the PFE).
So traffic outbound from the site router is input to the firewall filter on that M-series
router interface.
Sample Topology
197
Spoof Prevention
Internet
Subscriber
Location
ge-7/1/0
Screening
Router
FTP/
WWW
Server
Power
User
.100
.10
Hub
192.168.0/24
Rule 1: Input
From SA = 192.168.0
Then Accept
From SA = other
Then Reject
Rule 1 prevents the

origination of spoofed
packets from this site
Rule 2: Output
From SA = 192.168.0
Then Reject
From SA = other
Then Accept
Rule 2 blocks spoofed

packets from entering
this site
Figure 51: Spoof Prevention
Stopping Spoofs
IP address spoofing is the practice of sending IP packets with source IP
addresses that are not the addresses of the sending devices. You can use firewall
filters to prevent spoofed packets from being sent from the customer site to the
Internet. The details of the two rules shown on the slide are:
198
Spoof Prevention
Rule 1: A logical statement that blocks these packets. The firewall filter only
accepts packets outbound from the site (input to the M-series router) that
have the sites IP address space in the source address field. This stipulation
prevents spoofed packets from leaving the site and protects other sites.
Similarly, spoofed packets originating from the Internet can be blocked from
going to the customer site.
Rule 2: A logical statement that blocks these packets. The firewall filter only
accepts packets (that is, processes and forwards packets) inbound to the site
(output to the M-series router) that have addresses other than the sites IP
address space in the source address field. This rule protects the site itself. If a
packet claims to originate from the site but is coming from the Internet, the
packet is rejected (the packets in both sample rules also could be discarded,
and probably would be in actual practice).
Inbound Spoof Prevention

lab@router# show
filter no-spoofs-in {
term allow-valid {
from {
source-address {
192.168.0.0/24;
10.0.0.0/24;
}
}
then accept;
}
term reject {
then {
count bad-source-address;
log;
discard;
}
}
}
FTP/
WWW
Server
M40
.100
.10
10.0.0/24
.1
.2
ge-7/1/0
Power
User
Screening
Router
Hub
.1
192.168.0/24
Applied as input filter on subscriber interface

[edit interfaces ge-7/1/0]
lab@router# show
unit 0 {
family inet {
filter {
input no-spoofs-in;
}
address 10.0.0.2/24;
}
}
Figure 52: Inbound Spoof Prevention
Inbound Spoofs
Rule 1 from the previous slide is implemented with the associated firewall filter
statements defined in a firewall filter named no-spoofs-in. This filter first allows
packets with any valid source IP address coming from the screening router or
beyond (that is, any address from the 192.168.0/24 customer LAN plus the
10.0.0/24 link between the customer premise router and the service provider M40
router). Then, all other packets are rejected, and each dropped packet increments
the user-defined counter bad-source-address. The filter would drop these
packets anyway because of the implicit discard, but the count statement allows
the number of dropped packets to be counted. You can display the value of this
counter using the show firewall command in CLI operational mode.
Remember to Apply!
Once you define the filter, you must apply it to the appropriate logical unit under
family inet. This filter is constructed logically to match traffic originating from
the customer site, so it is applied as in input filter on the service provider router.
This slide does not show the implementation of Rule 2 from the previous slide, but
a similar approach could be taken. A filter that allows packets with certain
destination addresses (that is, any packets destined for the customer segment or
the screening router) could be applied outbound (as an output filter) on unit 0 of
interface
ge-7/1/0.
Inbound Spoof Prevention
199
Pop Quiz!
[edit firewall]
lab@router# show
family inet {
filter pop-me {
term telnet {
from {
protocol tcp;
port telnet;
}
then accept;
}
term ping {
from {
protocol icmp;
}
then accept;
}
}
}
M40
OSPF
10.0.0/24
Power
User
Screening
Router
Hub
192.168.0/24
Shortly after applying this filter to

the lo0 interface, the users
Telnet session hangs and cannot
be reestablished
Any ideas?
Figure 53: Pop Quiz
Quiz
The slide shows a firewall filter named pop-me that has the two terms shown. We
want only the power user to allow Telnet and pings into the Routing Engine in the
router, so we apply it to the loopback lo0 interface. However, very quickly after
the filter is applied, the power user loses all access to the Routing Engine via
Telnet!
Whats wrong with this picture? This firewall filter has been foiled by the dreaded
implicit discard all that lurks at the end of every firewall filter but is never seen.
The power users Telnet sessions and ICMP packets are allowed explicitly. Thus,
all other forms of traffic, such as routing protocol keepalives and updates, are
denied implicitly and so unable to reach the Routing Engine. Therefore, things
quickly grind to a halt. The proper situation in the Routing Engine only can be
restored via a Routing Engine management interface.
200
Pop Quiz!
Preventing Fragmentation Exploits

[edit firewall]
lab@San_Jose-3# show
family inet {
filter no-frags {
FTP/
Power
WWW
M40
term 1 {
User
Server
from {
.100
.10
10.0.0/24
is-fragment;
Screening
Hub
protocol [ icmp udp ];
Router
.2
.1
.1
192.168.0/24
}
then {
count no-frags;
Filter applied in output direction of subscriber interface
log;
[edit interfaces ge-7/1/0]
discard;
lab@router# show
}
unit 0 {
}
family inet {
term 2 {
filter {
output no-frags;
then accept;
}
}
address 10.0.0.2/24;
}
}
}
}
Figure 54: Preventing Fragmentation Exploits
Problems with Fragments

Routers inherently adapt IP packet sizes to the MTU size supported by an
interface when moving data from interfaces with one media MTU size to interfaces
with smaller MTU sizes. Routers do this through the process of fragmentation,
which takes a large IP packet and slices it up into smaller pieces. The first piece of
a large packet is not considered a fragment, but all of the subsequent packets
belonging to the original large IP packet are marked as fragments.
Certain denial-of-service (DoS) attacks take advantage of this mechanism by
sending large pings that must be fragmented, which in turn forces the receiver to
respond to many ICMP echo requests and consume cycles with reassembly
actions. Worse yet, some exploits generate malformed fragments that can result
in an operating system reboot or the shutdown of the machines TCP stack.
Because ping is designed to demonstrate reachabilityand nothing morefew
valid reasons exist for valid ICMP echo-request traffic being fragmented in todays
networks.
You can protect a site from a variety of ping-based DoS attacks, such as
Teardrop, Boink, and others, with a firewall filter that prevents reassembly of
fragmented ICMP or UDP packets. Here, the is-fragment keyword in term 1
matches on all intermediate and last fragments associated with either the UDP or
ICMP protocols; the associated discard action ensures that reassembly cannot
occur in the target host. It bears stressing that the first fragment, which has an
offset of 0, is not matched by the is-fragment keyword. Use the
first-fragment keyword to mach on the first fragment when needed.
By implementing such a filter on the outbound (output) direction at the service
provider router, bandwidth is not wasted on the link between the provider and the
customer when DoS attacks of this type take place. Also, this firewall filter counts,
logs, and discards fragmented ICMP and UDP packets.
201
Note the use of the final term to override the implicit discard all and to allow
normal-sized diagnostic pings, UDP, and other forms of traffic to reach the site.
202
Securing the FTP/WWW Server
[edit firewall family inet filter ftp-www-only]

lab@San_Jose-3# show
term allow-ftp-www {
from {
FTP/
Power
M40
WWW
192.168.0.10/32;
User
Server
}
.100
.10
10.0.0/24
protocol tcp;
destination-port [ ftp ftp-data http ];
Screening
Hub
}
Router
.2
.1
.1
192.168.0/24
then accept;
}
term reject-other {
interfaces ge-7-1/0 {
from {
unit 0 {
family inet {
192.168.0.10/32;
filter {
}
}
output ftp-www-only;
then {
}
count unauthorized-service-requests;
}
log;
}
Filter applied
discard;
in output direction of
}
}
subscriber interface
}
term accept-all {
Remember the implicit deny all for unmatched
then accept;
traffic!
}
Figure 55: Securing the FTP/WWW Server
Server Security
This filter allows only FTP and HTTP data to reach the FTP/HTTP server at the
customer site. It counts and logs any unauthorized attempts to access other
services on that server (such as might be done during a hacker port scan of the
server to find active ports). It also allows the power user device to do anything it
wants because the power users address is not matched by any term and instead
is subject to the explicit accept in the last term of the filter.
At first, the use of the terminology from destination-address might seem
jarring. How could something be from a destination address? Think of from as
meaning more like out of all packets.... Thus, in the case of this firewall filter as
applied, the use of the term from is more like out of all the packets output on this
interface, look at those with a destination address of.... Thus, the destination
address is properly the address of the FTP and Web server.
Again, note the use of the final accept to override the default filter behavior.
Securing the FTP/WWW Server
203
Outgoing Service Restriction

lab@San_Jose-3# show filter user-control
term normal-user-allow {
from {
0.0.0.0/0;
192.168.0.100/32 except;
}
protocol tcp;
source-port http;
tcp-established;
}
then accept;
}
term track-unauthorized {
from {
0.0.0.0/0;
192.168.0.100/32 except;
}
}
then {
count unauthorized;
discard;
}
}
term power-user {
then accept;
}
Filter applied in output direction to filter

response traffic!
FTP/
WWW
Server
M40
Power
User
.100
.10
10.0.0/24
.2
.1
Screening
Router
Hub
.1
192.168.0/24
.50
Restricted
User
Note the use of except, which

exempts the power user from a
particular terms in this filter
Figure 56: Outgoing Service Restriction
Restricting Services
This filter shown here is more elaborate than the previous examples. Here, we
want to allow the power user to do basically as he/she pleases, but to restrict
traffic to other users, including the FTP and Web servers.
This filter shows two primary features: the use of the except keyword, which
inverts a match condition to a non-match and functions in this example to exempt
the power users address from the first two terms; and the keyword
tcp-established, which, allows TCP sessions that originate from the
customer segment while blocking TCP sessions that originate from the Internet.
Note that the user-control firewall filter is applied in the output direction, which
causes it to filter response traffic (as opposed to request traffic initiated by the
customer).
204
Outgoing Service Restriction
Rate Policing
Instead of allowing or dropping packets that meet match conditions, you can
use a filter to identify traffic that is to be policed (rate-limited)
Traffic that matches the filter is then policed according to an average

bandwidth and a burst size
You can apply a policer directly to an interface to rate-limit all traffic

associated with that protocol family
Can specify bandwidth as a percentage of interface speed
When traffic exceeds the policing parameters, it can:
Be discarded
Have its loss-priority (PLP) bit set
Be associated with a forwarding class (output queue)
Filters Identify Traffic for Rate-Limiting

Firewalls filters can not only drop or accept packets but can also be used to police
or rate-limit traffic. Rate policing enables you to limit the amount of traffic that
passes into or out of an interface. Firewall filters that use rate policing still employ
normal match conditions, such as addresses, protocols, ports, and so on, to
determine which traffic on an interface is subject to rate limiting. As usual, lack of
a from subjects all packets on the interface (input or output, as the filter is
applied) to rate policing.
Recent JUNOS software releases accommodate interface-based policers that are
applied directly to a given protocol family on a given logical unit of a particular
interface. Such policers accommodate Layer 2 VPN traffic as well as the MPLS
and IPv6 families and operate without the need for a calling firewall filter. We
detail interface-based policers on a subsequent page.
Rate Limits
Policing applies two types of rate limits on the traffic: bandwidth, which is the
number of bits per second permitted on average, and maximum burst size, which
is the bursts of data that exceed the given bandwidth limit, but only up to a total
number of bytes given by this value. This value is usually set to ten times the
interfaces MTU for
low-speed interfaces. For interfaces that operate at OC-12 or above, the burst
size recommendation is interface speed times 35 milliseconds.
Policing employs the token-bucket algorithm, which enforces a limit on average
bandwidth while allowing bursts up to a specified maximum value. It offers more
flexibility than the leaky bucket algorithm (an interface configuration feature for
certain physical interface types) in allowing a certain amount of bursty traffic
before it starts discarding packets.
Rate Policing
205
Starting with JUNOS software Release 5.6, you can configure a policer with a
bandwidth restriction based on a percentage of the speed of the interface to which
the policer is applied.
Excess Traffic
You can define specific classes of traffic on an interface, to which you can apply a
set of rate limits. To do this, you define policers within a filter statement.
If a packet does not exceed its rate limits, it is processed further without being
affected. If the packet exceeds its limits, it is handled in one of two major ways,
depending on what you specify:
206
Rate Policing
The packet can be discarded. This does not discard all the traffic that matches
the filter match conditions; it only discards traffic that exceeds the traffic profile
definition.
The packet can be marked in one of two ways, by setting certain control
bits. These bits are the loss-priority (PLP) bit and the forwarding class (aka
output queue identifier) bits. You can set either the PLP bit or the forwarding
class, or both. (These topics fall under a full CoS discussion, which is beyond
the scope of this course.)
Rate Policing Example
[edit firewall]
lab@router# show
policer p1 {
if-exceeding {
bandwidth-limit 400k;
burst-size-limit 100k;
}
then discard;
}
family inet {
filter limit-ftp {
term ftp {
from {
source-address {
1.2.3.0/24;
}
protocol tcp;
destination-port [ ftp ftp-data ];
}
then {
policer p1;
count count-ftp;
}
}
}
}
z Example:
bandwidth-limit
In bits per second

30,520 bps to 4.29 Gbps
burst-size-limit
In bytes per second

Min should = 10 times
MTU (low speed) or
bandwidth times 35
milliseconds (high
speed)
Max = 16.7 Mb
Figure 57: Rate Policing Example
Example
The example on the slide rate-limits FTP traffic coming from the 1.2.3/24 range of
addresses. Because FTP is a TCP application, discarding packets that exceed the
traffic profile causes TCPs sliding window to shrink, which has the net effect of
the FTP session rate-limiting itself.
You configure policers at the [edit firewall] hierarchy. You can reference
multiple policers in a single filter, and you can use the same policer in multiple
filters simultaneously. To specify the rate-limiting aspects of a policer, include an
if-exceeding statement:
if-exceeding {
bandwidth-limit rate;
burst-size-limit bytes;
}
For example, you can define a bandwidth limit of 20 Mbps with a burst size limit of
500 KB (kilobytes):
if-exceeding {
bandwidth-limit 20m;
burst-size-limit 500k;
}
You specify bandwidth-limit in bits per second and burst-size-limit in

bytes. You can specify the value as a complete decimal number or as a decimal
number followed by the abbreviation K (1000), M (1,000,000), or G
(1,000,000,000).
207
There is no absolute minimum value for the bandwidth limit, but any value below
61,040 bps results in an effective rate of 30,520 bps. The maximum value is 4.29
Gbps. The maximum value for the burst-size limit is 16.7 MB. For low-speed
interfaces, you should configure a burst size that is at least 10 times the
interfaces MTU. For high-speed interfaces (above OC12-c), the recommended
burst-size is the interface speed multiplied by 35 milliseconds.
208
Interface-Based Policers
interfaces {
interface-name {
unit logical-unit-number {
family inet {
filter {
input filter-name;
output filter-name;
}
policer {
input policer-template;
output policer-template;
}
}
}
}
Figure 58: Interface-Based Policers
Two-Level Policers
Previous to JUNOS software Release 5.3, the only way to do interface policing
(rate limiting) of input and output traffic was to configure a firewall filter with a
then policer action modifier that was applied to the desired interface. The
purpose of interface-based policers is to allow a mechanism to support policing at
the protocol family level, independent of any firewall filters that may, or may not
be, applied to that interface.
Lets say you want to limit the bandwidth of an attached device to 30 M input and
output with a supported burst size of 200 K. With pre-JUNOS software Release
5.3, you were required to create a firewall filter to police the input and output traffic
along with any other filtering actions that you require, thus linking the policer and
firewall actions to the filter in question. The policer was then applied to the
interface using the filter option under the related protocol family as an input
and/or output filter.
With interface policers, you can apply a policer to an interface under a particular
protocol family in a manner that is independent of any firewall filters. All traffic
associated with the related family will be subjected to the action so the policer
because there are no match conditions for an interface policer.
Keep in mind that you can still call the policer from within firewall actions or you
can have your policer separate from any firewall actions. You can also define
different input and/or output policers to be applied to the desired interface as an
input or output policer.
Because an interface policer is evaluated before any firewall evokes policers, it is
possible to police the same traffic twice at ingress and two more times at egress,
using a combination of interface and firewall-evoked policers in both the input and
output directions.
Interface-Based Policers
209
Viewing Interface Policers

z
Use the show policer command to view a list of all

interface policers
Specify the policers name to display packets counts for that
policer only
lab@Montreal-3> show policer

Policers:
Name
foo-so-0/1/0.0-mpls-i
faa-so-0/1/2.0-inet-o
Policer name
The protocol family that

is being policed
Packets
0
0
Direction of policer
Packets exceeding the

policer s profile
Figure 59: Viewing Interface Policers
Viewing Policers (Part 1)

The show policer command displays a list of all applied interface-based
policers. The name of each policer is derived from the interface to which it is
applied, the protocol family that is being policed, and the direction of its
application. The display also includes a packet counter that counts the number of
packets exceeding the policers parameters. The show interfaces policers
command provides a quick display of all interfaces, and whether any policers are
applied:
lab@Montreal-3>
Interface
fe-0/0/0
fe-0/0/1
fe-0/0/2
fe-0/0/3
so-0/1/0
so-0/1/0.0
so-0/1/1
so-0/1/1.0
so-0/1/2
so-0/1/2.0
so-0/1/3
gr-0/3/0
ip-0/3/0
lt-0/3/0
. . . .
210
Viewing Interface Policers
show interfaces policers

Admin Link Proto Input Policer
Output Policer
up
down
up
down
up
down
up
down
up
up
up
up
inet
mpls foo-so-0/1/0.0-mpls-i
up
up
up
up
inet
up
up
up
up
inet
faa-so-0/1/2.0-inet-o
up
up
up
up
up
up
up
up
Firewall-Related Operational Commands
List of commands:
show firewall name
show firewall log
Resets counters associated with a firewall
show policer
Displays logged entries when the syslog action modifier is used in a

term
clear firewall name
Displays kernel log cache
show log log-file-name
Displays counter values
Displays a list of interface policers
show interfaces policer interface-name
Displays details about interface policers
Internet Processor II Operational Commands

This slide lists the operational commands associated with the Internet Processor
II and firewall filters. We address each command is addressed individually on
subsequent pages. Note that a problem report (PR) is on file for the show
firewall counter counter-name command. PR number 35493 indicates
that a workaround is to include the filter name along with the command as shown
here:
show firewall counter counter-name filter filter-name
Firewall-Related Operational Commands
211
Displaying Counter and Policer Statistics

lab@San_Jose-3> show firewall
Filter: loopback-filter
Counters:
Name
Packets
lo0-packet-count
0
Policers:
Name
police-icmp-police-and-count
Bytes
0
Packets
1
The show firewall output in this example is interpreted as:
loopback-filter is the name of the filter
lo0-packet-count is the name of a counter
police-icmp is the name of a policer called from a term named

police-and-count
Policers automatically count discarded traffic using a counter based

on the name of the policer and the calling term

The show firewall command displays counter and policer statistics for all
firewall filters or just the filter named as an argument.
In the example on the slide, a filter named loopback-filter has two
associated counters: lol-packet-count and police-icmp. Each counter
maintains byte and packet counts.
The lol-packet-count counter is the result of explicit counter configuration
within a firewall term, while the police-icmp counter is a side affect of
configuring a policer named police-icmp, which is evoked in a term named
police-and-count. By default, Internet Processor II policers automatically
create a counter to record traffic in excess of the policers profile.
212
Displaying Entries in the Kernel Cache

lab@router> show firewall log
Log :
Time
Filter
Action Interface Protocol
Addr
12:52:45 pfe
A
at-0/1/0.100TCP
192.168.2.1
12:52:40 pfe
A
at-0/1/0.100UDP
192.168.2.1
. . .
12:52:40 pfe
A
at-0/1/0.100UDP
192.168.2.1
12:52:40 pfe
A
at-0/1/0.100UDP
192.168.2.1
12:52:37 test
A
local
OSPF
224.0.0.5
12:52:35 test
A
local
TCP
192.168.24.1
12:52:35 test
A
local
TCP
192.168.20.1
Src Addr
Dest
192.168.5.1
10.0.0.2
10.0.0.2
10.0.0.2
10.0.1.2
192.168.0.1
192.168.0.1
Displays kernel logging cache
Approximately 400 entries before wraparound
No clear command

The show firewall log command displays entries logged into the kernel
cache. This cache can hold about 400 entries before wrapping around, and it is
lost in the event of a router reboot or power failure. There is no command to clear
the firewall log at this time.
The filter column displays the name of the filter that logged a particular entry when
that filter name is known. As the PFE is not aware of the filter name, filter actions
performed by the PFE are listed with a filter name of pfe. Because the Routing
Engine maintains copies of all filters and knows the filter name, traffic generated
locally by the Routing Engine and subjected to the copy of a transit filter is
displayed with the true filter name.
The A in this example indicates the action of accept. Reject (R) and discard (D) are
also possibilities. The log also displays the ingress interface and protocol
information, such as the source address, ports, and the type of protocol involved.
The ingress interface is not necessarily the interface to which the filter has been
applied. Knowing the ingress interface for a packet is a great aid when trying to
track backwards towards the source of packets with spoofed source addresses.
213
View Firewall-Related Syslog Entries

lab@router> show log messages | match FW
Jul 18 14:34:07 San_Jose-3 /kernel: FW: .local..0
192.168.0.1 1413
23
Jul 18 14:34:08 San_Jose-3 /kernel: FW: .local..0
192.168.0.1 1413
23
Jul 18 14:41:30 San_Jose-3 ssb FW: ge-7/1/0.0
D
10.0.16.2
21 3882 (1 packets)
Jul 18 15:13:58 San_Jose-3 ssb FW: ge-7/1/0.0
D
10.0.16.2
22 4118 (1 packets)
tcp 192.168.0.1
tcp 192.168.0.1
tcp 192.168.20.1
tcp 192.168.20.1
Use of syslog action modifier writes to standard system log file (messages)
Nonvolatile
Can be accessed remotely
Corresponding log file must be configured with the firewall facility
Displaying Firewall-Related Syslog Entries

In JUNOS software Release 5.0, the alert action modifier was renamed to
syslog. Use of this action modifier is similar to using log, except that matching
packets are written to the system log, which is stored on the routers rotating
media.
The use of syslog has many advantages over the use of log. These entries are
available to both the CLI and network management systems, and the entries
persist through a reboot. The size of the hard disk also accommodates far more
entries than the 400 that can be held by the kernel cache.
You can use the syslog firewall facility to place firewall-related entries into a
specific syslog file or to have them directed to a remote host. Firewall entries also
can be written to the messages file, if wanted. In the example shown on the slide,
we are searching the default syslog file (messages) for all entries that contain the
sequence FW.
As with the show log command, syslog entries indicate the ingress interface,
protocol, ports, and addresses.
214
View Firewall-Related Syslog Entries
Clearing Firewall Filter Counters

lab@router> clear firewall ?
Possible completions:
all
Clear all firewall counters
counter
Counter name
filter
Filter name
Clears a specific counter or all counters associated with a firewall filter

Use the clear firewall command to rest the counters associated with firewall
filters. You can clear a specific filter, or all of them, by using the appropriate
arguments on the command line.
215
Review Questions
What are the components of a packet filter?
How are packet filters applied?
How might commit confirmed be useful when working with security filters?
How would you apply a filter that is designed to protect the router itself?
Describe how policing is configured, and indicate if it is possible to police the

same packet twice.
216
Review Questions
JUNOS software firewall filter syntax;
Applying transit versus Routing Engine firewall filters;
Configuring a firewall filter; and
Monitoring and troubleshooting firewall filters.
Lab 5: JUNOS Software Firewall Filters

Lab Objective:
Configure and verify a Routing Engine-based firewall filter.
217
218
Chapter 7
219
Module Objectives
Describe IP multicast traffic flow
Explain how IP multicast addressing works
Identify the components of IP multicast
Explain the role of IGMP
Describe the differences between IGMP versions
Describe the need for RPF in multicast
Identify the difference between sparse- and dense-mode protocols, and

between source and shared multicast distribution trees
Describe rendezvous point (RP) discovery options
Explain the role of SDP and SAP
220
Module Objectives
IP multicast traffic flow;
Multicast addressing;
The components of multicast;
The role of IGMP and the differences between IGMP versions;
The need for RPF checks;
Dense- and sparse-mode operation;
The difference between shared and source-specific trees; and
PIM RP discovery mechanisms.
Chapter 7: Module 7: Multicast Theory
IP Multicast Agenda
Multicast theory
Traffic flow
IP multicast addressing and Ethernet mapping
IP multicast components
Group membership
Multicast routing
Reverse-path forwarding
Dense- and sparse-mode operation
Multicast trees
Rendezvous point discovery
SAP
IP Multicast Agenda
221
Traffic Flow
Without multicast, multiple streams are needed
Network
Clients
Server
With IP multicasting, a single stream can be delivered to all clients
Network
Server
Clients
Figure 60: Traffic Flow
Address Types and Traffic Flow

IP version 4 (IPv4) has three fundamental types of addresses: unicast, broadcast,
and multicast. Use a unicast address to send a packet to a single destination. Use
a broadcast address to send a datagram to an entire subnetwork. Use a multicast
address to send a datagram to a set of hosts that can be on different subnetworks
who are members of a multicast group.
A multicast datagram is delivered to destination group members with the same
best-effort reliability as a standard unicast IP datagram. Thus, multicast
datagrams are not guaranteed to reach all members of a group or to arrive in the
same order in which they were transmitted. The only difference between a
multicast IP packet and a unicast IP packet is the presence of a group address in
the IP header destination address field.
Individual hosts can join or leave a multicast group at any time. There are no
restrictions on the physical location or the number of members in a multicast
group. A host can be a member of more than one multicast group at any given
time and does not have to belong to a group to send packets to members of a
group.
222
Traffic Flow
IP Multicast Addressing
Multicast addresses are identified by coding of the four high-order address
bits
31
Multicast Group ID
28 bits
Figure 61: IP Multicast Addressing
Internet Assigned Numbers Authority (IANA) maintains list of registered IP

multicast groups
Base address 224.0.0.0 is reserved and cannot be assigned to any group
Multicast addresses from 224.0.0.1 through 224.0.0.255 are reserved for

local wire use
Range 239.0.0.0 through 239.255.255.255 is reserved for administratively

scoped addresses
Multicast Addresses
Multicast host group addresses are defined to be the IP addresses whose
high-order 4 bits are 1110, giving an address range from 224.0.0.0 through
239.255.255.255, or simply, 224.0.0.0/4. These addresses also are referred to as
Class D addresses.
Registered Groups
The Internet Assigned Numbers Authority (IANA) maintains a list of registered IP
multicast groups. The base address 224.0.0.0 is reserved and cannot be
assigned to any group. The block of multicast addresses from 224.0.0.1 through
224.0.0.255 is reserved for local wire use. Groups in this range are assigned for
various uses, including routing protocols and local discovery mechanisms.
Scoped Range
The range 239.0.0.0/8 through 239.255.255.255/8 is reserved for administratively
scoped addresses. Because packets addressed to administratively scoped
multicast addresses do not cross configured administrative boundaries, and
because administratively scoped multicast addresses are locally assigned, these
addresses do not need to be unique across administrative boundaries. These
addresses are available for private internal use.
IP Multicast Addressing
223
IP Multicast-to-Ethernet Mapping
IPv4 prefix (32 Bits)
First 4 high-order
bits are stripped
1110
28 bits remain
224. 10. 8. 5
5 remaining high-order
bits are stripped
23 bits remain
for mapping
01-00-5e-0A-08-05
23 bits
25 bits
MAC Address (48 Bits)
Figure 62: IP Multicast-to-Ethernet Mapping
Address Mapping
IANA has been allocated a reserved portion of the IEEE-802 MAC-layer multicast
address space. All the addresses in IANAs reserved block begin with 01-00-5E
(hex). A simple procedure was developed to map Class D addresses to this
reserved address block to allow IP multicasting to take advantage of
hardware-level multicasting supported by network interface cards. The use of
MAC-layer broadcast would cause all machines on the subnet to expend cycles
for every multicast packet, even though these machines might not want to receive
multicast. For example, the mapping between a Class D IP address and an
Ethernet multicast address is obtained by placing the low-order 23 bits of the
Class D address into the low-order 23 bits of IANAs reserved address block.
224
IP Multicast-to-Ethernet Mapping
IP Multicast-to-Ethernet Mapping Example

E
Class D Address: 224.10.8.5
1 1 1 0 0 0 00 0 0 0 0 1 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 1
Low Order 23 bits mapped
Not Used
0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 0 1 1 1 1 0 0 0 0 0 1 0 1 0 0 0 0 0 1 0 0 0 00 0 0 0 1 01
Resulting Ethernet Multicast Address
Figure 63: IP Multicast-to-Ethernet Mapping Example
Address Mapping Example

This slide illustrates how the multicast group address 224.10.8.5 (E0-0A-08-05) is
mapped into an Ethernet (IEEE-802) multicast address. The mapping places the
low-order 23 bits of the IP multicast group ID into the low-order 23 bits of the
Ethernet address. The mapping can place up to 32 different IP groups into the
same Ethernet address because the upper 5 bits of the IP multicast group ID are
ignored. For example, the multicast addresses 224.138.8.5 (E0-8A-08-05) and
225.10.8.5 (E1-0A-08-05) would also be mapped to the same Ethernet address
(01-00-5E-0A-08-05) used in this example.
When the sender and receivers are members of the same subnetwork (LAN), the
transmission and reception of multicast frames are a relatively simple process.
The source station simply addresses the IP packet to the multicast group, and the
driver maps the Class D address to the corresponding IEEE-802 multicast
address before the frame is sent. Receivers that want to capture the frame notify
their IP layer that they want to receive datagrams addressed to the group.
IP Multicast-to-Ethernet Mapping Example
225
Multicast Components
Sources and group members
Host protocols
Source does not have to be a group member
IGMP
Multicast routing protocols
DVMRP
PIM
MBGP (not really a multicast routing protocol)
Other mechanisms
Bootstrap Protocol, Auto-RP, Anycast RP
MSDP
SDP/SAP
Multicast scoping
Sources and Group Members

In multicast configurations, the source of the multicast information is unique in that
the source does not have to be a member of any multicast group. Only the clients
that want to receive the multicast need be concerned about group membership.
Host Protocols
JUNOS software supports the Internet Group Management Protocol (IGMP),
which allows hosts to communicate which multicast groups they want to join to the
router. JUNOS software uses Version 2 of this protocol by default, which is
defined in RFC 2236, Internet Group Management Protocol, Version 2.
Routing Protocols
For backwards compatibility with older routers that do not support PIM, JUNOS
software supports the Distance Vector Multicast Routing Protocol (DVMRP).
Protocol Independent Multicast (PIM) is supported in sparse, dense or
sparse-dense mode. The default version is PIMv2. You can use Multiprotocol
BGP (MBGP) to provide unique paths through the network for multicast traffic.
226
Other Multicast Features

To discover PIM sparse mode RPs dynamically, JUNOS software supports the
Bootstrap Protocol and Auto-RP. In addition, JUNOS software supports Anycast
RP to provide redundancy. Additional features include SAP/SDP for source
discovery and scoping to limit where multicast traffic can travel.
227
The IGMP Protocol
Usage of IGMP
JUNOS software support
IGMP versions
IGMP query/response messages
IGMP join and leave messages
Operation and Software Support for IGMP

The slide shows the topics we discuss on the following pages.
228
The IGMP Protocol
IGMP
Manages group membership between hosts and routers
IGMP message exchange
Router queries
Sends query messages to solicit group membership
Host messages
Report messages
Leave-group messages
JUNOS software supports IGMPv2, by default
Configurable to v1 and v3
Automatically enabled on multiprotocol ports where PIM or DVMRP is

configured
IGMP
The Internet Group Management Protocol (IGMP) manages multicast groups
participation between hosts and routers. IP hosts use IGMP to report their
multicast group memberships to their neighboring multicast routers. Multicast
routers use IGMP to determine if any hosts on their attached networks are
interested in receiving multicast traffic, and if so, in which multicast groups the
hosts are participating. IGMP is an integral part of IP and must be enabled on all
routers and hosts that want to receive IP multicast.
IGMP Message Exchange

For each attached network, a multicast router can be either a querier or a
nonquerier. The querier router periodically sends general query messages to
solicit group membership information. Hosts on the network that are members of a
multicast group send report messages. When a host leaves a group, it sends a
leave-group message when running IGMP version 2; IGMP version 1 does not
support explicit leaves and relies on aging out cached state to manage leaves.
JUNOS Software Support

On Juniper Networks M-series and T-series platforms, IGMP is enabled
automatically on all multi-access interfaces configured with a multicast routing
protocol such as DVRMP or PIM. You might need to configure the IGMP protocol
explicitly if you want to disable IGMP support on a given interface or if you need to
modify various IGMP parameters. The default version of IGMP is v2; however,
JUNOS software also supports v1 and v3.
IGMP
229
Multicast Groups and Routing

Group Membership Protocol
Multicast Routing Protocol
IGMP operates between receivers (hosts) and routers
IGMP is not a routing protocol
Figure 64: Multicast Groups and Routing
Group Membership Protocols versus Multicast Routing Protocols

Multicast routing protocols work in conjunction with IGMP. IGMP allows hosts to
join and leave multicast groups; multicast routing protocols allow multicast traffic
to flow between networks. Common multicast routing protocols are DVMRP and
PIM.
Normally you do not have to run IGMP between routers. This is because routers
normally do not join multicast groups.
230
Multicast Groups and Routing
IGMP Versions
Version 1
Routers periodically transmit host membership query messages to

determine what groups have listeners on directly attached networks
Version 2
Specified in RFC 2236
Defines procedure for electing the multicast querier for each LAN
Defines a group-specific query message
Defines a leave-group message
Reduces IGMP leave latency
Version 3
Defined in RFC 3376
Supports group-source report/query messages and enhancements to

leave-group messages
Provides source-specific multicast (SSM)
IGMP Version 1
RFC 1112 defines IGMPv1. IGMPv1 routers periodically transmit host
membership query messages to determine which groups have members on their
directly attached networks. Query messages are addressed to the all-hosts group
address (224.0.0.1) and have IP TTL=1. When a host receives a query message,
it responds with a host membership report for each group to which it belongs.
Multicast routers periodically transmit queries to update their knowledge of the
group members present on each interface. Because queries are normally sent
every 60 seconds, multicast traffic can be delivered to a subnet with no interested
hosts for several minutes after the last host has left that group.
IGMP Version 2
RFC 2236 specifies IGMPv2. It defines a procedure for the election of a querier
for each LAN. The router with the lowest IP address on the LAN becomes the
querier. In IGMPv1, the multicast routing protocol determined the querier election.
IGMPv2 also defines a group-specific query message and a leave-group
message, which improves on IGMPv1s leave latency.
IGMP Versions
231
IGMP Version 3
RFC 3376 defines IGMPv3 and introduces support for group-source report
messages. With these messages a host can elect to receive traffic from specific
sources of a multicast group. This capability accommodates source-specific
multicast (SSM). A host identifies the IP addresses of the specific sources from
which it wants to receive traffic by generating an inclusion group-source report
message. The host generates an exclusion group-source report message to
explicitly identify the sources from which it no longer wants to receive traffic.
232
IGMP Versions
IGMP Version 2
Enhances IGMPv1 by:
Allowing maximum query/response-time tuning
Adding group-specific query messages
Adds querier election process
This function was performed by the multicast routing protocol in IGMPv1
Adds leave-group messages
IGMP Version 2
RFC 2236 was ratified in November of 1997 as an update to RFC 1112. Its
purpose is to overcome some of the shortcomings of IGMPv1. The query and
membership process is the same as in version 1however, there are now two
types of query messages: general and group-specific. The general queries work
the same as in version 1. The group-specific query messages allow the querier
router to perform the query operation on a specific group instead of all groups.
The querier router now can specify a maximum query response time to control
burstiness and fine tune leave latencies.
Querier Election
IGMPv2 has its own querier election process. It uses the IP address in the general
query messages to elect the IGMP query router. The routers each multicast an
IGMPv2 general query message to the all multicast systems address of 224.0.0.l,
with their interface addresses in the source IP address field. When each router
receives the message, it compares the source IP address to its own interface
address. The router with the lowest IP address on the subnet is elected the
querier.
Leave-Group Message
With IGMPv1, it was possible for routers to continue to forward multicast traffic
onto the local subnet for several minutes after the last host left the group. IGMPv2
has an explicit leave message that significantly improves the leave latency.
IGMP Version 2
233
IGMPv2 Join Process
Report messages establish host membership for particular multicast groups

on a given network
Reports are sent to the group address being reported
Informs local router that a host wants to receive traffic associated with the
specified multicast group
Querier
Nonquerier
Report:
D=224.10.1.1
Group=224.10.1.1
Host 1
Figure 65: IGMPv2 Join Process
Joining a Multicast Group

When a host wants to join a specific multicast group, it sends out a membership
report for the multicast group it wants to join. This type of membership report is
sometimes referred to as unsolicited because it is not generated in response to a
membership query that is generated by a multicast router. In the example on the
slide, Host 1 multicasts an unsolicited IGMPv2 membership report to 224.10.1.1
to inform the multicast routers that it wants to join the 224.10.1.1 group.
Hosts that are interested in a given group also respond to the periodic query
messages, as generated by the querier router for this subnet, with report
messages to prevent the group state from timing out.
234
IGMPv2 Join Process
IGMPv2 Query-Response Process
Querier router sends general query to all-hosts multicast group
Host 2 sends its report for group 224.10.1.1 first
Host 1 hears the response from Host 2 and suppresses its report
Host 3 sends its report for the group 224.20.1.1
Host 1
Host 2
Host 3
Report
224.10.1.1
Report
Report
Suppressed
224.10.1.1
224.20.1.1
General
Query
Router A
QUERIER
Router B
NONQUERIER
Figure 66: IGMPv2 Query-Response Process
Query-Response Model
IGMPs primary function is to inform multicast routers as to which multicast groups
have active listeners on a given segment. In the example on the slide, two hosts
are reporting that they want to receive traffic for the group 224.10.1.1, and one
host reports a desire to receive traffic for group 224.20.1.1.
In this example, Router A is functioning as the querier router. The querier router is
responsible for periodically sending query messages to the all-hosts multicast
group 224.0.0.1 and is the multicast router with the lowest IP address on a
particular subnet.
The example begins with the querier router sending a general query to the
all-hosts multicast address. A general query does not contain a particular group
address, and as such, it applies to all possible groups. Note that IGMPv1 supports
only general queries, while IGMPv2 supports both general and group-specific
query messages. Group-specific queries are generated as a result of receiving a
leave-group message from an IGMPv2 host.
Each host now starts a randomized delay timer that determines how long that host
will delay the transmission of the resulting membership report for those groups in
which that host is a member. In this example, Host 2 generates its report for the
224.10.1.1 group before Host 1 (step 2). When Host 1 sees this report, it
suppresses its group report for the 224.10.1.1 group, which serves to reduce the
amount of traffic on the network. The use of a randomized response timer helps to
ensure that duplicate reports are not generated. Host 3 also receives the query
and responds with a membership report for group 224.20.1.1.
235
The end result is that the querier router (Router A) is now aware that there are
active receivers for groups 224.10.1.1 and 224.20.1.1. The nonquerier router
(Router B) knows the same information because it has eavesdropped on the
various query and report messages that have transpired. This allows the
nonquerier to rapidly take over the querier function when needed.
236
IGMPv2 Group Leave
Host 2 sends leave message for 224.1.1.1 to all-routers multicast group

address (224.0.0.2)
Querier router sends group-specific query for 224.1.1.1
Group 224.1.1.1 times out if no IGMP report are received within~3 seconds
Host 2
Host 3
1
Leave-group
Group=224.1.1.1
Group-Specific
Query
Group=224.1.1.1
Router A
(Querier)
Figure 67: IGMPv2 Group Leave
IGMPv2 Group Leave

This slide outlines the IGMP version 2 leave mechanism, which has the host send
a group-specific leave message to the all-routers multicast group (224.0.0.2) to
inform all routers it is leaving the group. The querier router then sends a
group-specific query to determine whether any host still remains active for the
group. If some hosts still exist, those hosts respond with a membership report to
inform the router that a member of the group is still present.
With IGMPv1, no mechanism exists for a host to notify the router that it wants to
leave a group. The router continues to send out its query for the group, and if it
stops getting membership reports, it knows that there are no active receivers for
the group. Because the query interval is 60 seconds, and the router does not time
out until after missing three query messages, the router could continue to forward
multicast traffic for up to three minutes after all hosts have left the group.
IGMPv2 Group Leave
237
IGMPv3 and SSM
Host 1 wants to receive from S=172.16.20.1, but not from S=192.168.30.1
Host 1 sends inclusion group-source message for S=172.16.20.1
Host 1 sends exclusion group-source message for S=192.168.30.1
Source=172.16.20.1
Group=224.1.1.1
X
(Pruned)
Router C
Source=192.168.30.1
Group=224.1.1.1
IGMPv3 group-source report:
D: 224.0.0.22 (All IGMPv3 routers)
Include 172.16.20.1, 224.1.1.1
Exclude 192.168.30.1, 224.1.1.1
Host 1 member of 224.1.1.1
Figure 68: IGMPv3 and SSM
IGMPv3 and SSM

Version 3 of IGMP supports the concept of source-specific joins, which allow a
host to issue a join for a specific source (S,G), as opposed to all sources (*,G).
This capability is called source-specific multicast (SSM). The (S,G) notation is
used to indicate a specific source (S) and a corresponding group (G). The use of a
shared tree is indicated with a wildcard (*) instead of a specific source address.
The slide shows how SSM allows a host to selectively choose the sources from
which it is interested in receiving traffic, on a per-group basis. Besides the obvious
efficiency gains, SSM has the added benefit of supporting a sparse-mode
topology without an RP. In the example, Host 1 sends an IGMPv3 membership
report with an include indication for source 172.16.20.1 and an exclude indication
for address 192.168.30.1. Note that in IGMPv3, report messages are sent to the
IGMPv3-capable multicast routers address of 224.0.0.22. Recall that IGMPv1
and IGMPv2 send report messages to the address of the group being reported.
One reason for this modified behavior is that IGMPv3 report messages can
contain information for multiple groups. Note that general queries are sent to the
all-systems multicast address (224.0.0.1) while group-specific and
group-and-source-specific queries are sent to a destination address that matches
the multicast address of interest. The down side to SSM is that hosts must have a
priori knowledge of the specific sources active for a given group before they can
formulate the appropriate group-source report message. This problem is
complicated by the fact that some groups are ephemeral in nature. Standards
238
IGMPv3 and SSM
work is underway to designate which groups are reserved for SSM and to work on
ways of propagating knowledge of active sources to a IGMPv3 hosts. For
example, addresses in the range of 233/8 are reserved for use by SSM. While
SSM can function with groups outside this range, attempts to perform an
anycast-source multicast (ASM) join (*, G) to a 232/8 prefix should fail with an
IGMPv3-compliant router.
IGMPv3 and SSM
239
Multicast Routing
Multicast routing protocol characteristics
Reverse-path forwarding (RPF)
PIM dense/sparse mode operation
Multicast Routing
The slide lists the topics we discuss on the following pages.
240
Multicast Routing
Multicast Routing Protocol Characteristics
Multicast routing differs from unicast routing
Unicast routing decisions based on destination
Multicast routing decisions based on sources
Reverse-path forwarding (RPF)
Directing traffic away from its source
Distribution trees
Shared or source specific
Multicast Routing Differs from Unicast Routing

Multicast routing differs from unicast routing. While unicast flows are directed
toward a destination by a router based on destination address, multicast flows are
more or less directed away from a source based on source address (destination
multicast group addresses are useless for unicast routing purposes).
Reverse-Path Forwarding
But how is this away direction defined? In reverse-path forwarding (RPF),
multicast-enabled routers use unicast routes to determine the best path back to
the source. RPF uses the existing unicast routing table to determine the upstream
and downstream neighbors for a particular address. A router only forwards a
multicast packet if it is received on the upstream interface, and then it only
forwards to interfaces considered downstream from the source.
This RPF check helps guarantee that the distribution tree is loop free. If the RPF
check is successful, the packet is forwarded. Otherwise, it is dropped. RPF
checks can be done using inet.0 and normal unicast routing protocols, or RPF
can use MBGP to put unicast routes in inet.2.
Distribution Trees
Multicast-capable routers create distribution trees, which control the path that IP
multicast traffic takes through the network when delivering traffic to all receivers.
The two basic types of multicast distribution trees are source trees and shared
trees. The simplest form of a multicast distribution tree is a source tree, with its
root at the source and branches forming a spanning tree through the network to
the receivers. Because this tree uses the shortest path through the network, it
also is referred to as a shortest-path tree (SPT). Unlike source trees that have
their root at the source, shared trees use a single, common root placed at some
chosen point in the network. This root of a shared tree is called a rendezvous
point (RP).
Multicast Routing Protocol Characteristics
241
Multicast uses unicast routes to determine the path back to the sourcethis
determines upstream interface
RPF check ensures packets do not loop because they are never flooded
back towards their source
RPF checks can be done using inet.0 and normal unicast routing
protocols
RPF can use MBGP to put unicast routes in inet.2
The incoming interface of an IP multicast packet is checked, and a decision is
made to either forward or drop the packet. When a packet comes in, the router
examines the source address to see if the packet arrived on an interface that is on
the reverse path back to the source. If it is, the packet is forwarded; if not, the
packet is discarded.
The RPF check ensures that multicast traffic always flows away from its source,
which prevents loops and wasted bandwidth.
When using PIM, RPF checks are performed against the main routing table
(inet.0), by default. DVMRP, on the other hand, requires the presence of
interface routes in the inet.2 table for this purpose. Normally, inet.2 is only
used in conjunction with PIM when you want unique unicast and multicast
topologies; when RPF checks are performed against the main routing instance,
you effectively have the same topology for both unicast and multicast.
242
The RPF Check (1 of 2)
Source prefix
172.16.0.0/16
Protocol
OSPF
RPF interface
fe-5/1/0
Source 1
172.16.20.1
RPF neighbor
10.0.31.1
RPF Table at R1
10.0.31.1
fe-5/1/0
R1
Packet
fe-7/2/0
Packet from Source 1 arrives

on wrong interface: RPF check
fails, discard the packet!
Multicast Traffic
Figure 69: The RPF Check (1 of 2)
The RPF Check: Part 1

In the example on the slide, a packet arrives at R1s interface fe-7/2/0 from
Source 1. R1 checks the existing unicast routing table and determines that this
interface is not on the reverse path back to the source. Thus, the packet is
discarded.
243
Source prefix
172.16.0.0/16
Protocol
OSPF
RPF interface
fe-5/1/0
Source 1
172.16.20.1
RPF neighbor
10.0.31.1
Pa
c
ke
t
RPF Table at R1
10.0.31.1
fe-5/1/0
R1
fe-7/2/0
Packet from Source 1 arrives on

correct interface: forward out all
outgoing interfaces
Multicast Traffic
Figure 70: The RPF Check (2 of 2)
The RPF Check: Part 2

In this example, R1 receives a packet from Source 1 on its fe-5/1/0 interface
and, once again, performs an RPF check. R1 determines that the packet is
coming in on an interface that is on the reverse path back to the source. Thus, the
RPF check succeeds, and the packet is forwarded to all interfaces on the
outgoing interface list.
244
Dense-Mode Routing Protocols
Assumes everyone wants to receive multicasts
Flood-and-prune mechanism builds distribution tree
Floods multicast traffic out all ports
Routers without receivers must prune back branches
Creates a source-based distribution tree
Root of this tree is the source hosts designated router
Guarantees shortest, most efficient, path
Considerable overhead
Examples
DVMRP
PIM-DM
Dense-Mode Routing Protocol Behavior

The flood first and prune later philosophy of dense-mode protocols works well in
enterprise networks where bandwidth is high and latency is low. However, this
approach does not scale well for large networks, especially where a large number
of connections are WAN links with limited bandwidth.
Source-Based Distribution Tree

The simplest form of a multicast distribution tree is a source tree with its root at the
source and branches forming a spanning tree through the network to the
receivers. Because this tree uses the shortest path through the network, it is also
referred to as a shortest-path tree (SPT).
Dense-Mode Protocols
Common dense-mode protocols include the Distance Vector Multicast Routing
Protocol (DVMRP), which builds a unique multicast routing table and has a finite
hop count of 32. DVMRP was the first multicast routing protocol, and it is widely
used in the MBONE.
As mentioned, PIM dense mode uses a flood-and-prune behavior to build a
source tree from the source of the multicast.
MOSPF rides upon OSPF to distribute multicast routing information. However,
JUNOS software does not support it.
Dense-Mode Routing Protocols
245
PIM Dense Mode Operation

Source
172.16.20.1
Receiver
(S, G) state created in

every router in the network
Multicast Traffic
Receiver
Figure 71: PIM Dense Mode Operation

PIM dense mode uses shortest-path trees to deliver (S,G) multicast traffic and
assumes that there is at least one receiver of the (S,G) multicast traffic on every
subnet in the network. Traffic is flooded to to all points in the network. PIM dense
mode creates an (S,G) entry for each source/group pairing and sends it to every
router in the network. Routers without locally attached receivers must prune
themselves periodically from the SPT to avoid the reception of unwanted multicast
traffic.
246
Pruning Unwanted Traffic
Source
172.16.20.1
Receiver
Prune Messages
Multicast Traffic
Receiver
Figure 72: Pruning Unwanted Traffic

Because PIM dense mode sends traffic to all network segments, routers send
prune messages back up the source distribution tree to shut off unwanted
multicast traffic when they have no locally attached receivers upon receiving a
prune from their downstream neighbors. The prune state eventually times out so
routers must reissue their prune messages periodically to once again stem the
flow of unwanted multicast traffic. When a new group membership is detected, the
router issues a join message up the SPT to allow the flow of multicast traffic for
that group. This join, which is sometimes called a graft, prevents the delays
associated with having to wait for the state associated with a previous prune to
time-out.
247
After the Prune...

Source
172.16.20.1
Ongoing flood and prune

every 3 minutes
Receiver
Multicast Traffic
Receiver
Figure 73: After the Prune
After the Prune

The result is that branches without receivers are pruned off of the distribution tree,
leaving only branches that contain receivers.
248
After the Prune...
A Shortest-Path Tree
Source
172.16.20.1
Notation: (S, G)
S= Source
G= Group
172.16.20.1, 224.1.1.1
Receiver 1
In group 224.1.1.1
Figure 74: A Shortest-Path Tree
Source Distribution Tree

A source distribution tree is a shortest-path tree (also SPT) between the sender
and a given receiver. Dense-mode protocols have the benefit of using SPTs
between all sources and receivers. As you will soon see, the use of a shared tree,
as associated with sparse-mode operation, results in less than optimal forwarding
between source and receivers.
To provide the best of both worlds, a sparse-mode receiver normally instigates a
join to an SPT after receiving a multicast packet over the shared tree with a new
source address and a join message. We describe this behavior in detail in
subsequent pages.
An SPT is indicated by the presence (S,G) state. A shared tree is indicated by a
(*, G) entry.
A Shortest-Path Tree
249
PIM Sparse Mode
PIM-SM (Protocol Independent Multicast sparse mode)
Independent of the underlying unicast protocol
Uses unicast information learned by IGPs and EGPs for RPF
PIM-SM trees
Receivers DR initially joins shared RP-based tree
RP tree allows receivers to learn of active sources
After receiving multicast traffic, receivers DR initiates an SPT from

source to receiver
Design considerations
Placement/reliability of RP router
Need for Tunnel Services PICs
PIM allows sparse-dense mode
Sparse mode for sparse groups, dense mode for dense groups
PIM Independence
PIM is indeed as it claimsprotocol independent. So whichever unicast protocol
is being used, PIM will use for its reverse-path forwarding check. PIM does not
care if this protocol is OSPF, IS-IS, RIP, or even BGP!
PIM Sparse Mode Trees

The purpose of an RP and a shared tree is to allow receivers to learn of active
senders for a given multicast group. Once an active sender is detected, that is,
data from sender x is received over a shared tree, PIM sparse-mode routers
attempt to optimize the topology by establishing a source-based tree. The
resulting SPT removes unnecessary hops, and possibly the RP itself from that
particular multicast flow. Subsequent slides provide details of this behavior.
Design Considerations
The placement and selection of a sparse-mode RP can be a critical factor in the
networks performance and fault tolerance. Subsequent pages discuss ways of
achieving RP redundancy. PIM sparse mode also requires that certain routers be
equipped with Tunnel Services PICs to handle register message encapsulation
and decapsulation.
250
PIM Sparse Mode
Sparse-Dense Mode
The PIM protocol allows the designation of groups to be either sparse or dense.
This designation allows some groups to operate in dense mode using SPT, while
other groups operate in sparse mode with a shared tree. One example of when to
use sparse-dense mode is when using Auto-RP.
PIM Sparse Mode
251
PIM Sparse Mode: The Shared Tree
Source
Shared tree rooted at the RP (RPT)

RP
E
Data
Receiver
Control
But, what if the RPT is not on the optimum path between sender
and receiver?
Figure 75: PIM Sparse Mode: The Shared Tree

Sparse-mode routing is ideal for efficiently routing to multicast groups that might
span wide-area and interdomain internetworks. JUNOS software supports sparse
mode, dense mode, and sparse-dense modes of operation in conjunction with the
PIM protocol.
In sparse mode, routers must join and leave multicast groups explicitly. Upstream
routers do not forward multicast traffic to a downstream router unless that router
has sent an explicit request (using a join message) to receive multicast traffic. In
other words, multicast traffic is forwarded out a PIM sparse-mode interface only if
the interface has received a join message from a downstream router or if group
members are connected directly to the interface.
When a host joins a multicast group, its first-hop router sends a join message
upstream toward the rendezvous point (RP) that handles that group. The RP
serves as the root of the shared multicast delivery tree and is responsible for
forwarding multicast data from various sources toward the receivers over the RPT.
The slide shows that the traffic flowing from the source to receiver does not follow
an optimal path when flowing over the shared tree. Future slides explain how this
inefficiency is resolved with the signaling of an SPT.
252
PIM Sparse Mode: Switch to SPT (1 of 3)
Source
RP
Join
(S, G)
Receivers DR is
responsible for
forwarding packets on
this LAN
E
Data
Receiver
Control
Switch to an SPT is triggered by receipt of traffic

Figure 76: PIM Sparse Mode: Switch to SPT (1 of 3)
PIM Sparse Mode: Switch to SPT (Part 1)

The presence of traffic flow down the PIM sparse-mode shared tree triggers a
switch to an optimal SPT-based tree.
The receivers designated router (that is, the router closest to the receiver with the
highest PIM priority) sends a join message toward the source while also pruning
the (S, G) state from the shared RP tree (not shown) when it determines that
traffic is not being received over the optimal path between the source and
receiver. This slide shows the process beginning with the DR sending a PIM (S,
G) join over the RPF path back to the source to establish an SPT.
Note that as a result of the join, multicast traffic is now being delivered from
Router A to Router C over an SPT. At this time duplicate traffic is also being
received over the RPT.
In JUNOS software the switch from a shared to a shortest-path tree is always
triggered by the receipt of the first packet from a new source on the shared tree.
253

Source
S1
RP deletes session reference and sends prune

message toward the source
Prune
(S, G)
RP
A
B
F
Prune
(S, G)
C
E
Data
Receiver
Control
Receivers DR (Router c) sends prune message up the RP tree

for the source

After the SPT is formed between the receiver and the source (source-based tree)
and data begin to flow, the receivers designated router sends an (S, G) prune
message to the RP. This (S,G) prune prevents the reception of data from that
particular source over the shared tree.
The slide shows that multicast traffic from S1 is no longer received over the
shared tree as a result of the prune messages. In this example, the RP has no
need to forward traffic from S1 (it has no downstream interfaces for the (S, G)
entry for source S1), so the RP also sends an (S, G) prune towards S1.
254
Source
Shortest-path tree established

RP
A
D
E
Data
Receiver
Control

The slide shows the resulting SPT between the sender (S) and a particular
receiver for a particular group (G) that yields optimal forwarding.
255
PIM Register Messages
Register encapsulated traffic is

sent to the RP as unicast
Source
RP
D
Register encapsulated is stripped by RP; native
multicast sent down the shared tree
E
Register Encapsulation
Receiver
Native Multicast
Figure 79: PIM Register Messages

PIM sparse mode requires that senders encapsulate multicast traffic inside
register messages, which are then sent as unicast datagrams to the groups RP.
Upon receipt, the RP removes the register encapsulation and forwards the traffic
down the shared tree as native unicast.
Register encapsulation is necessary because initially there is no state in the
network to allow native multicast to flow from the sender to the RP. Put differently,
the RP functions to allow receivers to locate active senders without a priori
knowledge that senders actually exist. By allowing a sender to initially contact the
RP using unicast forwarding, we eliminate the cart-before-the-horse problem of
the RP having no way to learn of active senders.
When the RP receives register messages from a new source, it initiates a
shortest-path tree back to that source; the RP learns of active sources from
receiving register messages, not from the services of another RP. Once the SPT
is established, the RP expects to receive native multicast from that source of the
SPT. This native multicast is then forwarded down the shared tree. When the SPT
between source and RP is built, the RP periodically sends register stop messages
to the first-hop router to prevent the unnecessary reception of
register-encapsulated traffic.
In JUNOS software, the RP always initiates a switch to a SPT upon receipt of the
first register-encapsulated packet from each source. M-series and T-series routing
platforms require an IP Tunnels Services PIC to handle the PIM register message
encapsulation and decapsulation. The Tunnel Services PIC performs these
functions in hardware to ensure optimal performance. The Tunnel Services PIC is
required in the first-hop router and in the RP routers.
256
The Result...
Source
RP
SPTs
D
F
RPT
Receiver
Receiver and RP on SPT; receiver remains RPT

Figure 80: Receiver and RPT on SPT (Result)
When All Is Said and Done

No one ever said that multicast was simple or easy to understand! The average
reader has likely had enough multicast theory at this juncture. This slide wraps up
the previous example by showing the final result PIM sparse-mode operation with
respect to the sender, RP, and receiver shown in the example.
The source station winds up as the root of an SPT that splits at Router A to deliver
native multicast from the source to both the RP and the receiver. The native
multicast received by the RP over the SPT is forwarded down the shared tree as
needed. The RP issues an (S, G) prune on the SPT if there are no (*, G) joins
associated with the group in question. Note that the shared tree is pruned for this
source from the perspective of the receiver shown, due to the presence of the
SPT.
The receiver maintains the shared tree to the RP so that it can begin receiving
traffic for any new sources that might begin sending to the multicast group in
question.
The Result...
257
Joining a Shared Tree Example: Step 1
Tokyo
/2
0 /0
fe- 5.2
1
ge-2/2
/0
16.2
fe-0/0/3
1.1.1.2
fe-0/0/0
22.2
fe-0/0/1
22.1
RP
San Jose
so-2/0/0
1.2
so-3/1/0
1.1
Montreal
/0
0/2
a t- 0 .1
at
-0
2. /2/0
1
Hong Kong
/0
fe-0/0
21.1
ge-0/1
/0
16.1
fe-0/0/0
21.2
Server
1.1.1.1
London
fe-0
29.1 /0/1
f e- 0
/0/
29.20
Amsterdam
/3
so-3/1
24.1
fe
31 -0/0
.1 /1
Server Groups=
224.7.7.7
224.8.8.8
at0
0.2 /2/0
Denver
(*,G) Join
/1
0/0
fe- .1
15
so
8.2 0/1/
0
Sydney
Client
10.200.200.2
fe-0/0/0
13.1
fe-0/0/0
13.2
fe
31 -0/0
.2 /1
so
-2
/
8.1 2/0
Sent towards RP
Sao Paulo
Data
Control
fe-0/0/3
10.200.200.1
Figure 81: Joining a Shared Tree Example: Step 1
Joining a Shared Tree Example

We use the classroom lab topology to illustrate a shared-tree join with the
Montreal router acting as the RP. When using PIM sparse mode, traffic is only
sent to locations of the network that explicitly request it. This is accomplished via
PIM join messages, which are sent hop by hop toward the root node of the tree. In
the case of a shared tree, the root node is the RP. As this join message travels up
the tree, routers along the path set up multicast forwarding state that will direct (*,
G) multicast traffic back down the tree.
For the purposes of this discussion, you can assume that Sydney has learned the
RPs address through some outside mechanism. Normally, stations learn of the
RPs address through static configuration or through the operation of the
Bootstrap or Auto-RP protocols.
Note that three equal-cost paths are between the London router and the RP
(Montreal), and that two equal-costs paths are between the source (1.1.1.1) and
the last-hop router (Sydney). Thus, the examples shown in the next series of
slides are based on one of several possible forwarding states that could result in
the classroom lab topology, given its rich level of interconnection.
The RPF table contains a single upstream interface for any given destination.
When this material was developed, the forwarding state in the network resulted in
Sydneys fe-0/0/1 and fe-0/0/0 interfaces being the respective RPF
interfaces for the 192.168.2.1 address associated with the RP and the 1.1.1.1
address associated with the multicast source.
This state is shown in the output of show multicast rpf commands issued at
the Sydney station:
lab@Sao_Paulo-3> show multicast rpf 192.168.2.1
258
Multicast RPF table: inet.0, 37 entries

192.168.2.1/32
Protocol: OSPF
Interface: fe-0/0/1.0
Neighbor: 10.0.31.1
1.1.1.0/24
Protocol: OSPF
Neighbor: 10.0.31.1
The key point is that after a routing restart or a reboot at Sydney, the RPF
interfaces might change for the 192.168.2.1 and 1.1.1.1 sources. A change in
RPF interface in turn results in changes to the networks multicast forwarding
patterns and overall multicast state. The bottom line is that the examples shown
on the following pages represent one of several possible realities for multicast
operation in the classroom lab topology.
259
Tokyo
2
/0/
-0
fe 5.2
1
ge-2/2
/0
16.2
fe-0/0/3
1.1.1.2
fe-0/0/0
22.2
fe-0/0/1
22.1
RP
San Jose
so-2/0/0
1.2
so-3/1/0
1.1
Montreal
/0
0/2
at- 0.1
at
-0
2.1 /2/0
Hong Kong
/0
fe-0/0
21.1
ge-0/1
/0
16.1
fe-0/0/0
21.2
Server
1.1.1.1
London
fe-0
29.1 /0/1
fe-0
/0/0
29.2
Amsterdam
/3
so-3/1
24.1
fe
31 -0/0
.1 /1
Server Groups=
224.7.7.7
224.8.8.8
at0
0.2 /2/0
Denver
/1
0/0
fe- .1
15
fe
31 -0/0
.2 /1
so
-2
/
8.1 2/0
Sydney
Client
10.200.200.2
fe-0/0/0
13.1
fe-0/0/0
13.2
Sao Paulo
Data
Control
fe-0/0/3
10.200.200.1
Figure 82: Joining a Shared Tree Example: Step 2
Traffic Flows Over the Shared Tree

PIM-SM operation centers around a single, unidirectional shared tree, whose root
node is called the rendezvous point (RP). In the example on the slide, we
configured the Montreal router to operate as an RP, and we configured all other
routers to use Montreal as the RP.
260
Analyzing Join State: Shared Tree

lab@San_Jose-3> show pim join extensive 224.7.7.7
Instance: PIM.master Family: INET
Group: 224.7.7.7
Indicates a (*, G) join
Source: *
RP: 192.168.2.1
Flags: sparse,rptree,wildcard
Upstream toward the RP (Montreal)
Upstream interface: so-2/0/0.0
Sends a join toward the RP
Upstream State: Join to RP

Downstream Neighbors:
Interface: ge-2/2/0.0
Towards the receiver (Sydney)
10.0.16.1 State: Join Flags: SRW Timeout: 197

Group: 224.7.7.7
Indicates a (S, G) prune towards the RP
Source: 1.1.1.1
RP: 192.168.2.1
Flags: sparse,rptree
Upstream interface: so-2/0/0.0
Sends a prune toward the RP
Keepalive timeout:
Interface: ge-2/2/0.0 (pruned)
10.0.16.1 State: Prune Flags: SR Timeout: 197
Figure 83: Analyzing Join State: Shared Tree
Shared-Tree Join State

A station joins the shared tree by generating explicit join messages sent hop by
hop toward the root node of the tree. You can determine if a router is part of an
RPT tree by analyzing the output of a show pim join extensive command.
This output, which is taken from the San Jose station, shows us that this router is
part of the RP tree (the tree toward the root node, which is the RP), that the
upstream interface is toward the root, and that this router has sent a (*, G) join
message to the RP. The display also confirms that the outgoing interface (the
downstream interface) for the (*, G) shared-tree join correctly points back towards
the receiver via the Hong Kong station. Seeing that the Hong Kong station is listed
as a downstream neighbor for the (*, G) state at San Jose indicates that the Hong
Kong station is also part of the shared tree between the RP and receiver.
The slide also shows that an (S, G) prune was sent along the shared tree for
source 1.1.1.1. This indicates that the last-hop router signaled an SPT towards
the source. The Sydney station prunes the 1.1.1.1 source from the shared tree
once the SPT is established because it now receives the traffic over the optimal
SPT. The (*, G) state at Sydney for the 224.7.7.7 group is shown here:
lab@Sydney-3> show pim join extensive 224.7.7.7
Group: 224.7.7.7
Source: *
RP: 192.168.2.1
261
Upstream interface: fe-0/0/1.0

10.200.200.1 State: Join Flags: SRW
262
Timeout: Infinity
Joining the Shortest-Path Tree
Hong Kong
/2
/0
-0
fe 5.2
1
fe-0/0/1
22.1
Prune Message
(S, G)
San Jose
so-2/0/0
1.2
RP
so-3/1/0
1.1
2/0
0/
at- 0.1
e Mes
s
(S, G) age
fe-0/0/3
1.1.1.2
fe-0/0/0
22.2
Montreal
at0
2. /2/0
1
Tokyo
-0/0/0
/0 fe .2
21
fe-0/0
.1
1
2
ge-0/1
/0
16.1
ge-2/2
/0
Prun
16.2
Server
1.1.1.1
Denver
Prune Message
(S, G)
/1
0/0
fe- .1
15
so
8.2 0/1/
Sydney
Client
10.200.200.2
fe-0/0/3
10.200.200.1
fe-0/0/0
13.2
Join Message
(S, G)
Me
ssa
G) ge
fe-0
/0/0
29.2
Amsterdam
/3
so-3/1
24.1
fe
31 -0/0
.2 /1
so
-2
/
8.1 2/0
fe-0/0/0
13.1
London
fe-0 (S,
29.1 /0/1
Jo
in
M
(S es
, G sa
) ge
at0
0. /2/0
2
Joi
n
fe
31 -0/0
.1 /1
Server Groups =
224.7.7.7
224.8.8.8
Sao Paulo
Data
Control
Figure 84: Joining the Shortest-Path Tree
Joining the SPT

PIM-SM does not limit receivers to the use of a shared tree. A receiver can send
an explicit join mechanism to join a source or SPT tree. An SPT results in an
optimal path between the sender and receiver and also prevents the RP from
becoming a bottleneck. In this case, the last-hop DR (Sydney) explicitly joins the
SPT back to the source (London). Because we now have traffic flowing over the
optimal path (London, Amsterdam, Sao Paulo, Sydney) to the receivers, what
happens with the traffic conveyed via the shared tree? To avoid a looping
situation, the Sydney router sends a (S,G) prune message to prune traffic sent by
the London router from the shared tree.
Joining the Shortest-Path Tree
263
Traffic Flows over the SPT

Server Groups =
224.7.7.7
224.8.8.8
Server
1.1.1.1
fe-0/0/3
1.1.1.2
fe-0/0/0
22.2
London
fe-0
29. /0/1
1
fe -0
/ 0/
29.20
fe
31 -0/0
.1 /1
Amsterdam
fe
31 -0/0
.2 /1
Shared-tree routers have been

pruned for these groups
Sydney
Client
10.200.200.2
fe-0/0/0
13.1
fe-0/0/3
10.200.200.1
fe-0/0/0
13.2
Sao Paulo
Data
Control
Figure 85: Traffic Flows over the SPT
Traffic Now Follows the SPT

The end result of all this joining and pruning is that the traffic generated by the
London router now takes the optimal path to the receivers on the Sydney router.
This slide illustrates the SPT between the London and Sydney routers.
264
Traffic Flows over the SPT
Sydney after Joining the SPT

lab@Sydney-3> show pim join extensive 224.7.7.7
Still on RPT for other sources
Group: 224.7.7.7
Source: *
RP: 192.168.2.1
Send (*, G) join toward the RP
10.200.200.1 State: Join Flags: SRW Timeout: Infinity
Group: 224.7.7.7
Now on the source tree
Source: 1.1.1.1
Send (S, G) join toward the source and a
Flags: sparse,spt
prune towards the RP
Upstream State: Join to RP, Join to Source
Keepalive timeout: 159
On the source tree
10.200.200.1 State: Join Flags: S
Timeout: Infinity
Figure 86: Sydney after Joining the SPT

This slide shows how you can verify that traffic is flowing down an SPT. Recall that
initially the flow of multicast traffic was over the suboptimal shared tree rooted at
the RP. The output from a show pim join extensive command issued at
Sydney confirms that the traffic is now forwarded over an optimal path down an
SPT rooted at the source (1.1.1.1) and terminates at the receiver.
The most important points on this slide are that the traffic is now on the source
tree (SPT), that it shows the correct upstream interface toward the source (traffic
arriving on other interfaces will be pruned), and that the router has sent a join
message toward the source and a prune message toward the RP. Also of note is
the ongoing presence of (*, G) state, which indicates that the Sydney router is still
on the shared tree for all other source address that might send to group 224.7.7.7.
Note that the display on the slide contains a bug that incorrectly displays Join
when, in fact, a Prune was sent. This problem is tracked as PR 36185 PIM (S,G)
flag says Join to RP while sending RPT Prunes. We expect this display bug to be
fixed in a subsequent release.
265
Confirming SPT State: Sao Paulo

lab@Sao_Paulo-3> show pim join extensive 224.7.7.7
Group: 224.7.7.7
Source: 1.1.1.1
On a source tree
Flags: sparse
Upstream State: Join to Source
Send (S, G) join toward the Source

On a source tree
10.0.13.1 State: Join Flags: S Timeout: 201
Figure 87: Confirming SPT State: Sao Paulo
Confirming Sao Paulo Is on the SPT

The Sao Paulo router, which was not in the shared-tree path, is part of the SPT
between the London and Sydney routers in this example. The upstream state on
the Sao Paulo router correctly indicates that it has sent a (S, G) join message to
the source (London). Notice that you do not see an (S, G) prune message to the
RP or a (*, G) join. This is because this Sao Paulo router was not part of the
shared tree in this example.
266
Confirming SPT State: Sao Paulo
Confirming RPF State: Sao Paulo

1.1.1.0/24
Protocol: OSPF
Neighbor: 10.0.31.1
Upstream (RPF) interface towards source
Upstream neighbor (Amsterdam)

10.200.200.0/24
Protocol: OSPF
Protocol use to calculate RPF
Neighbor: 10.0.13.1
10.0.2.0/24
Protocol: OSPF
Interface: so-0/1/0.0
Neighbor: (null)
Null RPF neighbor; this interface is not on the RPF path for
any join/prune messages. No multicast traffic is flowing from
Denver to Sao Paulo
Figure 88: Confirming RPF State: Sao Paulo
Confirming the RPF State on the Sao Paulo Router

The example on the slide uses the classroom lab topology to illustrate a simple
RPF check. From the view point of the Sao Paulo router, the upstream RPF
interface towards the source of the multicast traffic (1.1.1.1) is its fe-0/0/1
interface. The RPF neighbor is 10.0.31.1, which is the fe-0/0/1 interface on the
Amsterdam router. If the Amsterdam router were to go down, the router would
calculate a new path back to the source using the unicast routing table or
optionally, the inet.2 routing table. (Using the inet.2 routing table is covered
in the Advanced Juniper Networks Routing (AJNR) course because inet.2
usage normally relates to interdomain multicast using Multiprotocol BGP and the
Multicast Source Discovery Protocol (MSDP).
Confirming RPF State: Sao Paulo
267
PIM RP Discovery Options
Determining the RP
Auto-RP
Bootstrap router

The slide lists the topics we discuss on the following pages.
268
Determining the RP
Administrators can select and configure routers to be an RP for one or more

multicast groups
Should select centrally located routers
Other routers must be informed about the RP for each group
Static RP configuration
Simple, but fault tolerance is a concern
Dynamic RP mechanisms
Bootstrap protocol: RFC 2362, uses 224.0.0.13 (all PIM routers)
Auto-RP: proprietary, uses groups 224.0.1.39 and 224.0.1.40
Anycast-RP: multiple RPs sharing a single IP address, often used in

conjunction with interdomain multicast
Static RP
There are multiple ways to determine which router is the RP for a given multicast
group. You can statically define an RP on a given router and then configure the
other routers to use that RP. You also can statically define an RP for a group or
range of groups. In its most basic form, a statically defined RP does not support
failover. Methods for achieving static RP redundancy are beyond the scope of this
class.
Dynamic RPs
Two methods of dynamic RP discovery exist. The first method is the Bootstrap
Protocol (RFC 2362), in which all routers within a PIM domain collect bootstrap
messages. The domains bootstrap router originates bootstrap messages, and
these messages are sent hop by hop within the domain. The routers use
bootstrap messages to distribute RP information dynamically and to elect a
bootstrap router when necessary.
The second method is Auto-RP, which is a proprietary method that was used
before the release of PIMv2 (which supported the Bootstrap Protocol). It uses PIM
sparse-dense mode to implement automatic RP announcement and discovery.
You can configure the router to advertise that it is eligible to be the RP, to learn
which systems are RPs, and to run the RP election algorithm. You must first
configure two multicast groups, 224.0.1.39 and 224.0.1.40, as dense groups or
configure a static RP for those two groups.
Anycast RP can use any RP-set mechanism to distribute the RP-to-group
mapping (static, Bootstrap, Auto-RP). Normally, it is used as a way to introduce
RP redundancy when using static RP. Bootstrap and Auto-RP have built-in ability
for redundant RPs, so using Anycast on top of them does not gain much. Anycast
RP only requires additional configuration on the routers serving as the RPs. The
other routers are configured as normal, with the static RP configuration pointing to
the shared anycast address.
Determining the RP
269
Auto-RP
Allows routers to learn the address of the RP automatically
PIM version 1 or 2
Nonstandard
Needs two specific dense-mode groups
224.0.1.39 (announce)
Used to learn which routers in the network are possible candidate

RPs
224.0.1.40 (discovery)
Allows PIM routers to learn about the active group-to-RP mapping

information
Allows backup RPs for failover but no load balancing
Mapping agents
Selects the RP for a multicast group address range based on candidates

IP address (highest address is selected)
Dynamic RP Assignment
If you want a more dynamic way of assigning RPs in a multicast network, Auto-RP
is one option. Auto-RP has both positive and negative aspects to its operation.
From a positive perspective, it will operate in both a version 1 and a version 2 PIM
network. Negatively, it is a nonstandard (non-RPF based) function and requires
the use of dense mode PIM to advertise control traffic.
Dense Groups Needed

Auto-RP requires multicast flooding to both announce potential RP candidates
and to discover the elected RPs in the network. This flooding occurs using a PIM
dense-mode model where group 224.0.1.39 is used for the announce messages
and group 224.0.1.40 is used for the discovery messages.
Failover Capabilities
One advantage that Auto-RP maintains over static RP assignment is the ability to
maintain a backup RP in the network. This allows you to configure multiple routers
as RP candidates. Should the elected RP stop operating, one of the other
preconfigured routers can take over the RP functions. The Auto-RP mapping
agent controls this capability.
270
Auto-RP
Mapping Agents
As multiple candidate RP routers announce their capabilities to support multicast
groups, there needs to be a single router in the networkthe mapping agentto
perform the group-to-RP mapping. This functionality is required because there
can only be a single RP for each multicast group. The mapping agent sends out
discovery messages to the network informing all routers which RP to use for
specific multicast groups.
Auto-RP
271
Bootstrap Router (1 of 2)
Bootstrap router eligibility
Bootstrap priority is 0 by default
Modified with bootstrap-priority statement
Higher priority is elected
Highest IP address is used in a tie
Bootstrap router RP election algorithm
Most specific range
Priority
Hashing mechanism
Highest IP address
Priority for Becoming the Bootstrap Router

To set a preference for bootstrap router election, you must modify the priority
because, by default, the router has a bootstrap priority of 0. Thus, the router can
never be the bootstrap router. To modify this priority, include the
bootstrap-priority statement under [edit protocols pim] hierarchy
level. The router with the highest priority value is elected as the bootstrap router.
In the case of a tie, the router with the highest IP address is elected to be the
bootstrap router.
Mechanism to Select the RP

When using a bootstrap router, you can configure the RP by specific range. Use a
priority that overrides the group range, or rely on a hashing algorithm to
load-balance group mappings to RPs dynamically.
272
Most specific range: The default range is 224.0.0.0/4, which you can modify
with the group-ranges statement. The default value indicates that a router
running PIM is eligible to be the RP for all groups.
Priority: The router with the highest bootstrap priority for a given range is
elected as the domains bootstrap router. To modify the priority, include the
priority statement at the [edit protocols pim rp local] level.
Hashing: A hashing algorithm is used to select an RP for a given group. Input

variables, such as candidate RP address, group address, and a hash mask,
are used to return a hash value.
Highest IP address: If for some reason two candidate RPs result in the same
hash value, the tie is broken in favor of the candidate RP with the highest IP
address.
Can configure multiple candidate bootstrap routers
Router can be BOTH a candidate RP and a candidate bootstrap router
One candidate RP and one candidate bootstrap router necessary for

bootstrap mechanism to work
PIMv2 only
Automatic load balancing among candidate RPs
Bootstrap Mechanism
Several options exist when configuring the bootstrap router. The following list
provides a general overview of these options:
Candidates: Select which routers are candidate RPs and which routers are
candidate bootstrap routers. A router can be both a candidate RP and a
candidate bootstrap router.
Operation: You must have at least one candidate RP and one candidate
bootstrap router for the bootstrap mechanism to work.
PIM versions: All of the interfaces within the PIM domain must run PIM
version 2. The interfaces that connect to other PIM domains should run PIM
version 1 so that candidate RP and bootstrap messages are not leaked to the
other domain.
Load Balancing
All routers in a network maintain the complete RP set of PIMv2 candidate RP
advertisements in their group-to-RP mapping cache. Each entry has a holdtime
that specifies how long the candidate RP advertisement is valid. Automatic load
balancing is implemented using the hashing algorithm mentioned on the previous
page.
Bootstrap routers use a hashing algorithm to select the RP for a given multicast
group. The hashing mechanism takes as input variables a candidate RP address,
a group address, and a hash mask. If two candidate RPs result in the same hash
value, the tie is broken in favor of the candidate RP with the highest IP address.
This process is part of the PIMv2 specification and should be contrasted to
Auto-RP, which does not support an auto-load-balancing mechanism.
You can map specific group ranges to specific candidate RPs through
configuration. When no specific group range is specified, a default group range of
224.0.0.0/4 is put into effect, and the RP is considered a candidate for all groups.
The load-balancing behavior of the Bootstrap Protocol results in each bootstrap
router handling a subset of the Class D addressing space. The capture here
illustrates this automatic load-balancing behavior when two RPs are configured
with support of the entire Class D addressing space (224/4):
lab@saopaulo> show pim rps detail
RP: 192.168.16.1
Learned from 10.0.8.1 via: bootstrap
273
Time Active: 00:52:46

Holdtime: 150 with 103 remaining
Group Ranges:
224.0.0.0/4
Active groups using RP:
224.1.1.200
total 1 groups active
RP: 192.168.24.1
Learned from 10.0.8.1 via: bootstrap
Group Ranges:
224.0.0.0/4
224.2.127.254
224.7.7.7
224.8.8.8
274
SAP and SDP Protocols
SAP and SDP overview
Specifying SAP and SDP listen addresses

The slide lists the topics we discuss on the next page.
275
Overview of SDP and SAP

z The Session Description Protocol
provides information needed to

join multicast sessions
Session name and purpose
Time(s) that the session is active
Media type and format
H.261 video, MPEG video, etc.
Transport protocol (RTP/UDP/IP,
H.320, etc.)
z The Session Announcement
Protocol transports SDP

messages
Client announces to a well-known
address and port
The SDR client uses SDP/SAP

to list available multicast sessions
224.2.127.254:9875 is the default SAP

group/port
Figure 89: Overview of SDP and SAP
Session Description Protocol

SDP is a session description protocol for multimedia sessions. A common mode
of usage is for a client to announce a conference session by periodically
multicasting an announcement packet to a well-known multicast address and port
using the Session Announcement Protocol (SAP). SDP defines a format for
describing the properties of a media session, including its IP address(es), port(s),
and media type(s). RFC 2327 defines SDP.
Session Announcement Protocol

SAP is an announcement protocol used by clients to announce multicast sessions
described by SDP. In operation the clients periodically multicast SAP packets
containing session information to a well-known multicast address and port. The
default address and port for SAP is 224.2.127.254:9875. RFC 2974 defines SAP.
Session directory programs, such as the SDR client shown on the slide, work with
SAP and SDP to allow a multicast client to tune into a desired multicast channel
with a few simple mouse clicks.
As of this writing, you can download the SDR client for most operating systems
from the following location:
http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/download.html.
276
Overview of SDP and SAP
Displaying Session Details
The details needed to participate in a multicast session are listed when the
session is selected
Simply click the join button to participate
The SDR client displays the session details as communicated through SDP
Figure 90: Displaying Session Details

The SDR client displays the details of each multicast session, as communicated
through the SDP protocol, when the user selects a session from the main display
(shown on the previous page).
The session details include information on whether encryption is in effect, the
media type and encoding, the IP addressing, and the ports used to convey the
media streams. With the information obtained through SDP, as conveyed through
SAP, all the user has to do is click the join button to participate in the media
content.
277
Module Review
What is the need for an RPF check?
What are the differences between IGMP versions?
When is a shared tree used?
What are the differences between sparse- and dense-mode protocols?
What are the differences between the bootstrap router and Auto-RP election
mechanisms?
278
Module Review
IP multicast traffic flow;
Multicast addressing;
The components of multicast;
The role of IGMP and the differences between IGMP versions;
The need for RPF checks;
The difference between shared and source-specific trees;
Sparse- and dense-mode operation;
PIM RP discovery mechanisms; and
The function of the SAP and SDP protocols.
Chapter 8: Module 8: Multicast Configuration and Monitoring
Chapter 8
Module 8: Multicast Configuration and

Monitoring
Module Review
279
Module Objectives
List JUNOS software multicast support
Explain IGMP configuration
Configure PIM sparse and dense modes
Configure RP discovery mechanisms
List operational commands for multicast monitoring and troubleshooting
280
Module Objectives
JUNOS software multicast support;
Configuring IGMP using JUNOS software;
Configuring PIM using JUNOS software;
Implementing PIM RP discovery mechanisms; and
Commands used for multicast monitoring and troubleshooting.
Multicast Support
JUNOS software currently supports these multicast features:
IGMP versions, 1, 2, and 3
DVMRP
PIM sparse-dense mode
SAP
MSDP
MBGP
Scoping
Prefix limits
JUNOS Software Multicast Support

JUNOS software supports the following multicast protocols:
IGMP: Hosts use the Internet Group Management Protocol to join a multicast
group. Routers use it to maintain a list of multicast group memberships on a
per-interface basis.
DVMRP: The Distance Vector Multicast Routing Protocol was the first true
multicast routing protocol to see widespread use.
PIM: Protocol Independent Multicast is a multicast routing protocol

independent of the unicast protocol selected.
SAP: The Session Announcement Protocol is an announcement protocol for

multicast conference sessions.
MSDP: The Multicast Source Discovery Protocol allows RP peering across

different domains.
MBGP: Multiprotocol BGP adds new attributes to BGP used to exchange

reachability information for different address families. Using these attributes,
BGP can carry both unicast routing and multicast RPF information in the
same updates.
Scoping: This prevents high-rate multicast traffic from traveling outside of

regions that are provisioned to handle this rate of multicast traffic.
Prefix limits: These are used for multicast traffic engineering.
Multicast Support
281
282
IGMP configuration
General PIM configuration
Configuration examples
Static RP
Auto-RP
Bootstrap
Configuring IGMP
[edit]
protocols {
igmp {
interface interface-name {
disable;
Explicitly enable/disable IGMP on
static {
interfaces, set the IGMP version, and
group group {
configure static joins (ASM or SSM).
source source;
}
}
version version;
}
query-interval seconds;
Configure global IGMP
query-last-member-interval seconds;
timers and counters
query-response-interval seconds;
robust-count number;
}
}
Figure 91: Configuring IGMP
IGMP is enabled by default on multipoint PIM/DVMRP interfaces
Might auto-enable on point-to-point interfaces in some releases
IGMP Configuration
To configure IGMP, you include statements at the [edit protocols igmp]
hierarchy level of the configuration.
IGMP is enabled automatically on all nonpoint-to-point interfaces configured to
run DVMRP or PIM in all JUNOS software releases. The 6.x releases used to
develop this material also enables IGMP on point-to-point interfaces configured
for PIM or DVMRP. Indications are that future JUNO software releases will return
to the previous behavior of not automatically enabling IGMP on point-to-point
interfaces. Having to explicitly enable IGMP on a point-to-point interface is a rare
event, as multicast receivers are normally LAN attached.
You can manually list the interfaces that should run IGMP or use the all
keyword. In all cases you should ensure that IGMP does not run on the routers
out-of-band interface (fxp0) by specifically listing the fxp0 interface as disabled,
especially when using the interface all approach. Interfaces enabled for
IGMP run version 2, by default. You can manually select version 1 or 3 as needed.
IGMP version 3 supports source-specific multicast (SSM). The generic syntax on
the slide shows how you can configure a static IGMP join under a particular
interface for a given group address. By including a source address, you define a
static (S,G) join; omitting the source address creates a wildcard (*, G) join, which
is also called an
all-source multicast (ASM). Static joins are useful when testing multicast in the
absence of a multicast receiver.
Configuring IGMP
283
The IGMP querier router periodically sends general host-query messages. These
messages solicit group membership information and are sent to the all-systems
multicast group address, 224.0.0.1. By default, the router sends host-query
messages every 125 seconds. You might want to change this interface to tune the
number of IGMP messages sent on the subnet.
284
Configuring IGMP
PIM Configuration: General

[edit]
protocols {
pim {
List dense groups for
dense-groups {
sparse-dense mode operation
group-addresses;
}
disable;
Policy list for join filtering
import [ policy-names ];
interface interface-name {
disable;
Enable PIM on a given
hello-interval seconds;
interface, set the mode,
mode (dense | sparse | sparse-dense); version, and various
timers for that
priority number;
interface
version (1 | 2 );
}
Specify a RIB group for RPF
rib-group group-name;
(inet.0 used by default)
. . . .
Figure 92: PIM Configuration: General

This page focuses on PIM configuration that does not relate to rendezvous point
(RP) functionality. To enable PIM routing on the router, include the pim statement
at the [edit protocols] hierarchy level. By default, PIM operates in dense
mode. All other PIM configuration statements are optional.
When operating in a sparse-dense mode, you must tell PIM which groups are to
be flooded in dense mode with the dense-groups statement. You use PIM
import policy to filter PIM joins.
You can specify a specific interface or interfaces on which to enable PIM, or use
the keyword all to enable PIM on all interfaces. When listing specific interfaces,
be sure to specify the full interface name, including the physical and logical
address components. When using the interface all option, take care to
explicitly disable PIM on the routers fxp0 out-of-band interface. While this
prevents PIM from operating on the out-of-band interface, IGMP still is enabled on
the fxp0 interface unless you explicitly disable IGMP for the fxp0 interface under
the [edit protocols igmp] stanza. We recommend that you never run PIM
or IGMP on the routers out-of-band interface.
All systems on a subnet must run the same version of PIM. By default, JUNOS
software uses PIM version 2. To configure PIM version 1, include the version
statement. The priority value determines the likelihood of the local system being
elected the designated router (DR) for the subnet associated with this interface.
285
You can associate PIM with a routing table group used for PIM for reverse-path
forwarding (RPF) checks by including a rib-group statement. The routing table
group is a group that you define with the rib-group statement at the [edit
routing-options] hierarchy level. By default, PIM performs RPF checks
against the main routing instance (inet.0).
286
PIM Configuration: RP Properties

Configure automatic advertisement and
learning of local/remote RPs
. . .
rp {
auto-rp (announce | discovery | mapping);

bootstrap-export [ policy-names ];
Bootstrap priority and policy (to
bootstrap-import [ policy-names ];
filter bootstrap messages at domain
bootstrap-priority number;
boundaries)
local {
family (inet | inet6) {
disable;
address address;
group-ranges {
Configure local router to
function as an RP for desired
destination-mask;
family
}
hold-time seconds;
priority number;
}
}
static {
address address {
Statically configure this router
version version;
with the addresses of remote RPs
group-ranges {
destination-mask;
}
Figure 93: PIM Configuration: RP Properties
General PIM Configuration: RP Properties

This page focuses on PIM configuration relating to RP functionality. The auto-rp
and bootstrap related configurations support automatic RP election. We
discuss both mechanisms and their related parameters in detail on subsequent
pages. For bootstrap routers, you can configure the routers priority and
import/export policies that filter bootstrap messages at PIM domain boundaries.
Use the local portion of the PIM configuration stanza to define local RP
properties for this router. This portion of the configuration configures the local
router to function as an RP.
The static portion of the PIM stanza functions to list the IP addresses of remote
RP-capable routers. Generally speaking, you normally configure RP-related
functionality in one the following ways. Note that RPs are only used when
operating in a sparse mode:
Static RP election:
The RP is configured with local RP properties.
Non-RP routers are configured with the address of the RP router using
the static keyword.
Dynamic RP election:
The RP is configured with local RP properties.
287
288
The RP is also configured to run Bootstrap or Auto-RP, but normally not

both.
Non-RP routers are configured to run the Bootstrap or Auto-RP protocols

(but normally not both) to dynamically learn the RPs address.
Configuration Example: Static RP

Montreal
(RP)
Amsterdam
(Non-RP)
[edit protocols pim]

lab@Montreal-3# show
rp {
local {
family inet {
address 192.168.2.1;
}
}
}
interface all {
mode sparse;
}
interface fxp0.0 {
disable;
}

lab@Amsterdam-3# show
rp {
static {
address 192.168.2.1;
}
}
interface all {
mode sparse;
}
interface fxp0.0 {
disable;
}
Figure 94: Configuration Example: Static RP
Static RP Configuration Example

Static RP configuration is straightforward. Static RP designs have the benefit of
not requiring the added sophistication of RP election protocols like Bootstrap and
Auto-RP. Some measure of failover protection can be afforded in a static RP
design by configuring multiple local RP entities with a nonunique RP address and
full-mesh MSDP peering. In this case, non-RP routers use the IGP to resolve the
optimal route to the closest RP. The failure of one RP results in an IGP
convergence on the metrically closest RP that is still functional and reachable.
The MSDP sessions between the local RPs ensures that the PIM domain in not
bifurcated. This approach is similar to the techniques used in Any-RP.
The rp local portion of the hierarchy accommodates the configuration needed
for a given router to function as an RP. In the example on the slide, we configured
the Montreal-3 station to operate as a local RP; note that the routers lo0
address is normally specified as the RP address for maximum reliability. The
static portion of the hierarchy allows other routers to be statically configured
with a list of RPs and their associated group ranges. Here, we configured the
Amsterdam-3 router with the Montreals lo0 address as the PIM domains RP.
As a result of this configuration, the Amsterdam-3 station correctly displays
Monteral-3 as the domains RP:
lab@Amsterdam-3> show pim rps
Instance: PIM.master
Family: INET
RP address
192.168.2.1
Type
static
Holdtime Timeout Active groups Group prefixes

0
None
0 224.0.0.0/4
Configuration Example: Static RP
289
Configuration Example: Auto-RP

Montreal
(RP/Mapping)

dense-groups {
224.0.1.39/32;
224.0.1.40/32;
}
rp {
local {
family inet {
address 192.168.2.1;
}
}
auto-rp mapping;
}
interface all {
mode sparse-dense;
}
interface fxp0.0 {
disable;
}
Amsterdam
(Non-RP/Discovery)

dense-groups {
224.0.1.39/32;
224.0.1.40/32;
}
rp {
auto-rp discovery;
}
interface all {
mode sparse-dense;
}
interface fxp0.0 {
disable;
}
Figure 95: Configuration Example: Auto-RP
Auto-RP Configuration Example

Auto-RP is somewhat complex to configure because of the protocols reliance on
dense-mode flooding for the 224.0.1.39 and 224.0.1.40 group addresses. These
groups are used to convey Auto-RP announce and discovery messages
respectively. You can avoid the need for sparse-dense operation by defining static
RPs for the 224.0.1.39 and 224.0.1.40 groups. Note that Auto-RP currently
functions for the IPv4 protocol only.
The sample configurations include the Auto-RP dense groups and correctly
associates all interfaces with sparse-dense mode (sparse-dense mode is not
required on the loopback interface, but it causes no harm). Proper Auto-RP
operation requires that PIM be enabled on the routers loopback interface. We
accomplish this with the interface all statement in this example.
The auto-rp mapping statement configures Monteral-3 to perform the
RP-to-group mapping function and to announce itself as an RP candidate. The
configuration of the non-RP station includes an auto-rp discovery statement
to accommodate the processing of discovery messages generated by the
mapping router. In this example, the mapping and RP routers are the same;
however, this does not have to be the case. The result of this configuration is the
automatic discovery of the domains RP via Auto-RP at the Amsterdam-3 station:
Family: INET
RP address
Type
192.168.2.1
auto-rp
150
150
0 224.0.0.0/4
290
While Auto-RP provides inherent failover when multiple local RP-capable routers
exist within a PIM domain, the protocol suffers from a lack of standard status and
its inability to load balance among a set of RP-capable routers. The Anycast-RP
mechanism alleviates most of these concerns; however, a discussion of its
particulars are beyond the scope of this class.
291
Configuration Example: Bootstrap

Montreal
(RP/Bootstrap)

rp {
bootstrap-priority 100;
local {
family inet {
address 192.168.2.1;
}
}
}
interface all {
mode sparse;
}
interface fxp0.0 {
disable;
}
Amsterdam
(Non-RP)

interface all {
mode sparse;
}
interface fxp0.0 {
disable;
}
Figure 96: Configuration Example: Bootstrap
Bootstrap Configuration Example

The Bootstrap Protocol is another method to dynamically determine which router
is the RP. In operation, the domains bootstrap router originates bootstrap
messages that are sent hop by hop within the domain. The bootstrap messages
distribute RP candidacy status, which PIM routers use to map a candidate RP to a
specific group range. Bootstrap messages are also used to elect a bootstrap
router when needed.
By default, the router has a bootstrap priority of 0, which means the router can
never be the bootstrap router. Include the bootstrap-priority statement to
set a zero priority. The router with the highest priority value is elected as the
bootstrap router. In case of a tie, the router with the highest IP address is elected
as the bootstrap router. The bootstrap protocol requires PIM version 2 and does
not make use of sparse-dense operation.
The configuration of the non-RP station is pretty straightforward. Note that we
configured both stations with PIM enabled on all interfaces, except the fxp0
out-of-band interface. PIM is not required on the loopback interface for bootstrap
operation. Explicit declaration of sparse mode is because it is the default in the 6.0
Release, which we used to develop this section. The explicit sparse-mode
declaration is prudent considering that some versions of JUNOS software
defaulted to dense mode, however.
The result of this configuration is the automatic discovery of the domains RP and
bootstrap routers at the Amsterdam-3 station:
lab@Amsterdam-3> show pim bootstrap
BSR
Pri Local address
Pri State
Timeout
192.168.2.1
100 192.168.24.1
0 InEligible
116
292

Family: INET
RP address
Type
293
Monitoring Multicast Operation
show igmp
interface
group
statistics
show pim
bootstrap
rps
interfaces
neighbor
join
statistics
show multicast
rpf
route
usage
next-hops
Multicast Operational Commands

The slide lists the various operational commands used for the multicast protocols.
We provide details of these commands on the following pages. The information
you can gather about each protocol is:
294
IGMP: You can display members of IGMP groups by interface, show just the
groups themselves, or display IGMP statistics.
PIM: You can display bootstrap routers, rendezvous points, interfaces,

neighbors, PIM groups and statistics.
Generic multicast information: You can display multicast RPF calculations,

entries in the multicast forwarding cache, statistics, multicast next hops, and
the most active multicast groups.
Monitoring Multicast Operation
Obtaining IGMP Interface Information

lab@San_Jose> show igmp interface
Interface: at-0/2/0.100
Querier: 10.0.0.1
State:
Up Timeout:
None Version:
Interface: so-2/0/0.0
Querier: 10.0.1.1
State:
Up Timeout:
251 Version:
Interface: ge-0/3/0.0
Querier: 10.0.16.1
State:
Up Timeout:
184 Version:
2 Groups:
2 Groups:
2 Groups:
Configured Parameters:
IGMP Query Interval: 125.0
IGMP Query Response Interval: 10.0
IGMP Last Member Query Interval: 1.0
IGMP Robustness Count: 2
Derived Parameters:
IGMP Membership Timeout: 260.0
IGMP Other Querier Present Timeout: 255.0
Displaying the IGMP Interface

The output of the show igmp interface command is a listing of interfaces
running IGMP, the IGMP version, and the number of groups currently active. The
IGMP querier address is also listed when it is known. The display also provides a
listing of the derived and configured timer and counter parameters used to control
the operation of IGMP.
Note that some versions of JUNOS software require explicit configuration to
enable IGMP on point-to-point interfaces; multi-access interfaces like Ethernet
automatically enable IGMP when PIM or DVMRP is enabled on that interface. The
6.x Release we used to develop this material automatically enables IGMP on all
interfaces enabled for PIM operation.
Obtaining IGMP Interface Information
295
Displaying IGMP Group Information

lab@Sydney> show igmp group
Group: 224.0.0.2
Source: 0.0.0.0 Last reported by:
Timeout:
195 Type: Dynamic
Group: 224.0.0.5
Timeout:
194 Type: Dynamic
Group: 224.0.0.6
Timeout:
194 Type: Dynamic
Group: 224.0.0.22
Timeout:
194 Type: Dynamic
. . .
Group: 224.7.7.7
Timeout:
204 Type: Dynamic
Group: 224.8.8.8
Timeout:
204 Type: Dynamic
. . .
10.0.13.2
10.0.13.2
10.0.13.2
10.0.13.2
10.200.200.2
10.200.200.2

Use the show igmp group command to show the groups joined by directly
connected hosts and other routers. When a router is attached to a LAN that has
only IGMP-speaking hosts (that is, no other PIM-speaking routers), that interface
must run PIM for the router to function properly. If you explicitly enable IGMP on
an interface but fail to enable PIM on that interface also, the IGMP interface status
shows the Up state, but that interface is omitted from the output of a show igmp
group command.
The edited sample on the slide shows the group-related information for the
Sydney routers fe-0/0/0 and fe-0/0/1 interfaces. Note that the former is
connected to another PIM, while the latter is connected to a segment with IGMP
host only. The
fe-0/0/0 interface is displaying join information for the all-routers address
(224.0.0.2), the all-OSPF routers address (224.0.0.5), the OSPF designated
router, and the all-IGMPv3 routers multicast addresses. In contrast, Sydneys
fe-0/0/3 interface shows that only host-related group information is present.
Note that JUNOS software always accepts and listens to groups like the all-OSPF
routers or all-IGMPv3 routers addresses, even when these functions are not
actually configured. It causes no harm to list to these messages; they are not
actually acted upon unless the corresponding functionality is configured.
To clear group membership, use the clear igmp membership command.
When you want, you can clear all group information or just the information
associated with certain interfaces and groups.
296
Displaying IGMP Statistics

lab@Sydney-3> show igmp statistics
IGMP packet statistics for all interfaces
IGMP Message type
Received
Sent
Membership Query
11
13
V1 Membership Report
0
0
DVMRP
0
0
PIM V1
0
0
Cisco Trace
0
0
86
0
Group Leave
0
0
Mtrace Response
0
0
Mtrace Request
0
0
Domain Wide Report
0
0
0
0
Other Unknown types
IGMP v3 unsupported type
IGMP v3 source required for SSM
IGMP v3 mode not applicable for SSM
IGMP Global Statistics
Bad Length
Bad Checksum
Bad Receive If
Rx non-local
Rx errors
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
22
49

The show igmp statistics command displays a variety of IGMP-related
messages and error counts. You can clear IGMP statistics with the clear igmp
statistics command.
297
Displaying the Bootstrap Router

z Three scenarios:
No bootstrap router elected, local priority is zero
lab@Tokyo-3> show pim bootstrap
BSR
None
Pri Local address

0 192.168.20.1
Pri State
Timeout
0 InEligible
0
No bootstrap router elected, local priority is nonzero

lab@San_Jose-3> show pim bootstrap
BSR
None
Pri Local address

0 192.168.0.1
Pri State
110 Candidate
Timeout
55
Remote router elected as bootstrap router

lab@Tokyo-3> show pim bootstrap
BSR
192.168.0.1
Pri Local address

110 192.168.20.1
Pri State
Timeout
0 InEligible
74
Figure 97: Displaying the Bootstrap Router

The show pim bootstrap command lists the active bootstrap router along with
the local routers candidate bootstrap priority. A router with a bootstrap priority
setting of zero (default) is ineligible to become a bootstrap router. In the event of a
priority tie, the router with the highest IP address is elected the domains bootstrap
router.
The slide shows variations on the possible outcome from this command. The final
example demonstrates the successful election of a remote router (192.168.0.1) as
the domains bootstrap router while the local routers zero priority causes it to be
ineligible for bootstrap duties.
298
Determining RP Status
z
Two perspectives:
On the local RP, both static and Auto-RP are listed
lab@Montreal-3> show pim rps

Family: INET
RP address
192.168.2.1
192.168.2.1
Type
bootstrap
150
150
2 224.0.0.0/4
static
0
None
2 224.0.0.0/4
Family: INET6
While remote routers display only the Auto-RP entry

lab@Sydney-3> show pim rps
Family: INET
RP address
192.168.2.1
Type
bootstrap
150
150
2 224.0.0.0/4
Family: INET6
Figure 98: Determining RP Status
The show pim rps command displays the status of RPs configured statically or
learned dynamically through the bootstrap router or Auto-RP mechanisms. The
RP can be listed as either auto-rp, bootstrap, or static, based upon how
the RP is learned. Adding the detail switch provides additional information,
such as the group RPs active groups and the group range that it serves. In this
example, the RP is handling the entire Class D range (224/4) and has two active
groups:
lab@Sydney-3> show pim rps detail
Family: INET
RP: 192.168.2.1
Learned from 10.0.15.2 via:
Group Ranges:
224.0.0.0/4
224.8.8.8
224.7.7.7
Family: INET6
299
Viewing Extended RP Information

lab@Montreal-3> show pim rps extensive
Family: INET
RP: 192.168.2.1
Device Index: 128
Subunit: 32768
Interface: pd-0/1/0.32768
Group Ranges:
224.0.0.0/4
224.7.7.7
224.8.8.8
Register State for RP:
Group
Source
224.7.7.7
1.1.1.1
224.8.8.8
1.1.1.1
RP address and the router

from which it was learned
Tunnel interface-related information

(for register message
encapsulation/decapsulation)
FirstHop
192.168.28.1
192.168.28.1
RP: 192.168.2.1
Learned via: static configuration
Holdtime: 0
Device Index: 128
Subunit: 32768
Interface: pd-0/1/0.32768
Group Ranges:
224.0.0.0/4
Family: INET6
RP Address
192.168.2.1
192.168.2.1
Local RP
State
Receive
Receive
Timeout
0
0
Active groups on
this RP
Figure 99: Viewing Extended RP Information

The extensive switch displaysS a wealth of information about how an RP was
learned, what groups it handles, and the number of groups actively using the RP.
In this display, you also can see the tunnel interface used to decapsulate register
messages, which is pd.32768 in this case. First-hop routers encapsulate
multicast traffic into register messages, which are sent unicast to the RP using a
PIM encapsulation (pe) tunnel interface, as shown here from the London station:
lab@London-3> show pim rps extensive
Family: INET
RP: 192.168.2.1
Device Index: 133
Subunit: 32769
Interface: pe-0/3/0.32769
Group Ranges:
224.0.0.0/4
Register State for RP:
Group
Source
FirstHop
Timeout
224.7.7.7
1.1.1.1
192.168.28.1
29
224.8.8.8
1.1.1.1
192.168.28.1
29
Family: INET6
300
RP Address
State
192.168.2.1
Suppress
192.168.2.1
Suppress
Displaying PIM Interfaces

PIM version
lab@Sao_Paulo-3> show pim interfaces

Name
fe-0/0/0.0
fe-0/0/1.0
lo0.0
so-0/3/0.0
Stat
Up
Up
Up
Up
Mode
Sparse
Sparse
Sparse
Sparse
Interface status and

PIM mode
IP
4
4
4
4
V
2
2
2
2
State Count DR address

DR
1 10.0.13.2
DR
1 10.0.31.2
DR
0 192.168.12.1
P2P
1
Neighbor count
Figure 100: Displaying PIM Interfaces
Displaying Interfaces Running PIM

By default, none of the routers interfaces is enabled for PIM or IGMP. When
running PIM, you must include the routers lo0 interface to ensure proper
operation, and you should disable both PIM and IGMP explicitly on the routers
out-of-band interface (fxp0).
It is common to use the interface all switch when configuring PIM, and then
to issue interface-specific disable statements when you want the majority of the
routers interfaces to be enabled for PIM. The capture on the slide used such a
technique, and this is why the fxp0 out-of-band interface is listed as disabled.
Displaying PIM Interfaces
301
Displaying PIM Neighbors

lab@Sao_Paulo-3> show pim neighbors detail
Neighbors address and version
Address: 10.0.13.1, IPv4, PIM v2

Hello Option Holdtime: 105 seconds 78 remaining
Hello Option DR Priority: 1
Hello Option LAN Prune Delay: delay 500 ms override 2000 ms
Rx Join: Group
Source
Timeout
224.7.7.7
1.1.1.1
206
224.8.8.8
1.1.1.1
206
Neighbors timers
and supported PIM
options
PIM joins received
from this neighbor
Address: 10.0.13.2, IPv4, PIM v2, Mode: Sparse

Hello Option Holdtime: 65535 seconds
Local timers
and PIM options
Display repeats for each PIM interface
Address: 10.0.31.1, IPv4, PIM v2

Hello Option Holdtime: 105 seconds 95 remaining
Address: 10.0.31.2, IPv4, PIM v2, Mode: Sparse
Hello Option Holdtime: 65535 seconds
. . .
Figure 101: Displaying PIM Neighbors
Listing PIM Neighbors

The show pim neighbor command displays information about neighboring
routers running PIM. Adding the detail switch provides additional information,
such as the neighbors timer values and supported PIM options. The truncated
output sample on the slide shows that the router has detected two neighbors on
its fe-0/0/0 interface. One of the neighbors is 10.0.13.1 (Sydney), and the other
is the local router (10.0.13.2). Note that the external PIM neighbor has a
noninfinite hold time of 105 seconds. The output includes the various timers and
options supported by all detected PIM neighbors.
The display also confirms that the local router (Sao Paulo) has received (S, G)
joins for groups 224.7.7.7 and 224.8.8.8, from source 1.1.1.1, from the Sydney
station.
302
Displaying PIM Neighbors
Displaying PIM Join State

lab@Sydney-3> show pim join extensive
* source address indicates (*, G) state
Group: 224.7.7.7
Source: *
RP: 192.168.2.1
Indicates sparse mode, RP tree, (*, G)
RPF interface leading to RP
Outgoing interface list for this group
10.200.200.1 State: Join Flags: SRW Timeout: Infinity
Group: 224.7.7.7
Indicates (S, G) state (SPT)
Source: 1.1.1.1
Flags: sparse,spt
RPF interface towards source
Upstream State: Join to RP, Join to Source
Join to source, (S, G)
prune to RP
Outgoing interface list for this group
10.200.200.1 State: Join Flags: S
Timeout: Infinity
. . .
Figure 102: Displaying PIM Join State
Displaying PIM Join States

The show pim join command displays the join state for both shared (RPT)
and source (SPT) trees. Adding the extensive switch results in the display of
RPF and outgoing interface list (OIL) information that identifies the upstream and
downstream interfaces for that join entry. Entries with an asterisk (*) as the source
address indicate a wildcard address of 0.0.0.0 and a shared-tree join.
You can use the clear pim join command to flush the join state of all, or a
range of groups. Group activity causes the router to rejoin shared and source
trees as needed.
Note that the output on the slide contains a bug that incorrectly displays Join
when, in fact, a Prune was sent. This problem is tracked as PR 36185 PIM (S,G)
flag says Join to RP while sending RPT Prunes. We expect this display bug to be
fixed in a subsequent release.
Displaying PIM Join State
303
Examining Source RPF State

lab@Sydney-3> show pim source detail
1.1.1.1
Prefix: 1.1.1.0/24
Upstream neighbor: 10.0.13.2
Active groups:224.7.7.7
224.8.8.8
192.168.2.1
Prefix: 192.168.2.1/32
Upstream neighbor: 10.0.15.2
Active groups:224.8.8.8
224.7.7.7
Multicast source
Current RPF interface and neighbor
Rendezvous point
Instance: PIM.master Family: INET6
Figure 103: Examining Source RPF State
Displaying Source RPF State

The show pim source command displays information about the PIM source
RPF state. Adding the detail switch results in the display of the groups currently
associated with each PIM source. The example on the slide shows that two
groups are associated with the source address of the RP (shared-tree joins), and
two entries are associated with the 1.1.1.1 source address (SPT joins).
304
Examining Source RPF State
Displaying PIM Statistics

lab@Sydney-3> show pim statistics
PIM Message type
V2 Hello
V2 Register
V2 Register Stop
V2 Join Prune
V2 Bootstrap
V2 Assert
V2 Graft
V2 Graft Ack
V2 Candidate RP
V1 Query
V1 Register
V1 Register Stop
V1 Join Prune
V1 RP Reachability
V1 Assert
V1 Graft
V1 Graft Ack
AutoRP Announce
AutoRP Mapping
AutoRP Unknown type
Received
432
0
0
0
104
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Sent
325
0
0
105
102
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Rx errors
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Global Statistics
. . .
Displaying PIM Message Types

The show pim statistics command returns packet counts for a variety of
PIM-related messages. To reset PIM statistics, use the clear pim
statistics command. The truncated sample on the slide illustrates the types of
information provided in the command output.
The show multicast statistics command provides a detailed break down
of multicast activity, including error counts on a per-interface basis. You can reset
the statistics with the clear multicast statistics command. Sample
multicast statistics output is provided here:
lab@Sydney-3> show multicast statistics
Instance: master Family: INET
Interface: local
Routing protocol:
Mismatch error:
Mismatch:
0
Mismatch no route:
Kernel resolve:
0
Routing notify:
Resolve no route:
0
Resolve error:
Resolve filtered:
0
Notify filtered:
In kbytes:
0
In packets:
Out kbytes:
0
Out packets:
. . .
Routing protocol:
PIM
Mismatch error:
Mismatch:
2
Mismatch no route:
Kernel resolve:
0
Routing notify:
Resolve no route:
0
Resolve error:
Resolve filtered:
0
Notify filtered:
In kbytes:
7623
In packets:
0
0
0
0
0
0
0
0
0
0
0
0
27486
305
Out kbytes:
. . .
306
Out packets:
Viewing Usage Statistics

Active groups
Number of sources and per-source statistics
lab@Sao_Paulo-3> show multicast usage detail

Group
Sources Packets
Bytes
224.8.8.8
1
6770
1922680
Source: 1.1.1.1
/32 Packets: 6770 Bytes: 1922680
224.7.7.7
1
6769
1922396
Source: 1.1.1.1
/32 Packets: 6769 Bytes: 1922396
Prefix
/len Groups Packets
Bytes
1.1.1.1
/32 1
6769
1922396
Group: 224.7.7.7
Packets: 6769 Bytes: 1922396
Details about active source
Figure 104: Viewing Usage Statistics

The show multicast usage command provides usage statistics on a
per-group and per-sender basis for the ten most active DVMRP or PIM groups.
On the slide, the only groups with packet activity are the Auto-RP-related groups,
and a single source has generated all packets to send to these groups. When
wanted, you can use the detail switch for additional information on multicast
usage.
To reset usage information, use the clear multicast usage command.
307
Displaying Multicast Routing Table

lab@Sao_Paulo-3> show multicast route
Family: INET
Group
Source prefix
Act Pru InIf
224.7.7.7
1.1.1.1
/32 A
F 68
224.8.8.8
1.1.1.1
/32 A
F 68
NHid
287
287
Session Name
Active groups and sources

Family: INET6
lab@Sao_Paulo-3> show multicast route extensive
Outgoing interface list
Family: INET
Group
Source prefix
Act Pru NHid Packets
IfMismatch Timeout
224.7.7.7
1.1.1.1
/32 A
F 287
7812
0
360
Forwarding state (pruned or forwarding)
Session name: Unknown
Forwarding rate: 1 kBps (2 pps)
224.8.8.8
1.1.1.1
/32 A
F 287
7813
0
360
Session name: Unknown
Forwarding rate: 1 kBps (2 pps)
Family: INET6
Forwarding rate for this route
Figure 105: Displaying Multicast Routing Table
Displaying Multicast Routes

The show multicast route command provides a way of examining the
multicast routing table. This table acts as a kind of cache and is based on
source/group activity and the results of RPF checks. To see RPF and current
usage statistics, include the extensive switch, as shown in the second example
on the slide.
When a session name is associated with a route, it is displayed. The session
name can be known a priori (well-known groups like cisco-auto-rp-announce) or
through the operation of the Service Announcement and Session Description
protocols (SAP/SDP). In this example, no session names are associated with the
two active groups.
The pruned (Pru) column is very important. This column displays whether a given
multicast route is currently pruned (P) or forwarding (F). In this example, the
Sydney router shows that both multicast routes are being forwarded. The NHid
column provides a numerical reference to the outgoing interface list for each
route. We examine this field on the following page.
You can obtain similar information by viewing the multicast routing table (inet.1)
directly using a show route table inet.1 command:
lab@Sao_Paulo-3> show route table inet.1
224.7.7.7,1.1.1.1/32*[PIM/105] 01:20:17
Multicast (IPv4)
224.8.8.8,1.1.1.1/32*[PIM/105] 01:20:17
Multicast (IPv4)
308
Displaying Multicast Routing Table
Displaying Outgoing Interface Lists

Reference to outgoing interface list for each
lab@Sao_Paulo-3> show multicast route
route
Family: INET
Group
Source prefix
Act Pru InIf NHid Session Name
224.7.7.7
1.1.1.1
/32 A
F 68
287
224.8.8.8
1.1.1.1
/32 A
F 68
287
Family: INET6
Use the show multicast next-hops command to

display the next-hop ID to outgoing interface list
mappings
lab@Sao_Paulo-3> show multicast next-hops
Family: INET
ID
Refcount KRefcount Downstream interface
287
4
2 fe-0/0/0.0
Family: INET6
Figure 106: Displaying Outgoing Interface Lists
Displaying Next-Hop ID to Outgoing Interface List Mappings

The next-hop ID (NHid) column displays a numerical reference to the list of
outgoing interface list (OIL) for each route. Use the show multicast
next-hops command to display the OIL. The command takes a specific NHid
value as an argument; a display of all mappings is returned when a specific
next-hop identifier value is not given. The KRefcount field indicates the number
of routes that are associated with the next-hop ID. In this example, both active
multicast routes are using the same outgoing interface.
The example shows that the Sao Paulo station has two active multicast routes
and that each is associated with the same next-hop identifier value of 287. The
output of the show multicast next-hops command shows that the 278 NHid
maps to an OIL consisting of a single interface in the form of fe-0/0/0. The
display makes sense, considering that Sao Paulo uses its fe-0/0/0 interface
when forwarding traffic towards the multicast receiver.
Put another way, from the perspective of the Sydney station, the 10.0.13/24
subnet is currently on the RPF path back to source 1.1.1.1. Sydney therefore
expects to receive traffic generated from source 1.1.1.1 over its fe-0/0/0
interface, which is in turn attached to Sao Paulos outgoing interface (fe-0/0/0)
for the routes in question. The RPF output for the 1.1.1.1 source, from the
perspective of the Sydney station, is provided for reference:
lab@Sydney-3> show multicast rpf 1.1.1.1
1.1.1.0/24
Protocol: OSPF
Neighbor: 10.0.13.2
Displaying Outgoing Interface Lists
309
Tunnel Services PIC is required in first-hop and RP

routers
One way to confirm Tunnel Services PIC is installed:
lab@Montreal-3> show chassis hardware | match "FPC | Tunnel"

FPC 0
FPC
PIC 1
REV 01
750-002982
HF2556
1x Tunnel
An alternative approach:
lab@Montreal-3> show interfaces terse | match "pd|pe"
pd-0/1/0
up
up
pd-0/1/0.32768
up
up
inet
pe-0/1/0
up
up
Tunnel Services PIC configuration is not needed for

PIM operation
Figure 107: Confirming Presence of Tunnel Services PIC
Verifying Tunnel Services PIC Presence

The use of PIM sparse mode requires that M-series and T-series platforms be
equipped with a Tunnel Services PIC when it has locally attached sources (the
first-hop router), or when it serves as the RP. Intervening routers or routers with
only multicast receivers do not require a Tunnel Services PIC.
The Tunnel Services PIC performs hardware-based encapsulation of register
messages sent to the RP when a source sends over the shared tree. On the RP,
the Tunnel Services PIC decapsulates the register messages so they can be
forwarded down the shared tree as native multicast.
The receivers switch over to a shortest-path tree (SPT) as soon as they begin
receiving packets from a new source over the shared tree, so the Tunnel Services
PIC is only involved in the processing of packets during the cut-over from RPT to
SPT.
The slide shows two commands that you can use to determine if an IP Tunnel
Services PIC is present. The first example uses the match function along with a
fancy logical OR to match on both the FPC and tunnel fields in the output of the
show chassis hardware command. In this example, the router has a Tunnel
Services PIC installed in FPC 0, PIC slot 1. The second command matches on the
presence of PIM decapsulation (pd) or PIM encapsulation (pe) interfaces, and
also displays their automatically configured logical units.
310
Note that all M-series T-series platforms create pimd and pime interfaces for use
by the local Routing Engine. The RE-based versions of these interfaces do not
function to support PIM register messages sent or received over PFE ports. This
is a key point, because the RE form of the pime and pimd interfaces are listed in
the output of show interfaces commands, even though the router might not
be equipped with a Tunnel Services PIC. This situation is shown here for the San
Jose station:
lab@San_Jose-3> show chassis hardware | match "FPC | Tunnel"
FPC 0
REV 01
710-001292
AN1843
FPC 1
REV 01
710-001292
AN7273
lab@San_Jose-3> show interfaces terse | match pim
pimd
up
up
pime
up
up
No Configuration Needed
When used with PIM, the Tunnel Services PIC requires no configuration. JUNOS
software automatically creates the pe (encapsulation) and pd (decapsulation)
interfaces as needed. The RP uses the pd interface, while first-hop routers use
the pe interface. It is possible for the first-hop router to also be the RP. In this
situation, a Tunnel Services PIC is not needed, as encapsulated registers
messages are not generated.
311
Module Review
Which version of IGMP is the JUNOS software default?
How would you configure an M-series or T-series platform with a static RP?
What command can you use to display the RPs a router knows about?
What command tells you the number of packets sent to a specific multicast
group?
When is a Tunnel Services PIC required to support multicast?
312
Module Review
JUNOS software multicast support;
Configuring IGMP using JUNOS software;
Configuring PIM using JUNOS software;
Implementing PIM RP discovery mechanisms; and
Commands used for multicast monitoring and troubleshooting.
Labs 6 and 7: IP Multicast

Lab Objectives:
Configure and verify IPv4 multicast using PIM dense mode and optionally PIM
sparse mode using bootstrap and (optionally) Auto-RP.
313
314
Index
C
Configuration Example
Auto-RP .......................................................................... 290
Bootstrap ......................................................................... 292
Static RP ......................................................................... 289
Configuring IGMP ............................................................... 283
Configuring Multicast.......................................................... 282
Confirming Presence of Tunnel Services PIC ................. 310
PIM Configuration
RP Properties ..................................................................287
Viewing Extended RP Information ...................................300

Viewing Usage Statistics .....................................................307
Determining RP Status ........................................................ 299

Displaying IGMP Group Information ............................... 296
Displaying Multicast Routing Table ................................. 308
Displaying Outgoing Interface Lists ................................. 309
Displaying PIM Interfaces ..................................................301
Displaying PIM Join State ..................................................303
Displaying PIM Neighbors ................................................. 302
Displaying PIM Statistics.................................................... 305
Displaying the Bootstrap Router........................................ 298
Examining Source RPF State ............................................. 304
General PIM Configuration

RP Properties.................................................................. 287
Lab Objectives
Lab 1 - MPLS Setup Lab ............................................... 48
Lab 2 - RSVP Signaling ............................................... 125
Lab 3 - Routing Table Integration .............................. 150
Lab 4 - Routing Constraints......................................... 169
Lab 5 - JUNOS Software Firewall Filters ................. 217
Labs 6 and 7 - IP Multicast .......................................... 313
Module Objectives ............................................................... 280

Monitoring Multicast Operation ........................................ 294
Multicast Support .................................................................281
Obtaining IGMP Interface Information ............................ 295
315
316

Configuring Juniper Networks Routers Student Guide, Volume 2

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Configuring Juniper Networks Routers Student Guide, Volume 2

Încărcat de

Drepturi de autor:

Formate disponibile

Product Family

Second Line of Product Family

Configuring Juniper Networks Routers

Juniper Networks, Inc.

Course Overview ........................................................................................................22

Module 1: Traffic Engineering Overview

Configuring Juniper Networks Routers - Stujdent Guide V2

Module 2: Multiprotocol Label Switching Fundamentals

The MPLS Header (Label) Structure ..................................................................64

Module 3: RSVP-Signaled LSPs

Configuring Juniper Networks Routers - Stujdent Guide V2

Now Positioned as a Router Signaling Protocol .................................................94

Module 4: LSPs and Routing Table Integration

Module 5: Named Paths and Routing Constraints

Configuring Juniper Networks Routers - Stujdent Guide V2

Explicit Route Objects: A Definition .......................................................................154

Module 6: Firewall Filters

Numeric Range Filter Match Condition ...................................................................181

Configuring Juniper Networks Routers - Stujdent Guide V2

Module 7: Multicast Theory

IGMPv2 Join Process ...............................................................................................234

Configuring Juniper Networks Routers - Stujdent Guide V2

Shared-Tree Join State.......................................................................................261

Module 8: Multicast Configuration and Monitoring

Monitoring Multicast Operation ...............................................................................294

Configuring Juniper Networks Routers - Stujdent Guide V2

Keywords Used with Numeric Match Conditions..................................181

Configuring Juniper Networks Routers - Stujdent Guide V2

IGP Metric-Based Forwarding .................................................................35

Configuring Juniper Networks Routers - Stujdent Guide V2

ERO Case Study .....................................................................................163

Figure 99: Viewing Extended RP Information ........................................................300

Configuring Juniper Networks Routers - Stujdent Guide V2

Course Overview on page 22

Intended Audience on page 23

Course Level on page 23

Course Agenda on page 23

Document Conventions on page 26

Additional Information on page 27

Configuring Juniper Networks Routers - Stujdent Guide V2

Module 2: MPLS Fundamentals

Configuring Juniper Networks Routers - Stujdent Guide V2

Module 3: RSVP-Signaled LSPs

Module 4: LSP and Routing Table Integration

Module 5: Named Paths and Routing Constraints

Module 7: Multicast Theory

Module 8:Multicast Configuration and Monitoring

Configuring Juniper Networks Routers - Stujdent Guide V2

Lab instructions and

If told to do so by your instructor, enter the

Operational displays and

Courier New italic

A syntax variable that the

Courier New bold

The user can display interface status with

Courier New italic

Predefined syntax variYou will now apply the ospf-test-polables such

Courier New italic

You will now apply your

About This Publication

Juniper Networks Support

Configuring Juniper Networks Routers - Stujdent Guide V2

Chapter 1: Module 1: Traffic Engineering Overview