AJER_11.a-R_SG

Advanced Junos Enterprise Routing 11.a

Student Guide

Worldwide Education Services 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA 408-745-2000 www.juniper.net Course Number: EDU-JUN-AJER

This document is produced by Juniper Networks, Inc. This document or any part thereof may not be reproduced or transmitted in any form under penalty of law, without the prior written permission of Juniper Networks Education Services. Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. Advanced Junos Enterprise Routing Student Guide, Revision 11.a Copyright © 2012 Juniper Networks, Inc. All rights reserved. Printed in USA. Revision History: Revision 10.a—March 2011. Revision 11.a—April 2012. The information in this document is current as of the date listed above. The information in this document has been carefully verified and is believed to be accurate for software Release 11.4R1.6. Juniper Networks assumes no responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary, incidental, or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.

Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. YEAR 2000 NOTICE Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036. SOFTWARE LICENSE The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should consult the software license for further details.

Contents Chapter 1: Course Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1 Chapter 2: OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1 OSPFv2 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 Link-State Advertisements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-14 Protocol Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-41 OSPF Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-62 OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-68 Lab 1: Configuring and Monitoring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-80

Chapter 3: OSPF Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1 Review of OSPF Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3 Stub Area Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8 Stub Area Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-14 NSSA Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-17 NSSA Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-23 Route Summarization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-27 Lab 2: Configuring and Monitoring OSPF Area and Route Summarization . . . . . . . . . . . . . . .3-34

Chapter 4: OSPF Case Studies and Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1 IGP Transition Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3 Transition Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-12 OSPF Multiarea Adjacencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-20 External Reachability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-29 Virtual Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-44 Lab 3: Configuring and Monitoring Routing Policy and Advanced OSPF Policy . . . . . . . . . . . .4-62

Chapter 5: BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1 Review of BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3 BGP Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-22 Load Balancing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-30 Path Selection and Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-41 Lab 4: Implementing BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-61

Chapter 6: BGP Attributes and Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1 Policy and BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3 BGP Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-10 Details and Manipulation of Common BGP Path Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . .6-14 Lab 5: BGP Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-48

Chapter 7: Enterprise Routing Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1 Enterprise BGP Core Network Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3 Enterprise External Network Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-27 Lab 6: Implementing Enterprise Routing Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-53

www.juniper.net

Contents • iii

Chapter 8: Introduction to Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1 Overview of Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3 Multicast Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-10 RPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-15 IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-28

Chapter 9: Multicast Routing Protocols and SSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1 Overview of Multicast Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3 PIM-SM Using the ASM Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8 Lab 7: Implementing PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-44 PIM-SM Using the SSM Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-45 Lab 8: Implementing SSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-55

Chapter 10: Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1 CoS Components Review and Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3 CoS Processing and CoS Defaults on the SRX Series Device . . . . . . . . . . . . . . . . . . . . . . . .10-15 Policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-30 Virtual Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-38 Monitoring with Resource Performance Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-44 Lab 9: Implementing CoS Features in the Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-53

Appendix A: BGP Route Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1 Route Reflection Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3 Configuration and Routing Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9 Lab 10: BGP Route Reflection (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-21

Appendix B: Acronym List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1 Appendix C: Answer Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1

iv • Contents

www.juniper.net

Course Overview This three-day course is designed to provide students with the tools required for implementing, monitoring, and troubleshooting Layer 3 components in an enterprise network. Detailed coverage of OSPF, BGP, class of service (CoS), and multicast is strongly emphasized. Through demonstrations and hands-on labs, students will gain experience in configuring and monitoring the Junos operating system and in monitoring device and protocol operations.

Objectives After successfully completing this course, you should be able to:

www.juniper.net

•

Describe the various OSPF link-state advertisement (LSA) types.

•

Explain the flooding of LSAs in an OSPF network.

•

Describe the shortest-path-first (SPF) algorithm.

•

Describe OSPF area types and operations.

•

Configure various OSPF area types.

•

Summarize and restrict routes.

•

Identify scenarios that require routing policy or specific configuration options.

•

Use routing policy and specific configuration options to implement solutions for various scenarios.

•

Describe basic BGP operation and common BGP attributes.

•

Explain the route selection process for BGP.

•

Describe how to alter the route selection process.

•

Configure some advanced options for BGP peers.

•

Describe various BGP attributes in detail and explain the operation of those attributes.

•

Manipulate BGP attributes using routing policy.

•

Describe common routing policies used in the enterprise environment.

•

Explain how attribute modifications affect routing decisions.

•

Implement a routing policy for inbound and outbound traffic using BGP.

•

Identify environments that may require a modified CoS implementation.

•

Describe the various CoS components and their respective functions.

•

Explain the CoS processing along with CoS defaults on SRX Series Services Gateways.

•

Describe situations when some CoS features are used in the enterprise.

•

Implement some CoS features in an enterprise environment.

•

Describe IP multicast traffic flow.

•

Identify the components of IP multicast.

•

Explain how IP multicast addressing works.

•

Describe the need for reverse path forwarding (RPF) in multicast.

•

Explain the role of Internet Group Management Protocol (IGMP) and describe the available IGMP versions.

•

Configure and monitor IGMP.

•

Identify common multicast routing protocols.

•

Describe rendezvous point (RP) discovery options.

•

Configure and monitor Physical Interface Module (PIM) sparse modes. Course Overview • v

•

Configure and monitor RP discovery mechanisms.

•

Describe the basic requirements, benefits, and caveats of source-specific multicast (SSM).

•

List the address ranges used for SSM.

•

Illustrate the role of Internet Group Management Protocol version 3 (IGMPv3) and PIM sparse mode (PIM-SM) in an SSM implementation.

•

Configure and monitor SSM.

Intended Audience This course benefits individuals responsible for configuring and monitoring devices running the Junos OS.

Course Level Advanced Junos Enterprise Routing is an advanced-level course.

Prerequisites Students should have basic networking knowledge and an understanding of the Open Systems Interconnection (OSI) model and the TCP/IP protocol suite. Students should also have working experience with basic routing principles. Students should also attend the Introduction to the Junos Operating System (IJOS), Junos Routing Essentials (JRE), and Junos Intermediate Routing (JIR) courses prior to attending this class.

vi • Course Overview

www.juniper.net

Course Agenda Day 1 Chapter 1: Course Introduction Chapter 2: OSPF Lab 1: Configuring and Monitoring OSPF Chapter 3: OSPF Areas Lab 2: Configuring and Monitoring OSPF Areas and Route Summarization Chapter 4: OSPF Case Studies and Solutions Lab 3: Configuring and Monitoring Routing Policy and Advanced OSPF Options

Day 2 Chapter 5: BGP Lab 4: Implementing BGP Chapter 6: BGP Attributes and Policy Lab 5: BGP Attributes Chapter 7:

Enterprise Routing Policies Lab 6: Implementing Enterprise Routing Policies

Day 3 Chapter 8: Introduction to Multicast Chapter 9: Multicast Routing Protocols and SSM Lab 7: Implementing PIM-SM Lab 8: Implementing SSM Chapter 10: Class of Service Lab 9: Implementing CoS Features in the Enterprise Appendix A: BGP Route Reflection Lab 10: BGP Route Reflection (Optional)

www.juniper.net

Course Agenda • vii

Document Conventions CLI and GUI Text Frequently throughout this course, we refer to text that appears in a command-line interface (CLI) or a graphical user interface (GUI). To make the language of these documents easier to read, we distinguish GUI and CLI text from chapter text according to the following table. Style

Description

Usage Example

Franklin Gothic

Normal text.

Most of what you read in the Lab Guide and Student Guide.

Courier New

Console text: •

Screen captures

commit complete

•

Noncommand-related syntax

Exiting configuration mode

GUI text elements: • Menu names • Text field entry

Select File > Open, and then click Configuration.conf in the Filename text box.

Input Text Versus Output Text You will also frequently see cases where you must enter input text yourself. Often these instances will be shown in the context of where you must enter them. We use bold style to distinguish text that is input versus text that is simply displayed. Style

Description

Usage Example

Normal CLI

No distinguishing variant.

Physical interface:fxp0, Enabled

Normal GUI

View configuration history by clicking Configuration > History. CLI Input

Text that you must enter.

lab@San_Jose> show route Select File > Save, and type config.ini in the Filename field.

GUI Input

Defined and Undefined Syntax Variables Finally, this course distinguishes between regular text and syntax variables, and it also distinguishes between syntax variables where the value is already assigned (defined variables) and syntax variables where you must assign the value (undefined variables). Note that these styles can be combined with the input style as well. Style

Description

Usage Example

CLI Variable

Text where variable value is already assigned.

policy my-peers

Text where the variable’s value is the user’s discretion or text where the variable’s value as shown in the lab guide might differ from the value the user must input according to the lab topology.

Type set policy policy-name.

GUI Variable CLI Undefined

GUI Undefined

viii • Document Conventions

Click my-peers in the dialog.

ping 10.0.x.y Select File > Save, and type filename in the Filename field.

www.juniper.net

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/education/.

About This Publication The Advanced Junos Enterprise Routing Student Guide was developed and tested using software Release 11.4R1.6. Previous and later versions of software might behave differently so you should always consult the documentation and release notes for the version of code you are running before reporting errors. This document is written and maintained by the Juniper Networks Education Services development team. Please send questions and suggestions for improvement to [email protected].

Technical Publications You can print technical manuals and release notes directly from the Internet in a variety of formats: •

Go to http://www.juniper.net/techpubs/.

•

Locate the specific software or hardware release and title you need, and choose the format in which you want to view or print the document.

Documentation sets and CDs are available through your local Juniper Networks sales office or account representative.

Juniper Networks Support For technical support, contact Juniper Networks at http://www.juniper.net/customers/support/, or at 1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the United States).

www.juniper.net

Additional Information • ix

x • Additional Information

www.juniper.net

Advanced Junos Enterprise Routing Chapter 1: Course Introduction

Advanced Junos Enterprise Routing

This Chapter Discusses: •

Objectives and course content information;

•

Additional Juniper Networks, Inc. courses; and

•

The Juniper Networks Certification Program.

Chapter 1–2 • Course Introduction

www.juniper.net


Introductions The slide asks several questions for you to answer during class introductions.

www.juniper.net

Course Introduction • Chapter 1–3


Course Contents The slide lists the topics we discuss in this course.


www.juniper.net


Prerequisites The slide lists the prerequisites for this course.

www.juniper.net



General Course Administration The slide documents general aspects of classroom administration.


www.juniper.net


Training and Study Materials The slide describes Education Services materials that are available for reference both in the classroom and online.

www.juniper.net



Additional Resources The slide provides links to additional resources available to assist you in the installation, configuration, and operation of Juniper Networks products.


www.juniper.net


Satisfaction Feedback Juniper Networks uses an electronic survey system to collect and analyze your comments and feedback. Depending on the class you are taking, please complete the survey at the end of the class, or be sure to look for an e-mail about two weeks from class completion that directs you to complete an online survey form. (Be sure to provide us with your current e-mail address.) Submitting your feedback entitles you to a certificate of class completion. We thank you in advance for taking the time to help us improve our educational offerings.

www.juniper.net



Juniper Networks Education Services Curriculum Juniper Networks Education Services can help ensure that you have the knowledge and skills to deploy and maintain cost-effective, high-performance networks for both enterprise and service provider environments. We have expert training staff with deep technical and industry knowledge, providing you with instructor-led hands-on courses in the classroom and online, as well as convenient, self-paced eLearning courses.

Courses You can access the latest Education Services offerings covering a wide range of platforms at http://www.juniper.net/training/technical_education/.


www.juniper.net


Juniper Networks Certification Program A Juniper Networks certification is the benchmark of skills and competence on Juniper Networks technologies.

www.juniper.net



Juniper Networks Certification Program Overview The Juniper Networks Certification Program (JNCP) consists of platform-specific, multitiered tracks that enable participants to demonstrate competence with Juniper Networks technology through a combination of written proficiency exams and hands-on configuration and troubleshooting exams. Successful candidates demonstrate a thorough understanding of Internet and security technologies and Juniper Networks platform configuration and troubleshooting skills. The JNCP offers the following features: •

Multiple tracks;

•

Multiple certification levels;

•

Written proficiency exams; and

•

Hands-on configuration and troubleshooting exams.

Each JNCP track has one to four certification levels—Associate-level, Specialist-level, Professional-level, and Expert-level. The Associate-level, Specialist-level, and Professional-level exams are computer-based exams composed of multiple choice questions administered at Prometric testing centers worldwide. Expert-level exams are composed of hands-on lab exercises administered at select Juniper Networks testing centers. Please visit the JNCP website at http://www.juniper.net/certification for detailed exam information, exam pricing, and exam registration.


www.juniper.net


Preparing and Studying The slide lists some options for those interested in preparing for Juniper Networks certification.

www.juniper.net



Find Us Online The slide lists some online resources to learn and share information about Juniper Networks.


www.juniper.net


Any Questions? If you have any questions or concerns about the class you are attending, we suggest that you voice them now so that your instructor can best address your needs during class. This chapter contains no review questions.

www.juniper.net




www.juniper.net

Advanced Junos Enterprise Routing Chapter 2: OSPF


This Chapter Discusses:

Chapter 2–2 • OSPF

•

OSPF link-state advertisements (LSAs);

•

How LSAs are flooded throughout the network;

•

The shortest path first (SPF) algorithm;

•

OSPF link metrics;

•

OSPF authentication methods; and

•

The differences between OSPFv2 and OSPFv3.

www.juniper.net


OSPFv2 Review The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.juniper.net

OSPF • Chapter 2–3


Link-State Protocol OSPF is an interior gateway protocol (IGP) based on the concept of a link-state database (LSDB). As such, each OSPF-speaking router in the network attempts to form an adjacency with each neighboring OSPF router. When these adjacencies are in place, each router generates and floods LSAs into the network in a reliable manner. The LSAs are placed into the LSDB on each router where the SPF algorithm is calculated to find the best path to each end node in the network.

Neighbors Use Hello Packets OSPF routers send out hello packets to form and maintain adjacencies with their neighbors.

LSAs Are Flooded OSPF uses IP protocol number 89 and the AllSPFRouters multicast address of 224.0.0.5 to flood LSAs. OSPF routers forward all LSAs through all OSPF-configured interfaces except the one on which an LSA was received. The LSAs are then installed into the OSPF database, which forms the topology map of the network. Finally, the SPF algorithm is run to determine the shortest path to each destination subnet. Continued on the next page.


www.juniper.net


Hierarchical Design OSPF gains scalability as a protocol through the use of a hierarchical design. Portions of the network are designated as separate areas. These remote areas are then connected through a common area called the backbone.

Designated Router Election On a broadcast segment, OSPF routers elect a single node to represent the segment to the network. This node is called the designated router (DR). It forms an OSPF adjacency with all routers on the segment and floods a network LSA into the appropriate area. The criteria for electing the DR is the highest configured priority on the segment, which is set to 128 by default. The second criteria for electing a DR is the highest router ID on the segment. The election of a DR on a broadcast segment is a nondeterministic event. Thus, the router with the best criteria might not always be the DR for the segment. An operational DR maintains its status on the segment until it stops operating. The first OSPF router on a link determines itself as the DR if it does not detect a Hello from another router. Currently, a lot of Ethernet segments are used as point-to-point, full-duplex links. This obviates the need for a DR election. Use the interface-type p2p command on both sides of the link to change the default interface type. Using this option can save up to forty seconds of wait time to get the OSPF adjacency to a full state. [edit protocols ospf] user@router# show area 0.0.0.0 { interface ge-0/0/0.0 { interface-type p2p; } }

www.juniper.net



The Link-State Database In addition to discovering neighbors and flooding LSAs, a third major task of the OSPF protocol is to create and maintain the LSDB. The link-state, or topological, database stores the LSAs as a series of records. The records stored within the LSDB include details such as the advertising router’s ID, its attached networks and neighboring routers, and the cost associated with those networks or neighbors. According to the OSPF RFC, each router in an OSPF area must have an identical LSDB to ensure accurate routing knowledge. We discuss OSPF areas later in this course. The information recorded in the database is used as input data to calculate the shortest paths (that is, least-cost paths) for all destination prefixes within the network. OSPF uses the SPF algorithm (also known as the Dijkstra algorithm) to calculate, all at once, the shortest paths to all destinations. It performs this calculation by creating a tree of shortest paths incrementally and picking the best candidate from that tree. The results of this calculation are then handed to the router’s routing table for the actual forwarding of data packets. For the purposes of this course, the SPF and Dijkstra algorithm are considered the same.


www.juniper.net


Packet Types Every OSPF router uses a specific set of packets to perform its functions. The packet types include the following:

www.juniper.net

•

Hello: Sent by each router to form and maintain adjacencies with its neighbors.

•

Database description: Used by the router during the adjacency formation process. It contains the header information for the contents of the LSDB on the router.

•

Link-state request: Used by the router to request an updated copy of a neighbor’s LSA.

•

Link-state update: Used by the router to advertise LSAs into the network.

•

Link-state acknowledgment: Used by the router to ensure the reliable flooding of LSAs throughout the network.


Advanced Junos Enterprise Routing .

Hierarchical Design The slide graphically displays the hierarchical nature of OSPF. A backbone area (0.0.0.0) is the connecting point for all other areas. By specification, each area must attach to the backbone in at least one location. Areas 1, 2, and 3 each contain routers internal to that area as well as a single area border router (ABR). The ABR generates summary LSAs that represent the routes within its area and floods those to the backbone. The ABR is also responsible for generating summary LSAs that represent the backbone routes and injecting these LSAs into its attached area.


www.juniper.net


OSPF Routers OSPF routers can take on a number of different roles within an OSPF domain. The following list shows the common types of OSPF routers along with a brief description:

www.juniper.net

•

Area border router (ABR): An OSPF router with links in two areas, the ABR is responsible for connecting OSPF areas to the backbone. It transmits network information between the backbone and other areas.

•

Autonomous system boundary router (ASBR): An OSPF router that injects routing information from outside the OSPF autonomous system (AS), an ASBR is typically located in the backbone. However, the OSPF specification allows an ASBR to be in other areas as well.

•

Backbone router: Defined as any OSPF router with a link to Area 0 (the backbone), this router can be completely internal to Area 0 or an ABR depending on whether it has links to other, nonbackbone areas.

•

Internal router: An internal router is an OSPF router with all its links within an area. If that router is located within the backbone area (Area 0.0.0.0), it is also known as a backbone router.



Single Area Configuration Example The slide illustrates the basic hierarchy and syntax used to configure a single OSPFv2 area. OSPFv2 is configured at the [edit protocols ospf] hierarchy as shown in the example.

OSPF Interfaces All logical interfaces associated with the area should be listed under the area. Remember the loopback interface, if it should be advertised.


www.juniper.net


What If...? In the slide, interface lo0.0 has four addresses configured on it. Typically, you would put interface lo0.0 into OSPF using the set area interface command. However, doing this will create four LSAs: one for each of the configured addresses on interface lo0.0. You might come across a situation such as this for which you do not want to advertise all of the addresses into OSPF. A solution to this problem is offered on the next page.

www.juniper.net



Then... The slide shows a solution to our problem. By specifying the specific interface address to advertise, only one LSA is created in the LSDB.


www.juniper.net


Multiarea Configuration Example The slide illustrates the basic hierarchy and syntax used to configure the OSPFv2 multiarea. As in the single area example previously shown, the configuration is performed at the [edit protocols ospf] hierarchy.

OSPF Interfaces All logical interfaces associated with the particular area should be listed under that area. Remember the loopback interface, if it should be advertised.

www.juniper.net



Link-State Advertisements The slide highlights the topic we discuss next.


www.juniper.net


Multiple LSAs in a Single Update Each link-state update packet sent into the network by an OSPF-speaking router can carry multiple different LSAs. This ability saves network resources by allowing routers to use transmission and routing capacity more efficiently.

Link-State Update Format The graphic illustrates the format of the link-state update packet. Following the standard OSPF header, the update packet contains a 4-byte field used to notify other routers as to the number of advertisements stored in the update message. This field is followed by the LSAs themselves, each with its own header and format.

www.juniper.net



LSA Types The following list provides the details of the LSA types: •

Router LSA: Sent by each router to describe its individual links and their status.

•

Network LSA: Sent by the DR on the broadcast network.

•

Summary LSA: Sent by an ABR to describe routes or other information from one area into another.

•

AS external LSA: Sent by an ASBR to describe routes external to the OSPF domain.

•

Group membership LSA: Used to support Multicast Open Shortest Path First (MOSPF).

•

NSSA LSA: Sent by an ASBR in a not-so-stubby area (NSSA) to describe routes external to the OSPF domain.

•

External attributes LSA: Used to tunnel attributes used by other routing protocols through OSPF.

•

Opaque LSAs: Used to transmit information not currently supported by other LSA types. Examples include graceful restart and traffic engineering information.

Continued on the next page.


www.juniper.net


LSA Functions Each of the LSA types listed previously has a specific function within the OSPF domain. They each describe a portion of the topology used by the SPF algorithm to supply routing information to a routing table. We discuss each LSA in more detail on future slides. Each LSA has a maximum age of 3600 seconds (1 hour) associated with it. This maximum provides a mechanism for removing stale information from the database. To ensure that its LSAs are up to date, each OSPF router periodically refreshes them prior to reaching the maximum age limit. The Junos operating system performs this refresh every 3000 seconds (50 minutes).

LSAs Not Supported The Junos OS does not support some of the LSA types listed here. These LSAs are the group membership (Type 6), external attributes (Type 8), and the domain-scope opaque (Type 11) advertisements.

www.juniper.net



LSA Header The following list details the information contained in the LSA header:


•

Link-state age (2 bytes): Measured in seconds, the LS age is the time from when the LSA was first originated. Each router increments this field prior to reflooding the LSA.

•

Options (1 byte): Indicates support for OSPF options. Within the context of an individual LSA, the E bit (position 7) is set in all external LSAs and the P bit (position 5) is set in all NSSA external LSAs.

•

Link-state type (1 byte): Encodes the specific LSA type.

•

Link-state ID (4 bytes): Describes various portions of the OSPF domain. Each LSA type uses this field in a different manner.

•

Advertising router (4 bytes): The router ID of the router that first originated the LSA.

•

Link-state sequence number (4 bytes): Verifies that each router has the most recent version of an LSA. This field is incremented each time a new version is generated. Values range from 0x80000000 to 0x7FFFFFFF.

•

Link-state checksum (2 bytes): The checksum of the entire LSA contents, minus the LS age field. This field is used to ensure data integrity in the LSDB.

•

Length (2 bytes): The entire length of the individual LSA, including the header.

www.juniper.net


Router LSA Each OSPF-speaking router generates a Type 1 LSA to describe the status and cost (metric) of all interfaces on the router. This LSA is flooded to each router in the OSPF area. It is defined as having an area scope; therefore, it is not flooded across an area boundary. In addition to the standard LSA header, the router LSA also contains the following fields:

www.juniper.net

•

V, E, and B bits (1 byte): Following five bits set to a value of 0, the V, E, and B bits represent the characteristics of the originating router. The V bit is set when a virtual link is established. An ASBR sets the E bit. An ABR sets the B bit.

•

Reserved (1 byte): Reserved field. Value is always 0.

•

Number of links (2 bytes): Gives the total number of links represented by the remaining six fields.

•

Link ID (4 bytes): Represents the type of link the far end of the link is connected to.

•

Link data (4 bytes): Represents what the near side of the link is connected to.

•

Link type (1 byte): Describes the type of link. Used with Link ID and Link data fields.

•

Number of type of service (ToS) metrics (1 byte): Lists the number of type of service metrics encoded. Only a value of 0 is supported.

•

Metric (2 bytes): Contains the cost to transmit data out of the interface.

•

Additional ToS data (4 bytes): This field is unused. OSPF • Chapter 2–19


Link ID and Link Data Fields The information in the router LSA’s link ID and link data fields is associated with the type of link OSPF is operating. The following link types are supported:


•

Point-to-point (Type 1): On a point-to-point interface, an OSPF router always forms an adjacency with its peer over an unnumbered connection. As such, the link ID field contains the neighbor’s router ID. The link data field contains the IP address of the interface on the local router.

•

Transit (Type 2): A connection to a broadcast segment is always noted as a transit link. The link ID field contains the interface IP address of the segment’s DR. The link data field contains the interface IP address of the local router.

•

Stub (Type 3): A router advertises a stub network when a subnet does not connect to any OSPF neighbors. Advertising a stub network occurs for the loopback interface and any passive interfaces. In addition, the IP subnet for any point-to-point interface is advertised as a stub because the adjacency was formed over an unnumbered interface. The link ID field for a stub network contains the IP network number and the link data field contains the subnet mask.

•

Virtual link (Type 4): A virtual link operates between an ABR connected to Area 0 and an ABR that is not connected to Area 0. Once established, the virtual link appears in the Area 0 router LSA of each endpoint. The link ID field contains the neighbor’s router ID, and the link data field contains the interface IP address of the local router.

www.juniper.net


Router LSA Example You can see the details of the router LSA in the example on the slide. By using the keyword extensive, you can see each of the LSA fields. You can gather some important details about the local router by closely examining the LSA: •

This router is both an ABR as well as an ASBR. We see this by the setting of bits 0x3. Recall that position 7 (0x2) is for the E bit, which is set when the originating router is an ASBR. Bit position 8 (0x1) is for the B bit, which is set when the originating router is an ABR. Combining these two fields results in a value of 0x3, which we see in the database capture.

•

This router has three links connected to Area 0, which we can determine because of two factors. First, the link count field is set to a value of 3. Second, the LSA is shown in the database within the Area 0.0.0.0 section. Recall that a router LSA has area scope, so a separate LSA is generated for each area representing the links only within that area.

•

A single point-to-point link exists, and two links are connected to stub networks. This fact is clearly visible from the information in the type fields.


www.juniper.net



Router LSA Example (contd.)


•

This router LSA was originated by the same router from which the capture was taken. Notice the asterisk (*) next to the link-state ID value of 192.168.16.1. Also note that the last line of the capture states that this LSA is Ours.

•

The router LSA was installed 15 minutes and 47 seconds ago. If not refreshed, the LSA will expire in 44 minutes and 13 seconds when its 3600 second maximum age is exceeded, and the LSA was last flooded 15 minutes and 47 seconds ago. These details are shown in the Installed, expires, and sent fields, and they are present for every LSA in the show ospf database extensive output.

www.juniper.net


Add Type 1 LSAs to an OSPF Network Using the information in the router LSA, we can begin to draw a network map based on the LSDB:

www.juniper.net

•

We know of three routers within Area 0.0.0.0—192.168.16.1 (the local router), 192.168.24.1, and 192.168.36.1;

•

Two point-to-point subnets connect the three routers—10.222.28.0/24 and 10.222.4.0/24;

•

The IP address of the interface connecting 192.168.16.1 to 192.168.24.1 is 10.222.28.1; and

•

The IP address of the interface connecting 192.168.36.1 to 192.168.24.1 is 10.222.4.2.



Network LSA Each OSPF router elected to be the DR on a broadcast link generates a Type 2 LSA. This LSA lists each router connected to the broadcast link, including the DR itself. In addition to the standard LSA header, the network LSA also contains the following fields:


•

Network mask (4 bytes): This field denotes the IP subnet mask for the interface connected to the broadcast network.

•

Attached router (4 bytes): This field is repeated for each router connected to the broadcast network. The value of each instance is the router ID of the attached routers. You can deduce the total number of routers listed by the length of the LSA.

www.juniper.net


Network LSA Example You can see the details of the network LSA in the example on the slide. By using the keyword extensive, you can see each of the LSA fields. You can gather some important details about this network by closely examining the LSA:

www.juniper.net

•

The DR for this network is 10.222.1.1, which you can determine by examining the link-state ID field. This field lists the DR’s IP address.

•

Because only two instances of the attached router field are present, you can safely deduce that only two routers are connected to the link. The router IDs of those two routers are 192.168.20.1 and 192.168.40.1.



Add Type 2 LSAs to an OSPF Network Using the information in the network LSA, we can add information to our OSPF network map. Remember that all information is from the perspective of the 192.168.16.1 router.


•

We know of two routers within Area 0.0.0.1—192.168.20.1 and 192.168.40.1;

•

A broadcast segment connects the two routers together whose address is 10.222.1.0/24; and

•

The DR for the segment is 192.168.20.1 and its interface address is 10.222.1.1.

www.juniper.net


Summary LSA Each ABR that transmits information from one OSPF area into another generates a Type 3 LSA to describe that information. This LSA is flooded to each router in the OSPF area. This LSA has an area scope; therefore, it is not reflooded across the area boundary by another ABR. Instead, the receiving ABR generates a new Type 3 LSA describing the link and floods it into the adjacent area. In addition to the standard LSA header, the summary LSA also contains the following fields:

www.juniper.net

•

Network mask (4 bytes): This field represents the subnet mask associated with the network advertised. It is used in conjunction with the link-state ID field, which encapsulates the network address in a Type 3 LSA.

•

Metric (3 bytes): This field provides the cost of the route to the network destination. When the summary LSA is representing an aggregated route (using the area-range command), this field is set to the largest current metric of the contributing routes.

•

ToS (1 byte): This field describes any optional type of service information encoded within the network described. The Junos OS does not use this field.

•

ToS metric (3 bytes): This field is not used.



Summary LSA Example You can see the details of the summary LSA in the example on the slide. By using the keyword extensive, you can see each of the LSA fields. You can gather some important details about the local router by closely examining the LSA: •

This router is an ABR because it contains a database for Area 0.0.0.0. Within that area, three summary LSAs are listed. One of the LSAs (the third one listed) is from the router where the capture was taken. As with the router LSA earlier, notice that there is an asterisk (*) next to the link-state ID value of 192.168.40.1. Also note that the last line of the LSA states that the LSA is Ours.

•

A second router in the backbone (192.168.36.1) generates the two other summary LSAs. The two networks advertised by that ABR are 10.222.44.0/24 and 192.168.32.1/32. Each of the networks has a metric of 1 encoded within the LSA. The local router adds the cost to reach 192.168.36.1 to the metric of 1 prior to calculation of the SPF algorithm.

Note that the command output on the slide is truncated. A fourth summary LSA for the 192.168.20.1/32 network is present, but not shown. This network, however, is shown on the next slide.


www.juniper.net


Add Type 3 LSAs to an OSPF Network Once again, we view the database from the 192.168.16.1 router. Using the information in the summary LSAs, we can add the following information to our map:

www.juniper.net

•

A new router exists in an OSPF area connected to 192.168.36.1;

•

We do not know the 32-bit value for the area, but we know that an internal area router exists within it—192.168.32.1;

•

Using the metric values in the summary LSAs, we can determine that the area router and the ABR are connected over the 10.222.44.0/24 subnet; and

•

Within Area 0.0.0.1, we now know that the 192.168.20.1 router is directly connected to our local router of 192.168.16.1. We use the summary LSA metric value to make that determination.



ASBR Summary LSA Each ABR that must transmit information about an ASBR from one OSPF area into another generates a Type 4 LSA to describe that information. This LSA is flooded to each router in the OSPF area. It is defined as having an area scope; therefore, another ABR does not reflood it across the area boundary. In addition to the standard LSA header, the ASBR summary LSA also contains the following fields:


•

Network mask (4 bytes): This field has no meaning in a Type 4 LSA and is set to 0.0.0.0. The address of the ASBR is encoded in the link-state ID field.

•

Metric (3 bytes): This field provides the cost of the route to the ASBR.

•

ToS (1 byte): This field describes any optional type of service information used to reach the ASBR described. This field is not used.

•

ToS metric (3 bytes): This field is not used.

www.juniper.net


ASBR Summary LSA Example You can see the details of the ASBR summary LSA in the example on the slide. By using the keyword extensive, you can see each of the LSA fields. You can gather some important details about the local router by examining the LSA closely.

www.juniper.net

•

This router is an ABR because it contains a database for Area 0.0.0.0. Within that area, currently two ASBR summary LSAs are listed. The second LSA is from the local router (where the capture was taken). As with the router LSA earlier, notice that there is an asterisk (*) next to the link-state ID value and that the last line of the LSA states that the LSA is Ours.

•

The second router in the backbone (192.168.36.1) generates the other ASBR summary LSA.

•

The two ASBRs being advertised are 192.168.32.1 and 192.168.40.1. You can see this information coded in the link-state ID fields. Because the router ID of the ASBR is a full 32-bit value, the network mask is not needed and is set to a value of 0.0.0.0.

•

The metrics to each of the ASBRs are encoded in the appropriate field in the LSA. As with the summary LSA (Type 3), the local router must add the cost to reach a remote ABR to the encoded metric prior to calculation of the SPF algorithm.



Add Type 4 LSAs to an OSPF Network The network map does not change based on the information in the ASBR summary LSAs. However, these LSAs do provide a clue as to the capabilities of the OSPF routers:


•

Routers 192.168.32.1 and 192.168.40.1 both have export policies configured within OSPF, which means that they have set the E bit in their router LSAs.

•

Based on the E bit setting in the router LSAs, the ABRs of 192.168.16.1 and 192.168.36.1 generate ASBR summary LSAs across the area boundaries. In our case, we see the Type 4 LSAs within Area 0.0.0.0.

www.juniper.net


AS External LSA Each ASBR generates a Type 5 LSA to advertise any networks external to the OSPF domain. This LSA is flooded to each nonstub router in the entire OSPF domain. In addition to the standard LSA header, the AS external LSA also contains the following fields:

www.juniper.net

•

Network mask (4 bytes): This field represents the subnet mask associated with the network advertised. It is used in conjunction with the link-state ID field, which encapsulates the network address in a Type 5 LSA.

•

E bit (1 byte): The E bit determines the type of external metric represented by the metric field. It is followed by 7 bits, all set to 0 to make up the entire byte. A value of 0, the default value, indicates that this is a Type 2 external metric. Thus, any local router should use the encoded metric as the total cost for the route when performing an SPF calculation. A value of 1 indicates that this is a Type 1 external metric. Therefore, the encoded metric of the route should be added to the cost to reach the advertising ASBR. This additive value then represents the total cost for the route.

•

Metric (3 bytes): This field represents the cost of the network as set by the ASBR.

•

Forwarding address (4 bytes): This field provides the address toward which packets should be sent to reach the network. A value of 0.0.0.0 represents the ASBR itself.

•

External route tag (4 bytes): This 32-bit value field can be assigned to the external route. OSPF does not use this value, but it might be interpreted by other protocols.

•

Optional ToS fields (4 bytes): These fields are unused. OSPF • Chapter 2–33


AS External LSA Example You can see the details of the AS external LSA in the example on the slide. By using the keyword extensive, you can see each of the LSA fields. You can gather some important details about the local router by examining the LSA closely:


•

The external LSDB lists all the LSAs. This listing denotes their domain scope status as not belonging to a particular OSPF area.

•

This router is generating the first LSA listed. As with the router LSA earlier, an asterisk (*) exists next to the link-state ID value, and the last line of the LSA states that the LSA is Ours.

•

Different routers generate each of the other three LSAs because the advertising router field is different for each LSA.

•

Examination of the link-state ID and the network mask fields shows that the four different networks advertised are 192.168.17.0/24, 192.168.33.0/24, 192.168.37.0/24, and 192.168.41.0/24. Each of these networks has a metric value of 20 encoded. In addition, each of these LSAs is a Type 1 metric (as seen by the type field). Taking these two values in conjunction with each other tells the local router to add the cost to reach the remote ASBR to the encoded metric prior to calculation of the SPF algorithm. The metric to the ASBR is used because the forwarding address field for each LSA is listed as 0.0.0.0.

www.juniper.net


Add Type 5 LSAs to an OSPF Network The addition of AS external LSAs to our network map displays the external routes being advertised into the network:

www.juniper.net

•

The 192.168.17.0/24 route is being injected by the 192.168.16.1 router;

•

The 192.168.33.0/24 route is being injected by the 192.168.32.1 router;

•

The 192.168.37.0/24 route is being injected by the 192.168.36.1 router; and

•

The 192.168.41.0/24 route is being injected by the 192.168.40.1 router.



NSSA External LSA Origination Each ASBR within the NSSA generates a Type 7 LSA to advertise any networks external to the OSPF domain. This LSA is flooded to each router within the NSSA. Because the LSA has only an area flooding scope, it is not sent into other adjacent areas. The format of the NSSA external LSA is exactly the same as the AS external LSA (Type 5) described on an earlier slide. The only difference between the two LSAs is in the use of the forwarding address field. With the Type 7 LSA, the forwarding address depends on whether the network connecting the NSSA to the adjacent system is known as an internal route to the NSSA. If the network is known, the next-hop address of the remote router is placed into the forwarding address field. If the network is not known, the forwarding address field contains the router ID of the ASBR. Continued on the next page.


www.juniper.net


NSSA External LSA Translation By definition, only NSSA-capable routers can interpret a Type 7 LSA. Having only NSSA-capable routers able to interpret this LSA type causes a problem with flooding the routing knowledge throughout the OSPF domain because not all routers are configured to support NSSA. Furthermore, the NSSA external LSA represents the same type of information as the AS external LSA, and each OSPF router expects to receive an LSA for all external routes. This apparent contradiction is resolved by allowing the ABR to generate an AS external LSA (Type 5) on behalf of the NSSA ASBR. For each Type 7 LSA received, the ABR translates the information into a Type 5 LSA and sends that information into the backbone. This translation is performed by the ABR with the highest router ID. The other backbone routers do not know that the original information came from an NSSA and perform their duties as previously discussed. When an ASBR is also an ABR with an NSSA area attached to it, a Type 7 LSA is exported into the NSSA area by default. If the ABR is attached to multiple NSSAs, a separate Type 7 LSA is exported into each NSSA by default. Use the no-nssa-abr command to disable the export.

www.juniper.net



NSSA External LSA Example You can see the details of the NSSA external LSA in the example on the slide. The 192.168.32.1 ASBR generated this LSA. By using the keyword extensive, you can see each of the LSA fields. You can gather some important details about the local router by examining the LSA closely:


•

Notice that the LSA is listed within the Area 0.0.0.2 database. This listing denotes its area scope status as belonging to a single NSSA area.

•

An examination of the link-state ID and the network mask fields shows that the network advertised is 192.168.33.0/24. This network has a metric value of 20 encoded. It also is listed as a Type 1 metric (as seen by the type field). Taking these two values in conjunction with each other informs the local router to add the cost to reach the ASBR to the encoded metric prior to calculation of the SPF algorithm.

•

The NSSA does not know the network connecting the ASBR to the remote domain. You can see this fact by examining the forwarding address field where it lists the router ID of the ASBR, 192.168.32.1.

www.juniper.net


Add Type 7 LSAs to an OSPF Network When we focus our attention on the 192.168.36.1 ABR, we now get some added information about the network composition:

www.juniper.net

•

The area attached to the 192.168.36.1 router is Area 0.0.0.2. It is also currently configured as an NSSA.

•

The 192.168.33.0/24 route is being injected into Area 0.0.0.2 as a Type 7 LSA. It is translated into a Type 5 LSA by the 192.168.36.1 router.



Future Extensibility RFC 2370 defines the OSPF opaque LSA. It was designed to extend the protocol to support future enhancements without generating new LSA types. As of this writing, production networks use both the Type 9 and Type 10 opaque LSAs. The Type 9 LSA supports graceful restart. The Type 10 LSA supports MPLS traffic engineering. The Type 11 opaque LSA is not used at this time.

Flooding Scope The main difference between the opaque LSAs is in the flooding scope of each type: The Type 9 LSA has a link-local scope, the Type 10 LSA has an area scope, and the Type 11 LSA has domain scope.

Opaque LSA Format The format of the opaque LSA has the standard LSA header followed by some number of octets containing application-specific information. You can interpret the total number of octets contained in the message by examining the length field in the LSA header. In addition, the link-state ID field is segmented into a 1-byte opaque type field and a 3-byte opaque ID field. The Internet Assigned Numbers Authority (IANA) has the responsibility of assigning new opaque type codes in the 0–127 range. Values between 128 and 255 are set aside for private and experimental use only. Opaque-capable routers communicate their ability to each other by using a new bit in the options field. Bit position 2 is defined as the O bit. A value of 1 in this bit position allows a remote router to flood opaque LSAs to the local router. A value of 0 tells the remote router not to flood those LSA types. Chapter 2–40 • OSPF

www.juniper.net


Protocol Operations The slide highlights the topic we discuss next.

www.juniper.net



LSA Flooding Scopes As discussed in previous slides, each LSA in the OSPF protocol has a specific scope within which it can be flooded. The slide graphically displays those flooding scopes. LSA Types 1 and 2 are generated within each area. Because these LSAs have an area flooding scope, they remain within their own particular area and are not seen in other areas. The ABR places the routing information contained within these LSAs into a Type 3 LSA and forwards it across the area boundary. In addition, existing Type 3 LSAs within the backbone are forwarded into the nonbackbone areas to provide routing knowledge to those routers. This results in Type 3 LSAs within every area that represent all OSPF routes. Within Area 1, for example, Type 3 LSAs exist that represent Area 0, Area 2, and Area 3. In the diagram, two ASBRs inject routes into the OSPF domain. The AS external LSAs (Type 5) that represent those routes have domain flooding scope (with the exception of stub areas). As such, they exist within each OSPF area. To reach those external routes, the OSPF routers use either router LSAs or ASBR summary LSAs (Type 4) to have knowledge of the ASBRs. Much like the Type 3 LSAs, the ASBR summary LSAs have area scope, so the area border binds them. Each ABR regenerates the Type 4 summary LSAs into their respective areas to provide the knowledge of how to route toward the ASBR that is advertising a given external prefix. This capability leads to Type 4 LSAs for Area 0 being injected into Areas 1, 2, and 3, while a Type 4 for Area 3 is injected into Areas 0, 1, and 2.


www.juniper.net


Sample OSPF Database You can see key details of the OSPF database in the database example on the slide, which has been edited for brevity. To this point, we have examined small portions of the database through the use of the extensive keyword. We now take a step back and examine the database as a whole. As before, you can gather some details by examining the database closely:

www.juniper.net

•

The local router is an ABR between the backbone and Area 0.0.0.1, which you can see clearly through the existence of two databases on the router.

•

Within Area 0.0.0.1, a broadcast link is in use. In addition, the DR on that link is the router whose address is 10.222.1.1. Notice the Type 2 LSA within the Area 0.0.0.1 database. The link-state ID is 10.222.1.1, the DR’s IP address on the link.

•

Multiple routers act as ASBRs and inject routes into the OSPF domain. Those routers are 192.168.16.1, 192.168.20.1, 192.168.32.1, and 192.168.36.1. The routes advertised by those ASBRs can be used once the local router has knowledge of how to reach the ASBR.

•

One of the ASBRs is the local router, 192.168.16.1. One of the external LSAs lists this router ID, and that LSA is marked with an asterisk (*). A second ASBR is a router within Area 0.0.0.1 (192.168.20.1). This router ID is found within a router LSA in the Area 0.0.0.1 database. A third ASBR is a router within the backbone (192.168.36.1). This router ID is found within a router LSA in the Area 0.0.0.0 database. The fourth ASBR is a router in an area beyond the backbone (192.168.32.1). This router ID is found within an ASBR summary LSA in both the Area 0.0.0.0 and the Area 0.0.0.1 databases. OSPF • Chapter 2–43


OSPF Database Protection This feature limits the number of LSAs that were not generated by the local router, protecting the LSDB from being flooded with excessive LSAs. This is a very useful feature if a VPN routing and forwarding (VRF) instance is configured to use OSPF between the PE and CE routers. Consider, for example, a situation in which a customer misconfigured their OSPF network and inadvertently sent you several thousand of their routes. The maximum-lsa option can help to avoid such situations.


www.juniper.net


Dijkstra Algorithm After a router receives a new LSA and places it into the LSDB, the router runs the SPF algorithm. This computation uses the database as a data source and results in a loop-free network topology using the best metric from the local router to all nodes in the network. During the course of this calculation, the algorithm uses three databases—the LSDB, the candidate database, and the tree database. As we have explored, the LSDB is the total compilation of routing knowledge in the network. Conceptually, it consists of multiple tuples in the form of: router ID, neighbor ID, cost. These tuples describe each link in the network. Continued on the next page.

www.juniper.net



Dijkstra Algorithm (contd.) The first step is as follows: 1.

Evaluate each tuple in the candidate database and delete any tuples whose neighbor ID is currently in the tree database and whose cost to the root is greater than the entry currently in the tree database. Repeat this step until no more tuples can be deleted.

As the algorithm operates, the local router moves its own local tuple into the tree database and all tuples for its links into the candidate database. It then performs the following steps until the candidate database is empty: 2.

For each new entry in the candidate database, determine the cost from the root to each neighbor ID. Move the tuple with the lowest cost from the candidate database into the tree database. If multiple tuples exist with an equal cost, choose one randomly.

3.

If a new neighbor ID appears in the tree database, move all tuples in the LSDB with a router ID equal to the new tree entry’s neighbor ID into the candidate database.

Run on a Per-Area Basis The router calculates the Dijkstra algorithm for each LSDB present on the local router. Recall from an earlier slide that each OSPF area maintains a separate copy of the database. These copies allow each area to have a separate forwarding topology independent of another area.

Results Are Passed to the Routing Engine Once the algorithm is run, the routing table on the Routing Engine receives the results of the tree database. At this point, the Routing Engine controls the determination of whether to use any individual OSPF route to forward traffic. The preference value assigned to each route often handles this choice. The action of calculating the best OSPF route prior to the route being placed into the routing table has a consequence with regard to the filtering of routing knowledge. An individual filter (or policy) operates on IP routes that enter the router as IP routes and are placed into the routing table. This form of data flow is not present in OSPF because the routing information enters the router as an LSA and is only placed into the routing table after the Dijkstra algorithm is performed. Hence, the best method of filtering OSPF routing knowledge is to keep that information from being placed into the database (on a per-area basis) in the first place. OSPF does offer a limited import-policy functionality. You can use the import statement at the [edit protocols ospf] configuration hierarchy to block external routes—those learned from Type 5 and Type 7 LSAs—from being installed in the routing table. This import policy does not, however, prevent LSAs from being flooded. We strongly discourage the use of OSPF import policy because of the potential for unknowingly discarding traffic.


www.juniper.net


SPF Calculation Example: Part 1 In the following slides, a sample SPF calculation is displayed. This graphic shows the beginning state of the network including the routers involved, the configured link metrics, and the LSDB. The network and the LSDB have recently converged and the local router, RTR-A, is running an SPF calculation to determine the shortest path to each node in the network.

www.juniper.net



SPF Calculation Example: Part 2 RTR-A begins by moving its own local database tuple (A,A,0) into the candidate database. The total cost from the neighbor ID to the root is calculated, which results in a 0 value. In other words, RTR-A is directly connected to itself! The lowest, and only, tuple in the candidate database is moved to the tree database and RTR-A places itself on the network map.


www.juniper.net


SPF Calculation Example: Part 3 All tuples from the most recent node added to the tree database are now added to the candidate database. Because RTR-A is the most recent entry to the tree database, all of RTR-A’s tuples are moved from the LSDB into the candidate database. All known nodes in the tree database are removed from the candidate, of which there are none. (For example, if B were already in the tree database, the tuple (A,B,1) would be eliminated.) The cost to each neighbor ID from the root is then calculated. It costs RTR-A 0 to reach itself and 1 to reach RTR-B, so the total cost to RTR-B is 1. The same calculation is done for RTR-C, and the total cost of 2 is placed into the candidate database. The lowest cost tuple in the candidate database, (A,B,1), is now moved to the tree database, and RTR-B is placed on the network map. The candidate database is not empty, so the algorithm continues.

www.juniper.net



SPF Calculation Example: Part 4 RTR-B is the most recent entry to the tree database, so all RTR-B’s tuples are moved from the LSDB into the candidate database. All known nodes in the tree database are then removed from the candidate. Thus, the (B,A,3) tuple is removed because RTR-A already has the shortest path to RTR-B. The cost to each neighbor ID from the root is then calculated. It costs RTR-B 3 to reach RTR-D, and it costs 1 to reach RTR-B from the root. Therefore, the total cost to reach RTR-D from the root through RTR-B is 4. The lowest cost tuple in the candidate database, (A,C,2), is now moved over to the tree database, and RTR-C is placed on the network map. The candidate database is not empty, so the algorithm continues.


www.juniper.net


SPF Calculation Example: Part 5 As RTR-C is the most recent entry to the tree database, its tuples are moved from the LSDB into the candidate database. All known nodes in the tree database are then removed from the candidate. Thus, the (C,A,4) tuple is removed because RTR-A already has the shortest path to RTR-C. The cost to each neighbor ID from the root is then calculated. It costs RTR-C 4 to reach RTR-D, and it costs 2 to reach RTR-C from the root. So the total cost to reach RTR-D through RTR-C is 6. The lowest cost tuple in the candidate database, (B,D,3), is moved to the tree database, and RTR-D is placed on the network map. The candidate database is not empty, so the algorithm continues.

www.juniper.net



SPF Calculation Example: Part 6 RTR-D, through its link to router B, is the most recent entry to the tree database. Therefore, its tuples are moved from the LSDB into the candidate database. All known nodes in the tree database are then removed from the candidate. Thus, the (C,D,4), (D,B,1), and (D,C,2) tuples are removed because RTR-A already has paths to RTR-B, RTR-C, and RTR-D. The candidate database is now empty of all tuples, so the algorithm stops at this point. RTR-A now has a complete network map built with the total cost to each node calculated. This information is then passed to the Junos routing table for its use.


www.juniper.net


Consecutive SPF Calculations To enhance the convergence time of an OSPF network during a time of topology changes, the Junos OS by default allows for the SPF calculation to be run three times in a back-to-back fashion before encountering a mandatory hold-down period. The 5-second hold-down timer used to be hardcoded into the software but is now configurable. The timer ensures that the network can continue to forward packets, with potentially incorrect routing knowledge, during the convergence period. The timer also keeps the routing protocol process from hogging the CPU at the expense of other router functions.

Preconfigured Delay Between Calculations A configurable timer slightly delays consecutive SPF calculations. The default timer value is 200 milliseconds; you can alter it with the spf-options delay statement. The spf-options delay statement is supported both at the global OSPF configuration hierarchy and within an OSPF routing instance. Delay values ranging from 50 milliseconds to 1000 milliseconds (1 second) are supported. Regardless of the configuration of this timer, the mandatory 5-second hold-down timer still starts after the third consecutive rapid SPF calculation. A current best practice in today’s networking environment is setting the spf-options delay value to be slightly larger than the worst possible propagation delay found in your network. For example, if the delay across the network is 200 milliseconds, you might set the spf-options delay to 250 milliseconds. This setting allows time for all of the duplicate LSAs to arrive at all routers before the SPF calculation is performed. www.juniper.net



Cost of an Interface Prior to advertising a network into the OSPF domain, each router must determine the cost associated with that network. Often referred to as the metric, the cost is simply what the router views as the overhead associated with transmitting a packet on that interface. Because each OSPF-speaking router advertises these cost values in its router LSAs, each router can determine the total cost (or metric) to reach any destination in the network.

OSPF Default Cost Each router uses an algorithm to determine the cost of each interface—the calculation is 100,000,000 divided by the bandwidth of the interface. If the result of this calculation is less than 1, it is rounded up to a value of 1. Because 100,000,000 is the same as the bandwidth of a Fast Ethernet interface (100 Mbps), all interfaces operating at a faster bandwidth have their calculated cost less than 1, which becomes rounded up to 1.

Set on a Per-Interface Basis If you want to alter the automatic cost calculated by the formula above, you can manually set the cost for each interface. Within the interface portion of the [edit protocols ospf] configuration hierarchy, the metric command assigns a permanent cost to that interface. Each individual interface on the router can have a separate cost assigned to it.


www.juniper.net


Change the Cost Calculation Although each interface can have a cost assigned to it statically, assigning static costs often proves to be an administrative hassle in all but the smallest networking environments. A middle ground is available to administrators who would like an automatic calculation but have large bandwidth links in their network. The solution is to alter the values used in the bandwidth calculation. This alteration not only allows for an automatic cost assignment but also maintains a consistent ratio across all the router interfaces.

Reference Bandwidth To alter the calculation values, use the reference-bandwidth command within the [edit protocols ospf] configuration hierarchy. The value entered has a value in bits per second. You can use the standard Junos shortcut notations of k (kilobits per second), m (megabits), and g (gigabits). The entered value becomes the new numerator value in the bandwidth calculation. As noted on the slide, you still can assign a metric statically to an individual interface.

www.juniper.net



Advertisement of Metric Values After the OSPF process on a router decides what metric to assign to each interface, that information is flooded into the OSPF domain within either a Type 1 LSA or a Type 2 LSA. Because these LSAs have an area flooding scope, each router in the OSPF area receives a copy of the metric values.

SPF Calculations After receiving a new LSA from another router in the area, the local router performs an SPF calculation using all the values contained in the router and network LSAs. As mentioned on a previous slide, the cost is calculated from the root node to every other node in the network using the metric cost of the outgoing interfaces.

Routers Can Disagree Because each individual router performs a separate SPF calculation, it is possible for two routers on either side of a link to disagree on the metric of that link. The example on the slide shows that each router has decided upon a different metric value for its attached links. This discrepancy results in the Hong Kong router calculating a total cost of 45 to reach the Amsterdam router, while the Amsterdam router calculates a total cost of 60 to reach the Hong Kong router. While the configuration of different metrics for a single link does not affect the operation of OSPF, asynchronous routing might occur within the network. Asynchronous routing might cause response delays for some end users and make it challenging for network administrators to troubleshoot the network. Chapter 2–56 • OSPF

www.juniper.net


Avoid Transit Traffic OSPF borrows the overload concept from the IS-IS protocol. Its function is to advertise information into the OSPF area, but it is not to be used for transit traffic, if possible. This function can be useful in two situations—when a router must be taken out of the network for maintenance, and when the router has many BGP peers. In the first case, traffic should avoid the router because it can compromise its ability to forward traffic. In the second case, a network administrator might want the router to establish its BGP peering sessions fully before handling transit traffic. Because the overload concept is not native to OSPF, the software is modified to allow for this functionality. When you configure an OSPF-speaking router for overload, the metrics for all transit interfaces are set to the maximum value of 65,535. The overload router floods these LSAs into the network, where an SPF calculation is performed in each router. The large metric values generally ensure that transit traffic through the overload router uses alternative paths through the network. Unlike IS-IS, traffic transits the overload router if no alternative path exists to a given destination.

Overload Settings You can turn on the overload setting, turn it off as a permanent value, or have a timer associated with it. If the timer is omitted, the metric values are changed when you commit the configuration. The values will remain until you remove the overload setting from the configuration and commit it again. However, if you assign a timer value, the metrics are not changed automatically. The timer associated with the overload setting only initializes when the routing protocol process initializes. This timer can run from 60–1800 seconds. When the timer expires, the metrics return to normal in the router LSAs, but the configuration still contains the overload option. www.juniper.net



Case Study Enterprise networks are typically built with multiple paths from ingress and egress points for redundancy. During maintenance operations on a router, it can be beneficial to prevent the router from receiving and forwarding transit traffic. The overload feature provides this function. In the graphic on the slide, R2 is scheduled for maintenance. An alternate path exists through R3. Once R2 is put in overload mode the other routers will be notified and transit traffic will traverse R3. Any traffic destined for networks that terminate on R2 will still be forwarded to R2.


www.juniper.net


OSPF Router ID Each OSPF-speaking router in a network must select a 32-bit value to use as the router ID (RID) of the router. This RID uniquely identifies the router within the OSPF domain. It is transmitted within the LSAs used to populate the LSDB and is used to calculate the shortest-path tree using the method described on a previous slide. It is very important in a link-state network that no two routers share the same RID value. If two routers share the same RID value, the LSDB might not be consistent on all routers. This inconsistency happens because the RID is one method to verify whether an LSA is already present in the database. Therefore, new critical information from one of the routers is never present in all the routers. In addition, because the Dijkstra calculation uses the RID, it is possible that an individual router might not generate a loop-free shortest path topology. This scenario could have a disastrous affect on IP routing.

Router ID Is the Primary Interface Whenever the rpd restarts on a Juniper Networks router, the selection of the router’s primary interface takes place. This selection states that the primary interface will be the smallest non-127/8 IP address configured on the loopback interface. If no non-127/8 address is configured, the interface uses the first available IP address on the router. Continued on the next page.

www.juniper.net



Router ID Is the Primary Interface (contd.) Because the OSPF routing process uses the primary router interface as the RID, its selection can have a very important consequence. If the router addressing changes, the OSPF RID might also change, and a duplicate RID situation might arise. The hazards of this type of situation were outlined in the previous section.

Manual Router ID Selection To avoid possible problems with the OSPF RID changing, you can set the router ID manually within the Junos configuration. Within the [edit routing-options] configuration hierarchy, the router-id command assigns a 32-bit value to the RID. By setting this value, the process of using the router’s primary interface value is not used.


www.juniper.net


Loopback Is Often the Router ID In a vast majority of the networks using OSPF, the routers have unique loopback IP addresses configured. As such, the loopback address automatically becomes the router ID of the router, unless configured manually using the router-id command.

Automatic Advertisement of the Router ID As of Release 8.5, the Junos OS no longer automatically advertises the loopback (interface lo0.0) IP address, which might also be your RID, into the network. However, there are several important points to keep in mind when configuring your router. If you do not configure interface lo0.0 within an OSPF area, the loopback IP address will not be advertised. Thus, the loopback address will not be reachable. When you configure interface lo0.0 within a specific OSPF area, the loopback IP address will then only be advertised in the router LSA for that specific area. The ABR attached to Area 2 has its loopback configured within Area 0. It then advertises the loopback in its Area 0 router LSA only. The address is still visible to Area 2, but it is encoded in a summary LSA as all the other backbone routes are.

www.juniper.net



OSPF Authentication The slide highlights the topic we discuss next.


www.juniper.net


Authentication The three different forms of authentication that the Junos OS supports are none, simple, and MD5. As of Junos Release 8.3, IP Security (IPsec) was added.

Authentication Default The default operation of the OSPF process is the none mode. Thus, no authentication key is configured on any interface.

Plain-Text Passwords With simple authentication type configured, each OSPF packet includes a plain-text password. This password can be captured easily through a packet analysis system. Therefore, although this password protects against an inadvertent configuration, it does not provide any security.

www.juniper.net



Encrypted Checksum To provide better security in an OSPF network, we recommend that you use an authentication type of MD5. MD5 includes an encrypted checksum in all OSPF packets instead of a simple-text password. Each OSPF-speaking router uses the same MD5 algorithm to calculate the checksum value, so interoperability and a correct result can be virtually guaranteed.

Authentication Keys The actual password to verify and authenticate packets is contained within the authentication command. You can configure each individual interface with an authentication value.

Key ID Values You configure each individual interface with a key value. All interfaces in the area might share the same key value, or each interface might contain a separate value.


www.juniper.net


Multiple Key Values When configuring multiple key values, you can also specify a start time for the router to begin using a new MD5 key. This setting aids in the graceful transition from one password key to another. The example in the slide displays the format of the start-time command. When the local router’s time reaches the specified value, the router begins to transmit all OSPF packets using the new key ID value and password. To begin using a new MD5 key ID immediately, you can use the keyword of now in place of a specific time and date. The router automatically places the current system time in the configuration for you.

www.juniper.net



View Authentication Information The show ospf interface detail command displays the type of authentication used on the interface with the Auth type output. Displaying this output occurs regardless of whether you use per-area or per-interface authentication in your network. The possible values displayed in the output are None, Password, and MD5. When MD5 authentication is in use, the router also displays the current key ID value and the time at which that ID was first used. If start-time is not specified in the configuration, the value of the Start time field in the show ospf interface detail command output is the UNIX epoch (1970 Jan 1 00:00:00 UTC).


www.juniper.net


Authentication Mismatch OSPF routers must agree on the authentication method to be neighbors. Use the traceoptions functionality if you suspect there might be an authentication mismatch. The log shows that the local router is “ignoring” an OSPF packet from 172.20.77.1 because of an authentication mismatch. No authentication method is configured on the local router, so the type is none. The remote router has MD5 authentication configured.

www.juniper.net



OSPFv3 The slide highlights the topic we discuss next.


www.juniper.net


OSPFv3 OSPFv3 is defined in RFC 5340, with some additional features, such as grateful restart and authentication, defined in separate documents (RFC 5781—OSPFv3 Graceful Restart and RFC 4552— Authentication/Confidentiality for OSPFv3). OSPFv3 maintains the fundamental mechanisms of OSPF, including LSA flooding scopes, areas, DR election, stub areas, NSSAs, and so on. Though OSPFv3 is often associated with IPv6 addressing, it is also completely compatible with IP version 4 (IPv4) addressing schemes. However, some changes are necessary to account for the differences in IPv4 versus IP version 6 (IPv6) addressing. We address these differences on the following slides. In terms of the Junos OS configuration, all that is required is to substitute ospf3 for ospf in the configuration. [edit] user@router# show protocols ospf? Possible completions: > ospf OSPF configuration > ospf3 OSPFv3 configuration

www.juniper.net



Differences Between OSPFv2 and OSPFv3: Part 1 Though much remains the same, several differences exist between OSPFv2 and OSPFv3: •

Protocol processing per link, not per subnet: You need only a single adjacency per link even if multiple IPv6 subnets exist on the link. These adjacencies are formed using link-local addresses, which removes the requirement of having matching subnet and subnet mask configurations for two routers to become adjacent.

•

Removal of addressing semantics: Addressing semantics were removed from OSPF headers, and no prefix information is carried in the router LSAs or network LSAs. This change makes OSPFv3 somewhat protocol independent. The router and network LSAs now express the topology in a protocol-independent fashion. To carry the equivalent information that was carried in these LSAs with OSPFv2, a new LSA called the intra-area-prefix LSA is introduced. The intra-area-prefix LSA carries the IPv6 addressing information.

•

Flooding scope is generalized: Flooding is now generalized and is coded into the LS type field. An LSA can be either flooded on the local link, area, or throughout the AS. This flooding also assists in the handling of unknown LSA types as the flood scope is encoded.



www.juniper.net


Differences Between OSPFv2 and OSPFv3: Part 1 (contd.) •

www.juniper.net

Support for multiple instances per link: This support allows multiple OSPF instances to run over a single link to support separate routing domains or to support a single link belonging to multiple areas. Previously, this functionality was achieved in OSPFv2 by tweaking authentication to hide OSPF packets from an OSPF router. This functionality is now formalized by including an instance ID in the OSPF header.



Differences Between OSPFv2 and OSPFv3: Part 2 Further differences between OSPFv2 and OSPFv3: •

Use of link-local addresses: OSPF packets are sent using the IPv6 link-local addressing. These link-local addresses are also used as next-hop information during forwarding.

•

Authentication removed: Authentication uses the IPsec framework built into IPv6. As a result, it is not required at the application layer and was removed.

•

LSA format changes: Summary LSAs are now referred to as inter-area-prefix LSAs, and ASBR summary LSAs are now inter-area-router LSAs to account for differences in address size. The intra-area-prefix LSA is also included, carrying prefix information internal to areas that were previously carried inside router and network LSAs.

•

Unknown LSA handling: The old way of discarding unknown LSA types is no longer supported because a mix of capabilities in a network, especially on a single link, causes forwarding issues. OSPFv3 codes the proper handling of an unknown LSA type in the LSA handing bit. The LSA is either treated as being of local scope only or stored and forwarded as if it were understood.



www.juniper.net


Differences Between OSPFv2 and OSPFv3: Part 2 (contd.) This list is a continuation of the further differences between OSPFv2 and OSPFv3: •

www.juniper.net

The options field was expanded from 8 bits to 24 bits: The option field is included in OSPF hello packets, database description packets, and certain LSAs (router LSAs, network LSAs, inter-area-router LSAs, and link LSAs). Previously defined option bits are present, as well as added support for the V6-bit and R bits. The V6-bit is used to indicate whether the route or link should be excluded from IPv6 routing calculations. The R bit is used like the IS-IS overload bit and indicates whether the originator is an active router. If the R bit is clear (that is, 0) in the OSPF options field, the advertising router can participate in OSPF without being used for transit traffic. This would be a useful setting for hosts that are multihomed but never used to forward traffic between interfaces.



OSPFv3 LSA Types The link state (LS) type field is encoded in the LSA header and indicates the flooding behavior and the information contained in the LS update. LSA types are now encoded with LSA properties and an LSA function code. Continued on the next page.


www.juniper.net


OSPFv3 LSA Types (contd.) LSA properties include: •

U bit: Used to indicate how a router that does not understand the LS function code should handle the LSA. When the code is 0, the LSA should treat the LSA as if it has link-local scope only. When the code is 1, the router should store and flood it as if it were understood.

•

S-bits and flooding scope: Used to indicate the flooding scope for the LSA:

S-bits and flooding scope S2

S1

Flooding scope

0

0

Link-local scope.

0

1

Area scope.

1

0

AS scope.

1

1

Reserved.

The function codes are very much like the OSPFv2 type codes. Some exceptions, however, do exist. Most notably, all addressing semantics are removed from the router and network LSAs. The addresses that were advertised in the OSPFv2 versions of the LSAs are now carried in a new intra-area-prefix LSA. Another addition is the presence of the link LSA. The link LSA is used to advertise to directly attached OSPF neighbors the link-local IPv6 address assigned to the interface. As indicated by the LS type, the link LSA is not flooded beyond the physical broadcast domain.

www.juniper.net



OSPFv2 and OSPFv3 Similarities One similarity is the preservation of the 32-bit router ID. Like OSPF, in OSPFv3 every OSPF router has a single RID; it is a 32-bit number in dotted quad notation. If the RID is not explicitly configured under routing-options, the Junos OS uses IPv4 addressing to derive a RID based upon the same rules as OSPFv2 (that is, it is likely the loopback address). However, it is conceivable that IPv6 devices be deployed without any IPv4 addresses with which to derive the RID, and so we recommend configuring the router ID explicitly.


www.juniper.net


OSPFv2 and OSPFv3 Feature Support Similarities OSPFv3 is largely an adaptation of OSPFv2 and, as a result, features supported in OSPFv2 are also supported in OSPFv3. Perhaps the only obviously missing feature is authentication. Authentication is removed from OSPFv3 because IPv6 has this security feature built in (although it is off by default), and thus there is no need for both OSPFv3 and IPv6 to have the feature.

www.juniper.net



This Chapter Discussed:


•

OSPF LSAs;

•

How LSAs are flooded throughout the network;

•

The SPF algorithm;

•

OSPF link metrics;

•

OSPF authentication methods; and

•

The differences between OSPFv2 and OSPFv3.

www.juniper.net


Review Questions 1. 2. 3.

www.juniper.net



Lab 1: Configuring and Monitoring OSPF The slide lists the objectives for this lab.


www.juniper.net

Advanced Junos Enterprise Routing Chapter 3: OSPF Areas



OSPF area types and operations;

•

How to configure various OSPF area types; and

•

How to summarize and restrict routes.

Chapter 3–2 • OSPF Areas

www.juniper.net


Review of OSPF Areas The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.juniper.net

OSPF Areas • Chapter 3–3


OSPF Scalability With a link-state protocol, flooding link-state update packets and running the shortest-path-first (SPF) algorithm consumes router resources. As the size of the network grows and more routers are added to the autonomous system (AS), this use of resources becomes a bigger and bigger issue. This issue stems from the RFC requirement that all OSPF routers share an identical link-state database (LSDB). Eventually, the routers spend so much time flooding and running the SPF algorithm that they cannot route data packets. Clearly, this scenario is not optimal.

Shrinking the LSDB The solution to this problem (and link-state protocol scalability in general) is to reduce the size of the LSDB. You can reduce the size of the LSDB using multiple OSPF areas rather than a single area that encompasses the entire AS. Note that the type of OSPF areas used is important when attempting to shrink the size of the LSDB. We discuss the various OSPF area types on a subsequent slide. In addition to adding new OSPF areas that restrict link-state advertisement (LSA) flooding, you can also perform route summarization on the borders between OSPF areas. Route summarization has two key benefits: 1) It reduces the size of the LSDB; and 2) it can hide some instabilities in one OSPF area from all other OSPF areas. For route summarization to be effective, you must carefully plan the addressing within your OSPF network so that subnets can be more easily summarized. Complete coverage of route summarization is beyond the scope of this course.


