Professional Documents
Culture Documents
Configuring Juniper Networks Routers Student Guide, Volume 2
Configuring Juniper Networks Routers Student Guide, Volume 2
Release 6.a
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
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
:
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
49
Module Objectives......................................................................................................50
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
73
Module Objectives......................................................................................................74
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
:
Tracing RSVP...........................................................................................................123
RSVP Tracing....................................................................................................123
Review Questions .....................................................................................................124
This Module Discussed: ....................................................................................124
Lab 2: RSVP Signaling.............................................................................................125
Chapter 4
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
Review Questions .....................................................................................................149
This Module Discussed: ....................................................................................149
Lab 3: Routing Table Integration .............................................................................150
Chapter 5
151
Module Objectives....................................................................................................152
This Module Discusses:.....................................................................................152
Explicit Route Objects..............................................................................................153
171
Module Objectives....................................................................................................172
This Module Discusses:.....................................................................................172
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
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
Review Questions .....................................................................................................216
This Module Discussed: ....................................................................................216
Lab 5: JUNOS Software Firewall Filters .................................................................217
Chapter 7
219
Module Objectives....................................................................................................220
This Module Discusses:.....................................................................................220
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
11
279
Module Objectives....................................................................................................280
This Module Discusses:.....................................................................................280
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
13
14
List of Tables
Table 1:
Table 2:
Table 3:
Table 4:
Table 5:
Table 6:
: 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:
: 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
: List of Figures
: List of Figures
19
20
: List of Figures
: Preface
Preface
Objectives on page 22
Prerequisites on page 23
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
Module 1: Traffic Engineering Overview
The Concept of MPLS
The Need for Traffic Engineering
Overlay Networks and Their Drawbacks
Traffic Engineering: A Definition
23
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
24
Course Agenda
: Preface
Course Agenda
25
Document Conventions
The following table lists the syntax-related style conventions used throughout this
document:
Style
Description
Usage Example
Arial
Courier New
commit complete
Exiting configuration mode
Command syntax is
displayed in bold to
differentiate commands
from descriptive text.
erx1:isp-1#configure terminal
Or
26
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/.
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.
Additional Information
27
28
Additional Information
Chapter 1
29
Module Objectives
30
Module Objectives
Router evolution
31
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
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.
RFC Support
JUNOS software supports the following list of RFCs and Internet drafts related to
MPLS:
32
33
Early Internet
Early 1990s
34
Early Internet
A
1
35
A
1
36
Lacks control
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.
37
Mid-1990s
38
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
Per-circuit statistics
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:
Physical
View
Logical
View
A
B
A
C
B
Overlay Networks
41
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 tuned so that they minimally impact existing PVCs;
The configuration of each switch and router in the core must be modified.
42
OC-48 SAR
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
Deterministic performance
Software advances
Solution
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
46
Review Questions
Review Questions
47
48
Chapter 2
49
Module Objectives
Describe MPLS flow and packet processing from ingress to egress router
50
Module Objectives
Review of MPLS, the benefits of MPLS, and how MPLS is used for Internet
traffic engineering;
Label operations;
Label stacking.
MPLS Fundamentals
MPLS terminology
MPLS labels
Label stacking
MPLS Fundamentals
51
Benefits of MPLS
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.
52
Benefits of MPLS
192.168.1/24
134.112/16
New York
San
Francisco
53
Engineer unidirectional paths through your network without using the IGPs
shortest path calculation
San
Francisco
54
192.168.1/24
New York
San
Francisco
134.112/16
55
MPLS Terminology
New York
San
Francisco
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
LSP setup
New York
San
Francisco
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
Ingress router
New York
Ingress
San
Francisco
58
Transit router
New York
San
Francisco
Transit
LSRs
59
Penultimate router
Second-to-last router
New York
San
Francisco
Penultimate
60
Egress router
Egress
New York
San
Francisco
61
MPLS Labels
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.
62
MPLS Labels
Labeled Packets
L2
L2 Header
Header
MPLS Header
IP
IP Packet
Packet
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.
Labeled Packets
63
L2
L2 Header
Header
MPLS Header
CoS S
TTL
IP
IP Packet
Packet
32 bits
Stacking bit
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.
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.
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.
65
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
66
Transit LSR performs a label swap operation replacing label 1965 with
1026
134.112/16
New York
San
Francisco
1026
1965
IP
1026
IP
Santa Fe
Miami
1026
67
134.112/16
New York
IP
San
Francisco
1026
Label Stack
Popped (PHP)
IP
Santa Fe
Miami
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);
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)
70
Label Stacking
Review Questions
Ingress?
Transit?
Penultimate hop?
Egress?
What is the benefit of stacked labels, and how might they be used?
MPLS packet flow and processing from ingress to egress router; and
Label stacking.
Review Questions
71
72
Review Questions
Chapter 3
73
Module Objectives
74
Module Objectives
RSVP signaling;
RSVP signaling
75
Pros:
Cons:
No protection
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
Ingress node: Manually define the destination, label to push, and next hop
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.
78
Next hop must point to directly connected neighbor at remote end of each
link
134.112/16
New York
San
Francisco
202
10.0.5.4
303
10.0.1.2
10.0.3.39
79
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
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/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
82
83
Static LSPs:
Are nailed up
Installed in the inet.0 table where they are available for all traffic
Signaled LSPs:
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
Path through network chosen at each hop using routing table, by default
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
Extended to support:
Path numbering
Route recording
Visibility
Redundancy
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;
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?).
88
RSVP Signaling
Background
Extended RSVP
RSVP Signaling
89
RSVP Background
RSVP:
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
Simplex flows
Soft state
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
LSP established after path and resv messages are exchanged between
ingress and egress nodes
91
92
PathTear
ResvTear
ResvErr
PathErr
ResvConf
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.
93
Extended RSVP
Hello protocol
Label distribution
94
Extended RSVP
Label object
Tspec object
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 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.
95
ERO:
Without EROs, the LSP is routed according to the IGPs shortest path
96
Label Objects
Label object
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
In downstream direction
Loop detected
In upstream direction
Loop detected
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
Controls LSP
Priority
Preemption
Fast reroute
Identifies session
100
Tspec Object
Requested bandwidth
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
Adjacency maintenance
102
Hello extension
Path maintenance
Message aggregation
Adjacency Maintenance
Hello message
Asynchronous updates
Adjacency Maintenance
103
Path Maintenance
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
Message aggregation:
Controls
105
Seattle
San
Francisco
(Ingress)
Path
New York
(Egress)
Path
Path
Miami
106
The resv message visits each router on the path in reverse order
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
107
108
Configuring RSVP
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
109
Configuring RSVP
To configure RSVP:
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
Configuration example:
[edit protocols rsvp]
user@host# set interface fe-0/0/0 authentication-key test
[edit protocols rsvp]
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 ( ).
111
Configure a signaled LSP from San Francisco to Miami that follows the IGPs
shortest path
112
LSP setup fails if any router/link cannot reserve the requested bandwidth
113
114
Clearing LSPs
RSVP tracing
115
Hello
Ack
. . .
116
0
0
0
0
0
0
0
0
117
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
118
bandwidth information
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
121
Clearing LSPs
Two options:
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
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?
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
125
126
Chapter 4
127
Module Objectives
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
traffic engineering;
129
Routes associated with signaled LSPs are installed in the inet.3 routing
table
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
130
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
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.
131
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
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
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
The Problem
133
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
BGP
next hop
Preference: 170/-101
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 ?
Protocol next hop: 192.168.24.1
Localpref: 100
Router ID: 192.168.24.1
134
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;
}
. . .
135
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
136
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
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
138
RSVP/LDP:
OSPF
IS-IS
IP
Routing Table
(inet.0)
BGP
RSVP
LDP
MPLS
Routing Table
(inet.3)
IP Forwarding Table
Figure 36: Ingress Router Behavior
139
140
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
141
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
142
143
inet.0
inet.3
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
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
Preference: 170/-101
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 ?
Protocol next hop: 10.0.29.1
Localpref: 100
Router ID: 192.168.24.1
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
inet.0: 30 destinations, 31 routes (30 active, 0 holddown, 0 hidden)
192.168.24.1/32
A Thought-Provoking Question
147
The Answer
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
Why can the use of a passive IGP affect whether traffic is mapped to an LSP?
A review of MPLS, the benefits of MPLS, and how MPLS is used for Internet
traffic engineering;
Review Questions
149
150
Chapter 5
151
Module Objectives
Describe how you can use EROs to influence the path of an LSP
Describe how JUNOS software uses named paths to contain one or more
EROs
152
Module Objectives
ERO examples
153
Allow the ingress node to control the routing of the LSP independently of
the IGPs preferred path
Path message must visit all ERO hops specified, in the sequence that they
are listed
Resv message is routed back along the same path to establish the LSP
Loose
Strict
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
ERO
Egress
LSR
B strict
C strict
E strict
D strict
F strict
Strict
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
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
ERO
Strict
Egress
LSR
C strict
D loose
F strict
A
Ingress
LSR
Loose
158
Beware...
The IGP routes the LSP according to its view of the least-cost path in the
absence of ERO
Insufficient ERO can cause the IGP to route LSP back onto itself
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.
159
mpls {
label-switched-path to-miami {
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
160
If first subobject does not match local node, then generate error
161
162
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
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.
163
The CLIs rename and insert commands allow easy modification of named
paths
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
166
167
Review Questions
What is the difference between strict and loose ERO route constraints?
Why can specifying less than a complete list of ERO hops lead to LSP
establishment problems?
168
Review Questions
169
170
Chapter 6
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
172
Module Objectives
Firewall Filters
Match conditions
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.
The actions that can be taken on packets that match a JUNOS packet filter,
such as discard, reject, and logging, counting, and sampling.
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
Address field
Protocol type
Port type
Bit fields
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.
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
Implicit discard all for packets that do not match any term
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.
175
176
Old style syntax is officially supported in Release 5.7 but might be depreciated
at a later time
177
Single-term filters
If the packet matches all the conditions, the action in the then statement
is taken
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
The from statement specifies the conditions the packet must match for
the action to be taken
Numeric-range filter
Address filter
Bit-field filter
179
180
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
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
dscp number
fragmentation-offset
number
Fragmentation field
icmp-code number
icmp-type number
interface-group
group-number
packet-length bytes
port number
TCP or UDP
precedence ipprecedence-field
protocol number
source-port number
Keywords available
destination-address prefix
source-address prefix
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.
183
You can specify bit fields with symbolic names or numeric values
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
()
& or +
| or ,
185
Strict-source-route
record-route
router-alert (148)
Timestamp
(7)
( 137)
(68)
TCP Flags
ack (0x10)
rst (0x04)
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
186
Match Condition
Description
ip-options number
tcp-flags number
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
is-fragment
tcp-established
tcp-intial
187
Overview
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
Action Statements
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
discard
The packet is not accepted and is not processed further (silent discard).
reject
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
count
log
output-queue
losspriority
Set the packet loss priority (PLP) bit to the specified value.
sample
administratively-prohibited (default)
bad-host-tos, bad-network-tos
port-unreachable
precedence-cutoff, precedence-violation
protocol-unreachable
source-host-isolated, source-route-failed
tcp-reset
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.
191
Action Modifiers
counter-name
Logging
Sampling
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
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.
194
Remember to
accommodate your
routing and remote access
protocols!
FPC z
n
Routing
Engine
lo0
FPC
0
0
1
2
3
Input
IP II
Output
Packet
Forwarding
Engine
0
1
2
3
Apply filters to PFE ports for transit filtering, sampling, and cflowd export
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.
(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.
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 2: Output
From SA = 192.168.0
Then Reject
From SA = other
Then Accept
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).
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
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.
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
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!
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
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.
203
M40
Power
User
.100
.10
10.0.0/24
.2
.1
Screening
Router
Hub
.1
192.168.0/24
.50
Restricted
User
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
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)
Be discarded
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.)
[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
burst-size-limit
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;
}
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;
}
}
}
}
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
policer only
Policer name
Packets
0
0
Direction of policer
210
List of commands:
show policer
211
Bytes
0
Packets
1
212
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
No clear command
213
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
214
215
Review Questions
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?
216
Review Questions
217
218
Chapter 7
219
Module Objectives
220
Module Objectives
Multicast addressing;
IP Multicast Agenda
Multicast theory
Traffic flow
IP multicast components
Group membership
Multicast routing
Reverse-path forwarding
Multicast trees
SAP
IP Multicast Agenda
221
Traffic Flow
Without multicast, multiple streams are needed
Network
Clients
Server
Network
Server
Clients
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
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
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
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
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
225
Multicast Components
Host protocols
IGMP
DVMRP
PIM
Other mechanisms
MSDP
SDP/SAP
Multicast scoping
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
Multicast Components
Multicast Components
227
Usage of IGMP
IGMP versions
228
IGMP
Router queries
Host messages
Report messages
Leave-group messages
Configurable to v1 and v3
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
229
230
IGMP Versions
Version 1
Version 2
Defines procedure for electing the multicast querier for each LAN
Version 3
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
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
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
234
Host 1 hears the response from Host 2 and suppresses its report
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
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
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
237
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
238
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.
239
Multicast Routing
Multicast Routing
The slide lists the topics we discuss on the following pages.
240
Multicast Routing
Distribution trees
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).
241
Reverse-Path Forwarding
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
Reverse-Path Forwarding
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
Reverse-Path Forwarding
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
Multicast Traffic
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
Multicast Traffic
244
Considerable overhead
Examples
DVMRP
PIM-DM
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.
245
Receiver
Multicast Traffic
Receiver
246
Source
172.16.20.1
Receiver
Prune Messages
Multicast Traffic
Receiver
247
Receiver
Multicast Traffic
Receiver
248
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
A Shortest-Path Tree
249
PIM-SM trees
Design considerations
Placement/reliability of RP router
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!
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
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.
251
Source
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
252
Source
RP
Join
(S, G)
Receivers DR is
responsible for
forwarding packets on
this LAN
E
Data
Receiver
Control
253
RP
A
B
F
Prune
(S, G)
C
E
Data
Receiver
Control
254
Source
A
D
E
Data
Receiver
Control
255
Source
RP
D
Register encapsulated is stripped by RP; native
multicast sent down the shared tree
E
Register Encapsulation
Receiver
Native Multicast
256
The Result...
Source
RP
SPTs
D
F
RPT
Receiver
The Result...
257
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
258
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
260
Source: *
RP: 192.168.2.1
Flags: sparse,rptree,wildcard
Source: 1.1.1.1
RP: 192.168.2.1
Flags: sparse,rptree
Upstream interface: so-2/0/0.0
Upstream State: Join to RP
Keepalive timeout:
Downstream Neighbors:
Interface: ge-2/2/0.0 (pruned)
10.0.16.1 State: Prune Flags: SR Timeout: 197
261
262
Timeout: Infinity
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
263
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
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
264
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 interface: fe-0/0/0.0
Upstream State: Join to RP, Join to Source
Keepalive timeout: 159
Downstream Neighbors:
On the source tree
Interface: fe-0/0/3.0
10.200.200.1 State: Join Flags: S
Timeout: Infinity
265
Group: 224.7.7.7
Source: 1.1.1.1
On a source tree
Flags: sparse
Upstream interface: fe-0/0/1.0
Upstream State: Join to Source
On a source tree
Interface: fe-0/0/0.0
10.0.13.1 State: Join Flags: S Timeout: 201
266
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
267
Determining the RP
Auto-RP
Bootstrap router
268
Determining the RP
Static RP configuration
Dynamic RP mechanisms
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
PIM version 1 or 2
Nonstandard
224.0.1.39 (announce)
224.0.1.40 (discovery)
Mapping agents
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.
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)
Priority
Hashing mechanism
Highest IP address
272
Bootstrap Router (1 of 2)
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.
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.
Bootstrap Router (2 of 2)
PIMv2 only
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
Bootstrap Router (2 of 2)
273
274
Bootstrap Router (2 of 2)
275
H.320, etc.)
276
The details needed to participate in a multicast session are listed when the
session is selected
The SDR client displays the session details as communicated through SDP
277
Module Review
What are the differences between the bootstrap router and Auto-RP election
mechanisms?
278
Module Review
Multicast addressing;
Chapter 8
Module Review
279
Module Objectives
280
Module Objectives
Multicast Support
DVMRP
SAP
MSDP
MBGP
Scoping
Prefix limits
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.
Multicast Support
281
Configuring Multicast
282
Configuring Multicast
IGMP 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;
}
}
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
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
. . .
rp {
Static RP election:
Non-RP routers are configured with the address of the RP router using
the static keyword.
Dynamic RP election:
287
288
Amsterdam
(Non-RP)
Type
static
289
Amsterdam
(Non-RP/Discovery)
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
Amsterdam
(Non-RP)
292
293
show igmp
interface
group
statistics
show pim
bootstrap
rps
interfaces
neighbor
join
statistics
show multicast
rpf
route
usage
next-hops
294
IGMP: You can display members of IGMP groups by interface, show just the
groups themselves, or display IGMP statistics.
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
295
10.0.13.2
10.0.13.2
10.0.13.2
10.0.13.2
10.200.200.2
10.200.200.2
296
Rx errors
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
22
49
297
Pri State
Timeout
0 InEligible
0
Pri State
110 Candidate
Timeout
55
Pri State
Timeout
0 InEligible
74
298
Determining RP Status
z
Two perspectives:
On the local RP, both static and Auto-RP are listed
Type
Holdtime Timeout Active groups Group prefixes
bootstrap
150
150
2 224.0.0.0/4
static
0
None
2 224.0.0.0/4
Family: INET6
Type
Holdtime Timeout Active groups Group prefixes
bootstrap
150
150
2 224.0.0.0/4
Family: INET6
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
Instance: PIM.master
Family: INET
RP: 192.168.2.1
Learned from 10.0.15.2 via:
Time Active: 00:50:05
Holdtime: 150 with 145 remaining
Group Ranges:
224.0.0.0/4
Active groups using RP:
224.8.8.8
224.7.7.7
total 2 groups active
Family: INET6
Determining RP Status
299
FirstHop
192.168.28.1
192.168.28.1
RP: 192.168.2.1
Learned via: static configuration
Time Active: 08:36:27
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
300
RP Address
State
192.168.2.1
Suppress
192.168.2.1
Suppress
Stat
Up
Up
Up
Up
Mode
Sparse
Sparse
Sparse
Sparse
IP
4
4
4
4
V
2
2
2
2
Neighbor count
301
Neighbors timers
and supported PIM
options
PIM joins received
from this neighbor
302
Group: 224.7.7.7
Source: *
RP: 192.168.2.1
Indicates sparse mode, RP tree, (*, G)
Flags: sparse,rptree,wildcard
Upstream interface: fe-0/0/1.0
RPF interface leading to RP
Upstream State: Join to RP
Downstream Neighbors:
Outgoing interface list for this group
Interface: fe-0/0/3.0
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 interface: fe-0/0/0.0
Upstream State: Join to RP, Join to Source
Join to source, (S, G)
Keepalive timeout: 182
prune to RP
Downstream Neighbors:
Outgoing interface list for this group
Interface: fe-0/0/3.0
10.200.200.1 State: Join Flags: S
Timeout: Infinity
. . .
303
Multicast source
Rendezvous point
304
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
. . .
0
0
0
0
0
0
0
0
0
0
0
0
27486
305
Out kbytes:
. . .
306
Out packets:
Prefix
/len Groups Packets
Bytes
1.1.1.1
/32 1
6769
1922396
Group: 224.7.7.7
Packets: 6769 Bytes: 1922396
307
NHid
287
287
Session Name
308
309
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
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
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?
312
Module Review
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
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
315
316