www.juniper.net


OSPF Areas Using OSPF, you can segment an AS into smaller groups known as areas. Using areas achieves the OSPF hierarchy that can facilitate growth and scalability. You can constrain LSA flooding by using multiple areas, which can effectively reduce the size of the LSDB on an individual OSPF router. Each OSPF router maintains a separate and identical LSDB for each area to which it is connected. To ensure correct routing knowledge and connectivity, OSPF maintains a special area known as the backbone area. The backbone area is designated as Area 0.0.0.0 (or simply Area 0). All other OSPF areas must connect themselves to the backbone area. By default, all data traffic between OSPF areas transits the backbone. You can alter this default behavior and eliminate the requirement of all interarea traffic transiting Area 0.0.0.0 by configuring a multiarea adjacency on the same logical interface. The multiarea adjacency feature is documented in RFC 5185 and is discussed in the next chapter.

www.juniper.net



OSPF Area Types This slide introduces some OSPF area types and illustrates the relationship between these areas, including the types of routes exchanged between them. On the slide, all areas are connected directly to the backbone. In the rare situations where a new area is introduced that cannot have direct physical access to the backbone, you can configure a virtual link. Virtual links are covered in the next chapter. OSPF classifies different types of routing information as follows: •

Intra-area or internal routes: Routes that are generated from within an area, where the destination belongs to the area;

•

Interarea or summary routes: Routes that originate from other areas; and

•

External routes: Routes that originate from other routing protocols, or different OSPF processes, and that are injected into OSPF through redistribution.



www.juniper.net


OSPF Area Types (contd.) Stub areas are areas through which, or into which, AS external advertisements are not flooded (LSA Type 4 and Type 5). You might want to create stub areas when much of the topological database consists of AS external advertisements. Doing so reduces the size of the topological databases and, therefore, the amount of memory required on the internal routers in the stub area. When you configure an area border router (ABR) for stub area operation, a default route is normally advertised in the place of the external routes that are blocked from stub areas. The default route provides routers in the stub area with reachability to external destinations. In the Junos operating system, ABRs require explicit configuration for default route generation. Note that you cannot create a virtual link through a stub area, and a stub area cannot contain an AS boundary router. A totally stubby area is a stub area that receives only the default route from the backbone. ABRs do not flood LSA Type 3, Type 4, or Type 5 into totally stubby areas. An OSPF stub area has no external routes in it, so you cannot redistribute routes from another protocol into a stub area. A not-so-stubby area (NSSA) allows external routes to be flooded within the area. These routes are then leaked into other areas. However, external routes from other areas still do not enter the NSSA. (ABR does not flood LSA Type 4 and Type 5 into an attached NSSA.)

www.juniper.net



Stub Area Operation The slide highlights the topic we discuss next.


www.juniper.net


Reduce LSDB Size The operation of an OSPF stub area reduces the size of the LSDB within that area by eliminating AS external routing information. When all of an area’s routers agree to operate in stub mode, the ABR stops forwarding Type 5 external LSAs into the area. The ABR also stops generating Type 4 summary LSAs, which are no longer needed because of the suppression of Type 5 external LSAs.

ABR Provides Reachability The routers within the stub area still might require IP reachability to the external routes they no longer have in their databases. A 0.0.0.0/0 default route generated by the ABR in the area accomplishes this reachability. Within the Junos OS, the advertisement of a default route does not occur automatically; this allows for better control of which ABR, if any, should be used for outbound traffic flows.

No ASBRs in a Stub Area Because the definition of a stub area does not allow the use of external LSA information within the area, no functional AS boundary routers can exist within a stub area. If any ASBR configuration exists, the router generates one or more Type 5 LSAs and places them into its local database. These external LSAs cannot be sent out any interfaces supporting stub operation, however. Continued on the next page.

www.juniper.net



No Virtual Links in a Stub Area For similar reasons, a stub area cannot support a virtual link because the area attached to the backbone through the stub area might require external LSA information. Because the transit routers cannot forward the Type 5 LSAs, the far-end area would not receive the correct information.


www.juniper.net


Stub Area Flooding Scopes In the example on the slide, Area 1 is now configured as a stub area. This configuration causes the ABR of Area 1 to stop forwarding the Type 5 LSAs from Area 0 and Area 3. Because the routers within Area 1 no longer have the external LSA information, they also no longer require the knowledge of any ASBRs in the network. As such, the Area 1 ABR stops generating Type 4 LSAs for reachability of the ASBRs in Area 0 and Area 3.

www.juniper.net



Further Reduces LSDB Size The operation of an OSPF stub area with no summaries further reduces the size of the LSDB within that area by also omitting Type 3 summary LSAs. This behavior has the effect of the routers within the area only having Type 1 router and Type 2 network LSAs in their databases. As noted previously, this type of area is known as a totally stubby area because a default route is now needed to reach AS external and interarea prefixes.

ABR Provides Reachability The routers within a stub area with no summaries still might require IP reachability to interarea and external routes that are no longer represented in their databases. A 0.0.0.0/0 default route generated by the ABR in the area accomplishes this reachability. Within the Junos OS, this advertisement is a manual step for the network administrator that allows for better control of which ABR, if any, should be used for traffic flowing to interarea or external destinations.

No ASBRs in a Stub Area As before, no functional AS boundary routers can exist within a stub area, regardless of whether summaries are permitted.

No Virtual Links in a Stub Area Like a stub area, a stub area with no summaries cannot support virtual links. Chapter 3–12 • OSPF Areas

www.juniper.net


Flooding Scopes for Stub Area with No Summaries The slide shows that Area 1 is still configured as a stub area as shown on a previous slide. In addition, Area 3 has now been configured as a stub area with no summaries. As discussed previously, the ABR of Area 3 has stopped forwarding the Type 5 LSAs from Area 0 and has also stopped generating the Type 4 LSAs from Area 0. In addition, Area 3’s ABR no longer generates Type 3 LSAs for the other OSPF areas. This fact has left the LSDB for Area 3 quite small. Another interesting phenomenon has occurred as well. Recall that one of the Area 3 routers previously acted as an ASBR. Although the ASBR portion of that router’s configuration did not change, its operation changed into a stub network. This change causes the router to generate Type 5 LSAs and place them into its own database. However, because all interfaces are now operating in stub mode, the router has no ability to forward them. As such, notice that the entire network has lost knowledge of the Type 5 LSAs from Area 3.

www.juniper.net



Stub Area Configuration The slide highlights the topic we discuss next.


www.juniper.net


Configuration on All Routers For an OSPF stub area to function successfully, you must configure each router in that area to treat the area as a stub. This configuration alters the E bit setting in the options field of the OSPF hello packet to notify all neighbors that the local router does not support external LSAs. An OSPF router only forms an adjacency with another router when the E bit values match—hence, the requirement that all routers agree on whether the area is a stub area.

ABR Injects a Default Route The ABR of the stub area can optionally inject a 0.0.0.0/0 default route into the stub area. Using the default-metric command accomplishes this task, which causes the ABR to generate a Type 3 summary LSA advertising the 0.0.0.0/0 route with the associated metric attached. The need to manually assign the metric before the default route is generated provides additional control. The administrator can control how, or if, traffic will leave the stub area by controlling which (if any) ABRs advertise a default route as well as the metric for that route.

www.juniper.net



Configuration on the ABR Only Because the ABR generates new Type 3 summary LSAs for injection into the areas it serves, you configure the no-summaries option only on ABR routers by adding the no-summaries command to the stub area’s stanza. Because non-ABR routers in the area do not require the suppression of Type 3 LSAs, you do not have to perform this configuration on those routers.

ABR Injects a Default Route The ABR of an area configured as a stub with no summaries can optionally inject a 0.0.0.0/0 default route into the stub area. Use the default-metric command to accomplish this task, as described on previous pages.


www.juniper.net


NSSA Operation The slide highlights the topic we discuss next.

www.juniper.net



Altering the Stub Area Behavior Much like a stub area, the operation of an OSPF NSSA assists the routers within that area by reducing the size of the LSDB. The main difference between a stub area and an NSSA is that external routing information, in the form of a Type 7 LSA, is allowed within the NSSA area. The ABR with the highest router ID converts the Type 7 LSAs into Type 5 LSAs and forwards them toward the backbone as if they had originated from an ASBR in a non-stub area. This process keeps knowledge of the NSSA contained within the area.

ABR Provides Reachability The routers within the NSSA might require IP reachability to the external routes from the backbone they no longer have in their databases. A 0.0.0.0/0 default route generated by the ABR in the area can accomplish this reachability. Within the Junos OS, this advertisement is a manual step for the network administrator, which allows for better control over which ABR should be used for outbound traffic flows. For an NSSA, the default route will be carried in a Type 3 LSA by default. The default route can be advertised in a Type 7 LSA by adding the type-7 option. Type 7 support is needed for backwards compatibility with Junos OS Release 4.4 and earlier.

No Virtual Links in an NSSA In a similar fashion to a stub area, an NSSA cannot support a virtual link. Again, the area attached to the backbone through the NSSA area might require external LSA information. Because the transit routers cannot forward the Type 5 LSAs, the far-end area does not receive the correct information. Chapter 3–18 • OSPF Areas

www.juniper.net


NSSA Flooding Scopes Area 3 now is configured as an NSSA. This configuration causes the ABR of Area 3 to stop forwarding the Type 5 LSAs from Area 0. Because the routers within Area 3 cannot use the external LSA information, they also do not require the knowledge of any ASBRs in the rest of the network. As such, the Area 3 ABR stops generating Type 4 LSAs from Area 0. Recall that an ASBR is configured within Area 3. To allow that routing information to be propagated to the rest of the OSPF domain, the ASBR generates a Type 7 LSA for these routes. Each of the routers in Area 3 now can forward these LSAs because they each are configured as an NSSA router. When the information reaches the Area 3 ABR, it performs a Type 7 LSA to Type 5 LSA conversion and injects the Type 5 LSA into the backbone. All other OSPF routers in the domain use the Type 5 LSA as normal and have no knowledge that the routes originated within an NSSA.

www.juniper.net



Disabling Export of LSAs into NSSAs Attached to ASBR ABRs When an ASBR is also an ABR with an NSSA area attached to it, a Type 7 LSA is exported into the NSSA area by default. If the ABR is attached to multiple NSSA areas, a separate Type 7 LSA is exported into each NSSA area by default. Type 7 LSAs are not exported into an NSSA if only one NSSA and backbone area are connected to the ABR. To disable exporting Type 7 LSAs into NSSAs, include the no-nssa-abr statement. This statement is needed on the ABR only.


www.juniper.net


Behaves Like Stub Area with No Summaries The operation of an OSPF NSSA with no summaries assists the routers within that area by further reducing the size of the LSDB. In addition to the ABR not forwarding Type 5 external LSAs, and not generating Type 4 summary LSAs, the ABR also stops flooding Type 3 LSAs into the NSSA. This process has the effect of the routers within the area having only Type 1 router, Type 2 network, and Type 7 (NSSA) LSAs in their databases.

ABR Provides Reachability The routers within the NSSA with no summaries might require IP reachability to routes they no longer have in their databases. A 0.0.0.0/0 Type 3 LSA is generated by the ABRs to provide this reachability, when so configured. The advertisement of a default route is a manual step for the network administrator, which allows for better control over which ABR (if any) should be used for outbound traffic flows. A Type 7 LSA can be used for the advertisement of the default route for compatibility with earlier Junos OS releases.

No Virtual Links in an NSSA with No Summaries Like a regular NSSA, an NSSA with no summaries cannot support a virtual link.

www.juniper.net



NSSA with No Summaries Flooding Scopes Area 3 is now configured as an NSSA with no summaries. In addition to the functionality described on a previous slide, the ABR of Area 3 stops generating Type 3 summary LSAs from Area 0.


www.juniper.net


NSSA Configuration The slide highlights the topic we discuss next.

www.juniper.net



Configuration on All Routers To operate an OSPF NSSA successfully, you must configure each router to participate. This configuration alters the N/P bit setting in the Options field of the OSPF hello packet to notify all neighbors that the local router does not support Type 5 external LSAs, but does support Type 7 external LSAs. An OSPF router only forms an adjacency with another router when the N/P bit values match—hence, the requirement that all routers perform the configuration.

ABR Injects a Default Route The ABR of the NSSA can optionally inject a 0.0.0.0/0 default route into the area. Within the default-lsa configuration hierarchy, the default-metric command accomplishes this. The command causes the ABR to generate a Type 3 summary LSA to advertise the 0.0.0.0/0 default route into the area with the configured metric.


www.juniper.net


Configuration Only on the ABR Because it is the job of the ABR to generate new Type 3 summary LSAs into the area, configuration takes place only on this router to create a no-summaries area. To configure an ABR to support a no-summaries configuration, apply the no-summaries command to the NSSA setting within the ABR. Because all other routers in the area do not require the suppression of a Type 3 LSA, you do not need configuration on those routers.

ABR Injects a Default Route The ABR of the NSSA no-summaries area can inject a 0.0.0.0/0 default route into the NSSA when the default-metric command is issued. This causes the ABR to advertise a default route with the configured metric.

Type 3 LSA Generated by Default When the NSSA is configured with the no-summaries command, the 0.0.0.0/0 default route is advertised using a Type 3 summary LSA. This behavior reflects a change in the default operation of the Junos OS starting with Release 5.0. To interoperate with older Junos OS versions (earlier than 5.0), a Type 7 LSA might be required. The type-7 command within the default-lsa hierarchy accomplishes this task, which causes the ABR to generate a Type 7 LSA advertising the 0.0.0.0/0 route with the associated metric. Continued on the next page.

www.juniper.net



Type 3 LSA Generated by Default (contd.) This Type 7 LSA is advertised using a Type 1 metric, which means that all routers calculate the cost to the ABR and add to it the advertised default metric. You can alter this behavior with the metric-type command within the default-lsa hierarchy. The Type 7 LSA is then advertised using a Type 2 metric, which means that each area router uses only the advertised metric of the route.


www.juniper.net


Route Summarization The slide highlights the topic we discuss next.

www.juniper.net



Local Area Routes Forwarded to Area 0.0.0.0 The default operation of an ABR is to generate a Type 3 summary LSA into the backbone area for each Type 1 and Type 2 LSA in the LSDB. The configuration of a stub area or stub area with no summaries does not affect this operation because a stub configuration only alters information that enters the nonbackbone area.

Route Summarization To reduce the size of the LSDB in Area 0.0.0.0 (and other remote OSPF areas), you can configure the ABR not to perform its default one-for-one mapping function. This is accomplished using an address range statement on the ABR with the area-range command. All Type 1 and Type 2 LSAs that fall within that address range will no longer be advertised individually into the backbone. Instead, a single Type 3 summary LSA is advertised. The metric associated with this summary route will be equal to the highest metric associated with the individual contributing routes. Because only the ABR performs this mapping function, you configure the area-range command on ABR routers only.


www.juniper.net


Type 7 External Routes Forwarded to Area 0.0.0.0 The default operation of the ABR for Type 7 LSA routes local to a nonbackbone area is to generate a single Type 5 external LSA for each Type 7 LSA in the LSDB. The configuration of an NSSA or an NSSA area with no summaries does not affect this operation because an NSSA configuration only alters information that enters the nonbackbone area.

Route Summarization To reduce the size of the LSDB in Area 0.0.0.0 (and other remote OSPF areas), you can configure the ABR not to perform its default one-for-one mapping function. You can configure an address range on the ABR by using the area-range command within the NSSA configuration hierarchy. All Type 7 LSAs that fall within that address range are not advertised individually into the backbone. Instead, a single Type 5 external LSA is advertised. Because only the ABR performs this mapping function, only the ABR is configured with the area-range command. Note that the area-range command referenced here is specific to the NSSA configuration hierarchy and only affects Type 7 LSA routes. The area-range command discussed in the previous slide was within the area hierarchy itself and affected Type 1 and Type 2 LSA routes. The configuration can have these two commands in place at the same time, and they will summarize different aspects of the local area routing domain.

www.juniper.net



Suppressing Routes The default action of the area-range command causes the generation of a single Type 3 summary LSA into the backbone for all prefixes that fall within the defined range. You can configure the ABR with the restrict keyword to block one or more prefixes from advertisement into the OSPF backbone. Such a configuration prevents routing information from each Type 1 and Type 2 LSA that falls within the address range from being advertised to the backbone, which in turn can block connectivity to those prefixes for routers in other areas. Use the restrict function when you want to prevent interarea routing, or when you want a default route to be used instead of the more preferred summary information that would otherwise be generated. Because only the ABR is responsible for this mapping function, you configure only ABR routers with the area-range restrict command.


www.juniper.net


The restrict Command Suppresses Routes The default action of the area-range command is to send a single Type 5 external LSA into the backbone. This functionality already alters the default OSPF protocol operation. You then can configure the ABR additionally with the keyword restrict. This keyword prevents routing information from each Type 7 LSA that falls within the address range from being advertised to the backbone at all. Because only the ABR is responsible for this mapping function, you must configure only the ABR with the area-range restrict command.

www.juniper.net



This Chapter Discussed: •

OSPF area types and operations;

•

How to configure various OSPF area types; and

•

How to summarize and restrict routes.


www.juniper.net


Review Questions 1. 2. 3. 4.

www.juniper.net



Lab 2: Configuring and Monitoring OSPF Area and Route Summarization The slide provides the objective for this lab.


www.juniper.net

Advanced Junos Enterprise Routing Chapter 4: OSPF Case Studies and Solutions



Three interior gateway protocol (IGP) transition strategies;

•

Transitioning between IGPs with minimal or no network disruption while maintaining network stability;

•

Configuring OSPF multiarea adjacencies;

•

OSPF external reachability; and

•

Configuring OSPF virtual links.

Chapter 4–2 • OSPF Case Studies and Solutions

www.juniper.net


IGP Transition Overview The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.juniper.net

OSPF Case Studies and Solutions • Chapter 4–3


IGP Transition Overview There are many reasons why you might decide to transition your network from using one IGP to using a different IGP. When you find it necessary to move from one IGP to another, you have several goals. Your primary goal is to end with a well-designed network. When you design a network well, the IGP design is an integral part of the network design. So, moving between IGPs often requires you to make some network design changes to create a well-designed network by the end of the transition process. Your secondary goal is to maintain network stability while transitioning IGPs. Your tertiary goal is to minimize downtime during the transition. This chapter does not directly teach good IGP design; rather, it focuses on how to maintain network stability and minimize network downtime during the transition.

Generic Transition Strategies While you might decide to transition your network from using one IGP to using a different IGP for many reasons, a common reason is to move from proprietary protocols (such as Extended IGRP [EIGRP)]) to protocols based on open standards (such as OSPF). In this chapter, we discuss generic transition strategies. The examples in the chapter show how to transition a network of routers running the Junos operating system from RIP to OSPF. However, the transition strategies are generic, and you can use them for any beginning and ending IGPs, and you can apply the concepts to routers running any operating system. Continued on the next page.


www.juniper.net


Common Elements The IGP transition strategies contain a few common elements. Every IGP transition strategy requires that you know which IGP provides the active routing information for the network at every point. You control this information in the Junos OS using route preferences. Additionally, most transition strategies require you to export appropriate routing information between the two IGPs so that you can ensure that all routers have access to full routing information.

www.juniper.net



Preferred Routing Information Sources The router uses route preference to differentiate routes received from various routing protocols or routing information sources. Route preference is equivalent to administrative distance on other vendors’ equipment. To ensure the routers make consistent routing decisions, you should set route preferences consistently on every router in the network (including other vendors’ routers).

Primary Tiebreaker The Junos OS uses route preference as the primary criterion for selecting the active route. Preference values cause routes from certain information sources to be ranked more preferably than the same route received from another information source. The table on the slide shows the default preference values for a selected set of routing information sources. Continued on the next page.


www.juniper.net


Lower Is Better Routing preference values are a 32-bit number that is 0 or higher. The router prefers lower preference values over higher preference values. This command output demonstrates that a direct route with a preference of 0 is preferred over an OSPF internal route with a preference of 10: user@router> show route 10.251.254.130/31 exact inet.0: 18 destinations, 19 routes (17 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 10.251.254.130/31

*[Direct/0] 1d 07:53:39 > via ge-4/0/0.0 [OSPF/10] 1d 07:53:32, metric 65 > via ge-4/0/0.0

www.juniper.net



Avoiding Exporting Problems You can cause problems when you indiscriminately export routes from one IGP to another. In particular, you can cause routing loops or route oscillation when you configure unconditional bidirectional exporting. On the slide, a network administrator is transitioning from one IGP (RIP) to another IGP (OSPF). In an effort to provide redundancy during the transition, the network administrator configures two routers on the border between the old and new IGPs and configures both routers to export all RIP routes to OSPF and export all OSPF routes to RIP. The slide shows the way the routers react when they receive a route through OSPF for the prefix 10.14.15.0/24. The OSPF route is an external Type 1 route with a metric of 100. When R1 and R2 receive the route, they install it in the routing table as the active route, export the route to RIP, and send a RIP advertisement. However, R1 accomplishes this process microseconds before R2. So, R2 receives the RIP route and installs it in the routing table. Because the routers in this network are configured to prefer RIP routes over OSPF external routes, R2 prefers the route it received from R1 through RIP. When R2 receives the route through RIP from R1, it installs it in the routing table as the active route, exports the route to OSPF (as an external Type 1 route with a metric of 1), and sends an OSPF link-state advertisement (LSA). When R1 receives the OSPF LSA, it examines the metrics and determines that the OSPF route through R2 is the best path to 10.14.15.0/24. It therefore installs that route as the active route in the routing table. It continues exporting this route to RIP, as it is configured to do. As you can see, this configuration has caused a routing loop to form! Continued on the next page. Chapter 4–8 • OSPF Case Studies and Solutions

www.juniper.net


Avoiding Exporting Problems (contd.) To avoid problems like this, you must configure bidirectional exporting very carefully. In particular, the safest way to configure bidirectional exporting is to configure very explicit export filters that only allow expected routes to be exported between each protocol. As you continue the transition, you must continually update these filters. In the example on the slide, the routing loop (and routing information loop) would continue even if the router that originally advertised the 10.14.15.0/24 prefix in OSPF ceased making the announcement. The only way you can end the routing loop is to break the exporting loop. Configuring filters to only allow expected routes to be exported between each protocol would end the routing information loop.

www.juniper.net



Overlay Transition In the overlay transition, you configure all routers in the network to run the new IGP while they are still running the old IGP. Once you verify the proper operation of the new IGP, you configure all routers in the network to stop running the old IGP. This transition strategy is appropriate when all routers have the necessary resources (in particular, CPU and memory) to run both protocols simultaneously. Additionally, you must accomplish any network redesign necessary to accommodate the new IGP as part of the transition.

Route Redistribution If all routers cannot run both protocols simultaneously or if you must make some topology changes as part of the IGP change, you can gradually migrate the network one portion at a time. For example, if you are migrating to OSPF, you might migrate one future OSPF area at a time. As you progress from one portion of the network to another, you must configure routers on the border of the two IGPs to conduct mutual route redistribution, exporting routes between the two IGPs. Continued on the next page.


www.juniper.net


Integrated If you must significantly redesign your existing topology to make it a well-designed network with the new IGP, the integrated strategy might be the best approach. In this strategy, you create a new network core running the new IGP, connect it to the old network core, and export routes between the new and old IGPs. You then gradually migrate connections from the old core to the new core.

www.juniper.net



Transition Case Study The slide highlights the topic we discuss next.


www.juniper.net


Sample Topology This slide shows the topology this chapter uses as an overlay example. We start off with a RIP network and then transition it to an OSPF network.

www.juniper.net



Step 1: Configuring Route Preferences You begin the overlay transition by configuring the router to assign the existing IGP a better (in other words, numerically lower) route preference than the new IGP. This configuration ensures that the router continues to use the existing IGP for routing information while you configure the new IGP.

Step 2: Configuring the New IGP You continue the overlay transition by configuring the new IGP on all routers. You should configure it with the target end state (or at least as close to the target end state as possible).

Step 3: Verifying Routing Information The next step in the overlay transition process is for you to verify that all routers are receiving full routing information through the new IGP. At the same time, you should verify that the router is making the routing decisions you expect and want it to make. Continued on the next page.


www.juniper.net


Step 4: Deleting the Old IGP The final step is for you to deactivate the old IGP on all routers, verify the proper operation of the new IGP, and delete the old IGP configuration. You should proceed from one end of the network to the other to ensure that any untransitioned routers are not in the path between two already-transitioned routers.

www.juniper.net



Overlay Transition Example: Step 1 This slide and the next few slides show an example of how you can transition the sample network from RIP to OSPF. The first step in the overlay transition is for you to configure the router to assign a better route preference to the existing IGP than the new IGP. By configuring the old IGP to have a better route preference than the new IGP, you avoid extra cleanup and verification steps at the end of the transition. If you instead configure the routers to modify the new IGP’s route preferences to be worse than the old IGP, you must remove the configuration that modified the new IGP’s route preference at the end of the transition process. Note that this removal might cause the router to make different route selection decisions in some cases. Therefore, you would really need to verify each router’s configuration and routing decisions after making this change. In general, you want to configure the new routing protocol as it will exist at the end of the transition and make any temporary changes necessary for the transition to the existing IGP’s configuration. For these reasons, it is best to begin by configuring all routers to assign the existing IGP a better route preference than the new IGP. Recall from the route preferences table that OSPF internal routes have a default preference of 10, so you must choose a preference for RIP routes that is numerically lower than 10. Also note that static routes have a default preference value of 5. Therefore, you want to choose a preference for RIP routes that is numerically higher than 5. In this case, you choose 7 and configure all routers using the command shown on the slide.


www.juniper.net


Overlay Transition Example: Step 2 The next step is for you to configure OSPF on all the routers. Because you configured RIP routes to have a lower preference, the routers will continue using the RIP routes. Therefore, configuring OSPF does not change the router’s routing decisions.

www.juniper.net



Overlay Transition Example: Step 3 Now that you have configured both routing protocols to run side by side, you should confirm that you are receiving the same routing information through both protocols. Note that the previous slide showed that you configured OSPF summary routes for the OSPF areas. Because of this configuration, you notice that the router is receiving summary routes through OSPF that it is not receiving through RIP (on the slide, R2 is summarizing 10.14.16.0/24 from Area 3). Likewise, the router is receiving more specific routes through RIP that it is not receiving through OSPF (on the slide, 10.14.16.0/27 and 10.14.16.64/27). Because each area border router (ABR) has full routing information for the area, you should ensure that each ABR is receiving the same routing information through both RIP and OSPF for the routes within each OSPF area.


www.juniper.net


Overlay Transition Example: Step 4 Once you verify that you are receiving the same routing information through both the old and new IGPs, you are ready to start using the new IGP. To do this, gradually deactivate the old IGP throughout your network. On a router running the Junos OS, you should follow the procedure on the slide. First, deactivate the protocol (allowing it to be quickly reactivated, should the need arise). Then, commit the configuration. If you are accessing the router in-band, you should use the commit confirmed command. Anytime you make major routing protocol changes using Telnet, it is always advisable to use commit confirmed to ensure that the router returns to a working state should a problem arise. After you confirm the router is still reachable and has full routing information, run the commit command again to confirm the configuration changes. After you are confident that you do not need to reactivate the old IGP, delete the old IGP’s configuration.

www.juniper.net



OSPF Multiarea Adjacencies The slide highlights the topic we discuss next.


www.juniper.net


Multiarea Adjacencies By default, a single interface can belong to only one OSPF area. However, in some situations, you might want to configure an interface to belong to more than one area. Doing so allows the corresponding link to be considered an intra-area link in multiple areas and to be preferred over other higher-cost intra-area paths. Beginning with Junos Release 9.2, you can configure a logical interface to belong to more than one OSPF area. As defined in RFC 5185, OSPF Multi-Area Adjacency, the area border routers establish multiple adjacencies belonging to different areas over the same logical interface. Each multiarea adjacency is announced as a point-to-point unnumbered link in the configured area by the routers connected to the link. For a given logical interface, it is considered as primary for one single area. To configure that same logical interface in additional areas, you must use the secondary option. In the slide, you can see that interface ge-1/0/0.0 has been configured in two areas, Area 0 and Area 1. Because the Area 1 interface has the secondary option set, the Area 0 occurrence is considered the primary.

www.juniper.net



Case Study Topology The slide displays the case study topology.


www.juniper.net


Link Failure In normal operation, if a link failure occurred between R1 and R3, traffic from R1 to R3 would flow from R4 to R2 and then to R3. This creates three hops to reach a router that was previously one hop away.

www.juniper.net



Link Failure with Multiarea Adjacency With multiarea adjacency configured, a hop to reach R3 is eliminated.


www.juniper.net


Adjacency Verification Verify adjacencies with the show ospf neighbor command.

Normal Trace For the case study, R3 is one hop away from R1.

www.juniper.net



Disable the Interface To test normal operations, disable the interface between R1 and R3.

Trace Under Link Failure The trace from R1 to R3 now takes a three-hop path.


www.juniper.net


Multiarea Adjacency Configuration When configuring multiarea adjacencies, keep in mind that you are assigning a single interface to at least two distinct areas: one as the primary, and the others as secondary using the secondary option. As stated previously, a given logical interface can be considered as primary for only one area. For any other areas in which you configure that interface, it must be set as a secondary interface.

Point-to-Point Interface The output shows that the ge-1/1/0.0 interface now appears in two distinct OSPF areas, Area 0 and Area 100. However, note the secondary link in Area 100 shows up as a point-to-point interface.

www.juniper.net



Adjacency Is Formed Two adjacencies are now formed over ge-1/1/0.0 for Area 0 and Area 100.

Trace with Multiarea With the multiarea adjacency feature configured, the trace now requires only two hops, compared with the default case of three hops.


www.juniper.net


External Reachability The slide highlights the topic we discuss next.

www.juniper.net



OSPF Default Export Policy Recall that any policy applied to OSPF affects only external routes that are either Type 5 or Type 7 LSAs. Because OSPF does not inject any external routes by default, the default export policy is to reject all routes. In other words, no external routes are sent without a routing policy applied.


www.juniper.net


Route Redistribution For route distribution to occur, an export policy must be written and applied. Because external routes in OSPF have an interarea flooding scope, the policies are applied globally. This feature allows external routes to be sent into all areas that allow it. When an external route is brought into OSPF, it appears as an external Type 5 LSA of Type 2. If an external LSA Type 1 must be configured, you can modify it with a policy.

www.juniper.net



Mutual Redistribution Special care must be taken when redistribution is configured in a network. When multiple redistribution points are present sub-optimal routing and loops could occur. Generally, if the source route has a lower preference than the protocol into which it is being redistributed, no issues occur. However, when the source route has a higher preference, issues can occur. Several methods exist to resolve these issues, but the easiest method usually involves modifying route preference values.


www.juniper.net


Case Study Topology The slide displays the case study topology that will be used in subsequent slides. R1, R2, and C1 are all running RIP.

www.juniper.net



Case Study Background The slide describes the goal of the case study. The goal is to advertise a single RIP route into OSPF as well as send a default route to RIP.


www.juniper.net


Create a Policy for the RIP Route The first step is to create a policy and apply the policy to OSPF. In this case, two match conditions are used, creating a logical AND. This policy will be applied to both R1 and R2 under the [edit protocols ospf] hierarchy by performing a set protocols ospf export redistribute-rip command.

Verify Policy Operation Verify that the policy is working by examining the database and finding the Type 7 associated with the RIP route.

www.juniper.net



ABR Translation Because the route was originated from the not-so-stubby area (NSSA), the ABR must convert the Type 7 LSA to a Type 5 for interarea advertisement.

Forwarding Address When the ABR translates the Type 7 into a Type 5, it places the address of the autonomous system boundary router (ASBR) into the forwarding address. This action supports optimal routing because only one ABR will translate the Type 7 LSAs to Type 5 LSAs in the presence of multiple ABRs. This router might not be in the optimal path for routers in other areas.

ASBR Summary The ABR also creates a Type 4 LSA to represent the ASBR to other areas.


www.juniper.net


Redistribution of Default Route The next step is to redistribute the default route from OSPF into RIP using an export policy under RIP. By default, RIP has a lower preference than OSPF external routes. Because RIP has a better preference, the default route for RIP is preferred. In the sample network, this preference creates a loop, because the OSPF routers point to the RIP router as their gateway, and the RIP router points to the OSPF ASBRs. To fix the loop, modify the OSPF external route preference to a lower value than the RIP route.

www.juniper.net



The Result The result of the preference change is now a default that points properly to the ABRs in the NSSA.


www.juniper.net


SPF Review After a router receives a new LSA and places it into the link-state database (LSDB), the router runs an algorithm known as the Dijkstra algorithm (also called the shortest-path-first [SPF] algorithm). This computation uses the database as a data source and results in a loop-free network topology using the best metric from the local router to all nodes in the network. During the course of this calculation, the algorithm uses three databases—the LSDB, the candidate database, and the tree database. As we have explored, the LSDB is the total compilation of routing knowledge in the network. Conceptually, it consists of multiple tuples in the form of (router ID, neighbor ID, cost), which describe each link in the network.

www.juniper.net



Import Policy An import policy can be applied between the tree database and the routing table. This allows filtering of routes from the LSDB to the routing table but it only applies to external routes, as in the case for OSPF export policy. Note that the database stays consistent and the import policy does not block any normal LSA flooding.


www.juniper.net


Flooding Protection Some OSPF implementations encounter problems when large numbers of external routes are injected into the LSDB. The Junos OS does not behave in this manner, however, and a large number of routes are handled without a problem. Although this protocol stability is a nice feature, a configuration mistake could make a portion of your network unusable as only routers capable of handling such large numbers would be operating effectively. To help you when a configuration mistake occurs, the Junos OS allows a limit to be placed on the number of external routes exported into OSPF. The prefix-export-limit command informs the router how many routes to accept using a routing policy configuration. The command accepts a 32-bit value, which provides a range of routes from 1 to 4,294,967,295. Once the route limit is reached, the router transitions into an overload state where the local links are set to a metric of 65,535 in the router LSA. Additionally, all Type 5 LSAs from the router are purged from the database and the network in general. The local router remains in this state until the number of external routes returns to a level below the configured limit. This situation requires the administrator to manually change the existing configuration; either the number of advertised routes must be reduced or the routing policy must be changed.

www.juniper.net



Modify Policy To see prefix limits in action, a policy is modified to send all RIP routes into OSPF.

RIP Redistribution This policy causes all RIP routes to be sent into OSPF.


www.juniper.net


Prefix Limit To stop the large amount of LSAs that could enter the router, a prefix-limit of six is configured.

The Result The result is that no RIP routes are distributed. This prefix-limit setting ensures that a configuration error does not affect your network.

www.juniper.net



Virtual Links The slide highlights the topic we discuss next.


www.juniper.net


Area Border Router Technically speaking, an ABR is a router that connects two OSPF areas together. In normal cases, ABRs will be connecting Area 0 to other areas. However, networks can actually function without an Area 0 and with only two areas. So, is this router an ABR? How does OSPF indicate its ABR status to other routers?

www.juniper.net



The Router LSA An OSPF router is an ABR when the b bit is set in the router LSA, also referred to as a Type 1 LSA. The slide indicates this setting by a bits field value of 0x1. The other bits in the field are used to indicate virtual links or ASBR routers.


www.juniper.net


Summary LSA One of the primary jobs of the ABR router is to generate summary LSAs into its attached areas. This function provides interarea connectivity for the non-ABR routers.

www.juniper.net



Adding a Third Area The scenario gets interesting when you connect a third area. In this case, Area 0 is connected to R5. As soon as R5 establishes an adjacency with Area 0, routes to R1 and R2 disappear from the routing table.


www.juniper.net


Summary LSAs Are Still Present Building on the previous slide and issuing a show ospf database netsummary command, the summary LSAs are present on R5 for R1 and R2. R5 is also generating summary LSAs for its attached areas as designated by the asterisk (*) in the output.

SPF Does Not Install the Summary LSAs Even though the LSAs are present in the OSPF database, a show ospf route command does not show the routes to R1 and R2. The SPF calculation is removing those entries in its decision tree. The loop detection mechanism in OSPF causes this action. Essentially, R5 will only accept summary LSAs from routers from the backbone. Because an ABR would have a full view of each connected area, and it does not see R1 and R2, it ignores the summary LSA.

www.juniper.net



Technical OSPF From the OSPF RFC 2328: “Area border routers: A router that attaches to multiple areas. Area border routers run multiple copies of the basic algorithm, one copy for each attached area.” (Section 3.3) Technically, you can create a multiarea OSPF network with no Area 0. However, we do not recommend this configuration because SPF will process all LSAs in all areas and the ABR loses its OSPF loop detection mechanism.

Functional OSPF In practice, an ABR should always be connected to Area 0. Because the ABR calculation is similar to a distance vector protocol when processing the Type 3 LSA, a loop avoidance mechanism must be in place. This requirement is met with an Area 0 and a rule that SPF will only process LSAs within that area database.


www.juniper.net


Acquisitions and Mergers Companies are acquired or merged with other companies every day. These mergers present many interesting challenges, including how to combine the IP networks into one network. For example, imagine two companies running OSPF that must merge networks. For OSPF to work correctly, each company must connect their respective Area 0s together to form a single contiguous backbone. At first glance, you might think the easiest solution would be to create new physical connections between the routers in each company. However, this is often easier said than done. In addition, time can be a deciding factor. For these cases, a temporary solution such as a virtual link can be deployed.

www.juniper.net



Case Study In this case study, Alpha Corp. has acquired Bravo Corp. Both networks are running multiarea OSPF and the integration team must get both networks communicating with each other.


www.juniper.net


Integration Case Study During the acquisition phase, an integration team is formed to look at all facets of combining the two corporations, including their OSPF networks. The determination is that connecting both Area 0 networks together with physical connections is not a viable short term option. An alternative solution must be used.

www.juniper.net



Initial Physical Connection The first step is to establish some physical connectivity between the two corporations. In this case, the integration team chose to connect Alpha Corp’s A6 router and Bravo Corp’s B4 router. For now, the new interface will be configured in Area 10 on the A6 and B4 routers.


www.juniper.net


Connectivity Issues As soon as the physical connection is created, limited connectivity is achieved. For example, the B6 router can now reach the A1 router in Alpha Corp’s Area 0. However, Alpha Corp’s Area 0 routers cannot reach Bravo Corp’s Area 0 routers. The cause of this limited connectivity is the lack of a contiguous Area 0 backbone.

www.juniper.net



Virtual Link One solution to the connectivity problem is to create a virtual tunnel between the two backbone areas of the corporations. This feature, known as a virtual link, provides a logical connection between areas. Essentially, OSPF packets are tunneled through a transit area to establish an OSPF adjacency and logically connect the two areas together. This establishes full connectivity between the two corporations. Remember that a virtual link is a control plane feature only. SPF will still calculate the shortest physical path between two points, which might not be the same path as the virtual tunnel. This calculation could create some confusion when troubleshooting, which is one of the primary reasons virtual tunnels are not considered long term solutions.


www.juniper.net


Virtual Link Established In this case, a virtual link is established between ABRs in each corporation. These ABRs must be attached to Area 0. In the slide, A4 and B2 were chosen as the ABRs on which to establish the virtual link.

www.juniper.net



Virtual Link Configuration The configuration of a virtual link takes place within the Area 0.0.0.0 portion of the OSPF hierarchy. The virtual-link command itself requires both a transit area and a neighbor ID to be configured. The transit area is the OSPF area through which you configure the virtual link. The neighbor ID is the 32-bit router ID (RID) of the router on the far end of the virtual link. Once each side completes this configuration, each router begins to send unicast OSPF traffic towards the far-end router to complete the link setup and form an adjacency.

Virtual Link as an Interface Once the two ends of the link can communicate, the virtual link becomes an operational OSPF interface. It appears in show commands and within the OSPF LSDB. It is always noted in a format of vl-neighbor-id, where vl denotes it as a virtual link, and the neighbor-id is the RID of the far-end router.


www.juniper.net


Contiguous Area 0 Once the neighbor is established over the virtual link, connectivity is restored, all LSAs are processed, and routes to each corporation are installed into the routing table.

www.juniper.net




Three IGP transition strategies;

•

Transitioning between IGPs with minimal or no network disruption while maintaining network stability;

•

Configuring OSPF multiarea adjacencies;

•

OSPF external reachability; and

•

Configuring OSPF virtual links.


www.juniper.net



www.juniper.net



Lab 3: Configuring and Monitoring Routing Policy and Advanced OSPF Options The slide provides the objectives for this lab.


www.juniper.net

Advanced Junos Enterprise Routing Chapter 5: BGP


This Chapter Discusses:

Chapter 5–2 • BGP

•

Basic Border Gateway Protocol (BGP) operation;

•

Common BGP attributes;

•

The route selection process;

•

How to alter the route selection process; and

•

Configuring some advanced options for BGP peers.

www.juniper.net


Review of BGP The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.juniper.net

BGP • Chapter 5–3


BGP Review BGP is a routing protocol between autonomous systems (ASs). It is sometimes referred to as a path-vector routing protocol because it uses an AS path as a vector to prevent inter-domain routing loops. The term path vector, in relation to BGP, means that BGP routing information includes a series of AS numbers, indicating the path that a route takes through the network. Although BGP is primarily used for inter-AS routing, BGP is also used in large networks for MPLS-based virtual private networks (VPNs) and is used to separate large OSPF domains. BGP is much more scalable and offers a greater amount of control through policy than an interior gateway protocol (IGP). BGP exchanges routing information among ASs. An AS is a set of routers that operate under the same administration. BGP routing information includes the complete route to each destination. BGP uses the routing information to maintain an information base of network layer reachability information (NLRI), which it exchanges with other BGP systems. BGP is a classless routing protocol that supports prefix routing, regardless of the class definitions of IP version 4 (IPv4) addresses. BGP routers exchange routing information between peers. The peers must be connected directly for inter-AS BGP routing (unless certain configuration changes are done). The peers depend on established TCP connections, which we address later in this chapter. BGP version 4 (BGP4) is essentially the only exterior gateway protocol (EGP) currently used in the Internet. It is defined in RFC 4271, which made the former standard of more than 10 years, RFC 1771, obsolete.


www.juniper.net


BGP Usage Networks with a single upstream connection receive little benefit from running a dynamic routing protocol with their Internet service provider (ISP). These customers typically use a static default route to send all external traffic toward the Internet. Their provider also typically uses a static route to direct traffic destined for the customer’s addresses to the customer. Normally, a single-homed network uses addresses assigned by the provider from the provider’s aggregate. Because these addresses are assigned to the provider and can only be used by the customer while they are a customer of the provider, they are known as nonportable addresses. Using these addresses allows the provider to announce a single aggregate route for many customer networks, reducing global routing table growth. Currently, the Internet routing table contains hundreds of thousands of routes, which highlights the need for a scalable and robust protocol such as BGP. BGP is normally used when a network has multiple upstream connections, either to a single ISP or to multiple ISPs. BGP’s policy controls provide the ability to optimize inbound and outbound traffic flows based on a network’s technical and business constraints. Although BGP can detect and route around failures in redundant environments, BGP sessions within the same AS do not typically react as quickly as an IGP, and they often rely on the IGP used in the AS to remain operational when failures occur. Networks that are multihomed to a single ISP likely use nonportable addresses assigned by the provider. Networks that are multihomed to multiple ISPs likely use portable addresses assigned directly by the regional address registry.

www.juniper.net



BGP Peers BGP supports two different types of exchanges of routing information. Exchanges between ASs are known as external BGP (or EBGP) sessions and handle inter-AS routing. Exchanges within an AS are known as internal BGP (or IBGP) sessions, and handle intra-AS routing. An EBGP peer connection is between a device in one AS and another device in a different AS. The connection between the two ASs consists of a physical connection and a BGP connection. The physical connection is a shared Data Link Layer subnetwork between the two ASs. On this shared subnetwork, each AS has at least one border gateway belonging to that AS. The BGP connection exists between BGP speakers in each of the ASs. This session can communicate destinations that can be reached through the advertising AS. The EBGP connection typically is established between immediately connected devices located in two different ASs because the time-to-live (TTL) value of the EBGP packets is equal to 1, by default. An IBGP connection is typically established between loopback interfaces of the routers not immediately connected (of course, everything depends on the topology of the AS). BGP uses the loopback interfaces for stability reasons—these interfaces are always alive, unless the router itself dies. Because the IBGP connection typically exists between remotely connected routers, there is a requirement for an IGP within the AS. BGP’s TCP session is established using regular routing tables.


www.juniper.net


BGP Peering Sessions Unlike other dynamic protocols, BGP requires that you manually define the neighbors with which you want the local device to peer. Because BGP peers must be manually defined, no automatic neighbor discovery exists as with other protocols. BGP uses TCP as its transport protocol (port 179). TCP provides a full-duplex, connection-oriented, reliable, byte-stream service to BGP. BGP considers a connection between two peers to be idle until a TCP connection is established between them. With the TCP connection established, the endpoints are assured of a reliable connection. The following list describes the various BGP neighbor states: •

Idle state: The Idle state is the initial state when all incoming BGP connections are refused. A start event is required for the local system to initialize BGP resources and prepare for a transport connection with the other BGP peer.

•

Connect state: In the Connect state, BGP is waiting for the transport protocol connection to be completed. If the transport protocol connection succeeds, the local system sends an OPEN message and transitions to the OpenSent state. If the transport protocol connection fails, the local system restarts the ConnectRetryTimer, listens for a connection initiated by the remote BGP peer, and changes its state to Active.


www.juniper.net



BGP Peering Sessions (contd.) This list is a continuation of the various BGP neighbor states from the preceding page:


•

Active state: In the Active state, BGP is trying to acquire a peer by initiating a transport protocol connection. If the transport protocol connection succeeds, the local system sends an OPEN message to its peer and transitions to the OpenSent state. If the local system’s BGP state remains in the Active state, you should check physical connectivity as well as the configuration on both peers.

•

OpenSent state: In the OpenSent state, BGP waits for an OPEN message from its peer. When an OPEN message is received, it is checked and verified to ensure that no errors exist. If an error is detected, the system transitions back to the Idle state. If no errors are detected, BGP sends a Keepalive message.

•

OpenConfirm state: In the OpenConfirm state, BGP waits for a KEEPALIVE or NOTIFICATION message. If no KEEPALIVE message is received before the negotiated hold timer expires, the local system sends a NOTIFICATION message stating that the hold timer has expired and changes its state to Idle. Likewise, if the local system receives a NOTIFICATION message, it changes its state to Idle. If the local system receives a KEEPALIVE message, it changes its state to Established.

•

Established state: In the Established state, BGP can exchange UPDATE, NOTIFICATION, and KEEPALIVE messages with its peer. When the local system receives an UPDATE or KEEPALIVE message, and when the negotiated hold timer value is nonzero, it restarts its hold timer. If the negotiated hold timer reaches zero, the local system sends out a KEEPALIVE message and restarts the hold timer.

www.juniper.net


BGP Message Types BGP processes a message only after the entire message is received. The maximum message size is 4096 octets; the smallest BGP message is a header without any data, or 19 octets. The following list details the BGP message types: •

Open message: The open message is sent once the TCP three-way handshake is complete. The open message initiates the BGP session and contains details about the BGP neighbor and information about supported and negotiated options.

•

Update message: BGP uses update messages to transport routing information between BGP peers. Depending on the receiving device’s routing policy, this routing information is either added to the routing table or ignored.

•

Keepalive message: BGP does not use keepalives at the Transport Layer. TCP fills this need. Instead, peers exchange keepalives as often as needed to ensure that the hold timer does not expire.


www.juniper.net



BGP Message Types (contd.) The following list is a continuation of the BGP message types from the preceding page: •

Notification message: BGP uses notification messages to signal when something is wrong with the BGP session. A notification is sent when an unsupported option is sent in an open message and when a peer fails to send an update or keepalive. When an error is detected, the BGP session is closed.

•

Refresh: Normally a BGP speaker cannot be made to readvertise routes that have already been sent and acknowledged (using TCP). The route refresh message supports soft clearing of BGP sessions by allowing a peer to readvertise routes that have already been sent. This soft clearing has some very specific uses when working with MPLS-based VPNs and adding new customer sites to existing customer VPN structures.

Each BGP message uses the same fixed size header, which is 19 bytes. BGP keepalive messages do not include any data portion following the header.


www.juniper.net


BGP Attributes The primary purpose of BGP is not to find the shortest path to a given destination; rather, its purpose is to find the best path. Each AS determines the best path to a prefix by taking into account its own outbound routing preferences, the inbound routing preferences of the route’s originator (as updated by ASs along the path between the source and destination ASs), and some information that is collected about the path itself. All this information is contained in path attributes that describe the path to a prefix. The path attributes contain the information that BGP uses to implement the routing policies of source, destination, and transit ASs. The slide lists some common BGP attributes. We cover the listed attributes in greater detail on subsequent pages.

www.juniper.net



High-Level BGP Example The example on the slide explains the operation of BGP at a very high level. Consider the way traffic is routed to Customer A. Customer A has a single connection to ISP A. ISP A has assigned Customer A a prefix (172.20.21.0/24) from its aggregate address range (172.20.0.0/16). Because Customer A is a single-homed network, it has a static default route to reach all destinations on the Internet through its connection to ISP A. Likewise, ISP A has a static route to reach Customer A’s prefix.


www.juniper.net


ISP A’s Network The slide highlights a portion of ISP A’s network. Internally, ISP A maintains reachability information for each prefix within its aggregate address range. Therefore, every router in ISP A has knowledge about the /24 prefix assigned to Customer A. This reachability information can be maintained by either an IGP or by IBGP. Even though ISP A has reachability information about each prefix internally, it advertises the aggregate prefixes externally only. Because other networks use the same path to reach all prefixes available on ISP A’s network, other networks do not need the more specific information. To reduce the size of the global routing table, ISPs typically do not transmit the prefixes of their statically routed customers to their peers; rather, they just transmit the aggregate prefixes from which their addresses are assigned.

www.juniper.net



ISP A Advertises Its Aggregate ISP A advertises its aggregate address range of 172.20.0.0/16 through BGP along with some information about the path to reach that route. One of these path attributes is the AS path, which is a list of the ASs through which the path to this aggregate passes. By examining the AS path, ISP B knows that the 172.20.0.0/16 network was originated within ISP A. ISP B then advertises the 172.20.0.0/16 prefix to ISP C. It updates the path attributes, including the AS path, when it transmits the route. ISP C further advertises this prefix to Customer B, again updating the path attributes when it transmits the route.


www.juniper.net


Customer B’s Aggregate Customer B is currently a single-homed network but is planning on adding a second connection to another ISP in the near future. Customer B advertises its portable /20 prefix to ISP C with an AS path, indicating that it was originated locally. ISP C sends the advertisement to ISP B, which sends it to ISP A, with each ISP updating the path attributes as it sends the route. ISP A does not have a BGP session to Customer A, so Customer A does not receive any routing information for Customer B’s prefix. However, receiving the route information is not necessary because Customer A has a static default route that directs all Internet-bound traffic to ISP A. Once the traffic reaches ISP A, ISP A follows the BGP-received route to Customer B.

www.juniper.net



Customer B Becomes Multihomed Customer B decides to add a connection to ISP B. Therefore, Customer B now advertises its prefix to both its providers. In this example, ISP B receives routing information for Customer B’s prefix both from ISP C and directly from Customer B. ISP B chooses one of the paths as the best path and places a corresponding route for the prefix in the routing table. It then advertises the prefix with the associated path attributes to ISP A. Because ISP B chose the path directly to Customer B as the best path, it advertises the path attributes associated with that advertisement to ISP A. Note that it advertises an AS path that reflects that it can directly reach Customer B and does not include any information about ISP C. Because the path through ISP C was not chosen as the best path, ISP B does not send ISP A any of the path attributes associated with the advertisement from ISP C. If ISP B ceases to hear the announcement about Customer B’s prefix directly from Customer B (for example, because the circuit fails), it will begin using the path it received from ISP C and will send updated announcements to its peers to reflect the new path. Although not shown on the slide, Customer B now also receives two advertisements for ISP A’s aggregate. It chooses one of those advertisements as the best path and installs a corresponding route in the routing table. We cover the path selection process and many of the BGP attributes in greater detail later in this chapter.


www.juniper.net


Loopback Peering You maintain only one IBGP session between each internal peer. The IGP is used to maintain reachability between the loopback addresses regardless of the physical topology, allowing the IBGP sessions to stay up even when the physical topology changes. The physical topology is relevant in one respect: each router along the path between BGP speakers must have enough information to make consistent routing decisions about packet forwarding. In many cases, this requirement means that all routers along all possible physical paths between BGP speakers must run BGP; however, in some networks, this requirement is not necessary.

Interface Peering Recall that EBGP sessions are simply BGP sessions between two routers in different ASs. When two EBGP peers have a single path between them, EBGP sessions are usually established over the shared subnet between two peers, using the IP addresses assigned to the interfaces on that subnet as the session endpoints. By establishing the EBGP session using the IP address assigned to the interfaces on the shared subnet, you gain many advantages. One of these advantages is that you prevent either AS from needing to maintain any routing information about the other AS (besides what it received through BGP). You also ensure that all traffic flows over this particular shared subnet.

www.juniper.net



Configuring BGP The slide illustrates the sample configuration. In this configuration example, we see some parameters defined under the [edit routing-options] and [edit protocols bgp] hierarchies. Under the [edit routing-options] hierarchy, we defined the system’s router ID (RID) and the local AS number. Optionally, you can configure the system’s local AS number under the global BGP hierarchy for a specific BGP group, or, for a specific BGP neighbor, use the local-as configuration option. When the AS number is configured at multiple hierarchy levels, the AS number specified at the most specific hierarchy level is used. The ability to specify different AS numbers at different hierarchy levels can be quite useful, especially when merging networks with different AS numbers. Because we are using loopback-based peering for the internal BGP group, we must reference loopback addresses in the related BGP configuration. In this case, the neighbor address is the remote peer’s loopback address. The local-address is the local device’s loopback address. If the local address is not specified, the system uses the interface address of the egress interface used to reach the referenced peer address. Because the peer is expecting to form an IBGP peering session using the 192.168.100.1 address, you must specify that address as the local-address in the configuration. Continued on the next page.


www.juniper.net


Configuring BGP (contd.) As mentioned on the slide, the session type determines whether the peering session is IBGP or EBGP. You specify an external session type for EBGP and an internal session type for IBGP. If you omit the session type, you must specify the peer-as number, which can be a remote AS number or the local AS number. If the specified AS number does not match the AS number defined on the router, BGP assumes the session type is external. If the specified AS number does match the AS number defined on the router, BGP assumes the session type is internal. The software notifies you if you did not include the required details, as shown in the following sample output: [edit protocols bgp] user@router# show group x100 { neighbor 10.1.1.1; } [edit protocols bgp] user@R1# commit [edit protocols] 'bgp' Error in neighbor 10.1.1.1 of group x100: peer AS number must be configured for an external peer error: configuration check-out failed

www.juniper.net



BGP Authentication All BGP protocol exchanges can be authenticated to guarantee that only trusted routing devices participate in the AS’s routing. By default, authentication is disabled. You can configure MD5 authentication. The MD5 algorithm creates an encoded checksum that is included in the transmitted packet. The receiving routing device uses an authentication key (password) to verify the packet’s MD5 checksum.


www.juniper.net


Hitless Key Rollover Hitless authentication key rollover allows users to choose the algorithm through which authentication is established. The user associates a keychain and an authentication algorithm with a BGP neighbor session. The keychain can include multiple keys. Each key contains an identifier and a secret. The key is also configured with a unique start time and an end time. To configure the authentication key, include the key-chain statement at the [edit security authentication-key-chains] hierarchy level, and specify the key option to create a key chain consisting of several authentication keys. You then reference this keychain name under the appropriate BGP level. In the example, the keychain is configured at the group level.

www.juniper.net



BGP Operations The slide highlights the topic we discuss next.


www.juniper.net


BGP Route Tables BGP uses three different storage tables known as Routing Information Bases (RIBs) as databases to maintain routing knowledge. A separate Adjacency-RIB-IN exists for each established BGP peer to store all routes received from that peer. RIB-LOCAL is where BGP stores routes used for traffic forwarding. A separate Adjacency-RIB-OUT table is also created for each established BGP peer to house the routes that are to be advertised to that peer.

BGP Active Routes BGP can move only active BGP routes in the routing table into the Adjacency-RIB-OUT tables and advertise them to BGP peers. In addition, BGP places only the single, best BGP path to each separate IP route destination in the RIB-LOCAL and Adjacency-RIB-OUT tables. At times, the best BGP path might not be advertised to a peer because of the local router’s routing table rules. For example, if the router knows about a particular route through both Intermediate System-to-Intermediate System (IS-IS) and BGP, the IS-IS route will be active in the local routing table because of the default Junos OS protocol preference values. Therefore, the BGP version of that route is not sent to any peers because BGP advertises only active routes (routes used by BGP). To override this default action, you can use the advertise-inactive command. This command always forces the advertisement of the single, best BGP path to any destination, regardless of whether the route is currently active in the local routing table or not.

www.juniper.net



Default BGP Advertisement Rules By default, only active BGP routes are advertised. The slide illustrates the default BGP advertisement rules. The rules are as follows: 1.

IBGP peers advertise routes received from EBGP peers to other IBGP peers.

2.

EBGP peers advertise routes learned from IBGP or EBGP peers to other EBGP peers.

3.

IBGP peers do not advertise routes received from IBGP peers to other IBGP peers.

The purpose of the advertisement rules is to prevent routing loops on a BGP network.


www.juniper.net


IBGP Route Propagation IBGP speakers send routes to their IBGP peers that they received from EBGP peers and routes that they originated themselves. IBGP speakers never send routes to IBGP peers that they learned from other IBGP peers. For all IBGP speakers in an AS to have consistent routing information, a full mesh of IBGP sessions must exist between all BGP speakers. Without this full mesh, some BGP speakers might not receive all the required routing information. In the example on the slide, a full mesh of IBGP sessions does not exist. R1 receives the announcement through an EBGP session. Because it is the best route it has for that prefix, it propagates the route to its IBGP peer R2. R2 also determines that route to be its best path for the prefix; however, it does not send the route to its IBGP peer R3. Because it received the route through IBGP, it cannot send the route to any IBGP peers. Therefore, R3 does not receive or install a route for the prefix advertised from AS 65502. This situation can be alleviated by adding an IBGP session between R1 and R3. (It is irrelevant whether the two routers are directly connected.) If IBGP routers readvertised IBGP routes to other IBGP peers, a loop would form. Because the AS path is not updated by each router, but rather only when the associated prefix is advertised to an EBGP peer, the AS path cannot be used to detect loops for BGP routes advertised within an AS. For this reason, BGP enforces advertisement rules that require the full-mesh peering of IBGP routers to ensure consistent routing information on all IBGP routers within the AS. Using route reflectors or confederations can also alleviate this situation, both of which can reduce or alleviate the full-mesh requirement. Route reflectors and confederations will be covered in a later chapter of this class. www.juniper.net



Hidden Routes One might expect all routes received from a BGP peer would be installed in the RIB-LOCAL table and be visible using the show route protocol bgp command. This is not always true. There are several reason why: •

The route might be a martian route;

•

An import policy might exist that prevents the route from being installed;

•

The route’s protocol next-hop might be unresolvable.

Unresolvable Next-Hop The number one reason for hidden BGP routes is an unresolvable next-hop. The BGP Update message contains a protocol next-hop IP address. If the router cannot resolve this address using its routing table, the route cannot be used and is not installed in the routing table. The number of hidden routes is always shown in the output of the show route command. To view the reason why routes are hidden, issue the show route hidden extensive command.


www.juniper.net


IBGP Next-Hop Propagation By default, the next-hop attribute attached to a route is unchanged as it passes through an AS. Because routers can use the BGP routes only if they already have a route to the next hop, you must either configure the routers to advertise external interfaces through the IGP or configure the routers to change the next-hop attribute attached to BGP routes using policy. When EBGP speakers send routes to a peer, they set the next-hop attribute to the interface they share with that peer. In this example, R1 receives a route from its EBGP peer with the next-hop attribute set to 172.24.1.1. R1 sends this route to R2 without changing the next-hop attribute. Therefore, to use this route, R2 either must know how to reach 172.24.1.1 through the IGP or static routing, or R1 must send the routes with a different next hop. You can send the appropriate external routes into the IGP, if wanted; however, using the next-hop self action in a policy has some advantages. Using the next-hop self action in a policy causes the router to send BGP routes to its peers using the same IP address it uses to establish that BGP session. For the BGP session to remain established, the peer must have a route to that IP address. Therefore, using next-hop self guarantees that a router’s peers can reach the next hop of the routes that router sends, as long as the BGP session remains established.

www.juniper.net



BGP Next-Hop Solutions Numerous ways exist to solve this BGP next-hop reachability problem, and five examples are listed on the slide. Some of these examples do technically solve the reachability issue but are not best practices in a networking environment. The most commonly used (and recommended) solution is next-hop self. With this solution, when a BGP router advertises an EBGP-learned route to an IBGP peer, it alters the BGP next-hop attribute. The next-hop attribute’s IP address of the remote EBGP peer is replaced with the IP address of the BGP router itself. Because the IBGP session was most likely established using the peer’s loopback address, this new BGP next-hop value is reachable, and the advertised BGP route can be used. We create next-hop self by using a policy to match specific routes with an action of changing the next-hop attribute value. The Junos OS then applies this policy as an export policy to any IBGP peers. The next two options listed (export direct routes and IGP passive) are almost identical in their results. The difference between the two is in the approach that each takes to provide reachability. With export direct, the IGP operating in the AS with a routing policy advertises the address assigned to the point-to-point link between the two EBGP peers to all IBGP peers. Continued on next page.


www.juniper.net


BGP Next-Hop Solutions (contd.) Export direct uses a Junos OS routing policy to retrieve the subnet information from the local routing table. Within inet.0, these networks are known as protocol direct. The policy matches these direct routes and accepts them. The Junos OS then applies this policy as an export policy to the local IGP. With IGP passive, the IGP is configured on the inter-AS link and advertises the interface addresses, but forms no adjacency (it’s passive). Both methods inject the interface addresses into the local routing table for the IGP to use. An IGP passive interface allows the local IGP to advertise the subnet on a particular interface without forming an adjacency at the IGP level to the remote EBGP peer. This has the advantage of not using a policy, but it requires explicit configuration for each interface and subnet address that you want to advertise. The last two options listed on the slide (static routes and forming an IGP adjacency relationship with the remote EBGP router) have some severe disadvantages, but they both work. Static routes have an inherent scalability problem. You must configure each IBGP router in the network for a single static route for each remote EBGP peer. The more EBGP peers in the network, the more static routes required. The more IBGP peers in the AS, the more places that additions and changes must be made. Clearly, this is not a real-world option. With regard to the full IGP adjacency between AS networks, while reachability information can be provided by forming an IGP relationship with the remote EBGP peer, this is not a recommended practice. This is because of the very trusting nature of the IGP protocols. Once this adjacency is formed, the protocol accepts any routing information told to it by the remote EBGP peer. This behavior is very dangerous because the remote AS might inject bad information into your network. In addition, this method potentially violates the entire idea of having autonomous (independent of the IGP) systems in the first place.

www.juniper.net



Load Balancing Options The slide highlights the topic we discuss next.


www.juniper.net


Router ID and Peer ID Ignored When you configure multipath on a BGP router, the selection algorithm ignores both the router ID and the peer ID selection criteria. Should multiple copies of a route reach those portions of the route selection process, BGP installs all copies into the local routing table. Each version is listed in the table with only one of them marked as active. This active route is the version of the route that would have been selected by the algorithm had the multipath option not been configured. However, the next-hop values for the nonactive routes are also listed as valid next hops for the active route. This listing allows the Junos default load-balancing options to be used. The Junos OS also utilizes the link bandwidth extended community to unequally load-balance traffic in conjunction with the multipath command. If used, data packet forwarding is performed in a proportional manner to the bandwidth advertised in the extended community. The multipath command allows multiple copies of a route from the same remote router. It also allows multiple copies of a route from two different routers in the same AS (either a local or remote AS). The entire concept centers around resiliency and redundancy. Continued on the next page.

www.juniper.net



Router ID and Peer ID Ignored (contd.) The slide shows the R1 router peering with two routers in AS 2—R2 and R3. Both of the AS 2 routers are advertising the same four routes. Currently, the versions of the routes from R2 (10.222.28.2) are selected and placed into the routing table. We have some clues as to this behavior by examining the output of the show bgp summary command. The route information from R2 shows 4/4/4/0, which means that the four received routes are active in the local routing table. R3, on the other hand, has route information of 0/4/4/0. Its four advertised routes are not active in the routing table.


www.juniper.net


Single Next Hop for All Routes The local routing table of the R1 router is shown on the slide. We see the four routes advertised from AS 2: 172.16.20.4/30, 172.16.20.8/30, 172.16.20.12/30, and 172.16.20.16/30. Each listing of the prefix contains two versions of the route. One route is from the R2 router (10.222.28.2), and this route is marked active (indicated by the asterisk). The other version of the route is from the R3 router (10.222.29.2), and it is not marked as active.

www.juniper.net



Configure multipath on R1 The configuration of the R1 router now contains the multipath command within the peer group for AS 2. After committing the configuration, we examine the contents of the local routing table. We still see the four routes advertised from AS 2, and each listing of the prefix still contains two versions of the route. As before, the routes from the R2 router are marked as active while the routes from the R3 router are marked as inactive. The effect of the multipath command on the routes from AS 2 is that the next hop for the routes from R3 (10.222.29.2) are now added to the version of the route from R2. The next-hop information for the inactive route version does not change in this environment. Because each active route now has two next hops in the routing table, the default Junos load-balancing process can be used. Each route has a single next hop selected, and this single next hop is placed into the forwarding table. All traffic for each route uses just that single next hop. The overall benefit of this system is the total amount of traffic sent from AS 1 to AS 2 can now be load-balanced over the two inter-AS links. In our small example, three routes are now using the 10.222.29.2 next hop, whereas just the 172.16.20.4/30 route remains with the 10.222.28.2 next hop. As more routes are announced between the AS networks, the selection of the next hops becomes more evenly distributed. Although not shown on the slide, you can also see the effects of using multipath in the output of the show bgp summary command. The route information from both R2 and R3 now appears as 4/4/4/0. The routes from R2 are active while the next-hop values from R3 are also being used to forward user traffic. Chapter 5–34 • BGP

www.juniper.net


BGP Multihop Peering The default for an EBGP connection is to peer over a single physical hop using the physical interface address of the peer. In some cases, it is advantageous to alter this default, one-hop, physical peering EBGP behavior. One such case is when multiple physical links connect two routers that are to be EBGP peers. In this case, if one of the point-to-point links fails, reachability on the alternate link still exists. You must take three extra configuration steps to accomplish a single BGP peering session across these multiple physical links. First, each router must establish the peering session with the loopback address of the remote router. You can configure this session using the local-address command, which alters the peer address header information in the BGP packets. Second, use the multihop command to alter the default use of the neighbor’s physical interface address. In addition, you can also specify a TTL value in the BGP packets to control how far they propagate. On the slide, we use a TTL value of 1 to ensure that the session cannot be established across any other backdoor links in the network. Third, each router must have IP routing capability to the remote router’s loopback address. As the slide shows, we often accomplish this capability by using a static route to map the loopback address to the interface physical addresses. Note that when multihop is configured, the Junos OS sets the TTL value to 64, by default. You can specify a TTL value explicitly when wanted to help limit the scope of the EBGP session. Note that a TTL value of 1 is sufficient to enable an EBGP session to the loopback address of a directly connected neighbor because the IP TTL is decremented for egress traffic only, and this traffic will be considered as destined for the local Routing Engine (RE).

www.juniper.net



Accepting Remote Next Hops In the Junos OS, if the next hop received from the single-hop EBGP peer is recognized as not sharing a common subnet, then the route is discarded. However, in some situations, you might have to configure a single-hop EBGP peer to accept a remote next hop with which it does not share a common subnet. To work around this limitation, you would normally configure this peer with the multihop option. When you configure a multihop session in this situation, all next-hop routes learned through this EBGP peer are labeled as Indirect even when they do share a common subnet. This situation breaks multipath functionality for routes that are recursively resolved over routes that include these next-hop addresses. Configuring the accept-remote-nexthop statement allows next-hop routes that share a common subnet to be installed as direct, restoring multipath functionality for routes that are resolved over these next-hop addresses. When you enable a single-hop EBGP peer to accept a remote next-hop, you must also configure an import routing policy on the EBGP peer that specifies the remote next-hop address. Note that you cannot configure both the multihop and accept-remote-nexthop statements for the same EBGP peer. Furthermore, you can use this option to force an IPv4 BGP peer to accept routes with an IP version 6 (IPv6) next hop.


www.juniper.net


Case Study: Accepting Remote Next Hops over a Single-Hop EBGP Session In this example, AS 1 is advertising two routes toward AS 2, 2.2.2.0/24 and its own aggregate of 192.168.0.0/20. When you enable a single-hop EBGP peer to accept a remote next hop, you must also configure an import routing policy on the EBGP peer that specifies the remote next-hop address. The R3 router has a BGP import policy in place to set the next-hop of the 2.2.2.0/24 route to 192.168.3.21. By using the accept-remote-nexthop option, along with the import policy, you allow R3 to accept the route and still enjoy the benefits of a multipath setup.

www.juniper.net



Case Study: Accepting Routes with IPv6 Next Hops over an IPv4 EBGP Peer In this example, we show how you can use the accept-remote-nexthop option, along with a BGP import policy, to accept routes from an IPv4 peer that have IPv6 next-hops. Normally, in this situation, the IPv6 routes would be discarded entirely.


www.juniper.net


Routes with Multiple Next Hops Within the context of a BGP network, both the multihop and multipath options can result in a route being installed in the local routing table with multiple next hops. As we previously discussed, this route allows the Junos OS to perform per-prefix load balancing as the total amount of traffic sent towards the destinations is spread across the multiple next hops. However, each route selects a single next hop for forwarding traffic, which is installed into the forwarding table on the Packet Forwarding Engine. The slide shows the BGP route of 172.16.20.4/30, which is active in the routing table. This route has two possible next hops it can use to forward traffic—10.10.1.2 and 10.10.2.2. It has currently selected the 10.10.1.2 next hop, which we verify in the forwarding table with the show route forwarding-table command. The router output shows this single next hop in the table with a type set to ucst, for unicast transmission.

www.juniper.net



Load Balancing You can alter the default behavior of the Junos OS to install a single next hop per route in the forwarding table with a routing policy. The policy should contain the action of then load-balance per-packet and be applied as an export policy to the forwarding table within the [edit routing-options] configuration hierarchy. After committing the configuration, we see the same 172.16.20.4/30 route in the routing table of the local router. The same protocol information is displayed and again, a single next hop has been selected. This selection mechanism is not affected by our load-balancing policy, so we cannot verify if it is working by examining the routing table. Instead, a look at the forwarding table shows the outcome of our policy. Both the 10.10.1.2 and the 10.10.2.2 next hops are listed as valid outbound interfaces for the 172.16.20.4/30 route. Traffic destined for this route is now forwarded across both available next hops using a microflow hashing algorithm. The default inputs to the microflow hash are the incoming router interface, the source IP address, and the destination IP address. You can modify the inputs to the hashing algorithm at the [edit forwarding-options hash-key family inet] configuration hierarchy. Specifying the layer-4 command at this configuration hierarchy incorporates Layer 4 source and destination port information into the hash key.


www.juniper.net


Path Selection and Configuration Options The slide highlights the topic we discuss next.

www.juniper.net



BGP Update Messages BGP update messages describe a single path and then list multiple prefixes that can be reached through this same path. BGP peers assume that this information is unchanged unless a subsequent update advertises a new path for a prefix or lists the prefix as unreachable. Updates can list any prefixes that are no longer reachable, regardless of the path associated with those prefixes. BGP peers use update messages to ensure that their neighbors have the most up-to-date information about BGP routes. BGP uses TCP to provide reliable communication, which ensures that BGP neighbors never miss an update. A system of keepalives also allows each BGP peer to ensure that its neighbor is still functioning properly. If a neighbor goes down, the BGP speaker deletes all routes learned from that peer and updates its other peers accordingly. BGP uses the information within the update messages, in particular the BGP attributes, to detect routing loops and determine the best path for a given destination prefix.


www.juniper.net


Summary of BGP Active Route Selection Before the router installs a BGP route, it must ensure that the BGP next-hop attribute is reachable and that no routing loops exist. If the BGP next hop cannot be resolved or if a loop is detected, the route is not evaluated through the BGP route selection process or installed in the route table. Before the Junos OS installs a BGP route in the route table, the route preference is evaluated. Recall that the route preference can be changed through policy, so the route preference can differ for the same prefix learned through different BGP paths. If the route preference for a BGP prefix learned through different BGP paths differs, the BGP route with the lower route preference is selected. Note that this evaluation occurs prior to the BGP selection process outlined on the slide. When a BGP route is installed in the routing table, it must go through a path selection process if multiple routes exist to the same destination prefix and the route preference is the same. The BGP path selection process proceeds in the following order: 1.

The router compares routes for the highest local preference (the only choice based on a higher, rather than lower, value).

2.

The router evaluates the AS-path attribute next, where a shorter path is preferred. This attribute is often a common tiebreaker for routes.

3.

The router evaluates the origin code. The lowest origin code is preferred: ( I [IGP] < E [EGP] < ? [Incomplete]).


www.juniper.net



Summary of BGP Active Route Selection (contd.) The following list is a continuation of the steps in the BGP path selection process from the preceding page:


4.

If any of the remaining routes are advertised from the same neighboring AS, the router checks the multiple exit discriminator (MED) attributes for the lowest value. The absence of a MED value is interpreted as a MED of 0.

5.

If multiple routes remain, the router prefers any routes learned through an EBGP peer over routes learned through an IBGP peer. If all remaining routes were learned through EBGP, the router skips to Step 9.

6.

If the remaining routes were learned through IBGP, use the path with the lowest IGP cost to the IBGP peer. For each IBGP peer, install a physical next hop(s) based on the following three rules: a.

BGP examines both the inet.0 and the inet.3 routing tables for the BGP next-hop value. The physical next hop(s) of the instance with the lowest Junos OS preference is used. Often, this means that BGP uses the inet.3 version of the next hop, through an MPLS label-switched path.

b.

Should the preference values in the inet.0 and the inet.3 routing tables tie, the physical next hop(s) of the instance in inet.3 is used.

c.

When a preference tie exists and the instances are in the same routing table, the number of equal-cost paths of each instance are examined. The physical next hop(s) of the instance with more paths is installed. This tie might occur when the traffic-engineering bgp-igp option is used for MPLS.

7.

BGP then uses the route advertised from the peer with the lowest router ID (usually the loopback IP address). When comparing external routes from two distinct neighboring ASs, if the routes are equal up to the router ID comparison step, the currently active route is preferred. This preference helps prevent issues with MED-related route oscillation. The external-router-id command overrides this behavior and prefers the external route with the lowest router ID, regardless of which route is currently active.

8.

The router then examines the cluster-list attribute for the shortest length. The cluster list is similar in function to an AS path.

9.

The router prefers routes from the router with the lowest peer ID.

www.juniper.net


passive Option By default, a local router initiates a BGP open message to the remote router to establish the session. The passive command stops this default action, and no open message is sent. The IP address and AS of the remote peer are still configured, but the remote router must initiate the BGP session.

allow Option The related option of allow also stops the sending of a BGP open message to the remote router. In addition, the allow command also relaxes the requirement of explicitly configuring the remote router’s IP address by allowing you to define a subnet range for connections. BGP processes any open message received from an IP address within the configured range and initiates a session with that remote router.

www.juniper.net



Limiting the Number of Prefixes Accepted By default, each BGP router accepts any number of routes sent from each of its peers. You might want to alter this default for either security or memory reasons. You can use the prefix-limit command to set a limit on the maximum number of routes received from any individual peer. Use the maximum option to set the total amount of routes able to be received. When a BGP peer sends more routes than allowed, the peering session is terminated and restarted immediately with the teardown option. The value that immediately follows the teardown option is a percentage of routes upon which the router starts to generate system log messages. You can halt the BGP peering session between the two routers for up to 40 hours by specifying a value (in minutes) with the idle-timeout option. In addition, you can specify a value of forever. This value requires you to intervene manually to restart the peering session.

Altering the Session Hold Time When two BGP peers establish their peering session, they negotiate the hold time for that relationship. By default, the Junos OS uses a value of 90 seconds to negotiate for the hold time of the session. The hold-time command allows you to alter this value from as short as 20 seconds to as long as 65,535 seconds (18 hours, 12 minutes, and 15 seconds).


www.juniper.net


Disabling Suppression of Route Advertisements By default, the Junos OS does not advertise the routes learned from an EBGP peer back to the same EBGP peer. In addition, the software does not advertise those routes back to any EBGP peer that is in the same AS as the originating peer. You can modify the default behavior with the advertise-peer-as command. Prior to Release 7.0, advertise-peer-as was the Junos default behavior.

www.juniper.net



Restart Capability Is Negotiated When a BGP router supports graceful restart, it can restart its routing process without causing a topology change event in the network. Thus, no routes are withdrawn or announced based on the restart event, which can avoid the network converging on a new topology. During the establishment of the peering session, the two routers negotiate the ability to support graceful restart. The restart mechanism is only used when the feature is supported by both peers. When the local router restarts its routing process its peer continues to forward traffic to it. In addition, the loss of keepalive messages from the local router does not cause the peer to withdraw the active routes from the restarting router. The restarting router signals its peers that it has restarted by setting the restart state bit in the capability announcement within the open message. The signal alerts the peer to retain the restarting router’s routes and not run the path selection algorithm. In addition, the restarting router might also set the forwarding state bit in the capability announcement as well to alert the peer that it might still forward user traffic through the restarting router. Continued on next page.


www.juniper.net


Use End-of-RIB Markers After the restarting router returns to service and the session is established again, the peers exchange their active routes with each other. When the last route is sent, an end-of-RIB marker is advertised to inform the peer that the process is complete. This marker is simply an update message with no withdrawn or advertised routes. The receipt of the end-of-RIB marker allows each router to run the path selection algorithm and select new active routes, if necessary.

Configuration Options The graceful restart capability within the Junos OS is controlled under the [edit routing-options] configuration hierarchy. The following configuration enables the restart functionality: routing-options { graceful-restart; } The graceful-restart syntax is also a configuration hierarchy within BGP, which contains three options specific to the operation within the protocol. Those options include the following:

www.juniper.net

•

disable: This option stops the local router from participating in any graceful restart function.

•

restart-time: This negotiable timer sets the amount of time that can elapse for the peering session to reestablish. The default value for this timer is 120 seconds, and its range is between 1 and 600 seconds.

•

stale-routes-time: This timer specifies the amount of time that routes from the restarting peer can be used before they are withdrawn. The default value for this timer is 300 seconds, and its range is between 1 and 600 seconds.



Modifying the Local Preference The Junos OS provides a configuration option within BGP that alters the local preference attribute value for all advertised routes. You can use the local-preference command at either the global, group, or peer level in the BGP configuration. All advertised routes will inherit this value for the local preference attribute. The exception to this rule are any routes whose attributes are modified by an applied routing policy. These routes abide by the action defined in the policy and take precedence over the configured value. In other words, the configuration option is applied before the routing policy is applied for all outbound BGP routes.


www.juniper.net


Eliminating Private AS Numbers In spite of the wording in the BGP RFC, many vendors include configuration options in their BGP implementations that remove information from the AS path, which, technically, is not allowed. This removal, however, only operates on specific information in the AS path attribute, and it does not apply to making arbitrary changes to the actual AS path. Typically, the information removed was placed there by the AS itself or by other routers within the administrative control of the AS. Thus, it is not a question of one AS trampling on the path information another AS has put into the AS path attribute. One example of this type of configuration option is the remove-private configuration statement. This keyword allows an ISP to remove private AS numbers from paths received from BGP customers when those customers are using private AS numbers. Because the customers are effectively within the administrative scope of the ISP, the provider is allowed to remove the private AS numbers from the path. In the slide, AS 1000 has three different customers connected using BGP. The customers are using AS 65001, AS 65002, and AS 65003 for the BGP peer communications. Within AS 1000, each of the BGP routers sees the private AS numbers within the path. Continued on next page.

www.juniper.net



Eliminating Private AS Numbers (contd.) The remove-private option is enabled on the edge router in AS 1000 that faces the Internet or other EBGP peers. As BGP advertises the customer routes out of AS 1000, the private AS numbers are removed from the AS path attribute. In this case, BGP views all customer networks as having originated within AS 1000. You should not use this option in a BGP confederation network. We describe why the remove-private option should not be used with BGP confederation in a subsequent chapter.


www.juniper.net


Modifying the AS Path Attribute: Part 1 Another option for removing AS path attribute information is the local-as configuration statement. The purpose of the local-as keyword is to aid an ISP in migrating BGP customers to a new AS number. Subsequent slides display an example of how you can use the local-as option. Consider the normal BGP AS path operation first. AS 1 has two customers for which it provides service: AS 222 and AS 333. As AS 1 announces these routes from AS 222 and AS 333 on to the Internet, AS 1 injects its own AS number (1) into the AS path attribute, as the BGP RFC expects. So far, there is nothing unusual about the AS path operation.

www.juniper.net



Modifying the AS Path Attribute: Part 2 Next, consider what happens if AS 1 merges with AS 777. This situation is shown on the slide. Suppose the resulting merged organization decides to use AS 777 as the official AS to represent both networks on the Internet. To ease in the migration of the customer BGP configurations from AS 1 to AS 777, the edge routers can use the local-as 1 configuration option. The effect of this option is that the customer routes within AS 777 see both AS 1 and the customer AS numbers (AS 222 and AS 333). As AS 777 advertises those routes to the Internet, it prepends its own value of AS 777 onto each of the routes. Therefore, even though AS 1 has been merged into AS 777, AS 1 still shows up on the paths sent to the Internet.


www.juniper.net


Modifying the AS Path Attribute: Part 3 You can use an optional parameter with the local-as configuration statement that actually does remove AS path information from the BGP AS path attribute. This optional parameter restricts knowledge of AS 1 to the edge router connected to the customer (AS 222 and AS 333) only. This situation is shown on the slide. On the slide, the edge router in the formerly intact AS 1 is configured with the option of local-as 1 private. As the edge router advertises the customer routes into AS 777, AS 1 information is removed from the AS path attribute, as shown on the slide. At this point, the AS 777 routers, as well as the Internet, have no knowledge of AS 1. The local-as 1 private statement now has indeed removed AS path information. Again, this example applies to a type of special case and should not be used arbitrarily to attempt to change AS path information received from another AS.

www.juniper.net



MED and IGP Metrics The Junos OS allows you to configure a MED value for all BGP routes to an individual peer, peer group, or all peers. The configuration statement uses the keyword metric-out and has several optional parameters. To set the MED to a static numeric value, use the metric-out value statement. We can see this option, setting the MED to 10, for the 192.168.2.2 peer. You can set the MED to match the internal IGP metric to reach the IBGP peer that advertised the route. Use the metric-out igp command to do this. As the IGP metric to this peer changes (up or down), the MED value associated with these routes also changes. We can see this option on the 192.168.3.3 peer on the slide. If the MED behavior of metric-out igp is undesirable, you can associate the MED to the lowest possible IGP metric ever known for the specific IBGP peer. The MED might decrease if the IGP metric lowers, but a network failure that increases the IGP cost will not increase the MED value. Use the metric-out minimum-igp command to do this. We can see this option on the 192.168.4.4 peer on the slide. Lastly, you can add MED values or subtract them in conjunction with both the igp and minimum-igp options. To alter the MED in this fashion, use the metric-out igp offset command. We can see this option on the 192.168.5.5 peer on the slide, which adds 5 to the MED based on the IGP metric. To subtract 5, use –5.


www.juniper.net


MED Default Behavior Within the Junos OS, the default action of BGP is to compare the MED values on routes from the same neighboring AS. This process of grouping routes into the advertising AS is known as deterministic MED selection and is currently considered a best practice in the Internet. To see the effect of the deterministic MED operation, consider the following three route announcements. Each of the announcements was received on the local router in quick succession (within 1 second) in the following order: #1 #2 #3

AS Path:65001 AS Path:65002 AS Path:65001

MED:200 MED:150 MED:100

From EBGP peer From IBGP peer From IBGP peer

IGP cost:5 IGP cost:10

Paths 1 and 3 were received from the same AS, so their MED values are compared. Path 3 has a better MED value, so path 1 is no longer considered. Path 3 is now compared against path 2. Both paths were received from IBGP peers, so the IGP cost of path 2 makes it the active path for the local router. Continued on next page.

www.juniper.net



Always Compare MED Values The always-compare-med configuration statement allows you to override the default BGP behavior for MED evaluation. When configured, BGP compares all routes to each other to determine the route with the smallest MED value, not just routes from the same AS. BGP then selects the route with the lowest MED value as the active BGP path, regardless of the neighboring AS the route came from. Be careful when comparing MEDs from different AS networks. Some inherent danger exists when using the always-compare-med configuration option to compare MEDs from more than one AS because every autonomous system in the Internet can set its own good and bad values for MEDs. One AS might consider a MED of 50 as the best, whereas another AS might consider a MED of 5 to be good. To complicate matters further, some AS networks might not set the MED value at all (they are optional), which essentially sets the MED value to 0. To see the effect of using the always-compare-med command, we again examine the following three route announcements. Each of the announcements was received on the local router in quick succession (within 1 second) in the following order: #1 #2 #3


MED:200 MED:150 MED:100



The MED values of all three paths are compared against each other. Path 3 has a lower MED value then the other two paths, so the local router installs Path 3 as the active path.

Emulate Cisco Default Behavior The cisco-non-deterministic configuration statement allows you to emulate the default BGP MED behavior of a Cisco Systems router. We do not recommend this configuration option for use in your network because it selects paths based on the order they are received. It is provided as a method of interoperability to aid in the consistent, although potentially incorrect, selection of routes in your network. When configured, the local router compares the received routes in the order they arrived. This process does not account for multiple paths through the same neighboring AS, which might lead to an incorrect route selection based on current best practices. You can see the effect of the cisco-non-deterministic command by once again examining the following three route announcements. Each of the announcements was received on the local router in quick succession (within 1 second) in the following order: #1 #2 #3


MED:200 MED:150 MED:100



Path 3 was received the most recently, so it is compared against the previously received path, Path 2. The IGP cost of Path 2 is better than Path 3, so Path 3 is no longer considered by the algorithm. Path 2 is then compared against Path 1, which was received first. Path 1 was received from an EBGP peer, whereas Path 2 was received from an IBGP peer. The EBGP-over-IBGP preference rule causes the path selection algorithm to prefer Path 1, which is then installed as the active path for the local router.


www.juniper.net



www.juniper.net

•

Basic BGP Operation;

•

Common BGP attributes;

•

The route selection process for BGP;

•

How to alter the route selection process; and

•

Configuring some advanced options for BGP peers.



Review Questions 1. 2. 3. 4. 5.


www.juniper.net


Lab 4: Implementing BGP The slide provides the objective for this lab.

www.juniper.net




www.juniper.net

Advanced Junos Enterprise Routing Chapter 6: BGP Attributes and Policy



Routing policy with BGP;

•

Default BGP route movement through router;

•

BGP attributes and common BGP attributes in detail; and

•

Manipulation of BGP attributes.

Chapter 6–2 • BGP Attributes and Policy

www.juniper.net


Policy and BGP The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.juniper.net

BGP Attributes and Policy • Chapter 6–3


BGP and Policy Dependency BGP is a very policy-oriented protocol, in the sense that import and export policies largely determine BGP behavior.

BGP Attributes and Policy The router can use all the BGP attributes. You can adjust these attributes to influence the behavior of the local router as well as other routers receiving the route.

Changing BGP Attribute Values You can use each of the BGP attributes as a match criterion for a policy, and you can modify each attribute using a policy action. You can further decide to act on a BGP attribute on whether it is an EBGP route or an internal BGP (IBGP) route. To understand better where BGP import and export policies are applied to BGP routes, we detail the process of how a router uses BGP routes. Continued on the next page.


www.juniper.net


BGP RIB Tables BGP uses three different storage tables, known as routing information bases (RIBs), as databases to maintain routing knowledge. A separate RIB-IN exists from established BGP peers to store all routes received from those peers. A RIB-LOCAL is where BGP stores routes used for traffic forwarding. A separate RIB-OUT exists for each established BGP peer to store routes to be advertised to that peer.

BGP and Active Routes Only active BGP routes in the routing table can be moved into the RIB-OUT tables and are advertised to BGP peers. In addition, only the single best BGP path to each separate IP route destination is placed in the RIB-LOCAL and RIB-OUT tables. At times, it is possible that the best BGP path is not advertised to a peer because of the local router’s routing table rules. For example, if the router knows about a particular route through both OSPF and BGP, the OSPF route will be active in the local routing table. This is because of the default Junos operating system protocol preference values. Therefore, the BGP version of that route will not be sent to any peers because BGP advertises only active routes (routes used by BGP). To override this default action, you can use the advertise-inactive command. This command always forces the advertisement of the single best BGP path to any destination, regardless of whether the route is currently active in the local routing table.

www.juniper.net



Import Policies and BGP BGP stores the information about routes received from BGP peers in the RIB-IN table. No policies are applied yet; all BGP routing information that is received is stored in this table except routes that fail autonomous system (AS) path or cluster-ID sanity checks, as well as virtual private network (VPN) routes that do not have a matching target community. As BGP moves the routes that it received from peers to the RIB-LOCAL table, the Junos routing policy framework can apply import policies. These policies can reject (filter) routes or can change attributes and affect what the BGP route-selection process uses to pick the best route. After the BGP import policy (if any are configured and applied) has filtered and manipulated the BGP attributes, the BGP decision process chooses the best route to use. The Junos OS then installs that route into the IP routing table and moves the route to the forwarding table. Note that even if no routing policies are configured, the default (and unseen) BGP import policy is always applied.


www.juniper.net


Sample BGP Import Policy The slide shows an example of BGP import policies in action. Some policies are configured that reject the default route (0/0) if received from AS 1, prefer the AS 1 version of 192.168.14.0/24, and accept all other routes from AS 3. These three policies, which might be three separate policies or a single policy with three terms, are configured as import policies for BGP. Import policy is evaluated as the BGP process attempts to move routes from the RIB-IN table to the BGP decision process, where the active route is selected. The result of this policy example is that the forwarding table correctly reflects the user’s desire to forward through AS 1 for traffic matching the 192.168.14.0/24 prefix and AS 3 for traffic matching the 0/0 default route. Note that the routing table will contain two entries for the 192.168.14.0/24 prefix; this is because the 192.168.14.0/24 prefix coming from AS 3 is not filtered in this example. The AS 1 version of this prefix is preferred and is installed in the forwarding table as a result. The overall effects of this policy example are summarized here:

www.juniper.net

•

The 0.0.0.0/0:AS 1 route is rejected.

•

The 192.168.14.0/24 route from AS 3 is accepted but not preferred.

•

The 192.168.14.0/24 route from AS 1 is accepted and preferred.

•

All other AS 3 routes are accepted.



Export Policies and BGP BGP stores the information about routes to be advertised to BGP peers in the RIB-OUT table. As BGP moves the routes from the RIB-LOCAL table to the RIB-OUT table, the Junos routing policy framework can apply export policies. These policies can reject (filter) routes and affect which BGP routes are advertised to BGP peers or can change the BGP attributes of advertised routes. In addition, the Junos routing policy can inject new routing information into the BGP routing process at this point.


www.juniper.net


Sample BGP Export Policy The slide shows an example of BGP export policies in action. Some policies are configured that reject the default (0/0) route, do not send some routes to AS 4, alter a BGP attribute on routes sent to AS 2, and inject new route information into the BGP process. These four policies, which might be four separate policies or one policy with four terms, are then configured as export policies within BGP. As the BGP routing process attempts to move those routes from the RIB-LOCAL table to the RIB-OUT tables, the Junos OS applies the export policies. The net result of this policy application is shown on the slide and here:

www.juniper.net

•

The 0.0.0.0/0:AS 3 route is rejected and is not advertised.

•

The 192.168.27.0/24:AS 3 route is only sent to AS 2.

•

The 192.168.14.0/24 route is sent to both AS 2 (with a metric of 10) and AS 4.

•

The 172.31.10.0/24 is sent to both AS 2 and AS 4.



BGP Attributes The slide highlights the topic we discuss next.


www.juniper.net


BGP Attributes A BGP prefix and its set of attributes is defined as network layer reachability information (NLRI). BGP attributes are a group of parameters that characterize a BGP NLRI. Thus a BGP prefix is defined by both its IP address and its set of BGP attributes. Attributes set BGP apart from other protocols. They give a network operator the flexibility to design a robust network and the tools to engineer a scalable routing policy.

Use in Routing Policy Attributes, combined with the extensive features of Junos routing policy, provide the ability to build a scalable set of rules that dictate whether a network wants to filter an incoming route or influence the path of a neighbor. Junos policy can match and manipulate the more commonly used attributes, as we will see in upcoming slides.

BGP Attribute Categories To ease the introduction of new BGP features, the BGP designers introduced a set of categories for router vendors to follow. All BGP attributes must fall into one of the four categories listed on the slide. This framework allows for new BGP features like 32-bit ASs or multiprotocol extensions with IP version 6 (IPv6), MPLS, or multicast backwards compatibility without affecting running networks. The next slide describes these categories in more detail.

www.juniper.net



BGP Attribute Categories: Part 1---Well-Known Mandatory An attribute set as well-known mandatory must be on every BGP update and passed along to all peers. If an update message does not contain an attribute in this category, it causes the peering to reset and send a missing well-known attribute message.

Well-Known Discretionary An attribute set as well-known discretionary must be understood by every BGP speaker, but it does not have to be in every update. If an update message contains an attribute in this category and is not understood, the connection is reset and an unrecognized well-known attribute message is sent.


www.juniper.net


BGP Attribute Categories: Part 2---Optional Transitive An attribute set as optional transitive does not have to be understood by every BGP speaker, but it needs to be passed to all peers. If an unrecognized attribute such as AS4_PATH is received, it can safely be ignored, but it MUST be sent to all neighbors.

Optional Nontransitive An attribute set as optional nontransitive does not have to be understood by every BGP speaker, and it must not be passed to any peer. If an unrecognized attribute such as MP_REACH_NLRI is received it can safely be ignored, but it MUST NOT be sent to all neighbors.

www.juniper.net



Details and Manipulation of Common BGP Path Attributes The slide highlights the topic we discuss next.


www.juniper.net


Common BGP Route Attributes The slide lists six common BGP attributes. In the following pages, we describe the uses of these attributes and the categories in which they fall.

www.juniper.net



BGP Attributes: Part 1---Mandatory Attribute The origin attribute must be understood by all BGP speakers and must be included in every BGP update.

Originating Router The router that first inserts the prefix into BGP adds the origin attribute. Origin is supposed to measure the credibility of the source of the route, but it is mostly used by the Junos OS as a way to influence traffic flow.


www.juniper.net


BGP Attributes: Part 2---Internal, External, or Incomplete The values available for the origin attribute include interior gateway protocol (IGP), exterior gateway protocol (EGP), or incomplete. The IGP origin attribute is allocated to prefixes originated by an IGP process such as OSPF. The EGP origin attribute is allocated for routes learned through the legacy EGP. The incomplete origin attribute is assigned to routes that do not fall under this category. IGP origin is better than EGP, and EGP is better than incomplete, in the route-selection process. The Junos OS sets all routes to IGP by default when it first inserts them into BGP. This process can be manipulated by policy.

www.juniper.net



Using the Origin Attribute to Influence Incoming Traffic In this example, AS 4 is using the default path to get to AS 1; this path is not modified by any of the ASs shown. AS 1 wants to influence this path to force downstream ASs to come through AS 3. AS 1 crafts a policy to set the origin attribute to Incomplete for all routes sent to AS 2. AS 4 now sees a more desirable path through AS 3 for prefixes originating in AS 1. AS 4 should still use AS 2 in case of a failure through AS 3.


www.juniper.net


AS Path: Part 1---Mandatory Attribute The AS-path attribute must be understood by all BGP speakers and must be included in every BGP update.

AS Path Contents The AS-path attribute contains the AS number of each system advertising the route, prepended to the beginning of the attribute. This behavior can be modified with routing policy.

www.juniper.net



AS Path: Part 2---Loop Prevention AS path is also used for loop prevention. If the AS number of a router receiving an advertisement is included in the AS path, the router drops this prefix. This behavior can be manipulated with the use of as-override and loops options in the Junos OS, which are used mostly in MPLS-VPN environments.

Manipulates Route Selection AS path is also used as a tiebreaker in the route-selection algorithm. The shorter AS path is installed as an active route before a longer AS path is installed. This process can be manipulated with policy.

Regex Support The Junos OS supports regex operators, which allows for flexibility when using matching conditions with routing policy.


www.juniper.net


Using AS Path to Influence Incoming Traffic As with our origin example, we will use AS-path manipulation to influence traffic into AS 1. AS 4 currently uses an arbitrary path to get to AS 1. AS 1 crafts a policy to set the AS-path attribute to prepend the AS twice with AS 1 for all routes sent to AS 2. AS 4 now sees a more desirable path through AS 3 for prefixes originating in AS 1. AS 4 should still use AS 2 in case of a failure through AS 3.

www.juniper.net



AS Path Regular Expressions: Part 1 Unlike other vendor implementations, the entire AS number signifies a term and not individual numbers in the AS path. The simple dot regex character (.) matches an entire AS number instead of just one number in the AS. This is a very important concept as you implement regular expressions into routing policy.


www.juniper.net


Regular Expression Operators: Part 2 The slide lists the regex operators used in AS path matching for policy.

www.juniper.net



Regular Expression Examples As shown in the slide, these examples further emphasize how an entire AS number represents one regex character. The examples also point out the flexibility regular expression matching has on crafting the desired routing policy.


www.juniper.net


AS Path Regular Expression Example: Part 1 In this example, we use regex AS path matching to influence outbound traffic. AS 15 is advertising 69.3.176.0/20 to all peers. AS 1 is receiving the route directly from AS 2, because of the shorter AS path, AS 1 is using AS 2 to get to AS 15. The administrators of AS 1 have requested that we start to use AS 3 to get to AS 15 because of unspecified reasons. Due to its powerful policy flexibility, BGP is the perfect protocol for such a request.

www.juniper.net



AS Path Regular Expression Example: Part 2 The route, from the perspective of AS 1, chooses AS 2 because of AS path length.

Regex Matching We use a regular expression match for an as-path named REGEX-TEST. AS 1 needs to match an AS beginning with 3 and ending with 15, with anything in between. Using the regex operators available, the matching criteria becomes “^3 .* 15$” . Using a policy named MATCH-AS, term 1 matches an as-path named REGEX-TEST and raises the local preference of the route, making it more desirable. (The local-preference attribute will be covered in subsequent slides.) By using local preference, we force the router to choose the route before it takes AS path into consideration.


www.juniper.net


AS Path Regular Expression Example: Part 3 After applying the MATCH-AS policy as an import policy on the EBGP neighbors, AS 3 becomes the active path toward AS 15. Because the policy matches only on routes originated from AS 15 and coming from AS 3, this policy should not affect any other routes.

www.juniper.net



Mandatory Attribute The next-hop attribute must be understood by all BGP speakers and must be included in every BGP update.

Next Hop Reachability A BGP speaker marks a prefix unusable if the BGP next-hop IP is not accessible. The router will perform a recursive IP route lookup for the address in the BGP next-hop attribute. If the BGP next-hop IP is not found in the local routing table, the BGP route is not installed into the routing table.

Default Behavior The BGP next hop is only changed by default when it is sent across EBGP sessions. In this case, the BGP next hop is set to the IP address of the neighbor that sent the route. For IBGP sessions, if the route is originated from an EBGP peer, the BGP next hop remains unchanged.


www.juniper.net


BGP Next Hop Example: Part 1 As mentioned in the previous slide, a BGP next hop is not changed on a route learned from an EBGP neighbor if it is sent to an IBGP neighbor. In the example, R1 is learning 8.3.99.0/24 from R3 in AS 2 and sending the route to R2. Because R2 does not have a route in the route table for the BGP next-hop 20.1.1.2 destination, it marks this route as hidden.

www.juniper.net



Next Hop Example: Part 2 Multiple ways exist to fix this problem. One very popular approach is to use policy to change the next hop to the IBGP router receiving the route (in this case R1). Another way is to use the IGP to introduce the BGP next-hop route into the AS, as in the example on the slide. R1 adds the interface facing R3 into the IGP (OSPF in this case) as passive, thus avoiding any advertisement of IGP hello messages toward the EBGP peer. R2 now has the route to the 20.1.1.2 BGP next-hop destination.


www.juniper.net


Optional Nontransitive Multiple exit discriminator (MED) is an optional nontransitive attribute; thus it does not need to be understood by any BGP speaker. In the case that it is not understood, it is not sent to any peers.

Stays in the AS MED is never passed across an AS. If a BGP router receives a route from an EBGP peer with a particular MED value, it does not pass this MED value to any EBGP neighbors, but it does pass this MED value to all IBGP neighbors.

Comparison Rules By default, a Juniper BGP router only compares MED values on routes coming from the same AS. This behavior can be changed by configuring path-selection always-compare-med or path-selection cisco-non-deterministic BGP commands.

Influence of incoming traffic The MED value can, however, be set by the EBGP speaker on an advertisement to an EBGP neighbor. Thus it can influence which path the neighboring AS will take to reach it. The lowest value is preferred, and by default the value is based on the IGP metric.

www.juniper.net



MED Example: Part 1 In this example, R1 and R2 receive 69.3.184.0/21 from R3 through OSPF. The metric on each route is based on the IGP interface cost to the destination. R1 has a 10 Mbps link and its metric to reach 69.3.184.0/21 is 10. R2 has a 100 Mbps link and its metric to reach 69.3.184.0/21 is 1.


www.juniper.net


MED Example: Part 2 By default, MED is based on the IGP metric. R4 sees the MED value based on the internal IGP metric value of AS 1. The R2 path is preferred on R4 because R2 has the better metric to the destination.

www.juniper.net



MED Example: Part 3 The Junos OS allows the MED value to be changed with policy. The metric (MED) value is changed to 100 on R2 in our example and applied as export to the EBGP peers. R4, in turn, receives a better metric from R1 now and prefers this path to AS 1.


www.juniper.net


Well-Known Discretionary Local preference is a well-known discretionary attribute. Local preference must be understood by all BGP routers, but is not required to be present on every BGP update.

Restricted to the AS Local preference is only used within an AS. The value is reset to the default value on an EBGP session, and maintains its value in an IBGP session unless it is manipulated by policy.

The Higher the Better Unlike MED, the higher the local-preference value the better. The default local-preference value is 100. It is a 32-bit field; therefore, the possible range is 0 to 4,294,967,295.

First Tiebreaker Local preference is the first tiebreaker for route selection, so the router looks at local preference before any other attributes when choosing a route. This fact, and the fact that local preference is sent to all IBGP peers, makes it a suitable tool in choosing an exit point.

www.juniper.net



Local Preference Example: Part 1 In this example, R1 and R2 are advertising 8.8.8.0/24 learned from AS 2 to their IBGP neighbors, with the default settings. Thus R3 chooses the path with the lowest RID, all other things being equal.


www.juniper.net


Local Preference Example: Part 2 Local-preference value can be changed directly under the [edit protocols bgp] hierarchy. This process can also be done with routing policy. In our example, we use a policy named local-pref to change the local-preference value to 50 for outgoing advertisements. This policy is applied as an export policy to the rest of the IBGP peers. You can also configure local preference directly on a neighbor, as shown in the following example: [edit] user@R1# show protocols bgp group IBGP-2 group IBGP-2 { type internal; neighbor 10.10.10.1 { local-preference 80;

www.juniper.net



Local Preference Example: Part 3 After this change is committed on R1, R3 now prefers the path toward R2 that has the default value of 100.


www.juniper.net


Community: Part 1---Optional Transitive The community attribute is not required to be understood or used by a BGP speaker, but it MUST be sent to ALL peers.

Aid to Administrative Policy One of the main roles for the community attribute is to tag a route or group of routes. A network operator then has the option to group common routes with a community tag, making the administrative routing policy more efficient and scalable.

www.juniper.net



Community: Part 2--Community Format The community attribute is encoded as a 32-bit value, where the first 16 bits represent an AS number and the remaining 16 bits represent an arbitrary number defined locally.

Well-Known Communities RFC 1997 defines three community values that are regarded to be well known and should be understood by all BGP speakers. This makes it easier to implement routing policy in multivendor networks. The No-Export well-known community allows routes to be advertised to neighboring ASs, but those ASs are prohibited from sending it further upstream. The No-Advertise well-known community allows routes to be advertised to immediate neighbors, but those neighbors are prohibited from sending the routes to any peers. The No-Export-Subconfed well-known community is used in networks that use BGP confederations. It allows routes to be advertised to sub-confederation ASs but those routers are prohibited it from sending it further.


www.juniper.net


Community Regular Expressions Unlike AS number regular expression matches, one number in a community signifies a term and not the entire community number. The simple dot regex character (.) matches one character. The slide lists the regex operators used in AS path matching for policy.

www.juniper.net



Regular Expression Examples The slide examples point out the possibilities regular expression matching has on crafting a desired routing policy.


www.juniper.net


Community Example: Part 1 In the example on the slide, AS 1 wants to prohibit advertisement of the 10.0.0.0/8 private network outside of the AS. We do not want to create any complex policies throughout the network to accomplish this simple task. The No-Export well-known community is a perfect candidate for this task.

www.juniper.net



Community Example: Part 2 We create a policy on R3 to tag the 10.0.0.0/8 prefix with the no-export well-known community. The policy is applied as an export policy to all our IBGP peers.


www.juniper.net


Community Example: Part 3 After the policy is applied, R1 and R2 learn the route with the no-export community. R1 and R2 honor the community and do not advertise this route to their neighboring AS. As we have shown, this can be accomplished without the need for complex policies.

www.juniper.net




Routing policy with BGP;

•

Default BGP route movement through router;

•

BGP attributes and common BGP attributes in detail; and

•

Manipulation of BGP attributes.


www.juniper.net


Review Questions 1. 2. 3. 4. 5.

www.juniper.net



Lab 5: BGP Attributes The slide provides the objective for this lab.


www.juniper.net

Advanced Junos Enterprise Routing Chapter 7: Enterprise Routing Policies



BGP in the enterprise network for internal connectivity;

•

Common Internet service provider (ISP) policies that determine policy design; and

•

Three common routing policies used for external connectivity in the enterprise environment.

Chapter 7–2 • Enterprise Routing Policies

www.juniper.net


Enterprise BGP Core Network Design The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.juniper.net

Enterprise Routing Policies • Chapter 7–3


BGP Strengths Routing Policy Control: BGP cannot simply be viewed as just a routing protocol, but as a policy definition device. One of the BGP designers’ intentions is to give flexibility in designing routing policy. This approach is in contrast to interior gateway protocols (IGPs), where the intent is to provide reachability and fast reconvergence. Diverse Administrative Control: BGP allows the configuration of autonomous systems (ASs) to scope network boundaries. The ability to define network boundaries with ASs allows a more flexible division of administrative duties to network personnel. Handling Large Prefix Counts: The nature of BGP as a distance vector protocol allows it to scale well in environments with large routing tables including the internet routing table. In comparison, most of the IGPs requirements of fast convergence and link state characteristics limit the amount of routes that can be handled.

BGP Weaknesses Increased Convergence Time: The strengths that BGP has do come with a price. Fast convergence is not one of the things BGP is known for. BGP timers can be tuned or network change notifications can be deferred to a protocol like Bidirectional Forwarding Detection protocol (BFD), but convergence is more efficient with an IGP. Increased Complexity: An important factor to point out is that BGP is not intended to replace an IGP completely. It is rather to act in complimentary fashion with an IGP. With this added layer, an enterprise will need more knowledgeable network personnel. Chapter 7–4 • Enterprise Routing Policies

www.juniper.net


When Should BGP Be Used in the Enterprise Core? When looking at a simple network as shown in the diagram, an IGP like OSPF should be sufficient in meeting the needs of the network. However, a network engineer can confuse justification for BGP with a poorly designed network. For example, if the network is growing in the number of individual sites an engineer might prematurely introduce BGP to scope out each site into their own ASs. This correctly scopes administration duties, but it also increases the complexity of the network greatly, to the point that introduction of BGP is going to do more harm than good. In a common enterprise network, an IGP like OSPF should be more than sufficient and the decision to introduce BGP or build an initial network with BGP should be a carefully vetted process with all the pros and cons discussed.

www.juniper.net



Using BGP in the Enterprise Different enterprises have different needs. As shown in the diagram, the complexity of an enterprise network can be quite daunting for any network engineer. In the network shown, not only is outside connectivity needed for the network; connectivity to data center resources, a demilitarized zone (DMZ), and remote sites connected with various WAN technologies are needed as well. Often, connectivity to internal resources such as voice application servers, storage servers, collaboration applications, and connections to different branch sites is more important than internet connectivity. BGP complemented with OSPF can meet the needs of a complex network. Using routing policy to engineer traffic, by utilizing the most optimized network path, can aid in the performance of real-time applications like voice and video. By setting up ASs, network engineers can delegate administration to the appropriate individuals. BGP can be used to haul the bulk of prefixes and use an IGP like OSPF for core connectivity between routers. This approach allows the network to take advantage of BGP to handle large prefix counts and use the IGP for fast convergence in case of any network issues.


www.juniper.net


BGP in the Enterprise Case Study This case study demonstrates the advantages and flexibility BGP gives an enterprise network. It is better to implement BGP sooner than later as long as the solution is elegant and fits your needs. This approach saves a lot of headaches with migration when the network is more sensitive to changes.

Enterprise, Inc. Goals The following goals are accomplished by implementing BGP for this network:

www.juniper.net

•

Better handling of large prefix counts;

•

Easier summarization of prefixes;

•

Scalability for easier introduction of complex routing needs;

•

Routing policy flexibility for traffic engineering; and

•

Additional administrative boundaries with private ASs.



Enterprise, Inc. Initial Topology As shown in the slide, this network has characteristics that make it a good candidate for implementing BGP. Based on the diagram, it appears that a solid IP numbering scheme exists for the remote sites, allowing for sequential summarization of common network subnets. Two slow links are connecting the R1 and R2 routers and the R3 and R4 routers, which will benefit from some routing policy to keep traffic off those links. Two multihomed sites are connected to the core: Site B is connected with two point-to-point WAN links, and Site A with a generic routing encapsulation (GRE) tunnel through the Internet and an MPLS WAN connection, increasing the complexity of the network


www.juniper.net

Advanced Junos Enterprise Routing .

Enterprise, Inc. Goals The following goals are met with this network design:

www.juniper.net

•

Advertise the minimum amount of prefixes from the remote sites to Site A and Site B;

•

Keep traffic off the 20 Mbps links between R1/R2 and between R3/R4, but still use these in case of outage;

•

Only use the GRE tunnel between Site A and R1 in case there are problems with the MPLS provider; and

•

Scope Site A and Site B to their own AS for ease of administration.



Enterprise, Inc. Topology with Solutions Highlights from the proposed topology include the following: •

Created a full internal BGP (IBGP) mesh within the enterprise core, complemented with OSPF for fast convergence and loopback peering;

•

Using private ASs, created EBGP peering to all of the remote sites including the MPLS WAN and GRE links; a range of 64512 through 65534 can be used for private purposes. Most MPLS WAN providers only give an option of BGP as the provider edge (PE) to customer edge (CE) protocol.

The individual goal solutions are laid out in detail in the next few slides.


www.juniper.net


BGP Case Study: Prefix Count—Part 1 Currently, Site A and Site B are receiving approximately 11,000 routes from each peering to the core. One of the goals of this design is to reduce the number of prefixes advertised to each site.

www.juniper.net



BGP Case Study: Prefix Count—Part 2 An aggregate route is created that overlaps the routes from remote Site A and remote Site B on both R3 and R4 routers that peer with Site A and Site B. A new routing policy is created with a term matching the newly created aggregate route and accept for the action. A second term is created rejecting all other advertisements. The policy is applied to the EBGP neighbors.


www.juniper.net


BGP Case Study: Prefix Count—Part 3 After the policy is applied on R3 and R4, Site A (which is connected to the MPLS cloud, which in turn connects to R3) only receives two prefixes. These prefixes include the 10.0.0.0/8 route, which represents the remote sites.

www.juniper.net



BGP Case Study: Prefix Count—Part 4 Site B receives one prefix from R3 and R4 after the policy is applied on those routers. We have now accomplished our goal of reducing the prefix count to Site A and Site B.


www.juniper.net


BGP Case Study: Traffic Engineer—Part 1 A majority of traffic between sites of Enterprise, Inc. is voice and video. This type of traffic is very sensitive to high latency and packet loss. To reduce the possibility of degraded performance of real-time traffic, one of the goals for Enterprise, Inc. is to reduce the amount of traffic that traverses the low bandwidth and high latency links between R1 to R2 and R3 to R4. These links can still be used in case of failure. The previous goal was to reduce the number of prefixes Site A and Site B. However, a side effect of this task is that now Site B has lost some visibility of the network. All things equal, Site B is going to choose the path to 10.0.0.0/8 based on which peer came up first.

www.juniper.net



BGP Case Study: Traffic Engineer—Part 2 As shown on the slide, Site B chooses the path toward R4 for destinations to 10.0.0.0/8. This action causes Site B to send traffic destined for 10.128.0.0/9 to R4 using the slow link between R3 and R4. The 10.128.0.0/9 belongs to remote Sites A, which is closer to R3.


www.juniper.net


BGP Case Study: Traffic Engineer—Part 3 The solution is to create more specific aggregates from each location. R3, which is closer to the remote Sites A, adds the aggregate route 10.128.0.0/9 to the already configured policy EXPORT-EBGP. R4, which is closer to the remote Sites B, adds the aggregate 10.0.0.0/9 to the same policy.

www.juniper.net



BGP Case Study: Traffic Engineer—Part 4 R3 now advertises the more specific path to the remote Sites A to Site B. Site B uses a more optimal path to get to the remote sites, avoiding the use of the 20 Mbps link.


www.juniper.net


BGP Case Study: Traffic Engineer—Part 5 For the return traffic from remote Sites A, the optimal path is chosen by default because of the better IGP metric. To avoid incomplete visibility of the network, it is best to keep aggregation of internal destinations to the minimum for the core routers.

www.juniper.net



BGP Case Study: Traffic Engineer—Part 6 In case of failure, Site B still has a path to the remote sites because R3 and R4 are still advertising the least-specific aggregate route 10.0.0.0/8. This design meets the goal of using optimal paths in the core and using slower links in case of outage.


www.juniper.net


BGP Case Study: Backup Link —Part 1 A common goal for any enterprise is to have 100% uptime for any critical site. One way to accomplish this goal is to provide a backup link. A backup link is set up in the form of a GRE tunnel from Site A to R1. The goal of this task is to have the backup link idle for traffic toward the remote sites and only activate the link in case of an outage in the MPLS WAN connection of Site A. An EBGP connection between Site A and R1 is set up to accomplish this goal.

www.juniper.net



BGP Case Study: Backup Link —Part 2 An aggregate 10.0.0.0/8 route is created in R1. A policy is created and the first term matches the aggregate; the action is to accept and expand the last AS 5 times. A second term is created to reject everything else to prevent R1 from advertising more specific routes. The policy is applied to the EBGP neighbor configuration on R1 to Site A.


www.juniper.net


BGP Case Study: Backup Link—Part 3 Site A shows the aggregate route as active, but not preferred, because of the longer AS path. The current path to the remote sites is through the MPLS WAN, as we intended.

www.juniper.net



BGP Case Study: Backup Link—Part 4 By mimicking a failure in the MPLS WAN, Site A activates the path toward R1 and starts using it to reach destinations located at the remote sites. This action accomplishes the goal of using the tunnel in case of failure.


www.juniper.net


BGP Case Study: Administration Scope Because of unique personnel in various remote sites at Enterprise, Inc., the engineering department needs a way to scope administrative duties depending on which geographical location the personnel are in. By choosing BGP, Enterprise, Inc. has made it easier to accomplish this goal by providing administrative boundaries in the form of ASs per remote site. As shown in the slide, Site A and Site B are divided into their own unique, private ASs.

www.juniper.net



BGP Case Study Summary To recap, all of our goals were accomplished using BGP. Keep in mind that most of the tasks in this case study can be accomplished by using various IGP techniques. IGPs have the ability to summarize, optimize routing with link metric and scope network boundaries in various ways. However as mentioned previously, IGPs were primarily designed as tools to provide reachability and fast convergence, in contrast to BGP, which was designed primarily as a tool for routing policy. Thus by using BGP for the solutions in this case study, we were able to provide the network with an elegant and scalable design for any future growth.


www.juniper.net


Enterprise External Network Deployment The slide highlights the topic we discuss next.

www.juniper.net



Common Enterprise Routing Policies Many different possibilities exist for inbound and outbound routing policies, but most enterprise routing policies fall into roughly three categories: topology driven, primary/secondary, and load-shared per prefix. We explain these categories in the following pages. Organizations choose routing policies to balance many interests, among them performance, reliability, and cost. Those decisions are generally policy decisions made by managers. It is the job of the network engineers to choose the correct routing policies to implement those policy decisions. Different inbound and outbound routing policies can be used to fill the needs of the organization. For example, you can use a topology-driven outbound routing policy while using a load-shared per-prefix inbound routing policy. Note that you can only influence—but not fully control—the way inbound traffic reaches your AS. Because BGP is a policy-driven protocol and each AS controls its own outbound routing policy, you can again only influence—but not control—the routing decisions other ASs make. To produce the desired result, you must think about your announcements from the perspective of other ASs (both ISPs and other enterprises). You must think about the likely ways the path attributes you attach to your announcements will affect their routing decisions.


www.juniper.net


Common Enterprise Topologies Enterprise networks that have only a single ISP connected to a single router generally do not need to worry too much about routing policy. In fact, they really do not even need to run BGP with the provider. Other enterprise networks can be summarized by one of the topologies shown on the slide. The effect of outbound routing policies might differ slightly depending on which of the topologies you have. In the following slides, we look at each of the routing policies, describe the effect of that routing policy on the topologies shown on the slide, and discuss how to implement it in the topologies.

www.juniper.net



Local Preference Many practices are fairly common among ISPs. Understanding these practices can affect the way we implement routing policies. Among these practices is the use of local preference to prefer certain routes over others. Usually, ISPs assign default local preferences such that customer routes are preferred over routes received from peers (or upstream ISPs). ISPs also usually accept certain communities from customers that cause them to set a different local preference. In general, several options are available between the default customer and peer values, and often, at least one option is available that is less than the default peer value. We can use these communities to further influence inbound traffic flow.

Prefix Length Most ISPs do not accept routes that are more specific (longer) than a /24 from either customers or peers. Some ISPs accept longer routes from customers, but they do not announce them to other customers or peers. Continued on the next page.


www.juniper.net


Filter Customer Routes by Prefix, AS Path, or Both An almost universal practice among ISPs is to apply rather strict import filters to their BGP sessions with customers. Most filters match on prefixes, whereas some filters match the AS Path (either in addition to, or instead of, a prefix match). Those filters that match on prefixes can perform an exact match, an orlonger match, or an upto match. Some ISPs provide automated mechanisms for updating these filters, whereas others rely on a manual process. You should understand your ISP’s filtering policies because they might impact the way you implement a routing policy.

www.juniper.net



Topology-Driven Routing Policies In these routing policies, all routes are accepted without attribute modification. Thus, the BGP path selection algorithm looks primarily at topological factors (such as AS path, multiple exit discriminator (MED), and the IGP metric) to determine the best route to send the traffic. This model should generally produce the best performance, but it is only appropriate when you have no preference about the way traffic enters or exits your AS.

Path Selection In this model, the router first tries to determine the best path for traffic to reach its destination. The router first looks at the AS Path length, which should give some indication of the total distance to the destination. If that length is tied between routers from the same next-hop AS, it compares MEDs to determine which path the next AS wants it to use. (Hopefully, the next AS is setting its MEDs to accurately reflect internal metrics.) If the router determines that two or more BGP-received routes are still tied in these values, the router must break the tie between these equally well-preferred routes. Once the router reaches this point in the decision algorithm, it simply tries to choose the closest exit. It does this by preferring EBGP-received paths over IBGP-received paths. If no EBGP-received paths exist, the router next tries to break the tie by choosing the IBGP path with the closest exit, as determined by IGP metrics.


www.juniper.net


Outbound Routing Policy The slide shows an example of a topology-driven outbound routing policy. We assume that Nails, Inc. is receiving a full Internet routing table from both providers. In this example, AS 65501 prefers to send traffic to the topologically closest exit. Note that the routers in AS 65501 make consistent exit decisions, causing R1 to send all traffic destined for Saws Corp. to R2, and R2 to send all traffic destined to Hammers, Inc. through R1. Thus, outbound traffic might flow between R1 and R2, which might raise the bandwidth requirements for this connection. Also, note that the quality of the ISPs involved is important in this model. If R1 is connected to a tier 2 or 3 ISP while R2 is connected to a tier 1 ISP, the likelihood is that many paths will be shorter through the ISP connected to R2. This scenario would result in most traffic exiting the network through R2, essentially creating a primary/secondary configuration.

www.juniper.net



Inbound Routing Policy This slide shows a topology-driven inbound routing policy from Nails, Inc.’s perspective. Nails, Inc. advertises its prefixes without any modification. Assuming the other networks shown are using a topology-driven outbound routing policy, the result is shown on the slide. Remember that you cannot control inbound routing, only influence it. Therefore, note that Saws Corp. could decide to send its traffic through ISP A, which would result in all the traffic from both Hammers, Inc. and Saws Corp. arriving through R1.


www.juniper.net


Path Selection If two paths to a destination have equal AS Path lengths and MED values (if the next AS is the same), the router simply tries to choose the closest exit from the AS. Once it gets to this point, one of the differences between having multiple border routers and a single border router becomes clear. In the case of multiple border routers, each border router prefers one of the EBGP-received announcements over any of the IBGP-received announcements. Thus, traffic bound for Drills, Inc. that reaches R1 is sent through ISP B, and traffic bound for Drills, Inc. that reaches R2 is sent through ISP C. This scenario should result in load sharing, depending on the IGP configuration. In the case of a single border router, the router prefers the oldest EBGP-received announcement, which results in the router preferring the most stable path to a destination. However, in periods of great stability (or immediately following a period of high instability, such as a router reboot), it also generally results in the router preferring a single connection for most routes with an equal AS path. This behavior results in somewhat imbalanced load sharing; however, this behavior should result in better performance over time (because it favors stable paths).

www.juniper.net



Primary/Secondary Variations A true primary/secondary routing policy has a single preferred ISP, over which all traffic flows while the connection to that ISP is up. Only when that connection is down does traffic flow over the secondary connection. Variations on the primary/secondary routing policy do exist that allow certain traffic to flow over the secondary link, even when the primary link is up. For example, you might want to allow traffic to or from customers of the secondary ISP to use that connection even when the connection to the primary ISP is functioning normally. Continued on the next page.


www.juniper.net


Assured Redundancy The main benefit to a primary/secondary routing policy is to provide reliability through redundancy. To be assured of true redundancy, you must always have enough bandwidth available to the secondary provider to fully accept the load of the connection(s) to the primary provider. The easiest way to guarantee this availability is to use connections of the same bandwidth to both the primary and secondary providers and to use a strict primary/secondary routing policy. This method ensures that you always have enough bandwidth in place on the secondary link to fully accept the load on the primary link. Implementing a strict primary/secondary model can also allow you to reduce the costs of the secondary connection. It is usually possible to negotiate a lower monthly fixed fee for a secondary circuit in return for accepting a usage-based bill. Provided that there are not extended outages to the primary circuit, this fixed fee will likely result in a lower cost for the secondary circuit than if you purchased two circuits and used them both.

www.juniper.net



Local Preference The best way to enforce a primary/secondary outbound routing policy is by modifying the local-preference path attribute. The router always selects the route with the highest local preference (regardless of AS path) as its preferred route to a destination. Therefore, setting a higher local preference on the routes using the primary path and a lower local preference on the routes using the secondary path should cause the router to always prefer the routes using the primary path. However, this setting does not necessarily mean that all traffic will flow through the primary path.

Single Versus Multiple Border Routers The primary/secondary configuration is the same whether you have a single border router or multiple border routers. The routers communicate local-preference values between them, resulting in a consistent routing decision.


www.juniper.net


More Specific Routes ISPs typically have slightly different sets of routes in their routing tables. For a variety of reasons (prefix length filtering, aggregation, and so forth), it is common for each provider to have a handful (or more!) of more-specific routes that other providers do not have. In the example on the slide, ISP B is sending both a /23 prefix as well as the two more specific /24 prefixes to AS 65501. ISP C is only receiving a /23 aggregate prefix from ISP B and, therefore, is only sending the /23 prefix to AS 65501. Because AS 65501 is configured to assign a higher local preference to routes received from ISP C, both R1 and R2 prefer the announcement for the /23 prefix that is being received from ISP C. However, because AS 65501 only has one announcement to each of the /24 prefixes, it prefers that announcement and installs routes to send traffic for the two /24 prefixes to ISP B, which effectively results in ISP B being the primary provider for the /23 prefix. To avoid this situation and to enforce a strict primary/secondary outbound routing policy, it is best to only receive a default route from each provider. Receiving the default route from BGP (instead of configuring a static route) causes the route to disappear when the link to your ISP becomes unusable. Additionally, this configuration matches your intention of always following the path to the primary ISP when it is available. Continued on the next page.

www.juniper.net



More Specific Routes (contd.) If you choose to receive only default routes, you lose a small amount of reliability. If AS 65501 receives full routes and instability exists within ISP C’s network, ISP C might stop advertising some specific routes, at which point AS 65501 would begin using the path through ISP B (provided it is not experiencing the same instability). However, in this scenario, there is no guarantee that ISP C will withdraw any announcements. (Examples exist in which ISPs have continued to advertise full Internet routing tables.) As usual, this scenario comes down to a trade-off between reliability and cost: the cost of sending small amounts of traffic to the secondary ISP versus the small reliability gain.


www.juniper.net


Loose Primary/Secondary In a loose primary/secondary routing policy, you make one ISP your primary ISP and another your secondary ISP, but you want to allow traffic to select prefixes to use your secondary ISP even in normal operations. To implement a loose primary/secondary outbound routing policy, you accept a default route from both providers, but you also accept announcements for some specific prefixes from your secondary ISP. Because you do not receive announcements for those specific prefixes from your primary ISP, your routers use the announcements you receive for these prefixes from your secondary ISP. In the example on the slide, AS 65501 is receiving the specific routes for some of ISP B’s customers. AS 65501 is preferring to send traffic to these prefixes through ISP B.

www.juniper.net



Sample Configuration: Strict Primary/Secondary Outbound The slide provides a sample configuration to enforce a strict primary/secondary relationship. The routing policies set the local preference appropriately and accept only a default route.


www.juniper.net


Sample Configuration: Loose Primary/Secondary Outbound The configuration example shown on the slide is the same as the strict primary/secondary example, except that we added the isp-b-customers policy to the import policy chain on the secondary-isp group. The isp-b-customers policy matches on a community that our provider adds to the path attributes of all BGP announcements originated by their customers. Because we allow the more-specific routes to be received from the secondary ISP only, the routers choose the secondary ISP as the best path for those prefixes. Because these routes are more specific than the default route that is received from the primary ISP, the router follows these routes to the secondary ISP when it receives them. If the secondary ISP fails, it follows the default route received from the primary ISP.

www.juniper.net



Local Preference and AS Path Prepending To ensure the correct operation of a primary/secondary inbound routing policy, it must be configured correctly. In particular, you must pay attention to normal operation, failure conditions, and failback (restoration from failure) conditions. To ensure correct primary/secondary inbound routing policy operation, you must often set the local preference within the provider’s network through the use of communities and also prepend the AS path of the announcements sent over the secondary path.

Single Versus Multiple Border Routers Where a single primary and a single secondary path exist, you configure the primary/secondary routing policy in the same way whether there are one or two border routers. When multiple, equally preferred primary and secondary paths exist, this routing policy takes on a mixture of the primary/ secondary and topology-driven routing policies. Because each situation is different, guidance with regard to the policy design of every combination is beyond the scope of this chapter. However, we can describe a way to approach the problem. The following slides, which describe the operation of the primary/secondary inbound routing policy, illustrate how to think about these design scenarios.


www.juniper.net


Sample Configuration: Primary/Secondary Inbound In the configuration on the slide, the announcements to the secondary ISP are prepended to Nails, Inc.’s own AS number three times. Additionally, a community is set that causes ISP B to assign a local preference value lower than the value assigned to the routes received from its peers and upstream providers. Note that Juniper Networks routers send communities by default, so no additional configuration is necessary to send communities to BGP peers.

www.juniper.net



Load-Shared Per-Prefix Routing Policies A load-shared per-prefix routing policy is really a primary/secondary routing policy, but you choose a different provider as primary for each prefix (or set of prefixes). Because different providers should be used for traffic to certain prefixes, this approach should lead to load sharing over multiple providers. Maintaining any sort of traffic parity over the various providers requires fairly consistent monitoring and adjustment during setup, as well as ongoing monitoring and adjustment as traffic patterns change. This traffic model is appropriate where cost dictates using multiple available links to the fullest extent possible. This model sacrifices the 1:1 redundancy found in the strict primary/secondary model and the performance found in the topology-driven model.

Single Versus Multiple Routers Once again, the configuration is the same whether you use one or more border routers; however, it is important to keep configurations synchronized between multiple border routers to ensure that each router is correctly marking the routes it receives.


www.juniper.net


Load-Shared Per-Prefix Outbound Routing Policy To implement a load-shared per-prefix outbound routing policy, you set a higher local preference for the specific routes within a large range for each provider. For example, this slide shows that Nails, Inc. chose to set a higher local preference on the routes within 0.0.0.0/1 from ISP B and to set a higher local preference on the routes within 128.0.0.0/1 from ISP C. If either ISP fails, the routes from the other ISP are used, providing reachability. However, without 1:1 redundancy, we cannot guarantee that there would not be performance problems during a failure.

www.juniper.net



Sample Configuration: Load-Shared Per-Prefix Outbound We can use the sample configuration on the slide to implement the scenario described on the previous page.


www.juniper.net


Load-Shared Per-Prefix Inbound Routing Policy To implement a load-shared per-prefix inbound routing policy, you take advantage of longest-match routing. You announce your aggregate prefix to all your providers, but you also announce a more specific prefix to each provider. As long as all providers are functioning, all routers on the Internet follow the more specific routes, resulting in traffic for each prefix using a different provider. However, if a provider malfunctions and does not successfully advertise one of the more specific routes, the routers on the Internet follow the aggregate prefixes to the closest ISP announcing it. Again, without 1:1 redundancy, there is no way to guarantee good performance during failure conditions. Note that your more-specific prefixes must be no more specific than /24 prefixes for those announcements to propagate through the Internet. Also note that some ISPs might enforce stricter filtering guidelines; however, if you are assigned portable address space by a regional registry, your aggregate prefixes should be accepted by all ISP filters on the Internet, which is yet another reason to announce the aggregate prefix along with the specific prefixes.

www.juniper.net



Sample Configuration: Load-Shared Per-Prefix Inbound We can use the sample configuration on the slide to implement the scenario described on the previous page.


www.juniper.net



www.juniper.net

•

The reasons to use BGP for internal connectivity;

•

ISP policies that affect external connectivity; and

•

Three common routing policies for external connectivity in the enterprise.





www.juniper.net


Lab 6: Implementing Enterprise Routing Policies The slide provides the objective for this lab.

www.juniper.net




www.juniper.net

Advanced Junos Enterprise Routing Chapter 8: Introduction to Multicast



Basic multicast terminology;

•

Multicast address space;

•

Multicast reverse path forwarding (RPF); and

•

Basic Internet Group Membership Protocol (IGMP) functionality.

Chapter 8–2 • Introduction to Multicast

www.juniper.net


Overview of Multicast The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.juniper.net

Introduction to Multicast • Chapter 8–3


Address Types and Traffic Flow IP version 4 (IPv4) has three fundamental types of addresses: unicast, broadcast, and multicast. You use a unicast address to send a packet to a single destination, a broadcast address to send a datagram to an entire subnetwork, and a multicast address to send a datagram to a set of hosts that can be on different subnetworks who are members of a multicast group. A multicast datagram is delivered to destination group members with the same best-effort reliability as a standard unicast IP datagram. Thus, multicast datagrams are not guaranteed to reach all members of a group or to arrive in the same order in which they were transmitted. The only difference between a multicast IP packet and a unicast IP packet is the presence of a group address in the IP header destination address field. Individual hosts can join or leave a multicast group at any time. There are no restrictions on the physical location or the number of members in a multicast group. A host can be a member of more than one multicast group at any given time and does not have to belong to a group to send packets to members of a group. As shown on the slide, the use of multicast can dramatically reduce traffic loads when multiple hosts want to receive the same content.


www.juniper.net


Benefits of Multicast As shown in the previous slide, the use of multicast to deliver content to remote hosts greatly reduces the load on both the server that is generating the content as well as the network bandwidth usage.

Usage of Multicast Interest in multicast as a content delivery mechanism has increased over the last few years. Because the functionality of multicast is very similar to broadcasts from a radio or television station, it makes sense that many radio and television companies are showing interest in using multicast-enabled IP networks to deliver their content. Multicast is now widely deployed in enterprise networks for such applications as company meetings by video and distance learning.

www.juniper.net



Multicast Terms: Part 1 The slide describes some of the common terms used in multicast. •

Source: A multicast source is any device that originates multicast IP packets.

•

Multicast IP Packet: A multicast packet is any IP packet that is destined to a multicast group address. The same packet should have a unicast source address. Generally, a multicast packet uses User Datagram Protocol (UDP) and/or Real Time Protocol (RTP) as its transport protocol. There are no guarantees that packets will be received by all members of a group. One protocol, Pragmatic General Multicast (PGM), has been developed to add loss detection and retransmission capabilities to multicast.

•

Group Address: A multicast group address is an IP address in the range of 224.0.0.0/4.

•

Receivers: A multicast receiver is any host that is interested in receiving multicast packets. A receiver uses the IGMP protocol to inform the directly connected router of this desire to receive multicast packets.

•

Designated router (DR): The DR is the router closest to the source or receiver that will forward multicast packets into the network. If there are two or more routers attached to the source or receiver, only one will ever become DR based on some sort of election algorithm that depends on the multicast routing protocol being used.


www.juniper.net


Multicast Terms: Part 2

www.juniper.net

•

Group membership protocol - A group membership protocol is used by receivers to inform the directly connected router of an interest in receiving packets for one or more multicast group address. That is, the host is informing the router of its desire to become a member of a multicast group. IGMP is used by IPv4 hosts and routers for this purpose. Multicast Listener Discovery (MLD) is used for IPv6. This course covers IPv4 multicast only.

•

Multicast Routing Protocol - A multicast routing protocol is used between routers to build and maintain the multicast forwarding trees between sources and receivers. The following slides will describe the basic functionality of a multicast routing protocol. The two most common multicast routing protocols are Protocol Independent Multicast (PIM) and Distance Vector Multicast Routing Protocol (DVMRP).



(S,G) State The forwarding path built from receiver up to source is stored and maintained in the routers as an (S, G) forwarding state (S comma G). S indicates source address and G indicates group address. Dense Mode protocols always maintain (S,G) state. Sparse Mode protocols only maintain (S,G) state after the receiver router learns about the source.


www.juniper.net


(*,G) State When the source is not known, a source tree can not be built yet. If a receiver requests to receive traffic for a particular group but does not specify a specific source, the routers will need to build a tree towards an unknown source. PIM Sparse Mode’s (PIM-SM) solution to this problem is to have a meeting point for sources and receivers in the network. This meeting point is called a rendezvous point (RP). The tree built from the receiver to the RP in the network is called a shared tree (because it is shared by all sources). The forwarding path built from the receiver router to the RP is kept as (*,G) forwarding state (* comma G). The * indicates any source and the G indicates the group address.

www.juniper.net



Multicast Addressing The slide highlights the topic we discuss next.


www.juniper.net


Multicast Addresses Multicast group addresses are defined to be the IP addresses whose four high-order 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.

www.juniper.net



Reserved Ranges The following list comprises the reserved multicast address ranges: •

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.

•

GLOP addressing: The range of 233.0.0.0/8 is a statically assigned range of multicast addresses based on a network’s autonomous system (AS) number. For each AS, 255 unique multicast addresses are available for the global use of that AS.

•

Source-specific multicast (SSM) addressing: The range of 232.0.0.0/8 is dedicated for use with SSM. SSM will be covered in-depth in the next chapter.

•

Session Description Protocol (SDP)/Session Announcement Protocol (SAP) addressing: The range of 224.2.0.0/16 is used to send and receive multimedia session announcements. Session Directory tool (SDR) is a common application that uses SDP/ SAP. These protocols do not scale well and are not recommended for deployment on the Internet because of a potential denial of service (DoS) attack vector that they open.


www.juniper.net


Address Mapping IANA has been allocated a reserved portion of the IEEE-802 Media Access Control (MAC) layer multicast address space. All of the addresses in IANA’s reserved block begin with 01-00-5E (hexidecimal). 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 a 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 IANA’s reserved address block.

www.juniper.net



Address Mapping Example This slide illustrates how the multicast group address 224.10.8.5 (E0-0A-08-05) is mapped into an Ethernet (IEEE-802) multicast address. The mapping places the low-order 23 bits of the IP multicast group ID into the low-order 23 bits of the Ethernet address. The mapping can place up to 32 different IP groups into the same Ethernet address because the upper 5 bits of the IP multicast group ID are ignored. For example, the multicast addresses 224.138.8.5 (E0-8A-08-05) and 225.10.8.5 (E1-0A-08-05) would also be mapped to the same Ethernet address (01-00-5E-0A-08-05) used in this example. When the sender and receivers are members of the same subnetwork, or LAN, the transmission and reception of multicast frames is a relatively simple process. The source station simply addresses the IP packet to the multicast group, and the driver maps the Class D address to the corresponding IEEE-802 multicast address before the frame is sent. Receivers that want to capture the frame notify their IP layer that they want to receive datagrams addressed to the group. Things become more complicated when the sender is attached to one subnetwork and receivers reside in different subnetworks. In this case, the routers must implement a multicast routing protocol that permits the construction of multicast delivery trees and supports multicast data packet forwarding. In addition, each router must implement a group membership protocol that allows it to learn about the existence of group members on its directly attached subnetworks.


www.juniper.net


RPF The slide highlights the topic we discuss next.

www.juniper.net



Multicast Routing Differs from Unicast Routing Multicast routing differs from unicast routing. Whereas unicast flows are directed toward a destination by a router based on destination address, multicast flows are more or less directed away from a source based on source address. (Destination multicast group addresses are useless for unicast routing purposes.)

RPF But how is this away direction defined? With 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 multicast packets received on the upstream interface. These packets, in turn, are only forwarded out 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. Continued on the next page.


www.juniper.net


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).

www.juniper.net



RPF 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 determine whether 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 Protocol Independent Multicast (PIM), RPF checks are performed against the main routing table (inet.0), by default. Distance Vector Multicast Routing Protocol (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.


www.juniper.net


The RPF Check: Part 1 In the example on the slide, a packet arrives at R1’s interface ge-0/0/1.0 from Source 1. R1 checks the existing unicast routing table and determines that this interface is not on the reverse path back to the source. Thus, the packet is discarded.

www.juniper.net



The RPF Check: Part 2 In the example on this slide, R1 receives a packet from Source 1 on its ge-0/0/4.125 interface and, once again, performs an RPF check. R1 determines that the packet is coming in on an interface that is on the reverse path back to the source. Thus, the RPF check succeeds, and the packet is forwarded to all interfaces on the outgoing interface list. Initially, all interfaces other than ge-0/0/ 4.125 will be on the outgoing interface list.


www.juniper.net


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

Source-Based Distribution Tree The simplest form of a multicast distribution tree is a source tree with its root at the source and branches forming a spanning tree through the network to the receivers.

Dense-Mode Protocols Common dense-mode protocols include DVMRP, which builds a unique multicast routing table and has a finite hop count of 32. DVMRP was the first multicast routing protocol. As mentioned, PIM dense mode (PIM-DM) uses a flood-and-prune behavior to build a source tree from the source of the multicast.

www.juniper.net



PIM-DM Operation PIM-DM uses SPTs to deliver multicast traffic and assumes that there is at least one receiver of the multicast traffic on every subnet in the network. Traffic is initially flooded to all points in the network. Each router running PIM-DM creates an (S,G) state entry for each source/group pairing. The slide shows an example of what an (S,G) state entry looks like. Routers without locally attached receivers must prune themselves periodically from the SPT to avoid the reception of unwanted multicast traffic.


www.juniper.net


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

www.juniper.net



After the Prune The result of the prune process is that branches without receivers are pruned off of the distribution tree, leaving only branches that contain receivers. However, even routers that are not part of the distribution tree must continue to maintain (S,G) entries for all known source and group combinations. This excess state is needed in the case of adding a receiver to the network that did not previously exist.


www.juniper.net


Source Distribution Tree A source distribution tree is an SPT between the sender and a given receiver. Dense-mode protocols have the benefit of using SPTs between all sources and receivers. As you will soon see, the use of a shared tree, as associated with sparse-mode operation, results in less than optimal forwarding between source and receivers. To provide the best of both worlds, a PIM sparse-mode receiver normally instigates a Join message to an SPT after receiving a multicast packet over the shared tree with a new source address. We describe this behavior in detail in the next chapter. An SPT is indicated by the presence of (S,G) state. A shared tree is indicated by the presence of (*,G) state.

www.juniper.net



Adding a New Receiver The slide shows what happens when a new receiver joins the multicast group after the SPT has been established. R3 receives an IGMP report (described in subsequent pages) from the new receiver advertising its membership to the 224.7.7.7 group. R3 and every router along the SPT between the source and receiver, in turn, sends a Join message upstream toward the source. Note that the new receiver did not specify the source’s IP address (192.168.100.10). For R3 and all of the other routers to send the Join message toward the source, they must somehow know the IP address of the source. Any ideas? Because we are using a dense-mode protocol, every router is aware of every source and group combination that is being used in the network and stores that information as part of the (S,G) state. R3 looks over all of its (S,G) entries and finds the IP address of the source for 224.7.7.7. Each router along the SPT between the source and receiver sends a Join message toward the source until the source’s DR is reached.


www.juniper.net


A Branch Is Added for Forwarding Once the Join messages are received and sent along the new SPT, each router updates its (S,G) state to include a non-Null inbound interface and a non-empty outbound interface list. Because in the change in (S,G) state, traffic can now be delivered to the new receiver.

www.juniper.net



IGMP The slide highlights the topic we discuss next.


www.juniper.net


IGMP 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 whether 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 can also help a Layer 2 switch determine which port it should use for forwarding multicast packets. Normally a Layer 2 switch will forward multicast packets in the same manner as a broadcast packet by sending a copy of received multicast packets out of all interfaces except for the one on which the packet arrived. By enabling IGMP snooping (supported on Junos OS Layer 2 switches), a switch is able to listen in on the IGMP report messages between hosts and attached routers. From what the switch learns from these messages, it can make a better decision on where to send the multicast packets.

IGMP Message Exchange For each attached network, a multicast router can be either a querier or a non-querier. The querier router periodically sends general query messages to solicit group membership information. Hosts on the network that are members of a multicast group send report messages. When a host leaves a group, it sends a leave-group message when running IGMP versions 2 or 3; IGMP version 1 does not support explicit leaves. Instead, it relies on the aging out of cached states to manage leaves. Continued on the next page. www.juniper.net



Junos OS Support On Junos OS routers, IGMP is enabled automatically on all multiaccess interfaces configured with a multicast routing protocol such as DVMRP or PIM. You might need to configure the IGMP protocol explicitly if you want to disable IGMP support on a given interface, or if you need to modify various IGMP parameters. The default version of IGMP is version 2; however, the Junos OS also supports versions 1 and 3.


www.juniper.net


Group Membership Protocols Versus Multicast Routing Protocols Multicast routing protocols work in conjunction with IGMP. IGMP allows hosts to join and leave multicast groups; multicast routing protocols allow multicast traffic to flow between networks. Common multicast routing protocols are DVMRP and PIM. In general, you do not have to run IGMP between routers because routers typically do not join multicast groups.

www.juniper.net



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. RFC 2236 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 IGMPv1’s leave latency. Continued on the next page.


www.juniper.net


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 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. With IGMPv1 and v2, if a host wants to receive traffic from a given group, that host must be prepared to receive traffic from all active sources sending packets to that group. SSM maximizes efficiency by allowing a host to receive group traffic from a selected set of sources. The support for leave-group messages that was introduced in IGMPv2 is enhanced to support group-source leave messages in IGMPv3. Although IGMPv3 adds support for the SSM service model, it still offers backwards compatibility with the any-source multicast (ASM) service model as well.

www.juniper.net



Joining a Multicast Group When a host wants to join a specific multicast group, it sends out a membership report for the multicast group it wants to join. This type of membership report is sometimes referred to as unsolicited because it is not generated in response to a membership query that is generated by a multicast router. In the example on the slide, Host 1 multicasts an unsolicited IGMPv2 membership report to 224.10.1.1 to inform the multicast routers that it wants to join the 224.10.1.1 group. Hosts that are interested in a given group also respond to the periodic query messages, as generated by the querier router for this subnet, with report messages to prevent the group state from timing out.


www.juniper.net


Query-Response Model The primary function of IGMP 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. Continued on the next page.

www.juniper.net



Query-Response Model (contd.) 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. 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 non-querier router (Router B) knows the same information because it has eavesdropped on the various query and report messages that have transpired. This allows the non-querier to rapidly take over the querier function when needed.


www.juniper.net


IGMPv2 Group Leave This slide outlines the IGMPv2 leave mechanism, which has the host send a group-specific leave message to the all-routers multicast group (224.0.0.2) to inform all routers it is leaving the group. The querier router then sends a group-specific query to determine whether any host still remains active for the group. If some hosts still exist, those hosts respond with a membership report to inform the router that a member of the group is still present. With IGMPv1, no mechanism exists for a host to notify the router that it wants to leave a group. The router continues to send out its query for the group, and if it stops getting membership reports, it knows that there are no active receivers for the group. Because the query interval is 60 seconds, and the router does not time out until after missing three query messages, the router could continue to forward multicast traffic for up to three minutes after all hosts have left the group.

www.juniper.net



IGMPv3 and SSM Version 3 of IGMP supports the concept of source-specific reports, which allow a host to issue a report for a specific source (S,G), as opposed to all sources (*,G). This capability is called SSM. The (S,G) notation is used to indicate a specific source (S) and a corresponding group (G). The use of a shared tree is indicated with a wildcard (*) instead of a specific source address. The slide shows how SSM allows a host to selectively choose the sources from which it is interested in receiving traffic, on a per-group basis. Besides the obvious efficiency gains, SSM has the added benefit of supporting a sparse-mode topology without an RP. In the example, Host 1 sends an IGMPv3 membership report with an include indication for source 172.16.20.1 and an exclude indication for address 192.168.30.1. Note that in IGMPv3, report messages are sent to the IGMPv3-capable multicast routers’ address of 224.0.0.22. Recall that IGMPv1 and IGMPv2 send report messages to the address of the group being reported. One reason for this modified behavior is that IGMPv3 report messages can contain information for multiple groups. Continued on the next page.


www.juniper.net


IGMPv3 and SSM (contd.) Note that general queries are sent to the all-hosts multicast address (224.0.0.1), whereas group-specific and group-and-source-specific queries are sent to a destination address that matches the multicast address of interest. The disadvantage to SSM is that hosts must have a prior knowledge of the specific sources active for a given group before they can formulate the appropriate group-source report message. This problem is complicated by the fact that some groups are ephemeral in nature. Standards work is underway to develop ways of propagating knowledge of active sources to IGMPv3 hosts. For example, addresses in the range of 232/8 are reserved for use by SSM. Although SSM can function with groups outside this range, attempts to perform an ASM Join message (*,G) to a 232/8 prefix should fail with an IGMPv3-compliant router.

www.juniper.net



IGMP Protocol Configuration The slides shows the different IGMP configuration options. We describe most of these options in subsequent slides.


www.juniper.net


IGMP Interface Specific Properties Many of the settings for IGMP can be applied on an interface by interface basis. The following list describes each of these options. •

accounting: Enables join and leave notifications.

•

disable: Disables IGMP on this interface.

•

group-limit: Maximum number of (S,G) Join messages per interface.

•

group-policy: Allows you to block certain source and group combinations.

•

immediate-leave: Groups are immediately removed without sending a query for last membership. This option is good for when only one host is attached.

•

no-accounting: Disables join and leave notifications.

•

oif-map: Allows you to configure outbound interfaces for multicast traffic that are different than the one where the IGMP report was received.

•

passive: Suppresses the sending and receiving of certain IGMP messages.

•

promiscuous-mode: Accepts IGMP messages from a different subnet.


www.juniper.net



IGMP Interface Specific Properties (contd.) The following is a continuation of the list of IGMP settings from the preceding page: •

ssm-map: When an interface is set for IGMPv3 and an IGMPv1 or v2 report arrives (no source specified), this feature allow you to statically map a source to the group received in the report.

•

ssm-map-policy: Name of the SSM map policy created to match the group addresses you want translated to IGMPv3.

•

static: With this setting, regardless of what is received from an attached host, the router will automatically act as if it had received a report for the configured source and group combination. This is a great feature for testing the multicast routing protocol without the need for a host running IGMP.

•

version: Sets the IGMP version number to be used.


www.juniper.net


Sample Configuration To configure IGMP, you include statements at the [edit protocols igmp] hierarchy level of the configuration. IGMP is enabled automatically on all non-point-to-point interfaces configured to run DVMRP or PIM in all Junos OS releases. 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 router’s 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 SSM. The syntax on the slide shows how you can configure a static IGMP report under a particular interface for a given group address. This configuration causes the router to act as if it had received an IGMP report on the interface (no IGMP reports are actually sent or received as a result of this configuration). By including a source address, you will cause the router to send an (S,G) PIM Join message while omitting the source address causes the router to send a PIM (*,G) Join message. Static reports are useful when testing multicast in the absence of a multicast receiver. The IGMP querier router periodically sends general host-query messages. These messages solicit group membership information and are sent to the all-hosts multicast group address, 224.0.0.1. By default, the router sends host-query messages every 125 seconds. You might want to change this interval to tune the number of IGMP messages sent on the subnet.

www.juniper.net



Displaying the IGMP Interface The output of the show igmp interface command is a listing of interfaces running IGMP, the IGMP version, and the number of groups currently active. The IGMP querier address is also listed when it is known. The display also provides a listing of the derived and configured timer and counter parameters used to control the operation of IGMP.


www.juniper.net


Displaying IGMP Group Information Use the show igmp group command to show the groups joined by directly connected hosts and other routers. When a router is attached to a LAN that has only IGMP-speaking hosts (that is, no other PIM-speaking routers), that interface must run PIM for the router to function properly. If you explicitly enable IGMP on an interface but fail to enable PIM on that interface also, the IGMP interface status shows the Up state, but that interface is omitted from the output of a show igmp group command. Note that the Junos OS always accepts and listens to groups like the all-OSPF routers or all-IGMPv3 routers addresses, even when these functions are not actually configured. Listening causes no harm to these messages; the Junos OS does not act upon the messages unless the corresponding functionality is configured. To clear group membership, use the clear igmp membership command. When you want, you can clear all group information or just the information associated with certain interfaces and groups.

www.juniper.net



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


www.juniper.net



www.juniper.net

•

Basic multicast terminology;

•

Multicast address space;

•

Multicast RPF; and

•

IGMP functionality.



Review Questions 1. . 2. . 3. . 4.


www.juniper.net

Advanced Junos Enterprise Routing Chapter 9: Multicast Routing Protocols and SSM



Basic multicast routing protocol terminology;

•

Protocol Independent Multicast (PIM) sparse mode operation and configuration when using the any-source multicast (ASM) model; and

•

PIM sparse mode (PIM-SM) operation and configuration when using the source-specific multicast (SSM) model.

Chapter 9–2 • Multicast Routing Protocols and SSM

www.juniper.net


Overview of Multicast Routing Protocols The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.juniper.net

Multicast Routing Protocols and SSM • Chapter 9–3


ASM The ASM delivery model was designed into the original specifications of multicast in RFC 1112. This model supports traffic from one source to many receivers. Internet Protocol Television (IPTV) video is one example that uses this model. ASM also supports traffic between all members of a multicast group. Examples of this many-to-many model are videoconferencing and whiteboard applications. ASM gets its name from a mechanism that allows receivers to join a group without specifying from which source they want to receive traffic. As a result, the receivers accept multicast packets for a particular group from any source.

SSM In the SSM model, the receiver specifies the sources from which it would like to receive traffic. The receiver can also specify from which sources it does not want to receive traffic. So for SSM to work, the source information must be learned from the receiver. SSM makes deployment of multicast less complex and also makes addressing easier.


www.juniper.net


Dense Mode When using a dense mode multicast routing protocol, traffic gets forwarded to all parts of the network (flooding). This flooding process allows every router in the network to learn of any active sources in the network and store that information in a state called (S,G) or “S comma G”. The parts of the network that are not interested in receiving the traffic (no receivers) will send Prune messages to their neighbor routers asking them to stop forwarding traffic to them. In the case where a receiver joins a group after the branch of the forwarding tree has been pruned, the routers along the shortest-path tree (SPT) will send a graft message asking for the traffic to be forwarded again. In a dense mode network, multicast traffic is always forwarded along the SPT between source and receiver. Dense mode multicast routing protocols include Multicast Open Shortest Path First (MOSPF), Distance Vector Multicast Routing Protocol (DVMRP), and PIM dense mode (PIM-DM). The Junos operating system supports DVMRP and PIM-DM, but not MOSPF.

Sparse Mode When using PIM-SM, multicast traffic only gets forwarded into parts of the network where interested receivers exist. Only routers along the SPT need to maintain (S,G) state. Each router along the forwarding path sends Join messages to indicate its willingness to receive traffic. In the case where the receiver is no longer interested, the router sends Prune messages to the upstream neighbor asking the neighbor to stop forwarding the traffic. In PIM-SM, there are two possible forwarding trees that can be used to deliver traffic to an interested receiver: an SPT or a rendezvous-point tree (RPT). We describe each of these forwarding trees in subsequent slides.

www.juniper.net



SPT An SPT is a multicast forwarding tree that is rooted at the first-hop router closest to the source. When a dense mode protocol is used in the network, (S,G) state is maintained for every known source and group combination on every router, including those routers not on the SPT. When PIM-SM is used in the network, (S,G) state is maintained for every known source and group combination only on the routers on the SPT, as well as the rendezvous point (RP) (discussed in subsequent pages).


www.juniper.net


RP Tree An RPT can be found only in a PIM-SM network. The RP is a centralized router that is responsible for knowing all combinations of active sources and groups in the network. The RPT is a multicast forwarding tree that is rooted at the RP in the network and leafs out to the interested receivers. Because all last-hop routers fall on the RPT for a specific multicast group, this tree is sometimes referred to as the shared tree. This tree is generally used temporarily for forwarding until the routers closest to interested receivers learn the source of multicast traffic (learned from the source address of the multicast packets). Once these routers learn the source of the multicast traffic, they build an SPT directly to the source designated router (DR).

www.juniper.net



PIM-SM Using the ASM Model The slide highlights the topic we discuss next.


www.juniper.net


PIM Independence PIM is indeed as it claims—protocol independent. Whichever unicast protocol is being used, PIM will use this protocol for its reverse-path forwarding check. PIM does not care if this protocol is OSPF, Intermediate System-to-Intermediate System (IS-IS), RIP, or even BGP!

PIM-SM Trees The purpose of an RP and a shared tree is to allow receivers to learn of active senders for a given multicast group. Once an active sender is detected, that is, data from sender x is received over a shared tree, PIM sparse-mode routers attempt to optimize the topology by establishing a source-based tree. The resulting SPT removes unnecessary hops, and possibly the RP itself from that particular multicast flow. Subsequent slides provide details of this behavior.

Design Considerations The placement and selection of a sparse-mode RP can be a critical factor in the network’s performance and fault tolerance. Subsequent pages discuss ways of achieving RP redundancy. PIM-SM for IP version 4 (IPv4) requires a pd interface on the RP, and a pe interface on every router that is directly attached to a multicast source. On some Juniper Networks hardware, the pd and pe virtual interfaces require the presence of a specialized services PIC. Consult JTAC or technical documentation to determine whether your hardware model requires specialized hardware. Continued on the next page.

www.juniper.net



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.


www.juniper.net


PIM Register Messages PIM-SM requires that source DRs encapsulate multicast traffic inside register messages, which are then sent as unicast datagrams to the group’s RP. Upon receipt, the RP removes the register encapsulation and forwards the traffic down the shared tree as native multicast, if the tree exists. Register encapsulation is necessary because initially no state in the network exists to allow native multicast to flow from the sender to the RP. Put differently, the RP functions to allow receivers to locate active senders without the prior knowledge that senders actually exist. By allowing a sender to initially contact the RP using unicast forwarding, we eliminate the problem of the RP having no way to learn of active senders. On a Junos OS router, the source DR and RP must have tunnel services enabled to encapsulate and decapsulate register messages. To provide tunnel services some Junos OS routers require an Adaptive Services or Tunnel Services PIC.

www.juniper.net



Adding a Receiver Adding a receiver to a PIM-SM network (ASM model) requires that an RPT is built from RP to receiver. The slide shows a new receiver notifying R5 of its interest in receiving traffic destined to 224.7.7.7 by sending an Internet Group Management Protocol version 2 (IGMPv2) report. Not knowing the source of the 224.7.7.7 group, R5 sends a (*,G) Join message in the direction of the RP. R4, after receiving the Join message from R5, also sends its own (*.G) Join message to the RP. This results in the building of the RPT. Because the RP is aware of all active sources in the network (because of the reception of register messages), the RP sends an (S,G) Join message toward the source in an attempt to build an SPT from source to RP. R2, after receiving the Join message from the RP, also sends its own (S,G) Join message to the sources’ DR which completes the building of the SPT.


www.juniper.net


PIM-SM: The Shared RPT Sparse-mode routing is ideal for efficiently routing to multicast groups that might span wide-area and interdomain internetworks. In sparse mode, routers must join and leave multicast groups explicitly. Upstream routers do not forward multicast traffic to a downstream router unless that router has sent an explicit request (using a Join message) to receive multicast traffic. In other words, multicast traffic is forwarded out a PIM-SM interface only if the interface has received a Join message from a downstream router or if group members are connected directly to the interface. The slide shows that the traffic flowing from the source to receiver does not follow an optimal path when flowing over the shared tree. Future slides explain how this inefficiency is resolved with the signaling of an SPT.

www.juniper.net



PIM-SM: Switch to SPT—Part 1 The presence of traffic flow down the PIM-SM shared tree triggers a switch to an optimal SPT-based tree. The receiver’s designated router (that is, the router closest to the receiver with the highest PIM priority) sends a Join message toward the source while also pruning the (S,G) state from the shared RP tree (not shown) when it determines that traffic is not being received over the optimal path between the source and receiver. This slide shows the process beginning with the DR sending a PIM (S,G) Join message over the RPF path back to the source to establish an SPT. Note that as a result of the join, multicast traffic is now being delivered from R1 to R5 over an SPT. At this time duplicate traffic is also being received over the RPT. In the Junos OS, the switch from a shared to an SPT is generally triggered by the receipt of the first packet from a new source on the shared tree.


www.juniper.net


PIM-SM: Switch to SPT—Part 2 After the SPT is formed between the receiver and the source and data begins to flow, the receiver’s designated router sends an (S,G) Prune message to the RP. This (S,G) Prune message prevents the reception of data from that particular source over the shared tree. The slide shows that multicast traffic from the source is no longer received over the shared tree as a result of the Prune messages. In this example, the RP has no need to forward traffic from the source (it has no downstream interfaces for the (S,G) entry for the source), so the RP also sends an (S,G) prune toward R1. The first-hop router will periodically send null register messages to the RP so that it continues to be aware of the source. This process ensures that future receivers of this group can reach this source using the RP because they might not know of the source itself.

www.juniper.net



PIM-SM: Switch to SPT—Part 3 The slide shows the resulting SPT between the source and a specific receiver for a particular group (G) that yields optimal forwarding. Notice that R5 must maintain both (S,G) state for the SPT as well as (*,G) state for the RPT (that continues to exist). Because it is possible that another source can be added to the network that might send traffic to the same group, 224.7.7.7, the RPT must remain intact.


www.juniper.net


When All Is Said and Done No one ever said that multicast was simple or easy to understand! The average reader has likely had enough multicast theory at this juncture. This slide concludes the previous example by showing the final result PIM-SM operation with respect to the sender, RP, and receiver shown in the example. The source station becomes the root of an SPT that delivers native multicast from the source to the receiver. Note that the shared tree is pruned for this source from the perspective of the receiver shown because of the presence of the SPT. The receiver maintains the shared tree to the RP so that it can begin receiving traffic for any new sources that might begin sending to the multicast group in question.

www.juniper.net



Three RP Methods The Junos OS provides three separate methods for determining which router in the domain is the RP. These methods include static configuration, dynamic announcements using auto-RP, and dynamic announcements using a bootstrap router (BSR).

Precedence Order In the event that a local router encounters multiple methods of learning the address of the RP, the Junos OS has a default precedence mechanism for making the selection. The RP announced by the BSR is preferred over the RP announced using auto-RP, which is preferred over any local static RP configurations.

Local RP Configuration Regardless of the method used in the network for determining the RP address, a candidate rendezvous point (candidate RP) itself must be configured to perform that role. In the example on the slide, the local portion of the [edit protocols pim rp] hierarchy accommodates this configuration need. You define the address to be used as the RP address and any applicable group addresses the candidate RP should operate upon. If no group addresses are defined, the candidate RP is used for all possible group addresses (224.0.0.0/4).


www.juniper.net


Static RP A static RP configuration is very similar to static routes in that no automatic failover exists should the statically defined RP become unreachable. Although this configuration is simple and convenient, you might want to use this method in combination with any-cast RP and Multicast Source Discovery Protocol (MSDP) to provide a fault-tolerant mechanism. Static RP assignment has the benefit of operating in either a PIM version 1 or version 2 network. In the example on the slide, the static portion of the [edit protocols pim rp] hierarchy is used to configure a static RP address. You define the address of the RP, as well as the group addresses for which to use the RP. If no group addresses are defined, the RP is used for all possible group addresses (224.0.0.0/4).

www.juniper.net



Verifying a Static RP The show pim rps command with the extensive switch displays a wealth of information about how an RP was learned, which groups it handles, and the number of groups actively using the RP. In the example on the slide, the RP at 192.168.50.61 was learned from a static configuration. It can support all groups in the 224.0.0.0/4 range, which is all possible groups. The local router sent PIM control traffic for the 224.7.7.7 group to this particular RP.


www.juniper.net


Dynamic RP Assignment If you want a 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 operates in both a version 1 and a version 2 PIM network. Negatively, it is a nonstandard (non-RFC-based) function and requires the use of dense-mode PIM to advertise control traffic.

Dense Groups Needed Auto-RP requires multicast flooding both to announce potential RP candidates and to discover the elected RPs in the network. This flooding occurs using a PIM-DM model, where group 224.0.1.39 is used for the Announce messages and group 224.0.1.40 is used for the Discovery messages.

Failover Capabilities One advantage that auto-RP maintains over static RP assignment is the ability to maintain a backup RP in the network. This backup 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. Continued on the next page.

www.juniper.net



Mapping Agents As multiple candidate RP routers announce their capabilities to support multicast groups, there must be a single router in the network—the mapping agent—to perform the group-to-RP mapping. This functionality is required because only a single RP for each multicast group can exist. The mapping agent sends out Discovery messages to the network informing all routers which RP to use for specific multicast groups.


www.juniper.net


Auto-RP Message Each local router configured as an RP uses this auto-RP message to advertise its capability into the network. The mapping agent in the network collects these announcements and selects the RP for each group address. This information is then transmitted into the network using this same message format. The message fields include the following: •

Version and type (1 byte): This octet is split into two 4-bit fields. The first 4 bits represent the current version of auto-RP being used and are set to a constant value of 1. The second 4 bits are used to represent the actual type of auto-RP message encoded. The possible values are the following: –

1: RP announcement message; and

–

2: RP mapping message.

•

RP count (1 byte): This field displays the number of distinct RP addresses present in the message. For each address present, the RP address field, as well as its associated fields, is repeated.

•

Hold time (2 bytes): This field displays the amount of time, in seconds, for which the RP message is valid.


www.juniper.net



Auto-RP Message (contd.) The following is a continuation of the list of message fields on the preceding page: •

Reserved (4 bytes): This field is not used and is set to a constant value of 0x00000000.

•

RP address (4 bytes): This field displays the first RP address included in the message. The remaining fields in the message are repeated for each unique RP address.

The remaining fields of the auto-RP message are the following: •

Reserved and RP version (1 byte): This byte begins with a 6-bit reserved field, which is set to all zeros. The final 2 bits are used to display the version of PIM supported on the RP. The possible values include the following: –

00: Version unknown;

–

01: Version 1 only;

–

10: Version 2 only; and

–

11: Both versions 1 and 2.

•

Group count (1 byte): This field displays the number of groups associated with the RP address.

•

Encoded group address (6 bytes): This field contains three separate portions used to describe the group address associated with the RP. The entire 6 bytes are repeated based on the value in the group count field. The field portions include the following: –

Reserved and N bit (1 byte): This field contains seven bits set to a value of 0, followed by the N bit. The N bit denotes whether group address is positive or negative. A value of 0 represents a positive group address, which should use sparse mode PIM forwarding. A value of 1 represents a negative group address, which should use dense mode PIM forwarding.

–

Mask length (1 byte): This field displays the length of the group prefix to follow.

–

Group address (4 bytes): This field displays the multicast group address that the RP supports.


www.juniper.net


Electing an RP The slide shows how the mapping agent learns of all of the candidate RPs, performs the RP election, and then informs all of the routers in the network of the elected RP.

www.juniper.net



Configuring Auto-RP To enable auto-RP successfully in a PIM network, you must complete a few steps. First, each router in the network must enable the sparse-dense mode on all interfaces within the [edit protocols pim] hierarchy. This step allows the router to operate in sparse mode for most groups and dense mode for others. The default action is to operate in sparse mode unless specifically informed of a dense-mode group, which is accomplished with the dense-groups command. Both the 224.0.1.39 and 224.0.1.40 groups must be listed, and you must apply this configuration on all routers in the network. Once you complete the preceding steps, the actual configuration of auto-RP can take place. Each router must have the auto-rp command configured with one of three switches: discovery, announce, or mapping. The discovery option allows a router to receive and process the Discovery messages from the mapping agent. This function is the most basic and limited a router can support. The announce option adds to the same abilities as the discovery option, but also allows a router to send Announce messages into the network stating that it is a candidate RP. Finally, the mapping option adds to the abilities of the announce option, but also allows a router to perform the group-to-RP mapping function as well as to send Discovery messages into the network.


www.juniper.net


Verifying an Auto-RP RP In the example on the slide, the RP at 192.168.50.61 is learned from auto-RP. It can support all groups in the 224.0.0.0/4 range, which is all possible groups. In addition, the presence of tunnel services in an RP router creates a decapsulation interface to allow the RP to receive multicast traffic from the source. This interface is ppd0.32769 in the example.

www.juniper.net



PIM Version 2 Only Another method available to determine an RP router dynamically is the BSR. The functionality of the BSR was originally in RFC 2362, but has been updated in RFC 5059. The specification requires that all routers wanting to support BSR be capable of using the PIMv2 specification. This requirement stems from the method by which the BSR operates. All routers in the domain send and collect BSR messages on a hop-by-hop basis. Although this process means that only sparse mode interfaces are needed, it also means that all routers must be able to receive and regenerate these messages.

One BSR per Domain Within a PIM domain, only a single BSR is ever elected. It is the function of the BSR that allows all routers in the network to know the specific RP for any individual multicast group. The primary criterion for electing a BSR is a configured priority. Should the priority of two routers be equal, the router with the higher loopback IP address is elected. If multiple IP addresses are configured on the loopback, the lowest address configured is used unless any addresses have been configured with the primary option. In this case, the lowest address configured with the primary option is used. A router with a priority of 0 is ineligible to be the BSR and is never elected. Continued on the next page.


www.juniper.net


Multiple Candidate Routers One advantage that the bootstrap mechanism brings to PIM is the ability to have multiple routers configured with a priority. Although only a single BSR can be operational at one time, other routers are available to take over in the event of a failure. In addition, you can also configure a candidate BSR to be a candidate RP. This configuration allows for easier troubleshooting and keeps the overhead of PIM control messages centralized on a few routers. At a minimum, you must configure only a single candidate BSR and a single candidate RP to operate a multicast network successfully, although it is possible for both functions to be configured on a single router.

www.juniper.net



Candidate RP Advertisements After the election of the BSR, each configured RP in the network unicasts a candidate RP advertisement (C-RP-adv) into the domain. This announcement informs the BSR which multicast groups the RP can support, the hold time for the RP, and a priority value. This information allows for a dynamic failover in the event of a failure.

BSR Collects Advertisements The elected BSR collects all the C-RP-advs sent into the network. It places each of the announcements into a message known as the RP-set, which contains all announced RP routers. Local routing policies can affect which announcements are placed into the RP-set, allowing for maximum flexibility. Once the RP-set is complete, it is advertised into the domain in a bootstrap message. Continued on the next page.


www.juniper.net


BSR Advertises to the Domain The function of the BSR is completed once the RP-set is advertised into the PIM domain. At this point, it is up to the individual routers to choose which RP should be used for which multicast group. A process defined in the RFC allows all routers to make the same selection based on the available RP-set. This process allows different groups to be supported by different RP routers. The steps for selecting the RP are the following:

www.juniper.net

1.

Locate all RPs associated with the most specific advertised group range for the specific group in the PIM Join message.

2.

From the resulting RPs, select all devices with the best priority (the highest numerical value).

3.

From the resulting RPs, compute a hash value using the group address, the RP address, and the advertised hash mask length advertised in the bootstrap message. Select the RP with the highest hash value.

4.

From the resulting RPs, select the RP with the highest IP address.



BSR Message Each BSR message is encoded in a PIM protocol packet as type code 4. It contains as few as one multicast group address range or multiple ranges. Each advertised address prefix includes a list of RPs capable of servicing that group. The fields of the bootstrap message include the following: •

Fragment tag (2 bytes): It is possible that an individual bootstrap message might be too large for transmission in the network without fragmentation. This field includes a randomly generated number designed to ensure that all fragmented packets are associated with the same bootstrap message. Each fragment receives the same value in this field.

•

Hash mask length (1 byte): This field displays the length, in bits, that each router should use when calculating the BSR hash algorithm. For IPv4 messages, a value of 30 is recommended.

•

BSR priority (1 byte): This field displays the priority value of the current network BSR.

•

BSR address (6 bytes): The address of the domain’s BSR is placed in this field using the encoded unicast address format.



www.juniper.net


BSR Message (contd.) The remaining fields of the BSR message are the following:

www.juniper.net

•

Group address (8 bytes): This field, as well as its associated fields, can be repeated multiple times in a single bootstrap message. It contains the multicast group address using the encoded group address format.

•

RP count (1 byte): This field displays the number of RPs included in the RP-set for the associated group address.

•

Fragment RP count (1 byte): When a bootstrap message is fragmented, this field is used to display the number of RPs in the RP-set included in this fragment for the group address.

•

Reserved (2 bytes): This field is not used and is set to a constant value of 0x0000.

•

RP address (6 bytes): This field is repeated based on the value in the RP count field for the associated group address. The address of the RP is displayed using the encoded unicast address format. The RP hold time, RP priority, and reserved fields following the RP address are associated with this single address value.

•

RP hold time (2 bytes): This field displays the amount of time for which the associated RP, in the preceding field, is valid. This field is displayed in units of seconds.

•

RP priority (1 byte): This field displays the priority of the associated RP. It is used in the hash algorithm for deciding which RP should be used for a particular group address.

•

Reserved (1 byte): This field is not used and is set to a constant value of 0x00. It is associated with the RP address in the preceding field.



Candidate RP Advertisement Message Once the BSR for the PIM domain is elected, each router configured as an RP generates a C-RP-adv to announce which address groups it supports. Each C-RP-adv message is unicast to the BSR address in a PIM protocol packet as type code 8. It contains the address of the RP and which groups it supports. The fields of the candidate RP advertisement message include the following: •

Prefix count (1 byte): This field displays the number of distinct group address ranges the local RP supports. A value of 0 in this field means that the RP supports all possible groups—224.0.0.0/4.

•

Priority (1 byte): The priority of the RP for its advertised group address is placed into this field. Lower numerical values translate into a higher priority. The Junos OS uses a priority value of 0 by default.

•

Hold time (2 bytes): This field displays the amount of time the BSR should retain knowledge of the local RP and its supported group addresses.

•

RP address (6 bytes): The address of the local RP is placed in this field using the encoded unicast address format.

•

Group address (8 bytes): This field is repeated based on the value in the prefix count field. Each unique group address range supported by the local RP is placed here using the encoded group address format.


www.juniper.net


RP Election Using BSR The slide shows how BSR learns of all of the candidate RPs, generates the candidate RP-set BSR message, and sends the message to all of the routers in the network. A noticeable difference between auto-RP and BSR is that, in BSR, each individual PIM-SM router performs its own elections of RPs.

www.juniper.net



Configuring a BSR As stated on a previous slide, the router in the PIM domain with the highest configured priority becomes the BSR for the network. Set this priority using the bootstrap-priority command within the [edit protocols pim rp] configuration hierarchy. The possible values supported are 0 through 255. A value of 0 means that the local router is ineligible to become the BSR for the network. This value is the default setting within the Junos OS.


www.juniper.net


Verifying the BSR In the example on the slide, the BSR at 192.168.50.51 has been elected by all routers in the network based on having a BSR priority of 50.

www.juniper.net



Verifying an RP Using BSR In the example on the slide, the RP at 192.168.50.61 was learned from the BSR. It can support all groups in the 224.0.0.0/4 range, which is all possible groups. The local router sent PIM control traffic for the 224.7.7.7 group to the RP.


www.juniper.net


PIM Interfaces The show pim interfaces command lists the configured and operational interfaces for PIM. Each interface contains the following information:

www.juniper.net

•

Name: The name of the interface;

•

Stat: The current status (Up or Down) of the interface;

•

Mode: Whether the interface is in sparse only, dense only, or sparse-dense mode;

•

IP: Which version of IP is supported on the interface (IPv4 is the default);

•

V: Which version each interface is using (version 2 is the default);

•

State: The current state of the interface—options include P2P for all nonbroadcast-capable interfaces, DR if the interface is responsible for forwarding traffic, or NotDR if the interface is not responsible for forwarding traffic;

•

Count: The number of PIM neighbors seen on the interface; and

•

DR Address: The address on the network link of the current DR.



PIM Neighbors The show pim neighbors command displays information about neighboring routers running PIM.


www.juniper.net


Displaying PIM Join States The show pim join extensive command displays the (S,G) state for both shared and source trees. The use of the shared RP tree, which is a (*,G) state, is indicated with entries using an asterisk (*) as a source address. In addition, we see RPF information such as the interfaces on which the group should be received (Upstream interface) and on which they should be transmitted (Downstream interface). Finally, the current state of PIM can be viewed using the Upstream state information. On the slide, the router is currently on the SPT and RPT as noted by the Join to RP output. You can use the clear pim join command to flush the join state of all multicast groups or a specified range of groups. Group activity causes the router to rejoin shared and source trees as needed.

www.juniper.net



Is Multicast Traffic Flowing? The command on the slide shows that the router is currently forwarding multicast traffic destined for 224.7.7.7 at a rate of 262 packets per second.


www.juniper.net


RPF Table To determine which table the router is currently using for RPF checks, use the show multicast rpf command. The slide shows that the router is using inet.0 for RPF checks.

RPF Lookup Cache Once a router performs a passing RPF check, the lookup is cached in inet.1. You can find a similar entry in the forwarding table, which is used to forward future multicast packets from the same source and destination.

www.juniper.net



Lab 7: Implementing PIM-SM The slide lists the objectives for the lab.


www.juniper.net


PIM-SM Using the SSM Model The slide highlights the topic we discuss next.

www.juniper.net



Distinguishing SSM from ASM This slide shows the new terminology used in the SSM model. One major change that you should notice is that the address identifier is no longer just a group address. Instead, it is a combination of both a unicast source address and a multicast group address. It is the addition of the unicast source address that ensures that every channel is globally unique. This means that similar to the 239/8 group address space, an administrator can freely use the 232/8 address space without having to register with Internet Assigned Numbers Authority (IANA). However, there is no need to scope the 232/8 address space (filter at the edges of the AS) because of the global uniqueness caused by any group from that range being associated with a unicast source.


www.juniper.net


Guarantees for 232/8 To support SSM, PIM-SM’s behavior has been slightly modified to support SSM’s channeled nature. To support SSM, it is necessary that the many-source-to-many-receiver functionality called for in the original multicast specification is removed for the 232/8 group range. The slide lists the new behavior of a PIM-SM router when dealing with the 232/8 address range.

www.juniper.net



SSM Requirement and Features To support the delivery of multicast traffic destined for the SSM range, a receiver and associated DR must support Internet Group Management Protocol version 3 (IGMPv3). A router will ignore any IGMPv1 or v2 report that specifies a group from the SSM range. However, with the Junos OS, it is possible for you to allow for SSM forwarding behavior from groups outside of the SSM range when using IGMPv1 and v2. Subsequent slides show how to accomplish this task with the use of an ssm-map. Because a receiver is expected to notify the DR of the desired source, there is no need for an RP. The DR, learning the source from the receiver’s IGMPv3 report, will use PIM-SM to join the SPT. However, it is possible to support ASM and SSM models side by side in a network. To do so would require the use of an RP. As stated in a previous slide, an administrator can freely use the 232/8 range because its uniqueness is guaranteed by its association with a unicast source.


www.juniper.net


Adding a Receiver in the SSM Model The slide shows how the receiver’s DR, upon receiving an IGMPv3 report, builds an SPT. The RP is not needed in the case of SSM.

www.juniper.net



Always an SPT The slide shows the resulting SPT between the source and a particular receiver for a particular channel (S,G) that yields optimal forwarding. Notice that R5 must maintain only (S,G) state for the SPT. It no longer needs to maintain (*,G) state for an RPT. Because any additional receivers will also specify a specific source, there is no need to maintain an RPT.


www.juniper.net


SSM Configuration Notice that the PIM-SM configuration on the slide is minimal, with no RP configuration necessary. To support the SSM range of addresses, you must configure IGMPv3 on the receiver-facing interface of the receiver’s DR.

www.juniper.net



Allowing for IGMPv1 and IGMPv2 Without an RP The slide shows how IGMPv1 and IGMPv2 can still be supported in a network without RPs.


www.juniper.net



www.juniper.net

•

Basic multicast routing protocol terminology;

•

PIM-SM operation and configuration when using the ASM model; and

•

PIM-SM operation and configuration when using the SSM model.





www.juniper.net


Lab 8: Implementing SSM The slide lists the objectives for the lab.

www.juniper.net




www.juniper.net

Advanced Junos Enterprise Routing Chapter 10: Class of Service



Environments that might require a modified class of service (CoS) implementation;

•

Various CoS components and their respective functions;

•

CoS processing along with CoS defaults on SRX Series devices;

•

Situations in which various CoS features are used in the enterprise; and

•

The use of the Real-Time Performance Monitoring tool.

Chapter 10–2 • Class of Service

www.juniper.net


CoS Components Review and Case Study The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.juniper.net

Class of Service • Chapter 10–3


What Is CoS? The Junos operating system refers to all facets of quality of service (QoS) as CoS. CoS provides the ability to treat some packets differently as they transit a network. CoS is an end-to-end mechanism; enabling CoS on one router or one node does not provide the entire solution. CoS must be implemented in hops from the source to the destination. Any hop along the transit path of a packet could introduce latency.

Why Use CoS? The convergence of voice and data networks is critical to characteristics like delay and jitter. On a data network, if a packet arrives late, or if it arrives out of order, typically not much harm is done. However, in voice communication, packet transmission is much more sensitive. Imagine participating in a phone conversation where syllables arrive out of order or are delayed. The communication becomes garbled. This situation makes CoS absolutely necessary for real-time applications like voice or video. The issue becomes compounded when transferring real-time applications and data across the same network. Typically, data packets are large and utilize large amounts of bandwidth. CoS is necessary to prevent the data packets from monopolizing network bandwidth.


www.juniper.net


CoS Components The slide illustrates the primary components of CoS. When a packet arrives on the ingress interface of a network device performing CoS, the device examines certain IP header fields. CoS is able to use the IP header fields to differentiate various types of traffic into traffic classes. This process is known as classification. Multiple ways exist to classify traffic. Classification can be performed based on the first 6 bits of DiffServ code point (DSCP) values in the IP type of service (ToS) header, the first 3 bits of IP precedence values in the IP ToS header, and other IP header fields such as the source IP address, destination IP address, or port numbers. Classified packets are assigned to a forwarding class. Forwarding classes are assigned to output queues. In general, the device assigns packets to forwarding classes or output queues based on the classification of the packet. The slide depicts different classes of traffic being assigned to different queues. A physical interface contains multiple queues. Classified traffic is subject to policing. If the total traffic received is greater than what the interface can handle or is greater than the bandwidth of the interface, then some packets must be dropped. This bandwidth might not be the complete bandwidth of the interface. For example, assume traffic arrives at a 1 Gigabit Ethernet interface, but somewhere upstream exists a device interface that can handle only 10 Mbps. If the typical traffic load is more than 10 Mbps of traffic, some of that traffic will be dropped at the upstream device. Rather than dropping random voice and data packets, ensuring transmission of the most important 10 Mbps of traffic is better. A policer can provide this type of granular control. Continued on the next page. www.juniper.net



CoS Components (contd.) Policing, in its simplest form, drops packets. If traffic exceeds the policer limit, the device drops the offending packet. However, policing can also be configured to assign an offending packet into a specific forwarding class. Once packets have been classified and examined by a policer, they are assigned to outbound queues. This process is known as queuing. Each queue is assigned a priority. For example, queue A might have a higher priority than queue B, which might have a higher priority than queue C, and so forth. Each queue is also assigned a transmit rate. The transmit rate defines how many packets the queue transmits within a given scheduling interval. The transmit rate is typically defined as a specific bandwidth or a percentage of the interface’s bandwidth. Queues are allocated a percentage of the physical interface’s memory to hold packets as needed. This allocation is known as a buffer. The next stage in the output processing of CoS is the act of rewriting the bit markings. A device can manipulate the various bits in the ToS header. Rewrite rules facilitate the separation of trust points in the network and allow networks to have a consistent classification on downstream nodes.


www.juniper.net


Class of Service with VoIP and Data in the Enterprise In today’s networks, it is quite common to see a mixture of real-time applications and bulk data converged into a single IP infrastructure. In this case study, users are complaining about voice quality from Site B to Site A. In the next few slides, traffic classification and queuing settings are reviewed. Changes are then made to the default classification and scheduling to accommodate the applications sensitive to jitter and loss.

www.juniper.net



Verify Markings The engineers in the enterprise know that the VoIP clients are marking the traffic with the expedited forwarding (EF) DSCP value. In this slide, a firewall filter is created to match EF-marked traffic with an action to count. The filter is applied as input filter on the interface facing Site A. The counter increments, which confirms that the packets are coming in properly marked.


www.juniper.net


Default Classifier When looking at the extensive interface output with the command show interfaces ge-0/0/1 extensive | find “Queue counters”, the engineers observe that all traffic is classified into the best-effort queue regardless of markings. The engineers also observed that the SRX Series device is dropping packets in this queue. When viewing the default classifier with the command show class-of-service classifier type inet-precedence name ipprec-compatibility, the engineers observed that the EF class is classified into the best-effort queue.

www.juniper.net



Using the DSCP Default Classifier Each type of classifier comes equipped with a default classifier in the Junos OS. If the goal is to modify only some code points, using the default values should be sufficient. To view the default DSCP classifier, use the command show class-of-service classifier type dscp name dscp-default. In this slide, the default DSCP markings are imported into the CoS classifier configuration and applied to the incoming interface of Site A. This type of classifier is known as a behavior aggregate (BA) classifier.


www.juniper.net


Default Transmit Queues After committing the behavior aggregate configuration, the EF class traffic is classified into the queue 1 named expedited-forwarding, as expected. Drops in the expedited-forwarding queue continue to occur, though, and end users are still reporting problems. When viewing the default queues with the show interfaces ge-0/0/1 extensive | find “CoS information” command, the engineers observe that only queues 0 and 3 have reserved bandwidth. Queue 0 has reserved 95% of the bandwidth and queue 3 has reserved 5% of the bandwidth with no traffic reservations for queue 1. This is the default Junos OS configuration for every interface.

www.juniper.net



Bandwidth Reservation The expedited-forwarding forwarding class is configured with a higher priority than the other queues and is reserved the remainder of the bandwidth, which is 12% based on this configuration.


www.juniper.net


Priority Queue After committing the CoS configuration, the drops in the expedited-forwarding queue disappear and users stop complaining of poor voice quality. The queue counters are running counts; to get a fresh snapshot, clear the statistics with the clear interfaces statistics command. This action clears the statistics for all interfaces; you can optionally specify a particular interface you want to be cleared.

www.juniper.net



Priority Scheduler In this slide, an ingress policer is created for EF class traffic. The policer reclassifies any traffic in excess of 2 Mbps into the best-effort queue. This is done to keep the EF-class traffic from starving the lower-priority queues. In SRX Series devices, the configured transmit-rate is only honored for queues in the same priority level. On an SRX Series device, a high-priority queue can starve other priorities unless it is rate-limited. The same is true for medium-high and medium, medium low, and so on down the priority chain. We discuss this behavior in subsequent slides.


www.juniper.net


CoS Processing and CoS Defaults on the SRX Series Device The slide highlights the topic we discuss next.

www.juniper.net



Ingress CoS Processing The slide demonstrates ingress and egress CoS packet flow processing through an SRX Series device. The following list describes a packet’s ingress flow through the router: 1.

BA classification: Packets arriving at the router are first subjected to the BA classification stage. This stage sets the forwarding class and packet loss priority (PLP) using any of the supported BA classifier types, including IP precedence, DSCP, Institute of Electrical and Electronics Engineers (IEEE) 802.1P, and so on.

2.

Multifield classification: The next processing stage is multifield classification. Here a firewall filter can be defined to match against numerous packet fields, incoming interfaces, and so on, to set the forwarding class or PLP, or to override the values set during BA classification.

3.

Ingress policing: When desired, a firewall or interface-level policer can be applied to limit matching traffic by discarding, by reclassification, or by marking excess traffic with a loss priority of high. This means that, in the event of congestion, a random early detection (RED) profile can be used to more aggressively drop PLP high traffic.

4.

Forwarding policy: The last ingress processing stage is forwarding policy. This policy can alter the existing forwarding class or PLP setting, and it can be used to select a forwarding next hop based on a forwarding class, a feature called class-of-service– based forwarding (CBF).

Continued on the next page. Chapter 10–16 • Class of Service

www.juniper.net


Egress CoS Processing The following list describes a packet’s egress flow through the router:

www.juniper.net

1.

Egress policing: After the route lookup, a packet begins its journey toward the selected egress interface. The first egress CoS processing state is output policing, which is again based on either a firewall or an interface-level policer. Once again, excess traffic can be discarded or marked with a loss priority for later discard in the event of congestion.

2.

Rewrite marker: The rewrite marker stage allows you to alter one packet field, or in some cases multiple packet fields, as the packet is transmitted to downstream nodes. Normally, you rewrite packet fields to accommodate downstream BA-based classification. Rewrite markers are indexed by protocol family and by forwarding class— for example, writing a 001 pattern into the precedence field of all family inet packets that are classified as best effort (BE).

3.

Queuing and scheduling: The queuing stage involves placing packet notifications into the corresponding forwarding class queue, where they are serviced by a scheduler that factors priority and configured weight to determine when a packet should be dequeued from a given queue.

4.

Red/Congestion control: The final CoS processing stage involves a weighted random early detection (WRED) drop decision, based on protocol, loss priority, and average queue fill level. RED tends to operate at the head of the queue, and a RED decision is made against each packet selected for transmission by the scheduler stage.



Classification Based on Layer 2 and Layer 3 Fields As shown on the slide, there are various Layer 2 and Layer 3 fields supported by BA classification. Some combinations of BA classifiers simply make no sense and are mutually exclusive; for example, you cannot apply both an IP precedence and a DSCP classifier to the same logical interface at the same time.

Default Values BA classification can be populated by default values. The operational command show class-of-service classifier displays all the default values and configured values.


www.juniper.net


Behavior Aggregate Configuration A behavior aggregate classifier is first defined under the [edit class-of-service classifiers] hierarchy. The loss-priority (PLP) bit is set for internal operations and the code-point is matched depending on which type of field is matched. In the example on the slide, an inet-precedence type has been configured to match on code-points 001 and set the loss-priority to low.

www.juniper.net



Multifield Classifier A multifield classifier is implemented through a firewall filter. You use this filter to perform multifield classification by associating a set of match criteria to a then forwarding-class action. To activate multifield classification, the filter is applied as an input filter on an ingress interface. Because BA classification is always performed first, you can always apply a multifield classifier in combination with any BA classifier. In case of conflict, the forwarding class associated with the BA match is overwritten by the multifield classifier's choice of forwarding class.

Multifield Classifier Configuration In the slide, port 17000 and UDP traffic are matched and set to the assured-forwarding queue. The loss-priority is set to low.


www.juniper.net


Rewrite Marker One of the most important design goals for Enterprise CoS is to enable classification and marking close to the edge of the network. Doing so simplifies the classification logic and configuration on the rest of the routers in the network.

Default Markings As with behavior aggregates, a rewrite configuration can be populated with the default values. These values can be viewed with the show class-of-service rewrite-rules operational command.

Rewrite Rule Configuration In the example on the slide, a DSCP-type rewrite rule is created and the default values are imported. An explicit rewrite rule is created for packets in the best-effort queue with loss-priority set to low and code-point set to 000001. Keep in mind that any explicit rule you configure will override imported default values.

www.juniper.net



Scheduling and Queuing Because different transmit weights can be assigned, the SRX Series devices implement a modified deficit round-robin (MDRR) scheduler defined by three variables. •

Buffer size: This is the delay buffer for the queue that allows it to accommodate traffic bursts. You can configure a buffer size as a percentage of the output interface's total buffer capacity or as a temporal value from 1–200,000 microseconds, which simply represents buffer size as a function of delay, rather than bytes.

•

Quantum: The quantum is the number of credits added to a queue every unit of time and is a function of the queue's transmit weighting. The queue's transmit rate specifies the amount of bandwidth allocated to the queue and can be set based on bits per second or as a percentage of egress interface bandwidth. By default, a queue can be serviced when in negative credit, as long as no other queues with the same priority have traffic pending. When desired, you can rate-limit a queue to its configured transmit rate with inclusion of the exact option. MDRR uses a deficit counter to determine whether a queue has enough credits to transmit a packet. It is initialized to the queue's quantum, which is a function of its transmit rate, and it is the number of credits that are added to the queue every quantum.



www.juniper.net


Scheduling and Queuing (Contd.) •

Priority: The priority can be low, medium-low, medium-high, high, or strict-high, and it determines the sequence in which queues are serviced. The scheduler services high-priority queues before it addresses any low-priority queues.

Per-Unit Scheduler By default, when you apply a scheduler to an interface, it takes effect at the port, or interface device (ifd) level. This is fine when the port in question is configured with a single logical interface (ifl), such as would be the case when running Cisco High-Level Data Link Control (HDLC) or the Point-to-Point Protocol (PPP). However, when the interface is partitioned into multiple logical units—for example, as the result of adding virtual LAN (VLAN) tagging—you need to use the per-unit-scheduler option. This option provides fine-grained queuing by creating a set of queues and an associated scheduler for each logical interface.

www.juniper.net



Scheduler Configuration In this slide, a scheduler named test is configured. The scheduler has a high priority, a transmit-rate of 50% of the total interface speed, and a buffer-size of 30% of the total interface buffer. A drop profile named high-drop is referenced for any packets that are marked with a loss-priority (PLP) of low. The scheduler is then mapped to the forwarding-class expedited-forwarding and applied to the ge-0/0/0 physical interface.


www.juniper.net


Configuring the Scheduler Transmission Rate The transmission rate control determines the actual traffic bandwidth from each forwarding class you configure. The rate is specified in bits per second (bps). Each queue is allocated some portion of the bandwidth of the outgoing interface. This bandwidth amount can be a fixed value, such as 1 megabit per second (Mbps), a percentage of the total available bandwidth, or the rest of the available bandwidth. To configure transmission scheduling, include the transmit-rate statement at the [edit class-of-service schedulers scheduler-name] hierarchy level. You can specify the transmit rate as follows: •

transmit-rate rate: Transmission rate, in bits per second. The rate can be from 3200 through 160,000,000,000 bps.

•

transmit-rate percentage: Percentage of transmission capacity.

•

transmit-rate remainder: Use remaining rate available.

exact Option You can, optionally, enforce the exact transmission rate or percentage you configure with the transmit-rate rate or transmit-rate percent statement. Under sustained congestion, a rate-controlled queue that goes into negative credit fills up and eventually drops packets. Note that, in the configuration, you cannot combine the remainder and exact options.

www.juniper.net



Configuring the Scheduler Buffer Size To control congestion at the output stage, you can configure the delay-buffer bandwidth. The delay-buffer bandwidth provides packet buffer space to absorb burst traffic up to the specified duration of delay. Once the specified delay buffer becomes full, packets with 100 percent drop probability are dropped from the head of the buffer. To configure the buffer size, include the buffer-size statement at the [edit class-of-service schedulers scheduler-name] hierarchy level. For each scheduler, you can configure the buffer size as one of the following: •

A percentage of the total buffer: The total buffer per queue is based on microseconds and differs by platform type. Use the percent percentage option.

•

The remaining buffer available: The remainder is the buffer percentage that is not assigned to other queues. In the example on the slide, we have assigned 40 percent of the delay buffer to the sched-best scheduler, allowed sched-network to keep the default allotment of 5 percent, and assigned the remainder to sched-exped. With this configuration, the sched-exped scheduler will use approximately 55 percent of the delay buffer.

•

A temporal value, in microseconds: For the temporal setting, the queuing algorithm starts dropping packets when it queues more than a computed number of bytes. This maximum is computed by multiplying the logical interface speed by the configured temporal value. This value differs by platform; please refer to the documentation for your particular device.


www.juniper.net


Congestion Control with WRED The general goal of WRED is to perform indiscriminate drops on traffic. By default, the Junos OS applies a 100% drop at 100% fill, effectively disabling RED on that queue. This can potentially cause TCP global synchronization issues in the network.

Configured with drop-profiles A drop profile is configured under the [edit class-of-service] hierarchy and referenced in the scheduler. Juniper supports up to four drop profiles. The drop profiles can be referenced based on a traffic type of TCP, or UDP, or both, with a loss-priority (PLP) of high or low. The result is a weighting of RED drop actions, based on traffic type.

drop-profiles Configuration On a previous slide, the scheduler referenced a drop profile named high-drop for any traffic with a loss-priority of low. Under the [edit class-of-service] hierarchy, a drop profile named high-drop is configured with a fill-level of 40% with a drop-probability of 0%, a fill-level of 50% with a drop-probability of 10%, and a fill-level of 70% with a drop-probability of 20%.

www.juniper.net



Junos CoS Defaults The Junos OS comes with a set of default CoS settings that are designed to ensure that both transit and control plane traffic are properly classified and forwarded. The default CoS setting supports two forwarding classes (BE and network control [NC]) and implements an IP precedence-style BA classifier that maps NC traffic into queue 3 while all other traffic is placed into queue 0 as BE. A scheduler is placed into effect on all interfaces that allocates 95% of the bandwidth to queue 0 and the remaining 5% to queue 3. Both of the queues are low priority, which guarantees no starvation in either platform. A default WRED profile with a single loss point is placed into effect. The 100% drop at 100% fill setting effectively disables WRED. No IP packet rewrite is performed with a default CoS configuration. Packets are sent with the same markers as when they were received. Continued on the next page.


www.juniper.net


Junos CoS Defaults (contd.) The default CoS configuration defines four forwarding classes: BE, EF, assured forwarding (AF), and NC, which are mapped to queues 0, 1, 2, and 3, respectively. However, as noted earlier, there is no default IP classification that will result in any traffic being mapped to either the AF or the EF class. This is good because, as also noted earlier, no scheduling resources are allocated to queues 1 or 2 in a default CoS configuration. Some very interesting and difficult-to-solve problems occur if you begin to classify AF or EF traffic without first defining and applying schedulers for those classes. Doing so typically results in intermittent communications for the AF/EF classes; this intermittency is tied to the loading levels of the BE and NC queues, given that when no BE or NC traffic exists, more AF/EF traffic can be sent, despite the 0% default weighting.

Default Classification The Junos OS creates a complete set of BA classifier and rewrite marker tables for each supported protocol family and type, but most of these tables are not used in a default CoS configuration. For example, there is both a default IP precedence (two, actually) and a default DSCP classifier and rewrite table. You can view default and custom tables with the show class-of-service classifier or the show class-of-service rewrite-rule command. The default values in the various BA classifier and rewrite tables are chosen to represent the most common/standardized usage. In many cases, you will be able to simply apply the default tables. Because you cannot alter the default tables, it is suggested that you always create custom tables, even if they end up containing the same values as the default table. This does not involve much work, given that you can copy the contents of the default tables into a custom table and, in the future, you will be able to alter the custom tables as requirements change. In a default configuration, input BA classification is performed by the ipprec-compatibility table and IP rewrite is in effect. As a result, the ToS marking of packets at egress match those at ingress.

www.juniper.net



Policing The slide highlights the topic we discuss next.


www.juniper.net


Token Based To rate-limit traffic entering an interface, you can deploy a policer. Implemented policers are token based and use the IP packet to limit based on bandwidth and bursts. Bandwidth is measured as the average number of bits over a one-second interval.

Burst Size The burst size will set the initial and maximum sizes of a bucket in bytes (tokens) that would be accessed each time data needs to be sent. As a packet is sent, the bucket bytes (tokens) are removed from the bucket. If there are not enough tokens to send the packet, the packet is policed. The bucket is then replenished at the bandwidth rate.

Policer Actions Once the policer limits have been configured, you must choose the action taken if a packet exceeds the policer limit. Two types of policing are available: soft policing and hard policing. Hard policing specifies that the packet will be dropped if it exceeds the policer's traffic profile. Soft policing simply marks the packet or reclassifies the packet, which could change the probability of the packet being dropped at the egress interface during times of congestion. Soft policing is implemented by either setting the packet loss priority (PLP) setting on the packet or by placing the packet into a different forwarding class.

www.juniper.net



Policing in the Enterprise Case Study The following tasks are set to be accomplished in this case study. All configuration is done on the customer premises equipment (CPE) device. •

Drop traffic destined to port 80 if going over 5 Mbps

•

Set the loss-priority to high and classify to the best-effort queue if traffic in the EF class exceeds 10 Mbps

•

The rest of the traffic should be sent to the best-effort queue and loss-priority set to high if exceeding 15 Mbps


www.juniper.net


Rate Limit Web Browser Traffic One of the goals of this enterprise is to hard-limit all traffic destined to the Hypertext Transfer Protocol (HTTP) port to 5 Mbps. A policer named port80 is created with a bandwidth-limit of 5 Mbps and a burst-size-limit of 62500 bytes per second. The policer is then referenced in a firewall filter named RemoteSites and a term matching destination-port http (80), with an action of then policer port80. Omitting the interface-specific statement and applying the same filter to multiple interfaces results in a shared policer, which in this example would cap the aggregate EF class rate to 5 Mbps. The setting of the burst-size-limit has always seemed to be a mystery for many operators. Set this value too low, and potentially all packets will be policed. Set the value too high, and no packets will be policed. The rule of thumb is that the burst-size-limit should never be lower than 10 times the maximum transmission unit (MTU). The recommended value is to set the amount of traffic that can be sent over the interface in five milliseconds. So, if your interface is a Fast Ethernet interface, the minimum is 15,000 bytes (10 * 1,500), and the recommended value would be 62,500 bytes (12,500 bytes/ms * 5).

www.juniper.net



Rate Limit EF Class Traffic In this configuration, a policer named voice is created that, if it exceeds 10 Mbps of traffic, classifies the exceeding traffic as best-effort and sets the loss-priority (PLP) bit to high. A term named voice matching traffic with DSCP class ef is created with an action of then policer voice.


www.juniper.net


Limit All Traffic The last task is to limit all other traffic to 15 Mbps. If this limit is exceeded, set the loss-priority to high and classify the traffic into the best-effort forwarding-class. In the configuration, a policer named all is created with the appropriate criteria for the task. The policer is then used in a term named all created on the same firewall filter used in the previous slides. No matching criteria is used for the term; thus it matches all traffic.

www.juniper.net



Applying the Firewall When all the tasks are configured as policers and referenced in the firewall filter, the filter is then applied as input on the interfaces facing the remote sites.


www.juniper.net


Verifying the Policers Policers that are referenced in a firewall filter automatically get counters created for them based on the policer name, interface applied, and direction. You can view these counters with the show firewall command.

www.juniper.net



Virtual Channels The slide highlights the topic we discuss next.


www.juniper.net


Virtual Channels Virtual channels are used to ensure that a central site with a high bandwidth connection does not overrun remote sites that access the network at slower rates.

Used in Frame Relay Networks In a Frame Relay service, the absolute limit on data transfer rate is the logical port speed, which can be lower than the transmission link's physical bit rate. This means that a central site can have a full T1 line rate available and a remote site is using a fractional T1 (FT1) circuit to access the provider, but pays for only 128 kilobits per second (Kbps) of port speed and can use only 128 Kbps of the T1's capacity. Regardless of the committed information rate (CIR) or the state of network congestion, the remote site is physically limited to the reception of no more that 128 Kbps of traffic. The problem, if not already obvious, is that the central site can easily burst to full T1 rates, and if these bursts are of any appreciable duration, massive loss will result because of buffer overflow in the network. This causes TCP-based sources to sense congestion and throttle back. If not corrected, this can lead to an ongoing boom/bust cycle as the sources ramp up, sense loss, and then ramp back down, resulting in diminished throughput and higher latency because of buffering within the network

Configured at the Central Site All configuration of the virtual channels is done at the central site with the high-speed access.

www.juniper.net



Virtual Channel Example: Part 1 In the diagram on the slide, the central site terminates at a T1 switch port in the service provider’s network, while the remote sites are terminated at significantly lower speeds.


www.juniper.net


Virtual Channel Example: Part 2 Two virtual channels are defined, one for each remote site. In the slide, Site A is set as the default virtual channel. Traffic that is routed out the logical interface to which the virtual-channel-group is applied will default to the virtual channel for Site A, unless directed through a firewall filter to Site B. A virtual-channel-group configuration links multiple virtual channel definitions together for application to a logical interface. In the example, the cloud-group configuration links the siteA-default and siteB definitions, much like a scheduler-map links multiple scheduler policies. When applied to a logical interface, eight queues are created for each virtual channel associated with the group, and a scheduler-map is used to control scheduling into each set of per-virtual-channel queues. This example shapes each virtual channel to the remote site's port speed, but if desired, some virtual channels can be left unshaped to allow bursting up to physical interface speed.

www.juniper.net



Virtual Channel Example: Part 3 The virtual-channel-group is applied to an interface at the logical unit level. You cannot commit the configuration unless you remove any shaping or scheduler-map configuration on the same logical unit.


www.juniper.net


Virtual Channel Example: Part 4 The final step in the virtual-channel configuration is the definition of the filter that directs traffic to the correct virtual-channel, where it is in turn shaped according to the remote site's port speed. Recall that one virtual-channel in each group must be designated the default virtual-channel, which means it is used when no explicit virtual-channel mapping is found. The vc_select filter matches on packets addressed to Site B and directs them to the scheduler/shaper associated with the Site B virtual-channel. Any traffic not matched by the vc_select term is matched by the default term, which results in a mapping to the default virtual-channel. The vc_select filter is placed into service in the output direction. The per-unit-scheduler option must be enabled on the physical interface to support scheduling into each virtual channel.

www.juniper.net



Monitoring with Resource Performance Monitoring The slide highlights the topic we discuss next.


www.juniper.net


Resource Performance Monitoring Real-time performance monitoring (RPM) enables you to monitor network performance in real time and to assess and analyze network efficiency. Typically, network performance is assessed in real time based on the jitter, delay, and packet loss experienced on the network.

Uses Probes and a Client-Server Model Approach RPM is a service available in the Junos OS that enables a router to measure metrics such as round-trip delays and unanswered echo requests. To achieve this, RPM exchanges a set of probes with other IP hosts in the network for monitoring and network tracking purposes. These probes are sent from a source node to other destination devices in the network that require tracking.

Measure Multiple Traffic Attributes Data such as transit delay and jitter can be collected from these probes, and this data can be used to provide an approximation of the delay and jitter experienced by live traffic in the network. Different live traffic metrics like round-trip time (RTT), positive egress jitter, negative egress jitter, positive ingress jitter, negative ingress jitter, positive round-trip jitter, and negative round-trip jitter can be gleaned from the results. RPM calculates minimum, maximum, average, peak-to-peak, standard deviation, and sum calculations for each of these measurements.

www.juniper.net



RPM Configuration Example: Part 1 RPM in its most simplistic form can be described as having a client (source) that sends out probe queries and a server (destination) that responds. During a probe, the client device sends a packet across to a remote server, which in turn returns the packet with an acknowledgment to the sender. Both the type and content of the queries sent from the client are user configurable. Both the source and destination nodes running RPM services are aware that the packets in the probe are used to compute information such as RTT and jitter delay. For each probe, RPM makes several measurements (for RTT as well as for different positive and negative jitter). For each type of measurement, RPM calculates the minimum, maximum, average, peak-to-peak, standard deviation, and overall sum over several different collections of measurements. For example, some of these collections include the current test, the most recently completed test, a “moving average” of n number of most recent probes, as well as all tests performed (including the one in progress). In the example on the slide, a probe named test_probe is configured for SRX-1. The probe defines a test named udp_test that uses UDP packets as indicated by the udp-ping option. The probe is set to run 15 times with a two-second interval. Furthermore, it is configured to mark the packets with the EF DSCP class and, if 5 packets are lost, an SNMP trap is generated. The remote device, SRX-2, is configured as an RPM server to listen for UDP packets on port 52000.


www.juniper.net


RPM Configuration Example: Part 2 Probes can be one of the following types: •

udp-ping-timestamp: UDP timestamp requests sent to target address.

•

udp-ping: UDP packets sent to target.

•

tcp-ping: TCP packets sent to target.

•

icmp-ping: Internet Control Message Protocol (ICMP) echo requests sent to target address.

•

icmp-ping-timestamp: ICMP timestamp requests sent to target address.

•

http-get: HTTP get requests sent to target URL.

•

http-metadata-get: HTTP get request for metadata to target URL.

Note that the icmp-ping option is the default probe type on devices running the Junos OS. An RPM measurement can consist of multiple tests, each consisting of a different probe type and exchanged between a particular source-destination IP address pair. The interval between the probes and the tests is user configurable, as is the content of the probe’s data portion. The user can also control the number of probes that belong to a test. The probe packets are timestamped with the times at which they are sent and received at both the source and destination endpoints. Continued on the next page.

www.juniper.net



Timestamps Timestamping is needed to account for any latency in packet communications. Timestamps are applied on the client, the server, or both the client and server. All nodes in the network must be synchronized to a common, accurate clock source (preferably a Stratum 3 level) using Network Time Protocol (NTP). The probe types that support timestamping functionality include: •

icmp-ping;

•

icmp-ping-timestamp;

•

udp-ping; and

•

udp-ping-timestamp.

The timestamping activity consists of the source (client) node applying a timestamp to the RPM packets with the time at which they leave the node. The destination (server) node applies a second timestamp when it receives the probe and a third timestamp when the probe leaves the destination back to the source. The source receives the response and applies a fourth timestamp. Different metrics are calculated based on these timestamps collected from a series of probes.


www.juniper.net


RPM Configuration Example: Part 3 Typically, a homogeneous set of probes, collectively called a test, is configured for each device on the network, and the information collected from these tests is stored in the Ping Management Information Bases (MIBs) and the RPM MIB. The probed target is specified using its IP version 4 (IPv4) address, and each probed target is monitored over the course of a test that contains multiple probes. During a test, probes are generated and responses collected at a rate defined by the probe interval. A probe is considered lost if the probe interval expires before a response is received. You can see the results of a test using the show services rpm probe-results operational command. Each configured test is displayed. Results are displayed in alphabetical order, sorted first by owner name and then by test name.

www.juniper.net



RPM Configuration Example: Part 4 Polling can also be done from an SNMP network management system (NMS) device. Historical graphs with information given by the probes can be created with the polling information. This helps engineers build network baselines and aids in troubleshooting network performance issues. A trap server can also be configured to notify network personnel for the various configured thresholds under the RPM configuration. A full explanation of how to configure an NMS device for RPM polling is beyond the scope of this course.


www.juniper.net



www.juniper.net

•

Environments that might require a modified CoS implementation;

•

The various CoS components and their respective functions;

•

The CoS processing along with CoS defaults on SRX Series devices;

•

Situations in which some CoS features are used in the enterprise; and

•

The use of the Real-Time Performance Monitoring tool.





www.juniper.net


Lab 9: Implementing CoS Features in the Enterprise The slide provides the objective for this lab.

www.juniper.net




www.juniper.net

Advanced Junos Enterprise Routing Appendix A: BGP Route Reflection


This Appendix Discusses: •

The operation of BGP route reflection; and

•

How to configure a route reflector.

Appendix A–2 • BGP Route Reflection

www.juniper.net


Route Reflection Operation The slide lists the topics we cover in this appendix. We discuss the highlighted topic first.

www.juniper.net

BGP Route Reflection • Appendix A–3


IBGP Full Mesh Unlike link-state routing protocols, internal BGP (IBGP) does not flood routing updates. Instead, IBGP uses an explicit peering model that normally results in the exchange of routing information to peers that are connected in a full mesh. The need for a full-mesh IBGP topology stems from the fact that BGP uses the autonomous system (AS) path attribute to provide loop detection, but IBGP speakers do not add the local AS number in the updates they send to other IBGP speakers. Lacking AS number-based loop detection, IBGP speakers are normally precluded from readvertising routes to other IBGP speakers when the route in question was learned from an IBGP speaker. This default IBGP behavior leads to the need for a full mesh of IBGP peerings. Requiring that all IBGP peers within an AS be fully meshed has inherent scalability problems. For example, every time a new router is added to the AS, each existing IBGP router must have its configuration updated to include a peering statement for the router that has been added. This process can become quite an issue when there are 100, 200, or even 1000 routers in an AS. In fact, with only 100 routers in a full IBGP mesh, each router is required to maintain 99 IBGP peering sessions, with the network having to support a total of 4,950 IBGP sessions! Surely there must be a better way.

Two Ways to Improve Scalability The two primary ways to eliminate the need for a full BGP mesh are route reflection, as defined in RFC 4456, and BGP confederations, as defined in RFC 3065. This appendix explores the configuration and operation of route reflection. Appendix A–4 • BGP Route Reflection

www.juniper.net


IBGP Peers Can Readvertise Routes BGP route reflection relaxes the restriction that an IBGP peer should not readvertise IBGP-learned routes to other IBGP speakers. The routers allowed to override this default behavior are known as route reflectors (RR).

RR Sends the Active Route RRs only readvertise the active routes to their clients. You configure an RR by using the cluster statement within an IBGP peer-group configuration. BGP considers each of the peers configured within that peer group to be clients of the RR. The RR clients require no configuration changes; they do not have any knowledge of the presence of the RR—they simply see the RR as an IBGP peer.

IBGP Attributes Not Changed One of the primary drivers behind requiring the IBGP full mesh in the first place is loop prevention. This is because the AS-path attribute is not modified within an AS. Route reflection does not change that behavior. In fact, none of the existing BGP attributes changes, by default, when BGP uses route reflection in an AS. However, loop prevention is still a critical part of BGP, so new BGP attributes were introduced to facilitate loop detection in a route-reflection network. Continued on the next page.

www.juniper.net



New BGP Attributes Two new BGP attributes are defined to support route reflection; these attributes are the cluster list and the originator ID. An RR creates or modifies these attributes when it readvertises the routes to both clients and nonclients. The RR’s cluster ID is added to all routes that the RR touches, meaning that both clients and nonclients receive the cluster list attribute. This attribute contains a sequence of all cluster IDs that represent all RRs that have handled the route update.


www.juniper.net


New Cluster Attributes Prevent Loops Without the new cluster attributes, a loop can be created: 1.

Client sends routes to RR1;

2.

RR1 sends routes to all clients and to RR2 and RR3; and

3.

Because route reflection allows IBGP peers to send routes to other IBGP peers, RR2 sends the routes to RR3.

RR3 has no way of knowing the routes received from RR2 came from RR1. As a result, RR3 sends them to RR1, forming a loop.

www.juniper.net



Cluster List The cluster-list attribute is analogous to the AS-path attribute and is used to prevent loops. If an RR receives a route with its own cluster ID in the cluster list, it drops the route. In addition, each router in the network can use this attribute in the BGP path-selection algorithm prior to using the peer IP address attribute. BGP chooses the route with the shortest cluster list length. This process follows the same theory as the AS-path attribute. The cluster ID is very similar to an AS number and should be unique within an individual AS. The cluster ID is added to the cluster-list attribute when a route is sent to clients and nonclients.

Originator ID The originator-ID attribute provides the router ID of the first router to advertise the route in the AS. It also is used for loop prevention in the rare case where the cluster list does not prevent a loop.


www.juniper.net


Configuration and Routing Knowledge The slide highlights the topic we discuss next.

www.juniper.net



Clients in a Peer Group Within the Junos operating system configuration syntax, all clients of an individual RR are placed within a single peer group. This placement allows the RR to easily determine which peers are clients of a particular cluster. No configuration changes are needed in the client’s configuration.

RR Uses the cluster Command Once the clients are placed into their respective peer groups, use the cluster command to activate the route-reflection process of the RR. The cluster command is used to assign each cluster its cluster ID. This cluster ID is a 32-bit value that uniquely describes the cluster within the BGP AS. If only a single RR exists in the cluster, the router ID of the RR is often used as the cluster ID. Continued on the next page.


www.juniper.net


RR Uses the cluster Command (contd.) The common practice is to configure the same cluster ID on each reflector when more than one reflector exists within a given cluster. Assigning the same cluster ID has the advantages of reducing the total number of routes stored, and it tends to make sense when cluster and route-reflection boundaries are graphically depicted. Some people maintain that it is better to assign unique cluster IDs in these circumstances; the main advantage to unique cluster IDs is that the routes exchanged between RRs in that cluster are now stored because the receiving RR does not detect its own cluster ID. While this approach increases the number of routes being stored, it can offer increased redundancy in certain situations. The redundancy benefits of assigning unique cluster IDs are largely made moot by the practice of loopback peering for IBGP sessions, which is why the assignment of a common cluster ID is generally considered the current best practice.

Clients Peer to RRs The clients in the cluster must peer to the RR itself. The clients have no knowledge of the cluster and see the reflector as a regular IBGP peer.

www.juniper.net



Basic Route Reflection The slide shows an AS network using a typical route-reflection topology. BGP-speaking routers along the edge of the network all have a single peer configured in the form of the RR for the local cluster. The RRs are, in turn, fully meshed using standard IBGP peering procedures. The result is that all routes received by any BGP router will eventually be seen by all other BGP routers in the AS. It is a common best practice to have the logical route-reflection topology follow the physical topology of the network.


www.juniper.net


Route Propagation The next series of slides shows the flow of routing information in a route-reflection network using a basic topology. We begin with a client in the left-most cluster advertising the 10.10.10.0/24 route to the cluster’s RR (RR1). The slide details how the 10.10.10.0/24 route is readvertised to all other clients in the cluster as well as to all nonclient IBGP peers of the RR. This process applies to all other routes the RR receives from a client in its cluster. This slide shows how the other RRs in the network (RR2 and RR3) readvertise all routes received from IBGP peers (the other reflectors in this example) to all of their cluster clients.

www.juniper.net



Dual RRs in a Cluster The slide shows a cluster containing two RRs. This type of cluster design is popular because it avoids a single point of network failure. When a cluster has only a single RR, the clients might become segmented from the network in the event of a failure of that RR. A design that includes two RRs in each cluster ensures that the failure of a single router does not segment the network. Each of the client routers simply configures two IBGP peers and forwards EBGP-learned routes to both RRs. The RRs themselves can peer either within the cluster as clients of each other or outside of the cluster as normal IBGP peers. Either way, routes from within the cluster are dropped when advertised between the RRs because of cluster list routing loops. Each of the RRs also establishes IBGP peering sessions with the other RRs in the entire AS. As previously mentioned, a debate exists as to whether each RR should be assigned the same cluster ID or a unique cluster ID. In most cases, using unique cluster IDs is preferred. The drawback is that using unique cluster IDs requires more BGP route state at the RRs. This generally does not outweigh the advantage of maintaining connectivity.


www.juniper.net


Hierarchical Route Reflection The slide shows an AS network using a more complex, hierarchical, route-reflection topology. Hierarchical route reflection occurs when the RRs for some clusters are themselves clients in another route-reflection cluster. Very often, AS networks evolve to this type of setup when the reflector full mesh shown on a previous slide becomes too large to manage. In this case, the internal RR full mesh might evolve into a route-reflection cluster.

www.juniper.net



Clients Can Peer with Other Clients Clients within a cluster can peer with other clients in a full-mesh environment. This ability does not change the operation or need for the RR. The reflector still sends routes from the clients to the remainder of the IBGP network and forwards routes from the IBGP network into the cluster. What the client full mesh does provide is the ability of clients to use other clients’ routes natively when logical BGP connectivity exists between the clients. In this situation, each of the clients receives two versions of the route. One version is from the other client, and one version is from the RR. Because the extra copy of the route from the reflector is not needed, you can disable the internal cluster readvertisements using the no-client-reflect command. Once configured, the RR only forwards, to the clients, routes that arrive from outside of the cluster.


www.juniper.net


RR Can Modify Attributes The default operation of a RR is to not modify any BGP defaults. However, the Junos OS does allow an applied routing policy to do just that. The reason for this action is the support of customer networks. For reasons outside the scope of this course, some network administrators engineer traffic flows by altering attribute values when the RR readvertises routes from a nonclient into the cluster. This alteration is supported through the use of routing policies applied to the cluster's peer group.

Forwarding Paths Should Be Unaffected Although a client learns of a route from the cluster’s RR, the RR itself does not have to be in the forwarding path for packets sent from clients toward the route destination. In fact, oftentimes it is not. In the example on the slide, the 172.16.2.2 cluster client advertises the 192.168.0.0/16 route to the cluster’s RR with the BGP next hop set to its router ID. Because an active next-hop-self policy exists on the RR, the BGP next hop is overwritten with the router ID of the RR—172.16.1.1. When client 172.16.3.3 receives and installs this route, suboptimal forwarding occurs as packets are sent through the RR instead of directly to 172.16.2.2. This situation might occur when the RR also has EBGP peering sessions established. Most network designs avoid this problem by placing their RRs within the core of their networks. Continued on the next page.

www.juniper.net



Forwarding Paths Should Be Unaffected (contd.) The solution to this problem is a selective next-hop-self policy on the RR that modifies the BGP next hop for only EBGP-learned routes. This type of policy normally makes use of the from neighbor or from interface match conditions, as shown here. In this example, the RR has an EBGP peering session with the 172.16.0.1 address: [edit policy-options] user@router# show policy-statement selective-nhs term only-EBGP-routes { from { protocol bgp; neighbor 172.16.0.1; } then { next-hop self; } }


www.juniper.net


This Appendix Discussed:

www.juniper.net

•

The operation of BGP route reflection; and

•

How to configure an RR.





www.juniper.net


Lab 10: BGP Route Reflection (Optional) The slide lists the objective for this lab.

www.juniper.net




www.juniper.net

Appendix B: Acronym List ABR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . area border router AF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . assured forwarding AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . autonomous system ASBR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . autonomous system boundary router ASM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . any-source multicast BE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . best effort BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Border Gateway Protocol BGP4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Border Gateway Protocol version 4 CBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .class-of-service-based forwarding CBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . connection-based forwarding CIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . committed information rate CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .command-line interface CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .class of service C-RP-adv. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .candidate RP advertisement CS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . class selector DR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .designated router DSCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DiffServ code point DVMRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Distance Vector Multicast Routing Protocol EGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . exterior gateway protocol GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .graphical user interface HDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .High-Level Data Link Control IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Internet Assigned Numbers Authority IBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . internal BGP IGMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Group Management Protocol IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . interior gateway protocol IPsec. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .IP Security IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .IP version 4 ISP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet service provider JNCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Juniper Networks Certification Program LSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . link-state advertisement LSDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . link-state database MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .media access control MDRR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . modified deficit round-robin MOSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Multicast Open Shortest Path First NC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . network control NLRI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . network layer reachability information NSSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . not-so-stubby area OSPF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open Shortest Path First PID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .process ID PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol Independent Multicast PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Point-to-Point Protocol QoS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . quality of service RID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . router ID RP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . rendezvous point rpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . routing protocol daemon RPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . reverse path forwarding RPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . reverse-path multicasting RR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .route reflector SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simple Network Management Protocol SPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .shortest-path-first SPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . shortest path tree SSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .source-specific multicast ToS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . type of service TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . time-to-live

www.juniper.net

Acronym List • Appendix B–1

Appendix B–2 • Acronym List

www.juniper.net

Appendix C: Answer Key Chapter 1:

Course Introduction This chapter contains no review questions.

Chapter 2:

OSPF 1. LSA Type 9 supports graceful restart. 2. The metric or cost of a router’s links can be automatically altered with the reference-bandwidth command. 3. The different forms of OSPF authentication include none, simple, and MD5.

Chapter 3:

OSPF Areas 1. The ABR does not forward Type 4 and Type 5 LSAs into a stub area or NSSA. Type 3 LSAs are also not forwarded in an OSPF NSSA with no summaries. 2. You must configure all routers that are in the stub area or NSSA. 3. The ABR of the stub area can optionally inject a 0.0.0.0/0 default route into the stub area or NSSA. 4. The backbone area is directly affected by the area-range command. However, any area that is able to receive summary LSAs also benefits from this command.

Chapter 4:

OSPF Case Studies and Solutions 1. You risk double-exporting routes, which can lead to routing loops. 2. Although technically you do not need a backbone area, functionally you need one because of the loop prevention mechanisms in OSPF. 3. Virtual links would be deployed if two companies were merging their networks together and physical link connectivity was not an option. This could be because of cost or time constraints. 4. If the source route has a lower preference, there usually are no issues. If a source route has a higher preference, suboptimal routing or loops can occur.

www.juniper.net

Answer Key • Appendix C–1

Chapter 5:

BGP 1. Using loopback addresses for peering sessions between IBGP neighbors maintains reachability even when the physical topology changes as long as a viable path exists. 2. EBGP-learned routes are advertised to both EBGP and IBGP peers. IBGP-learned routes are advertised to EBGP peers. However, IBGP-learned routes are not advertised to other IBGP peers to prevent routing loops. 3. With the Junos OS, all new BGP routes have an origin code of I=Internal. When you configure multipath on a BGP router, the route selection algorithm ignores both the router ID and the peer ID selection criteria. The five valid ways to solve the BGP next-hop issue are: Next-hop self; IGP passive interfaces; Export direct routes into IGP; Static routes; and IGP adjacency formed on inter-AS links to EBGP peers.

Chapter 6:

BGP Attributes and Policy 1. Import policy is enforced between the RIB-IN and RIB-LOCAL tables. 2. Export policy is only enforced on active routes. 3. The three BGP attributes that must be in every update are origin, AS-path, and next-hop. 4. The “^” symbol denotes the beginning of an AS path. 5. The next-hop attribute is only modified when it is advertised across an EBGP session.

Chapter 7:

Enterprise Routing Policies 1. The benefits of BGP include routing policy control, diverse administrative control, and handling of large prefix counts. 2. The longest subnet ISPs will usually accept is a /24 subnet mask. 3. The course discusses topology driven, primary/secondary, and load-shared per-prefix routing policies. (Recall that some of these names are not industry-standard terms, but are merely attempts to accurately describe a class of routing policies.) In general, a topology-driven policy strategy provides the best performance, but usually at an increased cost and with the possibility of insufficient bandwidth in the event of a failure. In general, a primary/secondary policy strategy provides the best performance in a failure mode (because it should, if implemented correctly, provide equal bandwidth both in normal and failure operation), but it does so at a greatly increased cost and sometimes sacrifices performance by ignoring the network topology. In general, a load-shared per-prefix policy strategy provides the least expensive network, but it does so by sacrificing performance in the event of a failure and sometimes sacrificing performance in normal operation—by ignoring the network topology.

Appendix C–2 • Answer Key

www.juniper.net

Chapter 8:

Introduction to Multicast 1. Two benefits of using multicast are that it reduces both the load on the source server and the bandwidth usage in a network. 2. The designated router (DR) is the router closest to the source that is responsible for forwarding multicast traffic. 3. The primary purpose of a multicast routing protocol is to build an SPT between sources and receivers. 4. IGMPv3 can be used by a host to request multicast traffic from a particular source.

Chapter 9:

Multicast Routing Protocols and SSM 1. At the moment the receiver’s DR receives the first native multicast packet from the RPT, it learns the source address and joins the SPT. 2. The RPT must remain active and available in case another source begins sending traffic to the same multicast group address, or if another receiver wants to join the existing (S,G). 3. The only dynamic method of learning an RP for PIM version 1 is auto-RP. 4. The router closest to the receiver never initiates a (*,G) Join message for 232/8. Backbone routers never propagates a (*,G) Join message for 232/8. RPs do not accept PIM Register messages or (*,G) Join messages for 232/8. A source DR does not send PIM Register messages to RP for 232/8.

Chapter 10: Class of Service 1. Behavior aggregate classification is performed first. Because a multifield classifier is processed after a behavior aggregate classifier, the multifield classifier can overwrite conflicting values. 2. The loss priority status is an internal flag that is set based on classification or policing actions. 3. A policer can drop a packet or set the forwarding class and loss priority bit.

Appendix A:

BGP Route Reflection 1. The Cluster List attribute and Originator ID attribute support route reflection. 2. The cluster statement is configured only on the route reflector.

www.juniper.net

Answer Key • Appendix C–3

3. The no-client-reflect command can be used to stop excess advertisements. An RR readvertises routes received from clients and nonclients, adding the cluster-ID attribute and the cluster-list attribute. 4. An RR readvertises routes received from clients and nonclients, adding the cluster-ID attribute and the cluster-list attribute.

Appendix C–4 • Answer Key

www.juniper.net

AJER_11.a-R_SG

Recommend Documents