Advanced Junos Routing

Advanced Junos Service Provider Routing 10.b

Student Guide

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

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 Service Provider Routing Student Guide, Revision 10.b Copyright © 2011 Juniper Networks, Inc. All rights reserved. Printed in USA. Revision History: Revision 10.a — March 2011 Revision 10.b—September 2011. 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 10.4R5.5. 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-13 Protocol Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-40 OSPF Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-61 Lab 1: OSPF Multiarea Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-69

Chapter 3: OSPF Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1 Review of OSPF Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3 Stub Area Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9 Stub Area Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-16 NSSA Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-19 NSSA Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-24 Route Summarization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-28 Lab 2: Configuring and Monitoring OSPF Areas and Route Summarization . . . . . . . . . . . . . .3-35

Chapter 4: OSPF Case Studies and Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1 Virtual Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3 OSPF Multiarea Adjacencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-19 External Reachability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-28 Lab 3: Advanced OSPF Options and Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-44

Chapter 5: IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1 Overview of IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3 IS-IS PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-12 Neighbors and Adjacencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-43 Configuring and Monitoring IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-48 Lab 4: IS-IS Configuration and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-65

Chapter 6: Advanced IS-IS Operations and Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . .6-1 IS-IS Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3 IS-IS Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-16 IS-IS Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-31 Lab 5: Advanced IS-IS Configuration Options and Routing Policy . . . . . . . . . . . . . . . . . . . . . .6-43

Chapter 7: Multilevel IS-IS Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1 Level 1 and Level 2 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3 Multilevel Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-10 Lab 6: Configuring a Multilevel IS-IS Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-22

www.juniper.net

Contents • iii

Chapter 8: BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1 Review of BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3 BGP Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-23 BGP Path Selection Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-31 Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-41 Lab 7: BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-59

Chapter 9: BGP Attributes and Policy—Part 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1 BGP Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3 Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-10 Origin and MED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-25 AS Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-45 Lab 8: BGP Attributes: Next-Hop, Origin, MED, and AS Path . . . . . . . . . . . . . . . . . . . . . . . . . .9-72

Chapter 10: BGP Attributes and Policy—Part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1 Local Preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3 Communities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-13 Lab 9: BGP Attributes: Local Preference and Communities . . . . . . . . . . . . . . . . . . . . . . . . . .10-49

Chapter 11: Route Reflection and Confederations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1 Route Reflection Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-3 Configuration and Routing Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-9 BGP Confederations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-19 Lab 10: Scaling BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-28

Chapter 12: BGP Route Damping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1 Route Flap and Damping Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-3 Route Damping Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-10 Configuring and Monitoring Route Damping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-17 Lab 11: BGP Route Damping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-28

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

iv • Contents

www.juniper.net

Course Overview This four-day course is designed to provide students with detailed coverage of OSPF, IS-IS, BGP, and routing policy. 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. This course is based on the Junos OS Release 10.4R5.5.

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.

•

List key differences between OSPFv2 and OSPFv3.

•

Describe OSPF area types and operations.

•

Configure various OSPF area types.

•

Summarize and restrict routes.

•

Identify some scenarios in a service provider network that can be solved using routing policy or specific configuration options.

•

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

•

Explain the concepts and operation of IS-IS.

•

Describe various IS-IS link-state protocol data unit (PDU) types.

•

List IS-IS adjacency rules and troubleshoot common adjacency issues.

•

Configure and monitor IS-IS.

•

Display and interpret the link-state database (LSDB).

•

Perform advanced IS-IS configuration options.

•

Implement IS-IS routing policy.

•

Explain the default operation in multiarea IS-IS.

•

Describe IS-IS address summarization methods.

•

Configure and monitor a multiarea IS-IS network.

•

Describe basic BGP operation.

•

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

•

Explain the causes for route instability.

•

Describe the effect of damping on BGP routing.

•

Explain the default behavior of damping on links.

•

Describe the operation of BGP route reflection.

•

Configure a route reflector. Course Overview • v

•

Describe the operation of a BGP confederation.

•

Configure confederations.

•

Describe peering relationships in a confederation.

•

Control damping using routing policy.

•

View damped routes using command-line interface (CLI) commands.

Intended Audience This course benefits individuals responsible for implementing, monitoring, and troubleshooting Layer 3 components of a service provider’s network.

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

Prerequisites Students should have intermediate-level networking knowledge and an understanding of the Open Systems Interconnection (OSI) model and the TCP/IP protocol suite. 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: OSPF Multiarea Networks Chapter 3: OSPF Areas Lab 2: Configuring and Monitoring OSPF Areas and Route Summarization Chapter 4: OSPF Case Studies and Solutions Lab 3: Advanced OSPF Options and Policy

Day 2 Chapter 5: IS-IS Lab 4: IS-IS Configuration and Monitoring Chapter 6: Advanced IS-IS Operations and Configuration Options Lab 5: Advanced IS-IS Configuration Options and Routing Policy Chapter 7:

Multilevel IS-IS Networks Lab 6: Configuring a Multilevel IS-IS Network

Day 3 Chapter 8: BGP Lab 7: BGP Chapter 9: BGP Attributes and Policy—Part 1 Lab 8: BGP Attributes: Next-Hop, Origin, MED, and AS Path

Day 4 Chapter 10: BGP Attributes and Policy—Part 2 Lab 9: BGP Attributes: Local Preference and Communities Chapter 11: Route Reflection and Confederations Lab 10: Scaling BGP (Detailed) Chapter 12: BGP Route Damping Lab 11: BGP Route Damping (Detailed)

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 Service Provider Routing Student Guide was developed and tested using software Release 10.4R5.5. 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 Service Provider Routing Chapter 1: Course Introduction

Advanced Junos Service Provider 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.

Course List 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 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. Associate-level and Specialist-level exams are computer-based exams composed of multiple choice questions administered at Prometric testing centers worldwide. Professional-level and Expert-level exams are composed of hands-on lab exercises administered at select Juniper Networks testing centers. Professional-level and Expert-level exams require that you first obtain the next lower certification in the track. Please visit the JNCP Web site at http://www.juniper.net/certification for detailed exam information, exam pricing, and exam registration. Chapter 1–12 • Course Introduction

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.

www.juniper.net




www.juniper.net

Advanced Junos Service Provider Routing Chapter 2: OSPF


This Chapter Discusses:

Chapter 2–2 • OSPF

•

OSPF link-state advertisements (LSAs);

•

The flooding of LSAs throughout the network;

•

The shortest-path-first (SPF) algorithm; and

•

The key 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: •

LSAs are installed in the OSPF database that forms the topology map of the network; and

•

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 known as 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. Most Ethernet segments are point-to-point, full-duplex these days, which eliminates the need for a DR election. Use the interface-type p2p command to change the default interface type.

www.juniper.net



The LSDB 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 contents 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 or 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.


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 Service Provider 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. Area 1, Area 2, and Area 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 those 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

•

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 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 also be an internal or 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 an OSPFv2 single 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


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



OSPFv3 Protocol Highlights OSPFv3 is to IP version 6 (IPv6) what OSPFv2 is to IP version 4 (IPv4). OSPFv3 is defined in RFC 5340 and supports IPv6 addressing.

OSPFv3 Versus OSPFv2 OSPFv3 and OSPFv2 have much in common, but OSPF has many differences that take advantage of the new features of IPv6. Some but not all of the differences are listed on this slide.

Beyond the Scope An in-depth discussion of OSPFv3 is beyond the scope of this course.


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


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 OSPF (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.


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 Dijkstra (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 50 minutes (3000 seconds).

LSAs Not Supported The Junos OS does not support some of the previously listed LSA types. 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:

www.juniper.net

•

LS age (2 bytes): Measured in seconds, the link state age is the time since 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.

•

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

•

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

•

LS checksum (2 bytes): The checksum of the entire LSA contents, minus the link state 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.



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:


•

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.

•

Number of links (2 bytes): This value gives the total number of links represented by the following set of fields.

•

Link ID (4 bytes): This field represents to what the far side of the link is connected. It is used in conjunction with the link type field.

•

Link data (4 bytes): This field represents to what the near side of the link is connected. It is used in conjunction with the link type field.

•

Link type (1 byte): This field describes the type of link.

•

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

•

Metric (2 bytes): This field provides the cost to transmit data out of the interface.

•

Additional ToS data (4 bytes): This field is unused. www.juniper.net


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:

www.juniper.net

•

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 designated router. 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.



Router LSA Example The slide shows the details of the router LSA in the example. 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: •

This router is both an ABR as well as an ASBR, which we can see 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.)

www.juniper.net

•

The router LSA will be regenerated in 48 minutes and 50 seconds as indicated by the Gen timer. The OSPF standard requires that every LSA be refreshed every 60 minutes. The Juniper implementation refreshes LSAs every 50 minutes. By default, any LSA that is not refreshed expires after 60 minutes.

•

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.20.1. Also note that the last line of the capture states that this LSA is Ours.

•

The router LSA was installed 1 minutes and 10 seconds ago. If not refreshed, the LSA will expire in 58 minutes and 50 seconds, when its 3600 second maximum age is exceeded. The LSA was last flooded 1 minutes and 8 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.



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:


•

We know of three routers within area 0.0.0.0—192.168.20.1 (the local router), 192.168.100.1, and 192.168.21.1;

•

Two point-to-point subnets connect the three routers—172.22.121.0/24 and 172.22.122.0/24;

•

The IP address of the interface connecting 192.168.20.1 to 192.168.100.1 is 172.22.121.1;

•

The IP address of the interface connecting 192.168.21.1 to 192.168.100.1 is 172.22.122.1.

www.juniper.net


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:

www.juniper.net

•

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.



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 examining the LSA closely:


•

The designated router for this network is 10.0.12.2, 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.2 and 192.168.20.4.

www.juniper.net


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.20.1 router.

www.juniper.net

•

We know of two routers within area 0.0.0.10—192.168.20.2 and 192.168.20.4;

•

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

•

The designated router for the segment is 192.168.20.4 and its interface address is 10.0.12.2.



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:


•

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 ToS information encoded within the network described. The Junos OS does not use this field.

•

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

www.juniper.net


Summary LSA Example The slide shows the details of the summary LSA in the example. 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: •

This router is an ABR because it contains a database for area 0.0.0.0. Within that area, three summary LSAs are listed. Two of the LSAs (the first and second ones listed) are from the router where the capture was taken. As with the router LSA earlier, notice that an asterisk (*) is next to the link-state ID values of 10.0.10.0 and 10.0.12.0. Also note that the last line of the LSA states that the LSA is Ours.

•

A second router in the backbone (192.168.21.1) generates the other summary LSA. The network advertised by that ABR is 10.0.14.0/24. The network has a metric of 1 encoded within the LSA. The local router adds the cost to reach 192.168.21.1 to the metric of 1 prior to calculation of the SPF algorithm.

Note that the command output on the slide is truncated.

www.juniper.net



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


•

A new router exists in an OSPF area connected to 192.168.21.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.21.2.

•

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

•

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

www.juniper.net


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:

www.juniper.net

•

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.



ASBR Summary LSA Example The slide shows the details of the ASBR summary LSA in the example. 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.


•

This router is an ABR because it contains a database for Area 0.0.0.0. Within that area, two ASBR summary LSAs are listed on the slide. The second LSA is from the local router (where the capture was taken). As with the router LSA earlier, notice that an asterisk (*) is 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.21.1) generates the other ASBR summary LSA.

•

The two ASBRs being advertised are 192.168.21.2 and 192.168.20.4. 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.

www.juniper.net


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:

www.juniper.net

•

Routers 192.168.20.4 and 192.168.21.2 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.20.1 and 192.168.21.1 generate ASBR summary LSAs across the area boundaries. In our case, we see the type 4 LSAs within area 0.0.0.0.



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:


•

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. www.juniper.net


AS External LSA Example The slide shows the details of the AS external LSA in the example. 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

•

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 20.20.1.0/24, 20.20.3.0/24, 20.20.5.0/24, and 20.20.6.0/24. Each of these networks has a metric value of 0 encoded. In addition, each of these LSAs is a Type 2 metric (as seen by the type field). Type 2 is the default type for route redistribution. It reflects only the cost of the path from the ASBR to the destination. A Type 1 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.



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:


•

The 20.20.1.0/24 route is being injected by the 192.168.20.1 router;

•

The 20.20.3.0/24 route is being injected by the 192.168.21.1 router;

•

The 20.20.5.0/24 route is being injected by the 192.168.20.4 router; and

•

The 20.20.6.0/24 route is being injected by the 192.168.21.2 router.

www.juniper.net


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 The slide shows the details of the NSSA external LSAs in the example. The 192.168.21.2 ASBR generated the second 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:

www.juniper.net

•

Notice that the LSA is listed within the area 0.0.0.20 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 20.20.6.0/24. This network has a metric value of 0 encoded. It also is listed as a Type 2 metric (as seen by the type field).

•

The NSSA does 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.21.2.



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


•

The area attached to the 192.168.21.1 router is area 0.0.0.20. It is also currently configured as an NSSA.

•

The 20.20.6.0/24 route is being injected into area 0.0.0.20 as a Type 7 LSA. It is translated into a Type 5 LSA by the 192.168.21.1 router.

www.juniper.net


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. www.juniper.net



Protocol Operations The slide highlights the topic we discuss next.


www.juniper.net


LSA Flooding Scopes As discussed on previous slides, each LSA in the OSPF protocol has a specific scope within which it can be flooded. This 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 towards the ASBR that is advertising a given external prefix. This capability leads to Type 4 LSAs for Area 0 being injected into Area 1, Area 2, and Area 3, while a Type 4 for Area 3 is injected into Area 0, Area 1, and Area 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:


•

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. www.juniper.net


OSPF Database Protection This feature limits the number of LSAs that were not generated by the local router. This limit protects the LSDB from being flooded with excessive LSAs. Once the specified maximum LSA count is exceeded, the database typically enters the ignore state. In this state, all neighbors are brought down, and nonself-generated LSAs are destroyed. In addition, the database will send out hellos but ignore all received packets, not form any full neighbors, and therefore not learn about new LSAs. However, if you had configured the warning-only option, only a warning is issued and the database does not enter the ignore state but continues to operate as before. Overall, this feature can be very useful if a VPN routing and forwarding (VRF) instance is configured to use OSPF between the PE and CE routers.

www.juniper.net



Dijkstra Algorithm After a router receives a new LSA and places it into the LSDB, the router runs an algorithm known as the Dijkstra algorithm (also called the shortest-path-first 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, and cost), which describe each link in the network. OSPF evaluates 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. This evaluation is repeated until only the lowest-cost tuple per neighbor ID remains. Continued on the next page.


www.juniper.net


Dijkstra Algorithm (contd.) When 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: 1.

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.

2.

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 in regards 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 [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 is 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 was 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-A. 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 Because 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-A 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-A 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 allows the routing process (rpd) to not consume excessive CPU resources 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 (ms); 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 ms to 1000 ms (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 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 ms, you might set the delay to 250 ms. This setting allows time for all of the duplicate LSAs to arrive at all routers before the SPF calculation is performed. Chapter 2–52 • OSPF

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 previous formula, 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, two routers on either side of a link can 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 R1 router calculating a total cost of 45 to reach the R4 router, while the R4 router calculates a total cost of 60 to reach the R1 router. While the configuration of different metrics for a single link does not affect the operation of OSPF, asymmetric routing might occur within the network. Asymmetric routing might cause response delays for some end users and make it challenging for network administrators to troubleshoot the network.

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 daemon (RPD) 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. Chapter 2–56 • OSPF

www.juniper.net


Case Study Service provider networks are typically built with multiple paths from ingress and egress points for redundancy. During maintenance operations on a router, preventing the router from receiving and forwarding transit traffic can be beneficial. The overload feature provides this function. In the graphic, 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 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 if 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 there is only a 127/8 address configured on the loopback, the router will choose the first available IP address on an interface as the Router ID. Continued on the next page.


www.juniper.net


Router ID Is the Primary Interface (contd.) Because the OSPF routing process uses an IP address 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 are 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 most networks, routers will have a unique IP address configured as their loopback address. 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 your loopback IP address, which might also be your RID, into the network. However, keep several important points 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 four different forms of authentication that the Junos OS supports are none, simple, MD5, and IPsec. IPsec was added as of the Junos OS release 8.3. IPsec is configured at the [edit protocols ospf area area-id interface interface-name] hierarchy using the set ipsec-sa name; command. See the Junos OS Routing Protocols Configuration Guide for more information.

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 vales 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 on 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 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 commands 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 due to 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


This Chapter Discussed:

www.juniper.net

•

OSPF LSAs;

•

The flooding of LSAs throughout the network;

•

The SPF algorithm; and

•

The key difference between OSPFv2 and OSPFv3.



Review Questions 1. 2. 3.


www.juniper.net


Lab 1: OSPF Multiarea Networks The slide lists the objectives for this lab.

www.juniper.net




www.juniper.net

Advanced Junos Service Provider Routing Chapter 3: OSPF Areas



OSPF area types and operations;

•

The configuration of various OSPF area types; and

•

The summarization and restriction of 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 Link-State Database 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 LSA flooding, you can also perform route summarization on the borders between OSPF areas. Route summarization has two key benefits: •

It reduces the size of the LSDB; and

•

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. Chapter 3–4 • OSPF Areas

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 Routers OSPF routers can perform several different roles within an OSPF domain. The following list shows the common types of OSPF routers along with a brief description: •

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 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 also be an internal or area border router 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.


www.juniper.net


OSPF Area Types The 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 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 stub area with no-summaries 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



Default LSA Flooding Scopes As discussed in a previous chapter, each LSA in the OSPF protocol has a specific scope within which it can be flooded. The slide graphically displays those flooding scopes. Note that 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 non-backbone areas to provide routing information to those routers. This process results in Type 3 LSAs within every area that represent all OSPF internal 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) representing those routes have a domain flooding scope (with the exception of stub areas). As such, they exist within each OSPF area. The OSPF routers use either the router LSA or the ASBR summary LSAs (Type 4) to gain knowledge of how to best route to the advertising ASBRs. Much like the Type 3 LSAs, the ASBR summary LSAs have area scope, so they are bound by the area border. However, the ABR has the capability to regenerate and forward Type 4 LSAs across area boundaries to provide the required knowledge of the best routes to each ASBR. This capability leads to Type 4 LSAs for Area 0 and Area 3 being within all the OSPF areas in the network.


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. In addition, the ABR also stops generating Type 4 summary LSAs, because they 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, which 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 will generate one or more Type 5 LSAs and place them into its local database. However, these external LSAs cannot be sent out any interfaces supporting stub operation. 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 this example, Area 1 is now configured as a stub area, which 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. 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–14 • 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 also 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. While 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 will only form 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 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 towards 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 7 LSA by default. If the area is an NSSA with no-summaries the default route will be in a Type 3 LSA.

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.


www.juniper.net


NSSA Flooding Scopes Area 3 is now configured as a not-so-stubby area. 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



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.

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 injection. The command causes the ABR to generate a Type 7 NSSA External Links LSA to advertise the 0.0.0.0/0 default route into the area with the configured metric. If the NSSA is configured with no-summaries a Type 3 Summary LSA is advertised.

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, which 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. The type-7 command within the default-lsa hierarchy 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.) The Type 7 LSA is advertised using an External Type 1 (E1) 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 an External Type 2 (E2) metric, which means that each area router uses only the advertised metric of the route.

www.juniper.net



Route Summarization This 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 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, which 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 non-backbone 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 on this page is specific to the NSSA configuration hierarchy and affects only 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 will prevent 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



www.juniper.net

•

OSPF area types and operations;

•

The configuration of various OSPF area types; and

•

The summarization and restriction of routes.



Review Questions 1. 2. 3. 4.


www.juniper.net


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

www.juniper.net




www.juniper.net

Advanced Junos Service Provider Routing Chapter 4: OSPF Case Studies and Solutions



The configuration of OSPF virtual links;

•

The configuration of OSPF multiarea adjacencies; and

•

OSPF external reachability.

Chapter 4–2 • OSPF Case Studies and Solutions

www.juniper.net


Virtual Links 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


Area Border Router Technically speaking, an area border router (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 link-state advertisement (LSA), also referred to as a Type 1 LSA. The slide indicates this setting by the bits field of 0x1. The other bits in the field are used to indicate virtual links or autonomous system boundary routers (ASBRs).

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 To change things up a bit, connect another area to R5. 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 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 2324: “Any router running OSPF attached to multiple areas is known as Area Border Router (ABR). An ABR will have topological information of all attached areas and will run SPF for each 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 0’s together to form a single contiguous backbone. The easiest solution will be new physical connections between the routers in each company. However, this solution is often easier said than done, and time can be a deciding factor. For these cases, a temporary solution such as virtual tunnels or virtual links can be deployed.


www.juniper.net


Case Study In this case study, ISP A has acquired ISP B. Both networks are running multiarea OSPF and they 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 companies, 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 companies. In this case, the integration team chose to connect ISP A’s A6 router and ISP B’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 ISP A’s Area 0. However, ISP A’s Area 0 routers cannot reach ISP B’s Area 0 routers. The cause of this limited connectivity is the lack of a contiguous Area 0 backbone.


www.juniper.net


Virtual Tunnels One solution to the connectivity problem is to create a virtual tunnel between the two backbone areas of the companies. 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 companies. Remember that a virtual tunnel 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 company. These ABRs must be attached to Area 0.


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 link-state database (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 company are installed into the routing table.


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. For example, you configure an interface to belong to multiple areas with a high-speed backbone link between two ABRs to enable you to create multiarea adjacencies that belong to different areas. As defined in RFC 5185, OSPF Multi-Area Adjacency, the ABRs 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 each area, one of the logical interfaces is treated as primary, and the remaining interfaces that are configured for the area are designated as secondary.


www.juniper.net


Case Study 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, which 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, R1 is one hop away from R3.


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 3 hop path.

www.juniper.net



Multiarea Adjacency Configuration To configure multiarea adjacency in the Junos operating system, configure a secondary logical interface for an OSPF area using the secondary statement. Any logical interface not configured as a secondary interface for an area is treated as a primary interface for that area. A logical interface can be configured as a primary interface for only one area. For any other area in which you configure the interface, you must configure it as a secondary interface.

Point-to-Point Interface Interface ge-1/0/4.1100 now has two OSPF links, however, the secondary link show up as a point-to-point interface.


www.juniper.net


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

Trace with Multiarea With the multiarea adjacency feature configured, the trace now requires only 2 hops, compared with the default case of 3 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 send without a routing policy applied.

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 issue, 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 were used, creating a logical AND. This policy will be applied to both R1 and R2 under [edit protocols ospf] 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 LSA associated with the RIP route.

www.juniper.net



ABR Translation Because the route was originated from the 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 ASBR’s address into the forwarding address. This action supports optimal routing because only one ABR will translate the Type 7s to Type 5s in the presence of multiple ABRs. This router might not be in the optimal path for routers in other areas.

ASBR Summary The ABRs also create 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 into OSPF 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 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 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, and 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 policy 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


The Junos OS Supports Large Numbers of Routes 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. While this protocol stability is a nice feature, a configuration mistake could make a portion of your network unusable, because only the Juniper Networks routers 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 zero 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



This Chapter Discussed: •

The configuration of OSPF virtual links;

•

The configuration of OSPF multiarea adjacencies; and

•

OSPF external reachability.


www.juniper.net



www.juniper.net



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


www.juniper.net

Advanced Junos Service Provider Routing Chapter 5: IS-IS



Chapter 5–2 • IS-IS

•

IS-IS concepts and operation;

•

IS-IS link-state protocol data unit (PDU) types;

•

IS-IS adjacency rules and troubleshooting; and

•

The configuration and monitoring of IS-IS in the Junos operating system;

www.juniper.net


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

www.juniper.net

IS-IS • Chapter 5–3


The IS-IS Protocol The IS-IS protocol is an IGP that uses link-state information to make routing decisions. It also uses the shortest-path-first (SPF) algorithm, similar to OSPF.

The ISO The protocol was developed by Digital Equipment Corporation for its DECnet Phase V. The International Organization for Standardization (ISO) standardized IS-IS to be the routing protocol for the ISO's Connectionless Network Protocol (CLNP) and is described in ISO 10589. The ISO was working on IS-IS at the same time as the Internet Advisory Board (IAB) was working on OSPF. ISO proposed that IS-IS be adopted as the routing protocol for TCP/IP in place of OSPF. This proposal was driven by the opinion that TCP/IP was an interim protocol suite that would eventually be replaced by the Open Systems Interconnection (OSI) suite.


www.juniper.net


CNLS Connectionless Network Service (CLNS) is the service that CLNP provides to route messages to their destinations. This service is independent of any other messages and can transmit data before a circuit is established. M, MX, and T Series routers only support IP routing with IS-IS. They do not support CLNP or CLNS routing. Full IS-IS CLNP routing (including End System–to–Intermediate System [ES-IS] routing) is supported on SRX Series Gateways and J Series Routers.

Dual IS-IS The Integrated IS-IS protocol was proposed to support the transition from TCP/IP to OSI. Integrated IS-IS, also known as dual IS-IS, provides a single routing protocol capable of routing both CLNS and IP. Integrated IS-IS was developed to operate in a CLNS, IP, or CLNS/IP setting.

Single Algorithm Like all integrated routing protocols, Integrated IS-IS requires that all routers run a single routing algorithm. LSPs sent by routers running Integrated IS-IS include all destinations running either IP or CLNP Network Layer protocols. Routers running Integrated IS-IS still must support protocols such as the Address Resolution Protocol (ARP), the Internet Control Message Protocol (ICMP) for IP, and the ES-IS protocol for CLNP. Continued on the next page.

www.juniper.net



LSPs Standard IS-IS packets must be modified to support multiple Network Layer protocols. IS-IS packet formats were designed to support the addition of new fields without a loss of compatibility with nonintegrated versions of IS-IS. IS-IS adds type/length/value (TLV) objects (discussed further on the following pages) to support integrated routing. These TLVs tell intermediate systems (ISs) which Network Layer protocols are supported by other ISs and whether end stations running other protocols can be reached. They also include any other required Network Layer, protocol-specific information.


www.juniper.net


Operation of IS-IS An IS-IS network is a single AS, also called a routing domain, that consists of end systems (ESs) and intermediate systems (ISs). End systems are network entities that send and receive packets. Intermediate systems—which is the OSI term for a router—send and receive packets and relay, or forward, packets. IS-IS packets are called PDUs.

IS-IS Areas In IS-IS, a single AS can be divided into smaller groups called areas. Routing between areas is organized hierarchically, allowing a domain to be divided administratively into smaller areas. IS-IS accomplishes this organization by configuring Level 1 and Level 2 intermediate systems. Level 1 systems route within an area, and Level 2 intermediate systems route between areas and toward other ASs. A Level 1/Level 2 system routes within an area on one interface and between areas on another. A Level 1/Level 2 system sets the attached bit in the Level 1 PDUs that it generates into a Level 1 area to indicate that it is a Level 2-attached backbone router and that it can be used to reach prefixes outside the Level 1 area. Level 1 routers create a default route for interarea prefixes, which points to the closest (in terms of metrics) Level 1/Level 2-attached router.

www.juniper.net



Network Entity Title The slide displays a sample IS-IS network with two distinct areas configured—49.0001 and 49.0002. The area address can range from 1 to 13 bytes in length and is always the first component of the Network Entity Title (NET) address. The middle portion of the NET is the system ID of the router, which should be unique throughout the entire domain. The system ID is always 6 bytes and can be any set of hexadecimal digits you want. One common convention is placing the IP address of the loopback interface into the system ID portion of the NET. You accomplish this convention by ensuring that the dotted-decimal IP address is written with all of the leading zeros filled in. On the slide, the router in the top left of the network has 192.168.16.1 configured as its loopback address. This address can also be written as 192.168.016.001. We now have an address with 12 digits in it, exactly the number we need for the system ID. We simply move the dots between the digits into a format used in the hexadecimal notation. This process results in a system ID of 1921.6801.6001.


www.juniper.net


IS-IS and OSPF Common Features The slide lists the commonalities between IS-IS and OSPF.

www.juniper.net



OSPF Areas IS-IS and OSPF are link-state routing protocols with many similarities. Differences exist between them as well. Recall that, under OSPF, routers separate areas. The slide shows how a typical OSPF network might be broken up into areas. Some interfaces are in one area, and other interfaces are in another area. When an OSPF router has interfaces in more than one area, it is an ABR.


www.juniper.net


IS-IS Areas In IS-IS areas, a Level 1/Level 2 router fulfills the same purpose as an area border router (ABR) in OSPF. Likewise, the collection of Level 2 routers in IS-IS is the backbone, while Area 0 is the backbone in OSPF. However, in IS-IS, all routers are completely within an area, and the area borders are on the links, not on the routers. The routers that connect areas are Level 2 routers, and routers that have no direct connectivity to another area are Level 1 routers. An intermediate system can be a Level 1 router, a Level 2 router, or both (an L1/L2 router).

www.juniper.net



IS-IS PDUs The slide highlights the topic we discuss next.


www.juniper.net


Describes Adjacency State The LSP that each IS-IS router generates describes the state of the local router and its adjacencies in the network. Some fields of interest in the LSP header include the ID length and the maximum area address, which are set to a constant value of 0x00. This value does not mean that the Junos OS does not support their functionality. Instead, these fields are used for backward compatibility with older protocol implementations. The system ID is always 6 bytes in length, and the maximum area addresses supported is always 3 bytes. By setting these two fields to a value of 0, the Junos OS is reporting that it supports the default values for these two settings. You might also notice that the LSP header contains two version fields. The first of these fields, according to the original IS-IS specification, was designed as an extension of the protocol ID field. Most modern implementations, including the Junos OS, do not support this function and instead place a constant value of 0x01 in the field to represent the version of the protocol. The second version field is the actual specified location for the protocol version, which is also set to a value of 0x01—the current version of the protocol. Continued on the next page.

www.juniper.net



Flooded Periodically The IS-IS LSPs are flooded when either a network change occurs or often enough to keep the database from having stale information. Each LSP has a 2-byte field named the remaining lifetime. Each IS-IS router initializes this field to a certain value when the LSP is created. By default, this timer value is set to 1200 seconds, or 20 minutes. Each router takes this value and begins a countdown toward 0. Before the timer expires (at approximately 317 seconds), the originating system regenerates the LSP and floods it to all its neighbors.

Contains TLV Segments Each individual LSP contains multiple TLV segments that describe the originating router. Many possible TLVs can be sent, but each system only sends those that it needs to communicate to adjacent systems. The details of the TLV segments are discussed in future slides using the output of the show isis database extensive command. You can also view the received TLVs using the monitor traffic detail command. The following output shows a sample from this command: user@router> monitor traffic detail interface so-0/1/0 size 1514 Listening on so-0/1/0 11:55:48.470418 In ISIS(186), 30:30:30:30:30:30 > 30:30:30:30:30:30, hlen: 27, v: 1, sys-id-len: 6 (0), max-area: 3 (0), L2 LSP lsp-id: 1921.6804.8001.00-00, seq: 0x00000008, lifetime: 1189s chksum: 0x86c9 (correct), PDU length: 186, L1L2 IS Area address(es) TLV #1, length: 4 Area address (3): 49.0001 Protocols supported TLV #129, length: 2 NLPID(s): IPv4, IPv6 Traffic Engineering Router ID TLV #134, length: 4 Traffic Engineering Router ID: 192.168.48.1 IPv4 Interface address(es) TLV #132, length: 4 IPv4 interface address: 192.168.48.1 Hostname TLV #137, length: 8 Hostname: SaoPaulo IPv4 Internal reachability TLV #128, length: 24 IPv4 prefix: 192.168.48.1/32 Default Metric: 00, Internal, Distribution: up IPv4 prefix: 10.222.60.0/24 Default Metric: 10, Internal, Distribution: up Extended IPv4 reachability TLV #135, length: 17 IPv4 prefix: 192.168.48.1/32 Metric: 0, Distribution: up, no sub-TLVs present IPv4 prefix: 10.222.60.0/24 Metric: 10, Distribution: up, no sub-TLVs present IPv4 External reachability TLV #130, length: 12 IPv4 prefix: 192.168.49.0/24 Default Metric: 00, Internal, Distribution: up Extended IPv4 reachability TLV #135, length: 8 IPv4 prefix: 192.168.49.0/24 Metric: 0, Distribution: up, no sub-TLVs present IS Reachability TLV #2, length: 12 IsNotVirtual IS Neighbor: 1921.6805.2001.00, Default Metric: 10, Internal Extended IS Reachability TLV #22, length: 23 IS Neighbor: 1921.6805.2001.00, Metric: 10, sub-TLVs present (12) IPv4 interface address: 10.222.60.2 IPv4 neighbor address: 10.222.60.1 Authentication TLV #10, length: 17 HMAC-MD5 password: 00bb32fd7712bcea6003e516e2333077


www.juniper.net


PDU Type The 1-byte PDU type field denotes whether the PDU is Level 1 or Level 2 PDU. A value of 18 represents a Level 1 PDU and a value of 20 is a Level 2 PDU. With this exception as well as different multicast destination addresses, the PDU contents and formats are identical to each other.

LSP ID Field The ID of the LSP uniquely identifies it within the IS-IS domain. The 8-octet field is comprised of the router’s system ID (6 bytes), the circuit ID (1 byte), and the LSP number (1 byte). The system ID is located within the NET address of the router and is used exactly as is. The LSP number field represents a fragmented LSP. The initial LSP receives a value of 0x00, and it is incremented by 1 for each following fragment. The circuit ID field helps distinguish LSPs advertised from a single router. By default, all LSPs representing the router as a node use a value of 0x00 for the circuit ID field. When a router is operating as a designated intermediate system (DIS), it places the value of the circuit ID into this field and generates a separate LSP for the broadcast segment. The Junos OS uses a constant value circuit ID value of 0x01 for the loopback interface as well as all point-to-point interfaces. Each broadcast segment receives a unique circuit ID value beginning at 0x02 and incrementing to a maximum value of 0xff. Continued on the next page.

www.juniper.net



Attached Bit Any IS-IS router with a Level 2 adjacency to a system in another area sets the Attached bit in its Level 1 LSP. Level 1 routers can then forward data packets to that attached router for transport out of the local area.

Overload Bit An IS-IS router can set the overload bit to inform the other routers in the network that it is incapable of reliably transmitting transit packets to other portions of the network. While the original intent of the bit was to ease memory problems on individual routers, modern-era routers do not have such constraints. In today’s network environment, the bit is often used to take a router out of service for maintenance or to allow it to fully converge within the network before forwarding traffic.

IS Type Bits The IS type bits inform other routers in the network about the capabilities of the local router. Two possible settings are available for these bits. When the bits are set to a value of 01 (0x01), the local router can support only Level 1 routing. A value of 11 (0x03), however, means that the local router can support both Level 1 and Level 2 routing. These settings are the only two settings possible for these bits.


www.juniper.net


Purpose of IS-IS Hello PDUs The purpose of the IS-IS hello PDU is to allow IS-IS routers to discover IS-IS neighbors on a link. Once the neighbors have been discovered and are adjacent, the hello PDU acts as a keepalive to maintain the adjacency and to inform the neighbors of any changes in the adjacency parameters.

IS-IS Hello PDU Types Two kinds of IS-IS hellos PDUs exist: LAN hello PDUs and point-to-point hello PDUs. The LAN hello PDUs can be divided further into Level 1 and Level 2 hello PDUs. The format of the two types of LAN hello PDUs is identical. Note that on broadcast networks IS-IS Level 1 and Level 2 hellos are coded with multicast address 01-80-C2-00-00-14 or 01-80-C2-00-00-15 respectively.

Hello Transmission Routers send hello packets at a fixed interval on all interfaces to establish and maintain neighbor relationships. The hello interval field advertises this interval in the hello packet. By default, a DIS router sends hello packets every 3 seconds, and a non-DIS router sends hello packets every 9 seconds. Continued on the next page.

www.juniper.net



PDU Fields The following list provides the details of the PDU fields:


•

Circuit type: Defines the router as an Level 1, Level 2, or Level 1/Level 2 router;

•

Source ID: Identifies the system ID of the router that originated the hello PDU;

•

Holding time: Specifies the period a neighbor should wait to receive the next hello PDU before declaring the originating router dead;

•

PDU length: Specifies the length of the entire PDU in octets;

•

Priority: Provides a value between 0 and 127 used for DIS election; and

•

LAN ID: Identifies the system ID or the DIS plus one more octet (the pseudo-node ID) to differentiate this LAN ID from another LAN ID that might have the same DIS.

www.juniper.net


IS-IS LSPs IS-IS sends LSPs at regular intervals and when an IS discovers any of the following: •

Its link to a neighbor is down;

•

It has a new neighbor; or

•

The cost of a link to an existing neighbor has changed.

Once LSPs are distributed appropriately, IS-IS runs the Dijkstra algorithm to compute optimal paths to each ES. This algorithm iterates on the length of a path, examining the LSPs of all ISs working outward from the host IS. At the end of the computation, IS-IS forms a connectivity tree yielding the shortest paths, including all intermediate hops, to each IS.

www.juniper.net



Partial Sequence Number PDUs A receiver multicasts partial sequence number PDUs (PSNPs) when it detects that it is missing an LSP or when its LSP database is out of date. The receiver sends a PSNP to the system that transmitted the complete sequence number PDUs (CSNPs), effectively requesting that the missing LSP be transmitted. That router, in turn, forwards the missing LSP to the requesting router.

Complete Sequence Number PDUs CSNPs contain a complete description of all LSPs in the IS-IS database. IS-IS sends CSNPs periodically on all links. The receiving systems use the information in the CSNP to update and synchronize their LSP databases. The DIS router multicasts CSNPs on broadcast links in place of sending explicit acknowledgments for each LSP.


www.juniper.net


IS-IS Information Objects IS-IS PDUs use TLV encoding as the basic structure for all routing information. TLV encoding requires that the length of any field be defined explicitly when a PDU uses that field. IS-IS ignores all unknown TLVs, making the protocol easily extensible.

www.juniper.net



TLV Variables: Part 1 The following list provides the details of several of the TLVs:


•

TLV 1 (Area address): Provides the area address encoded within the IS-IS NET on the loopback 0 (lo0) interface.

•

TLV 2 (IS reachability): Advertises the IS neighbors adjacent to the local router as well as the metric used to reach those neighbors.

•

TLV 10 (Authentication): Contains the authentication type and the configured password.

•

TLV 22 (Extended IS reachability): Advertises the IS neighbors adjacent to the local router and the routers that support traffic engineering capabilities. This TLV also contains multiple sub-TLVs that describe the user constraints placed on the router by the network administrator. This TLV also populates the traffic engineering database (TED).

•

TLV 128 (IP internal reachability): Advertises the IP address and subnet mask for each of the router’s interfaces capable of supporting IP version 4 (IPv4) traffic.

•

TLV 129 (Protocols supported): Informs other routers in the network which Layer 3 protocols the local router supports. By default, the Junos OS supports both IPv4 and IP version 6 (IPv6). On the J Series Services Router and the SRX Series Services Gateways, you can also use the Junos OS to support CLNS.

www.juniper.net


TLV Variables: Part 2 The following list is a continuation of the details of several TLV variables: •

TLV 130 (IP external reachability): Advertises the network and subnet mask for all routes advertised into IS-IS by using a policy.

•

TLV 132 (IP interface address): Advertises the host IP address for all router interfaces.

•

TLV 134 (Traffic engineering IP router ID): Advertises the 32-bit router ID (RID) of the local router.

•

TLV 135 (Extended IP reachability): Advertises the IP address and subnet mask for router interfaces that can support traffic engineering. This TLV also populates the TED.

•

TLV 137 (Dynamic hostname resolution): Advertises the ASCII hostname configured on the local router. Other IS systems use this TLV to resolve the hostname of the router for use in show command output and within certain TLVs.


www.juniper.net



Multiple Topology TLVs The following list provides the details of the TLVs that support multiple topologies: •

TLV 222 (Multiple topology IS reachability): Advertises the IS neighbors adjacent to the local router and the routers that support multiple topologies of IS-IS.

•

TLV 229 (Multiple topologies supported): Advertises which multiple topologies of IS-IS the local router supports. Each topology is identified by a 12-bit ID field.

•

TLV 235 (Multiple topology IP reachability): Advertises the IP information for interfaces that support multiple topologies. This TLV contains multiple sub-TLVs, which define the actual information. Each set of sub-TLVs is accompanied by the 12-bit topology ID field.

IPv6 TLVs The following list provides the details of the TLVs that support IPv6:


•

TLV 232 (IPv6 interface address): Advertises the IPv6 interface address for those interfaces that support IPv6 traffic.

•

TLV 236 (IPv6 reachability): Advertises information about the network link on which the IPv6 protocol is operating. This TLV contains multiple sub-TLVs that contain the actual metric information, among other things.

www.juniper.net


Area Address TLV Each IS-IS router sends this TLV in both its Level 1 and its Level 2 LSPs. At times, during a network migration, for instance, when you might need more than one area configured on the router, so up to three area addresses are configurable per system. The area ID field is repeated for each unique area address. The area address TLV contains the following fields:

www.juniper.net

•

TLV type (1 byte): The type of the TLV is encoded in this field with a constant value of 1.

•

TLV length (1 byte): This field contains the length of the remaining fields in the TLV. Together, the TLV length and area length fields allow an IS-IS router to determine the number of area addresses encoded within the TLV.

•

Area length (1 byte): The length of the following advertised area is encoded in this field.

•

Area ID (variable): This field can range from 1 to 13 bytes. It contains the actual area address configured within the NET ID of the router.



IS Reachability TLV Each IS-IS router advertises its adjacencies with neighboring systems through this TLV. The various metric fields as well as the neighbor ID field are repeated for each adjacent neighbor. The metric values are encoded in a 6-bit field resulting in possible metrics between 0 and 63. These values are sometimes referred to as old-style or small metrics. The IS reachability TLV contains the following fields: •


•

TLV length (1 byte): The length of the remaining fields in the TLV is placed in this field. This length allows the router to determine the number of neighbors encoded within the TLV. Each set of neighbors and metrics occupies 11 octets of space. Therefore, the field length minus 1 (for the virtual flag) should be divisible by 11, resulting in the number of adjacent neighbors.

•

Virtual flag (1 byte): An IS-IS router sets this flag when the advertised information should be used to repair a nonadjacent Level 2 area. The Junos OS does not support partition repair and this field is set to a constant value of 0x00.



www.juniper.net


IS Reachability TLV (contd.)

www.juniper.net

•

Default metric (1 byte): The first bit in this field is a reserved bit and is set to a value of 0. The second bit in this field can be used to support internal and external metrics by indicating the metric type; internal and external metrics are not comparable. Because this TLV is never leaked, the I/E bit is always coded to a zero to indicate an internal type. The remaining 6 bits are used to encode the metric cost to reach the adjacent neighbor.

•

Delay metric (1 byte): The Junos OS does not support the use of type of service (ToS) metrics within IS-IS. The S bit is set to a constant value of 1 (not supported), while the I/E and metric bits are all set to a constant value of 0.

•

Expense metric (1 byte): The Junos OS does not support the use of ToS metrics within IS-IS. The S bit is set to a constant value of 1 (not supported), while the I/E and metric bits are all set to a constant value of 0.

•

Error metric (1 byte): The Junos OS does not support the use of ToS metrics within IS-IS. The S bit is set to a constant value of 1 (not supported), while the I/E and metric bits are all set to a constant value of 0.

•

Neighbor ID (7 bytes): The ID of the adjacent neighbor is encoded in this field. It is comprised of the 6-byte system ID and the 1-byte circuit ID of the neighbor.



Authentication TLV If configured to support authentication, an IS-IS router includes this TLV in all advertised link-state PDUs. The authentication TLV contains the following fields:


•


•

TLV length (1 byte): The length of the remaining fields in the TLV is placed in this field.

•

Authentication type (1 byte): The specific form of authentication is encoded in this field. Plain-text authentication uses a value of 1, while Message Digest 5 (MD5) authentication uses a value of 54.

•

Password (Variable): The actual authentication data is stored in this field. When MD5 is used, the size of this field is always 16 bytes.

www.juniper.net


Extended IS Reachability TLV Each IS-IS router also advertises its adjacencies with neighboring systems through this TLV. The system ID, metric field, and optional sub-TLV fields are repeated for each adjacent neighbor. The main use of TLV 22 for regular IS-IS is the larger metric values it supports. The extended IS reachability TLV uses a 24-bit field that results in possible metrics between 0 and 16,777,215. This range of metric values is often referred to as new-style or wide metrics. The extended IS reachability TLV contains the following fields: •


•

TLV length (1 byte): The length of the remaining fields in the TLV is placed in this field.

•

System ID (7 bytes): The ID of the adjacent neighbor is encoded in this field. It is comprised of the 6-byte system ID and the 1-byte circuit ID of the neighbor.

•

Wide metric (3 bytes): The metric cost to reach the adjacent neighbor is encoded in this field.


www.juniper.net



Extended IS Reachability TLV (contd.) The following list is a continuation of the fields contained in the extended IS reachability TLV:


•

Sub-TLV length (1 byte): The length of any optional sub-TLVs is encoded in this field. If no sub-TLVs are present, the field is set to a value of 0.

•

Sub-TLVs (Variable): Additional traffic engineering information is advertised in these fields, each with a separate type code, length, and value portion. Each of the fields is placed within the TED on the router. In addition, some sub-TLVs are placed into the LSDB on the router. The possible sub-TLVs include the following: –

Administrative group (Type 3);

–

IPv4 interface address (Type 6);

–

IPv4 neighbor address (Type 8);

–

Maximum link bandwidth (Type 9);

–

Reservable link bandwidth (Type 10); and

–

Unreserved bandwidth (Type 11).

www.juniper.net


IP Internal Reachability TLV Each IS-IS router advertises its locally connected IP prefixes with the IP internal reachability TLV. The metric fields, the IP address, and the subnet mask are repeated for each advertised prefix. As with the IS reachability TLV, the metric values are encoded in a 6-bit field resulting in possible metrics between 0 and 63 (small metrics). The IP internal reachability TLV contains the following fields: •

TLV type (1 byte): The type of the TLV is encoded in this field, which holds a constant value of 128.

•

TLV length (1 byte): The length of the remaining fields in the TLV is placed in this field. This length allows the router to determine the number of prefixes advertised within the TLV. Each set of metrics and addresses occupies 12 octets of space.

•

Default metric (1 byte): The first bit in this field is known as the Up/Down (U/D) bit. It is used to provide information to IS-IS routers in a multilevel network to allow for prefix advertisements across a level boundary and to prevent routing loops. The second bit in this field can be used to indicate whether a given pair of metrics are comparable by indicating a metric type of either internal or external. Although some Junos OS versions made use of the I/E bit for TLV 128, the current release ignores this bit upon reception and treats all prefixes as internal. The final 6 bits represent the metric cost to reach the advertised prefix.


www.juniper.net



IP Internal Reachability TLV (contd.) The following list details the remaining fields in the IP internal reachability TLV:


•

Delay metric (1 byte): The Junos OS does not support the use of ToS metrics within IS-IS. The S bit, the R bit, and the metric bits are all set to a constant value of 0.

•

Expense metric (1 byte): The Junos OS does not support the use of ToS metrics within IS-IS. The S bit, the R bit, and the metric bits are all set to a constant value of 0.

•

Error metric (1 byte): The Junos OS does not support the use of ToS metrics within IS-IS. The S bit, the R bit, and the metric bits are all set to a constant value of 0.

www.juniper.net


Protocols Supported TLV Every IS-IS router sends this TLV in all LSPs. It lists the Layer 3 protocols supported by the local router, making IS-IS a true multiprotocol routing protocol. The network layer protocol identifier (NLPID) is repeated for each supported protocol. The TLV contains the following fields:

www.juniper.net

•

TLV type (1 byte): The type of the TLV is encoded in this field. A constant value of 129 is placed in this field.

•

TLV length (1 byte): The length of the remaining fields in the TLV is placed in this field. This length allows a router to determine the number of NLPIDs encoded within the TLV.

•

Network Layer protocol ID (1 byte): The 8-bit NLPID is placed within this field. By default, the Junos OS supports both IPv4 (0xCC) and IPv6 (0x8E) and encodes those values in this TLV. On J Series routers and SRX Series devices, you can also configure the Junos OS to support the CLNS protocol by configuring clns-routing at the [edit protocols isis] configuration hierarchy.



IP External Reachability TLV Each IS-IS router advertises prefixes that are natively external to IS-IS with the IP external reachability TLV. As with the IP internal reachability TLV, the metric, IP address, and subnet mask fields are repeated for each advertised prefix. The metric values are again encoded in a 6-bit small metrics field. The IP external reachability TLV contains the following fields: •


•

TLV length (1 byte): The length of the remaining fields in the TLV is placed in this field. This length allows the router to determine the number of prefixes advertised within the TLV. Each set of metrics and addresses occupies 12 octets of space.

•

Default metric (1 byte): The first bit in this field is the U/D bit. It is used by IS-IS routers in a multilevel network to allow for prefix advertisements across a level boundary and to prevent routing loops. The second bit in this field can be used to indicate whether a given pair of metrics are comparable by indicating a metric type of either internal or external. Although some Junos OS versions made use of the I/E bit for TLV 130, the current release ignores this bit upon reception and treats all prefixes as external by virtue of their being carried within TLV 130. The final 6 bits represent the metric cost to reach the advertised prefix.



www.juniper.net


IP External Reachability TLV (contd.) The following list details the fields remaining in the IP external reachability TLV:

www.juniper.net

•

Delay metric (1 byte): The Junos OS does not support the use of ToS metrics within IS-IS. The S bit, the R bit, and the metric bits are all set to a constant value of 0.

•

Expense metric (1 byte): The Junos OS does not support the use of ToS metrics within IS-IS. The S bit, the R bit, and the metric bits are all set to a constant value of 0.

•

Error metric (1 byte): The Junos OS does not support the use of ToS metrics within IS-IS. The S bit, the R bit, and the metric bits are all set to a constant value of 0.

•

IP address (4 bytes): The IPv4 prefix being advertised in the TLV is encoded in this field.

•

Subnet mask (4 bytes): The subnet mask associated with the advertised prefix is stored in this field.



IP Interface Address TLV IS-IS routers send this TLV in all LSPs, which list IP addresses configured on the originating router. At least one interface address must be advertised while each router interface can be advertised. By default, the Junos OS encodes the RID of the local system in this TLV. This RID is often the same as the primary address of the router's lo0.0 interface. The IP interface address TLV contains the following fields:


•


•

TLV length (1 byte): The length of the remaining fields in the TLV is placed in this field. This length allows a router to determine the number of addresses encoded within the TLV.

•

IPv4 address (4 bytes): The RID is placed in this field.

www.juniper.net


TE IP RID TLV All routers configured to support traffic engineering, which is the Junos OS default setting, generate this TLV. The RID of the local router is placed in this field for use in the TED. The TE IP RID TLV contains the following fields:

www.juniper.net

•

TLV type (1 byte): The type of the TLV is encoded in this field with a constant value of 134;

•

TLV length (1 byte): The length of the remaining fields in the TLV is placed in this field with a constant value of 4; and

•

IPv4 address (4 bytes): The RID of the local router is placed in this field.



Extended IP Reachability TLV Each IS-IS router configured to support traffic engineering advertises its local IP prefix information using this TLV. Both locally connected and nonnative IS-IS routes use this TLV for reachability information, with no concept of internal or external metrics. The metric, prefix length, prefix, and sub-TLV fields are repeated for each advertised address. The metric field uses 32 bits (wide metrics) for each advertised prefix, which results in possible metrics between 0 and 4,294,967,295. The extended IP reachability TLV contains the following fields: •


•

TLV length (1 byte): The length of the remaining fields in the TLV is placed in this field. This length allows the router to determine the number of prefixes advertised within the TLV.

•

Metric (4 bytes): The metric of the advertised prefix is encoded in this field.



www.juniper.net


Extended IP Reachability TLV (contd.) The following list details the remaining fields of the extended IP reachability TLV:

www.juniper.net

•

Prefix length (1 byte): The first bit in this field is the U/D bit, which is used to allow prefixes to be advertised across a level boundary and to prevent routing loops. The second bit in this field is the sub bit, which denotes if any optional sub-TLVs are associated with the advertised prefix. The final 6 bits represent the length of the advertised prefix.

•

Prefix (variable): The advertised prefix is placed in this field.

•

Optional sub-TLV type (1 byte): The type of the sub-TLV is encoded in this field. The Junos OS currently supports only one sub-TLV type, which is a 32-bit route tag with a type code of 1.

•

Optional sub-TLV length (1 byte): The length of the remaining fields in the sub-TLV is placed in this field.

•

Optional sub-TLV (variable): For the supported route tag sub-TLV, the 32-bit tag value is placed in this field. IS-IS route tagging offers the same administrative filtering capabilities as the OSPF protocol. IS-IS traffic engineering extensions, which enable TLV 135, must be enabled to support route tagging. TE extensions are enabled for IS-IS by default.



Dynamic Host Name TLV All IS-IS routers advertise their configured hostname into the network using this TLV. This advertisement allows network operators to view information about the network routers using a symbolic name instead of the hexadecimal system ID in various show commands. The dynamic host name TLV contains the following fields:


•


•

TLV length (1 byte): The length of the hostname field is placed in this field. Possible values range from 1 to 255 octets.

•

Hostname (Variable): The locally configured ASCII hostname of the router is placed in this field.

www.juniper.net


Level 2 PDU TLVs Example The example on the slide shows the details of a level 2 PDU. By using the extensive keyword, you can see each of the TLV fields. You can gather important details about this network by examining the TLVs closely: •

The local router is configured within Area 49.0001, and the area length is 3 bytes. This information is available in the Area Address field and TLV 1.

•

The local router’s RID is 192.168.48.1. This information is available in the IP router id field and TLV 134.

•

The LSP was originated by the Sao Paulo router, because the Hostname field of TLV 137 lists SaoPaulo in its payload.

•

The local router has an IS adjacency with the Sydney routers at a metric of 10. This information is available in the IS Neighbor field and TLV 2.

•

The IP address of the router’s interface toward Sydney is 10.222.60.2, as seen in TLV 22, sub-TLV 6.

•

The local router is advertising two internal local IS-IS routes, 10.222.60.0/24 and 192.168.48.1/32. This information is available from the IP Prefix field and TLV 128.


www.juniper.net



Level 2 PDU TLVs Example (contd.)


•

The local router has a policy configured to advertise the external prefix of 192.168.49.0/24. This information is available in the IP external prefix field and TLV 130.

•

All three prefixes advertised by the local router are carried in TLV 135 and are visible in the IP extended prefix field.

www.juniper.net


Neighbors and Adjacencies The slide highlights the topic we discuss next.

www.juniper.net



Neighbors and Adjacencies The slide lists the rules Level 1 and Level 2 routers must follow when forming an adjacency.


www.juniper.net


DIS Election The IS-IS DIS election process is achieved by assigning a Level 1 priority and a Level 2 priority on every IS-IS router interface, with a range of 0 through 127. The Junos OS uses a default priority of 64 for both levels. The router advertises its priority in the hello PDUs sent from each interface. The L1 priority is advertised in L1 hello PDUs, and the L2 priority is advertised in L2 hello PDUs. If the priority is 0, the router is ineligible to become the DIS. Interfaces to nonbroadcast networks automatically have a priority of 0. The router with the higher priority value becomes the DIS. In the event of a tie, the router with the numerically highest subnetwork point of attachment (SNPA), which is a fancy name for a MAC address, wins the election.

DIS Characteristics Unlike OSPF, however, an IS-IS router attached to a broadcast, multi-access network establishes adjacencies with all of its neighbors on the network, not just the DIS. Each router multicasts its LSPs to all of its neighbors, and the DIS uses a system of PDUs—called sequence number PDUs—to ensure that the flooding of LSPs is reliable. Also unlike OSPF, no election of a backup designated router occurs in IS-IS. If the IS-IS DIS fails, a new DIS is elected. Another characteristic is that if a new router with a higher priority than the existing DIS becomes active, or if the new router has an equal priority and a higher subnetwork point of attachment (MAC address), the new router becomes the DIS. When the DIS changes, a new set of LSPs must be flooded.

www.juniper.net



Pseudo-Node IS-IS elects a DIS on broadcast and multi-access networks for the same reason as OSPF. Rather than having each router connected to the LAN advertise an adjacency with every other router connected to the LAN, the network itself is considered a router—a pseudo-node. Each router, including the DIS, advertises a single link to the pseudo-node. The DIS also advertises, as the representative of the pseudo-node, a link to all of the attached routers.


www.juniper.net


IP Configuration Necessary You can check several things while troubleshooting IS-IS adjacency problems. When establishing adjacencies in IS-IS, all routers on a link must agree upon the IP subnet to which they belong, except on point-to-point links, which can be unnumbered or use /32 addressing. The Junos OS needs the IP portion of the network to function so that the IS-IS adjacency will work.

www.juniper.net



Configuring and Monitoring IS-IS The slide highlights the topic we discuss next.


www.juniper.net


Configuring IS-IS: Part 1 For IS-IS to run on the router, you must enable IS-IS on the router, configure a NET on one of the router’s interfaces (preferably the loopback interface, lo0), and configure the ISO family on all interfaces on which you want IS-IS to run. The Junos OS supports the assignment of multiple ISO NETs to the router’s loopback interface. Such a configuration might prove helpful when migrating two previously independent IS-IS domains into a single routing domain.

www.juniper.net



Configuring IS-IS: Part 2 By default, all IS-IS interfaces are Level 1 and Level 2 interfaces. You might need to disable a particular level on a given interface. Notice that configuring IS-IS on Junos devices requires minimal configuration.


www.juniper.net


Metric Cost of an Interface Each IS-IS router must determine the metric (or cost) associated with that network. Often referred to as simply the metric, the cost is simply what the router views as the overhead associated with transmitting a packet on that interface. Each IS-IS-speaking router advertises these cost values in its LSPs; each router can determine the total cost (or metric) to reach any destination in the network.

IS-IS Default Metric Each router in as IS-IS network uses a default metric of 10 for all interfaces on the router. The notable exception to this default setting is the loopback interface of the router, which has a default metric of 0. When you configure an IS-IS interface to operate in passive mode, the default metric is still set to a value of 10. This default is different from the operation of other router vendors, so be careful in a multivendor environment to ensure a consistent metric calculation.

Set on a Per-Interface Basis If you want to alter the metrics in the network, you can set the cost for each interface. Within the interface portion of the [edit protocols isis] configuration hierarchy, the metric command assigns a permanent cost to that interface for a particular level. Each interface on the router can have a separate cost assigned to it.

www.juniper.net



Change the Cost Calculation Although you can statically assign each interface with a cost, this process often proves to be an administrative hassle in all but the smallest networking environments. However, an option is available to administrators who want an automatic calculation of metrics in their networks. The solution is to enable a bandwidth calculation similar to that used in OSPF. This calculation takes a supplied value—the reference bandwidth—and divides it by the bandwidth of the physical interface. This solution not only allows for an automatic cost assignment, but it also maintains a consistent ratio across all the router interfaces.

Reference Bandwidth To enable the calculation, use the reference-bandwidth command within the [edit protocols isis] configuration hierarchy. The value entered has a value in bits per second. Use the standard Junos shortcut notations of k (kilobits per second), m (megabits), and g (gigabits). The entered value becomes the numerator value in the bandwidth calculation.


www.juniper.net


Monitoring IS-IS Operation This slide lists the show commands discussed on the following pages.

www.juniper.net



Displaying Interface Status The show isis interface command displays the status of an interface. Use this command to ensure that IS-IS is configured correctly on the router. The output of this command includes the following fields: •

interface-name (detail output only): Displays the name of the interface.

•

Index (detail output only): Displays the interface index assigned by the Junos kernel.

•

State (detail output only): Displays the internal implementation information.

•

Circuit ID (detail output only): Displays the circuit identifier.

•

Circuit type (detail output only): Displays the circuit type, which can be 1—Level 1 only, 2—Level 2 only, or 3—Level 1 and Level 2.

•

LSP interval (detail output only): Displays the interface’s link-state PDU interval.

•

Sysid (detail output only): Displays the system identifier.

•

Interface (brief output only): Displays the interface through which the adjacency is made.



www.juniper.net


Displaying Interface Status (contd.)

www.juniper.net

•

Level 1 DR/Level 2 DR (brief output only): Displays the Level 1 or Level 2 designated intermediate system.

•

L1/L2 Metric: Displays the interface’s metric for Level 1 and Level 2. If no information exists, the metric is 0.

•

Adjacencies (detail output only): Displays the number of adjacencies established on this interface.

•

Priority (detail output only): Displays the priority value for this interface.

•

Metric (detail output only): Displays the metric value for this interface.

•

Hello (s) (detail output only): Displays the interface’s hello interval.

•

Hold (s) (detail output only): Displays the interface’s hold time.



Displaying IS-IS Adjacency Status The show isis adjacency command displays the status of IS-IS adjacencies. The output of this command includes the following fields:


•

Interface: Displays the interface through which the neighbor is reachable.

•

System (brief output only): Displays the system identifier (sysid), printed as a name if possible.

•

L: Displays the level, which can be 1—Level 1 only; 2—Level 2 only; or 3—Level 1 and Level 2. An exclamation point (!) preceding the level number indicates that the adjacency is missing an IP address.

•

State: Displays the state of the adjacency. It can be Up, Down, New, One-way, Initializing, or Rejected.

•

Hold (secs) (brief/standard output only): Displays the remaining hold time of the adjacency. Note that the show isis adjacency command returns brief output by default.

•

SNPA (brief output only): Displays the subnetwork point of attachment (MAC address of the next hop).

www.juniper.net


Displaying Detailed Adjacency Information The show isis adjacency detail command displays detailed IS-IS adjacency information. The output of this command includes the following fields:

www.juniper.net

•

Expires in (detail output only): Displays how long until the adjacency expires, in seconds;

•

Priority (detail output only): Displays the priority to become the DIS;

•

Up/Down transitions (detail output only): Displays the count of adjacency status changes from up to down or from down to up;

•

Last transition (detail output only): Displays the time of the last up/down transition;

•

Circuit type (detail output only): Displays the bit mask of levels on this interface, which can be 1—Level 1 router, 2—Level 2 router, or 1/2—both Level 1 and Level 2 routers;

•

Speaks (detail output only): Displays the protocols supported by this neighbor; and

•

IP addresses (detail output only): Displays the IP address of this neighbor.



Displaying SPF Operation The show isis spf log command displays the elapsed time to perform SPF calculations and the reasons why they were triggered. The output fields of this command are the following:


•

Node: Displays the sysid of a node;

•

Metric: Displays the metric to the node;

•

Interface: Displays the interface of the next hop;

•

Via: Displays the sysid of the next hop;

•

SNPA: Displays the subnetwork point of attachment (MAC address of the next hop);

•

Start time (log output only): Displays the time that the SPF computation started;

•

Elapsed time (log output only): Displays the length of time required to complete the SPF computation in seconds;

•

Count (log output only): Displays the number of times the SPF was triggered; and

•

Reason (log output only): Displays the reason that the SPF computation was completed.

www.juniper.net


Displaying IS-IS Statistics The show isis statistics command displays statistics about IS-IS traffic. The output fields of this command are the following: •

PDU type: Displays the protocol data unit type.

•

Received: Displays the number of PDUs received since IS-IS started or since the statistics were zeroed.

•

Processed: Displays the number of PDUs received less the number dropped.

•

Drops: Displays the number of PDUs dropped.

•

Sent: Displays the number of PDUs transmitted since IS-IS started or since the statistics were zeroed.

•

Rexmit: Displays the number of PDUs retransmitted since IS-IS started or since the statistics were zeroed.

•

Total packets received/sent: Displays the total number of PDUs received and transmitted since IS-IS started or since the statistics were zeroed.

•

SNP queue length: Displays the number of CSNPs and PSNPs sitting on the SNP queue waiting for processing. This value is almost always 0.


www.juniper.net



Displaying IS-IS Statistics (contd.)


•

LSP queue length: Displays the number of LSPs sitting on the link-state PDU queue waiting for processing. This value is almost always 0.

•

SPF runs: Displays the number of SPF calculations performed. If this number is incrementing rapidly, it indicates that the network is unstable.

•

Fragments rebuilt: Displays the number of link-state PDU fragments that the local system has computed.

•

LSP regenerations: Displays the number of link-state PDUs that have been regenerated. An link-state PDU is regenerated when it is nearing the end of its lifetime and it has not changed.

•

Purges initiated: Displays the number of purges that the system initiated. A purge is initiated if the software decides that an link-state PDU must be removed from the network.

www.juniper.net


Displaying IS-IS Routes The show isis route command displays the routes in the IS-IS routing table. The output of this command includes the following fields:

www.juniper.net

•

Current version: Displays the number of the current version of the IS-IS routing table.

•

L1: Displays the version of Level 1 SPF that was run.

•

L2: Displays the version of Level 2 SPF that was run.

•

Prefix: Displays the destination of the route.

•

L: Displays the level, which can be 1—Level 1 only; 2—Level 2 only; and 3—Level 1 and Level 2.

•

Version: Displays the version (or run) of SPF that generated the route.

•

Metric: Displays the metric value associated with the route.

•

Type: Displays the metric type. It can be int (internal) or ext (external).

•

Interface: Displays the interface to the next hop.

•

Via: Displays the system identifier of the next hop, displayed as a name if possible.



Displaying Detailed IS-IS Database Information The show isis database extensive command provides detailed output for the contents of the IS-IS LSDB. The output of this command includes the following fields: •

LSP ID: Displays the LSP identifier.

•

Sequence: Displays the sequence number of the LSP.

•

Checksum: Displays the checksum value of the LSP.

•

Lifetime (in seconds): Displays the remaining lifetime of the LSP, in seconds.

•

IP prefix (detail and extensive output only): Displays the prefix advertised by this LSP.

•

IS neighbor (detail output only): Displays an IS-IS neighbor of the advertising system.

•

Metric (detail and extensive output only): Displays the metric of the prefix or neighbor.

The command output then displays detailed packet content information.


www.juniper.net



www.juniper.net

•

IS-IS concepts and operation;

•

IS-IS LSP types;

•

IS-IS adjacency rules and troubleshooting; and

•

The configuration and monitoring of IS-IS in the Junos OS.





www.juniper.net


Lab 4: IS-IS Configuration and Monitoring The slide provides the objective for this lab.

www.juniper.net




www.juniper.net

Advanced Junos Service Provider Routing Chapter 6: Advanced IS-IS Operations and Configuration Options



The display and interpretation of the IS-IS link-state database (LSDB);

•

Advanced IS-IS configuration options; and

•

The implementation of IS-IS routing policy.

Chapter 6–2 • Advanced IS-IS Operations and Configuration Options

www.juniper.net


IS-IS Operations The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.juniper.net

Advanced IS-IS Operations and Configuration Options • Chapter 6–3


Link-State PDU Flooding Scopes Each link-state protocol data unit (PDU) in the IS-IS protocol has a specific scope within which it can be flooded. The slide graphically displays these flooding scopes. Note that the Level 1 link-state PDUs (LSPs) are generated within each area. Because these LSPs have a Level 1 flooding scope, they remain within their own particular area and are not seen in other areas. The L1/L2 router at the edge of the area places the routing information contained within the LSP into a Level 2 LSP and forwards it across the area boundary. All Level 2 LSPs are flooded across every contiguous Level 2 area. This flooding results in Level 2 LSPs within every area that represent all IS-IS routes. Within Area 49.1111, for example, Level 2 LSPs exist that represent Area 49.2222 and Area 49.3333.


www.juniper.net


Sample IS-IS Database The example on the slide shows the details of the IS-IS database. To this point, we have been examining small portions of the database through the use of the extensive keyword. Now, we take a step back and examine the database as a whole. You can gather details by examining the database closely:

www.juniper.net

•

This router has both Level 1 and Level 2 adjacencies. You can determine this fact by the existence of two databases on the router.

•

Within the Level 1 area, R1 is the router that can communicate with other Level 2 systems. You can determine this fact by the Attached keyword in its Level 1 LSP.

•

The R2 and R3 routers are configured to operate at Level 1 only because their attributes are set to 0x01 (not shown in the output). Notice the L1 designation and the absence of a L2 notation within the Attributes field.

•

The R3 router is the designated intermediate system (DIS) for one of its links in the network. You can determine this fact by the extra LSP advertised as R3.02-00. The circuit ID of the interface upon which it is the DIS is 0x02.



Dijkstra Algorithm After a router receives a new LSP and places it into the LSDB, the router runs an algorithm known as the Dijkstra algorithm (or 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. Remember that the LSDB is the total compilation of routing knowledge in the network. Conceptually, it consists of multiple tuples in the form of router ID (RID), neighbor ID, and cost, which describe each link in the network. When 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: 1.

For each new entry in the candidate database, the router determines the cost from root to each neighbor ID. The SPF algorithm moves the tuple with the lowest cost from the candidate database into the tree database. If multiple tuples exist with an equal cost, one is chosen randomly.

2.

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



www.juniper.net


Dijkstra Algorithm (contd.) 3.

Each tuple in the candidate database is evaluated and 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 are deleted. Step 1 is repeated until the candidate database is empty.

Run on a Per-Level Basis The Dijkstra algorithm is calculated for each LSDB present on the local router. Recall that each IS-IS level maintains a separate copy of the database. These separate copies allow each level to have a separate forwarding topology independent of another level.

Results Are Passed to the Routing Engine Once the algorithm is run, the routing table on the Routing Engine receives the results in the tree database. At this point, the Routing Engine controls the determination of whether to use any individual IS-IS route to forward traffic. The preference value assigned to each route often handles this choice. The action of calculating the best IS-IS route prior to the route being placed into the routing table has a consequence in regards 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 IS-IS because the routing information enters the router as an LSP and is only placed into the routing table after the router performs the Dijkstra algorithm. Hence, the only method of filtering IS-IS routing knowledge is to keep that information from being placed into the database (on a per-level basis) in the first place.

www.juniper.net



SPF Calculation Example: Part 1 In the following slides, an example 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-A. 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. So 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 Because 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-A. 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-A 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 RTR-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. 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 OS routing table for its use.

www.juniper.net



Back-to-Back SPF Calculations To enhance the convergence time of IS-IS during topology changes, the Junos OS enables 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 is hardcoded into the software and is not configurable. The timer ensures that the network can continue to forward packets with potentially incorrect routing knowledge during the convergence period. The timer also allows the routing process to not control the CPU at the expense of other routing functions.

Controlling the Delay Between Calculations A configurable timer slightly delays consecutive SPF calculations. The default timer value is 200 milliseconds (ms), which you can alter with the spf-delay statement. The spf-delay statement is supported both at the global IS-IS configuration hierarchy and within an IS-IS routing instance. Delay values ranging from 50 ms to 1000 ms (1 second) are supported. The mandatory 5-second hold-down timer is still brought to bear after the third consecutive rapid SPF calculation, regardless of the spf-delay setting. As a best practice, we recommend you set the spf-delay value slightly larger than the worst possible propagation delay found in your network. For example, if the delay across the network is 200 ms, then you might set the spf-delay to 250 ms. This setting allows time for all of the duplicate LSPs to arrive at all routers before the SPF calculation begins.


www.juniper.net


Full SPF Is Actually Two Steps The IS-IS routing protocol actually performs two separate calculations during each SPF computation. The first stage of this full SPF is the generation of a tree representing all IS nodes in the network. The second stage then maps the advertised IP prefixes onto the IS tree for determining the shortest path to each router. These routes are then placed into the routing table on the router.

Only Recalculate IP Reachability If an IS-IS router begins advertising a prefix (or removes a prefix from the network), but does not alter its IS reachability, no need exists to recalculate the IS tree for the network. This partial route calculation (PRC) reruns only the IP reachability portion of the SPF algorithm. Each router in the network makes the decision to run a full or partial SPF independently based on the contents of the received LSP. Each field is examined to determine the extent of the changes (if any). Should a router find that only IP information is changed, a PRC is scheduled and run, after which the results are passed to the routing table on the router.

Automatically Enabled The functionality of the PRC is automatically enabled when you configure IS-IS within the Junos OS— you do not have to do anything to benefit from the enhancement. Conversely, no configuration option is available to disable this feature.

www.juniper.net



IS-IS Configuration Options The slide highlights the topic we discuss next.


www.juniper.net


Small Metric TLVs The IS-IS protocol uses 6 bits in type/length/values (TLVs)—2, 128, and 130—to advertise the metric of an individual interface or external route respectively. Therefore, the largest possible metric that an interface can be assigned is 63. Any larger value configured on the interface, or calculated using the reference-bandwidth, is advertised as a 63 in those TLVs in all LSPs. This value does not affect the total metric to reach a network as determined by the SPF algorithm. The algorithm adds multiple 63 values together to reach a total cost. The largest value possible for this total metric cost is 1023 to any destination in the network.

Wide Metric TLVs With the creation of the traffic engineering TLVs (22 and 135), the concept of limiting an interface cost to six bits was changed to allow for greater granularity and scalability. The new TLVs use 24 bits to advertise the metric, for a maximum link cost of 16,777,215 and the field for the total cost is expanded to 32 bits. Continued on the next page.

www.juniper.net



Only Advertise Wide Metrics The default operation of IS-IS is to advertise both the small and wide metric TLVs in all LSPs. You can inform the local router to use only the wide metric TLVs with the wide-metrics-only command. This command is applied on a per-level basis and allows the local router to advertise larger metrics using only the extended TLVs. Note that wide metrics cannot differentiate between internal and external prefixes. As a result, the use of only wide metrics results in the automatic leaking of external prefixes from Level 1 areas into Level 2 areas. You can use routing policy to block the leaking of external prefixes into the backbone area if needed.


www.juniper.net


Wide Metrics Operation: Part 1 The example on the slide (as well as the following slides) shows a small IS-IS network consisting of 2 routers. Each of the routers is running only Level 2 on all of its interfaces and is using all of the default settings. We see that the current cost to the R2 router’s loopback address of 192.168.48.1/32 is 10. This cost accounts for the cost to reach R2 over the ge-1/1/0.0 interface (10.222.60.0/24) on R1 in addition to the metric advertised by R2 for its loopback address (0 by default). A look at the LSDB information advertised by R1 shows that both TLV 128 (IP prefix) and TLV 135 (IP extended prefix) are being sent to announce the IP prefixes available on R1.

www.juniper.net



Wide Metrics Operation: Part 2 The R1 router has configured a metric value of 10,000 on its interface toward R2. After committing the configuration, we see that the metric cost to reach R2’s loopback is now 63. The LSDB shows both TLV 128 and TLV 135 being advertised with a metric of 63, the maximum metric available to the IP internal reachability TLV.


www.juniper.net


Wide Metrics Operation: Part 3 Sydney has now configured its Level 2 operation to use only wide metrics through the wide-metrics-only command. The metric cost to R2’s loopback address is now listed as 10,000 in the routing table. The LSDB now shows that only TLV 135 is being advertised with a metric value of 10,000 assigned to it.

www.juniper.net



Advertisement of Metric Values After the IS-IS process on a router decides which metric to assign to each interface, that information is flooded into the domain within either a Level 1 LSP or a Level 2 LSP.

SPF Calculations After receiving a new LSP from another router, the local router performs an SPF calculation using all the values contained in the LSPs in the database. 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 router performs a separate SPF calculation, two routers on either side of a point-to-point link can disagree on the metric of that link. The example on the slide shows that each router has determined a different metric value for its attached links. This difference results in the R1 router calculating a total cost of 45 (5+15+25=45) to reach the R4 router, while the R4 router calculates a total cost of 60 (30+20+10=60) to reach R1 router. Although the configuration of different metrics for a single link does not affect the operation of IS-IS, asynchronous routing can occur within the network, which might cause response delays for some end users and make troubleshooting the network challenging for network administrators.


www.juniper.net


Authentication Configured in Various Places Within the IS-IS protocol, you can enable authentication in multiple places within the configuration hierarchy. Each specific location encrypts certain IS-IS PDU packets. Any authentication configured at either Level 1 or Level 2 secures all hello PDUs, LSPs, and sequence number PDUs sent by the local router for that specific level. Authentication at the interface level secures only hello PDUs. Again, this configuration occurs for either Level 1 or Level 2.

Authentication Types The Junos OS supports three different forms of authentication for the IS-IS protocol. These types are none, simple, and Message Digest 5 (MD5). The type of authentication used must match on all routers within a level.

MD5 Authentication Checksum For better security in an IS-IS network, we recommend you use authentication type MD5. MD5 includes an encrypted checksum in all IS-IS packets—not a simple text password. Each IS-IS router uses the same MD5 algorithm to calculate the checksum value, so it virtually guarantees interoperability and a correct result.

www.juniper.net



Level Authentication Configuration of any authentication at either Level 1 or Level 2 secures hello, link-state, and sequence number PDUs. In the example on the slide, MD5 authentication is enabled for Level 1, and simple authentication is configured for Level 2. Note Take care when configuring authentication on a point-to-point interface. IS-IS uses a single hello PDU on these interfaces (as opposed to a broadcast interface having a Level 1 and a Level 2 hello). Thus, the local router uses the authentication configured at the lowest level for the hello PDUs on this interface. Potential problems might arise if one side of the interface is operating both Level 1 and Level 2 while the other side is operating only Level 2. Continued on the next page.


www.juniper.net


Per-Interface Authentication As is a common practice within the Junos OS configuration hierarchy, IS-IS authentication options configured at an interface level supercede any options configured at a higher level. Interface fe-0/0/0.0 on the slide has MD5 authentication configured for hello PDUs sent at Level 2 using the hello-authentication commands. This hello authentication will be used only on that specific interface.

www.juniper.net



Selectively Disable Authentication For easier interoperability with implementations from other vendors as well as for more control by network operators, the Junos OS can selectively disable authentication for certain PDUs. This ability stops both the securing of transmitted PDUs as well as the verification of received PDUs. In essence, the router operates as if no authentication was ever configured within IS-IS for the specific PDUs configured.

No Authentication Verification on Received PDUs To aid you during a migration period or for troubleshooting an authentication problem, you can ignore the verification on received packets with the no-authentication-check command. Transmitted packets are still secured, but all received packets are used, regardless of any authentication information contained in them.


www.juniper.net


Default IS-IS Flooding As mentioned on previous slides, the default IS-IS operation is to flood all LSPs to any adjacent router for a configured level.

Full-Mesh Topologies At times, the default flooding mechanism might be a disadvantage. Such is the case with a full-mesh physical or logical topology. In this type of an environment, each IS-IS router receives extra copies of the same LSP. These extra copies are not needed and can be discarded safely. In the example on the slide, the R4 router receives an LSP generated from the R1 router three times.

Mesh Group Members The IS-IS protocol has the option of configuring a mesh group for certain peers. Once configured, the mesh group members do not re-flood LSPs within their group. Only LSPs received from outside the group membership are flooded within the group. If a mesh group were configured in the example on the slide, the R4 router would receive only a single copy of the LSP from the R1 router.

www.juniper.net



Group Numbers To configure a mesh group within the Junos OS, assign each interface within IS-IS a group number by using the mesh-group command. This number can be any 32-bit value. Within each local router, any LSPs received on an interface assigned to a mesh group are not flooded out any interfaces within that same mesh group.

Prevent All Flooding Because the mesh-group command alters the default IS-IS flooding, you can disable all flooding out a particular interface by using the mesh-group blocked command. This command might be useful in an environment where a local IS-IS router might want to receive LSPs from an adjacent neighbor but not send any LSPs to that neighbor. [edit protocols isis] user@router# show interface ge-0/0/1.0 { mesh-group blocked; }


www.juniper.net


Avoid Transit Traffic The concept of the overload bit was first available within the IS-IS protocol. Put simply, its function is to advertise information into the IS-IS network, but to prevent transit traffic on the router. This functionality can be useful in two situations—first, when a router must be taken out of the network for maintenance, and second, when the router has many BGP peers. In the first case, traffic should avoid the router because its ability to forward traffic can be compromised. In the second case, a network administrator might want the router to fully establish its BGP peering sessions before handling transit traffic. When an IS-IS router is configured for overload, a bit is set to 1 within the attributes field in the LSP header. This configuration is then visible to all other routers in the level within the LSDB. In the example on the slide, the Router-2.00-00 LSP is advertised with the overload bit set.

Overload Settings You can turn the overload setting on or off as a permanent value, or you can associate a timer with it. If the timer is omitted, then the overload bit is set once you commit the configuration. The bit remains until you remove the overload setting from the configuration, and the configuration is committed once again. However, if you assign a timer value, the bit is not set automatically. The timer associated with the overload bit initializes only when the routing protocol daemon (rpd) also initializes. This timer can run from between 60 and 1800 seconds. Once the timer expires, the bit is removed from the LSPs, but the configuration still contains the overload command.

www.juniper.net



CSNP Packets on a LAN Interface By default, the DIS router on a LAN interface advertises a complete sequence number PDU (CSNP) every 10 seconds. This advertisement allows other routers on the link to ensure that their databases are complete. Perhaps more importantly, it allows the other IS-IS routers to know when the DIS is no longer available. This fast CSNP timer allows IS-IS to not require the election of a backup DIS.

Alter the Timers If you do not need the quick timer of the CSNP, you can change it. One possible situation where this change might be useful is on a broadcast link with only two routers. If the DIS is not available any longer, the other router becomes aware of this unavailability from a lost adjacency or downed network link. To lengthen or shorten the timer value, you can use the csnp-interval command. On a per-interface basis, you can set the timer value as short as 1 second or as long as 65,535 seconds.


www.juniper.net


IS-IS Routing Policy The slide highlights the topic we discuss next.

www.juniper.net



IS-IS Import Policies Like OSPF, IS-IS is a link-state protocol. The routing table is populated by the results of the SPF algorithm. User-defined import policies are allowed but might affect database consistency.

Default Export Policy for IS-IS Remember that policies affect routes into and out of the routing table. The information in an IS-IS LSP is not gathered from inet.0. Instead, the LSP is populated through the configuration of IS-IS within the [edit protocols isis] configuration hierarchy. However, for IS-IS you can block internal subnets as well as external subnets from entering the LSP in an export policy, essentially overriding the inherit first term. This behavior is different from OSPF, where export policy affects only external subnets.


www.juniper.net


Route Redistribution in IS-IS You can add routes to an advertised LSP through an export policy. A new TLV is added to the update for each route accepted by the policy. These types of policies often match and accept all routes from a particular protocol. For example, the redistribute-routes-into-isis policy on the slide advertises all RIP and OSPF routes into the network.

Routing Loop Concerns Again, you must take care when redistributing routes between protocols to avoid a routing loop.

www.juniper.net



IS-IS Export Attributes IS-IS can change the advertised metric value for routes redistributed into the protocol. A policy action of then metric value changes the value in the advertised LSP.

IS-IS Route Tagging IS-IS route tagging offers the same administrative filtering capabilities as the OSPF protocol. Route tagging for IS-IS requires traffic engineering extensions, which are enabled by default. The example on the slide shows an IS-IS export policy that matches all active static routes in inet.0 and advertises them into IS-IS with a metric of 40 and a route tag of 68.


www.juniper.net


Case Study Topology The slide displays the case study topology that will be used in subsequent slides. R1, R2, and C1 all run 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 IS-IS 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 IS-IS. In this case, two match conditions were used, creating a logical AND. This policy will then be applied under the [edit protocols isis] hierarchy by performing a set protocols isis export redistribute-rip command.

Redistribution of Default Route The next step is to redistribute the default IS-IS route into RIP using an export policy under RIP. We will use two match conditions again. This policy will be applied under [edit protocols rip].

www.juniper.net



Redistribution of Default Route By default, RIP has a lower preference than IS-IS external routes. Because RIP has a better preference, the default route for RIP is preferred. In this sample network, this preference creates a loop, because the IS-IS routers point to the RIP router as its gateway while the RIP router points to the IS-IS routers. To fix the loop, modify the IS-IS 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 IS-IS router.

www.juniper.net



Junos OS Supports Large Numbers of Routes IS-IS implementations can encounter problems when large numbers of external routes are injected into the LSDB. The Junos OS has great protocol stability and handles these external routes without failing. However, a configuration mistake could make a portion of your network unusable, because only the Juniper Networks routers would be left operating.

Limit External Routes To help network administrators when a configuration mistake occurs, the Junos OS allows a limit to be placed on the number of external routes exported into IS-IS. The prefix-export-limit command informs the router how many routes to accept using a routing policy configuration. You configure this option at a specific level using 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 bit is set in all LSPs. The external routing information is no longer transmitted in the LSPs as well. The local router remains in this state until the number of external routes returns to a level below the configured limit. This level reduction 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



www.juniper.net

•

The display and interpretation of the IS-IS LSDB;

•

Advanced IS-IS configuration options; and

•

The implementation of IS-IS routing policy.





www.juniper.net


Lab 5: Advanced IS-IS Configuration Options and Routing Policy The slide provides the objectives for this lab.

www.juniper.net




www.juniper.net

Advanced Junos Service Provider Routing Chapter 7: Multilevel IS-IS Networks



The default operation in a multilevel IS-IS network;

•

IS-IS address summarization methods; and

•

The configuration and monitoring of a multilevel IS-IS network.

Chapter 7–2 • Multilevel IS-IS Networks

www.juniper.net


Level 1 and Level 2 Operations The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.juniper.net

Multilevel IS-IS Networks • Chapter 7–3


IS-IS Level 2 Operation As discussed in a previous chapter, the IS-IS protocol advertises either a Level 1 LSP or a Level 2 LSP for each adjacency formed with a neighbor. The type of LSP advertised depends on the level at which the adjacency is formed. Also recall that an IS-IS Level 1 LSP can be flooded only within a specific area because a Level 1 adjacency cannot form across an area boundary. Level 2 LSPs include the routing information carried in Level 1 LSPs, which results in the L2 backbone knowing routes for all areas and levels. In the example on the slide, routing information from all routers is present in all databases in the network. The presence of a single L2 database shared by all routers occurs because all of the adjacencies in the network are at Level 2, and Level 2 LSPs are flooded both within, and across, IS-IS area boundaries.


www.juniper.net


IS-IS Level 1 Operation This slide details a single area Level 1 IS-IS network. In this example, all routers in the network share a Level 1 database containing identical information. The presence of a common Level 1 database in all routers occurs in this case because all adjacencies are Level 1 in nature, and all routers are within the same IS-IS area (49.4444). Level 1 LSP flooding will reach all routers in the network because of the single area.

www.juniper.net



Multilevel IS-IS Operation In this example, routing information for each router is present in all Level 2 databases in the network. This routing information is present because Level 1 routing information is summarized at the L1/L2 boundary and flooded throughout the Level 2 backbone in Level 2 link-state protocol data units (PDUs). The Level 1 routers within each Level 1 area have a single Level 1 database that contains routing information for that area only. The Level 1 routers use the attached bit in an advertised Level 1 link-state PDU (LSP) to install a local default route. The Level 1 router forwards packets to the metrically closest attached router when routing to destinations outside of their Level 1 area. Level 1 routers are isolated from routing changes in other areas, and summarization of Level 1 information prevents Level 2 routers from having to perform a full SPF calculation for topology changes within a Level 1 area. This isolation and summarization of routing information improves the scalability of a multilevel IS-IS network.


www.juniper.net


Multilevel IS-IS Operation Is Similar to OSPF NSSA You can readily compare the operation of a multiarea IS-IS network to an OSPF not-so-stubby area (NSSA) with the no-summaries and default-metric options configured. In a multiarea IS-IS network, each Level 1 IS-IS router has complete routing knowledge of the routes local to its Level 1 area only. Level 1 routers reach other IS-IS destinations by using a 0.0.0.0/0 default route generated by the detection of L1/L2 attached routers. As with an OSPF NSSA, you can inject external routing information into the Level 1 area. The Level 2 LSPs of the attached routers in the area advertise the internal Level 1 routes to other IS-IS Level 2 areas.

L1/L2 Border Router Is a Natural Boundary Although a Level 2 LSP advertises all Level 1 internal routes, routing information for the Level 2 backbone is constrained by the L1/L2-attached router. Thus, Level 2 routes are not advertised into the Level 1 area by default; hence the need for a default route in the Level 1 area. Level 1 routes advertised as external routes into Level 1 are not advertised to any Level 2 routers by default; routing policy is needed to effect the leaking of Level 1 externals into the L2 backbone. Note that the use of wide-metrics-only alters the natural L1/L2 boundary in that routes are no longer distinguishable as being internal or external. The use of wide metrics therefore results in the automatic leaking of all Level 1 routes into Level 2, because they will all appear to be internal routes. Continued on the next page.

www.juniper.net



L2 Routers Set the Attached Bit To provide interarea reachability for Level 1 routers, an L1/L2 router with a Level 2 adjacency to a router in another area sets its attached bit in its Level 1 LSPs. Level 1 routers install a 0.0.0.0/0 default route to the metrically closest attached router when they detect Level 1 LSPs with the attached bit set. Note that while each possible metric type (default, delay, expense, and error) is associated with its own attached bit, the Junos OS supports only the default metric type. You can disable the generation of a default route by including the ignore-attached-bit statement at the [edit protocols isis] configuration hierarchy.


www.juniper.net


Ignoring the Attached Bit In some corner situations you might want to prevent the installation of a default route based on the presence of Level 1 LSPs with attached bits. The slide provides an example of one such application in which a multilevel IS-IS network with Level 2 to Level 1 route leaking in place. Because the leaking of Level 2 routing information into the Level 1 areas provides all routers with complete IS-IS routing information, a default route is no longer needed for routing to destinations outside of a given Level 1 area. Because the goal of a multilevel IS-IS design is normally to reduce database size for routers in Level 1 areas, you might ask yourself why someone would design a multilevel IS-IS topology only to leak Level 2 routes into Level 1. In this example, the network operator wants to leverage the built-in LSP flooding scope of a multilevel IS-IS network to provide some level of isolation in the event that a malformed LSP is generated. For example, if a malformed Level 1 LSP is generated in area 49.7777, this LSP will not be flooded into the Level 2 backbone (the contents of Level 1 LSPs are repackaged into a Level 2 LSP for submission to the Level 2 backbone by an attached router, but the Level 1 LSP itself is not flooded into Level 2). Another application for the ignore-attached-bit option relates to the fact that using the metrically closest attached router might not always yield optimal interarea routing. In these cases it might be desirable to use a locally defined static or generated route, in which case the IS-IS derived default route might no longer be needed.

www.juniper.net



Multilevel Configuration The slide highlights the topic we discuss next.


www.juniper.net


IS-IS Interfaces Operate in L1/L2 Mode The default operation of the IS-IS protocol within the Junos OS is to enable both Level 1 and Level 2 capabilities for all interfaces. This default behavior is designed to promote connectivity with all neighbors. If an adjacency can be formed between two routers, it will. One consequence of this default, however, is that you might form both a Level 1 and a Level 2 relationship with a given neighbor, which results in two separate adjacencies and two separate LSP flooding topologies. To disable the operation of a particular level on an interface, use the disable keyword as shown on the slide. The so-0/0/0.0 interface only operates at Level 2, and the ge-0/1/0.0 interface only operates at Level 1. As a shortcut, you can disable all Level 1 or Level 2 processing on the router, which will result in all interfaces being Level 2, or Level 1, respectively. For example, the set protocols isis level 1 disable statement will result in all interfaces operating at Level 2 only. We recommend that you explicitly configure the lo0.0 interface within the IS-IS protocol, even when the router's network entity title (NET) is assigned to another interface. Although its omission does not harm the operational aspects of IS-IS (adjacencies still form), the IP address configured on the lo0 interface will not be advertised in TLV 128 or TLV 135, making the loopback address unreachable. Note that in most cases you must run the IS-IS protocol on the lo0 interface for proper operation because the router’s NET is normally assigned to loopback interface for resiliency reasons. Continued on the next page.

www.juniper.net



IS-IS Interfaces Operate in L1/L2 Mode (contd.) Because the loopback interface operates in passive mode, you do not need to disable a particular level on that interface. By default, the IP address on the interface is advertised in both the Level 1 and Level 2 LSPs generated by the router. You can restrict the advertisement of the router’s loopback address in a particular level by disabling that level in the lo0.0 statement in the isis stanza.


www.juniper.net


Case Study: Route Leaking As previously discussed, Level 2 routes are not advertised into Level 1 areas by default. In this example, the network operator wants to advertise, or leak, Level 2 routes into Area 49.0001. This action will require a routing policy on R2, the L1/L2 area border router (ABR), specifying that the matching routes are Level 2 and will be advertised in Level1.

www.juniper.net



Policy Used to Advertise Routes Because the L1/L2 border router naturally stops the transmission of Level 2 routes into a Level 1 area, it is the logical location to override that default. You can accomplish this goal with a Junos routing policy. You configure this policy within the [edit policy-options] configuration hierarchy, and then apply the policy to the IS-IS instance at the global IS-IS level, that is, [edit protocols isis]. In the example on the slide, the match criterion within the route-leak policy is all IS-IS routes within the subnet 192.168.16.0/20 that are currently Level 2 routes and are eligible to be sent to Level 1. Once these routes are found, the configured action is to accept these routes. The use of the from and to keywords allows granular control about the desired direction of route leaking. Once the routing policy is exported into the IS-IS protocol, the Level 2 routes are inserted into the Level 1 LSP of the L1/L2 border router and are advertised into the Level 1 area. Recall from a previous slide that the L1/L2 border router also blocks external Level 1 routes from being advertised into Level 2. A similar policy is used to advertise Level 1 external routes into the Level 2 backbone. This new policy simply reverses the Level 2 and Level 1 notations and makes use of an appropriate route filter statement. Once you apply this policy, the external routes are included in the Level 2 LSPs.


www.juniper.net


Up/Down Bit Prevents Looping Previous slides described the default action of an L1/L2 router with regard to the advertisement of internal Level 1 routes within its Level 2 LSP. Conceptually, the policy referenced on the slide could interact with this default action to create a routing loop. For example, consider the case illustrated on the slide. If R1 has a policy to advertise Level 2 routes into Level 1, then R1 will include the Level 2 routes in its Level 1 LSP. As this LSP is flooded throughout the Level 2 area, it eventually arrives at R2. R2 has a policy in place that will leak Level 2 LSPs into its Level 1. Eventually, this information makes it way around to R4. If R4 advertises the Level 2 routes back into Level 2, a routing loop can form. The potential for route leaking-induced routing loops is averted by a bit in the LSP known as the up/down (U/D) bit. The purpose of this bit is to inform the L1/L2 routers whether a configured policy can advertise a route. Only routes marked with the up direction are eligible for advertisement from Level 1 to Level 2. All internal Level 1 routes will have the up/down bit set in this manner. If the up/down bit is set to down, the route has already been leaked from Level 2 into a Level 1 area and, as such, the route cannot be sent back into the Level 2 backbone by R4.

www.juniper.net



Summarize Routes at the L1/L2 Router Routes that are naturally bound by the L1/L2 border router are eligible for route summarization. These routes include external Level 1 routes and Level 2 routes from other IS-IS areas. In addition, you can also summarize internal Level 1 routes that are normally advertised into Level 2 automatically.

Create an Aggregate Route and Advertise It with Policy No concept of an area-range command exists in IS-IS. To summarize routes, you must create an aggregate route on the L1/L2 border router within the [edit routing-options] hierarchy that encompasses the routes you want to summarize. To advertise the aggregate route, you create a policy similar to the example shown on the slide. This policy is applied as an export to the IS-IS instance at the global [edit protocols isis] level. In this example, the goal is to advertise a 172.16.20.0/22 aggregate into the Level 2 backbone to represent Level 1 external routing information in the Level 1 area. When summarizing routes from one level into another, you might need to alter the default IS-IS export policy to ensure that specific prefixes are not advertised along with the corresponding aggregate. You can accomplish the altering of the export policy with a reject action associated with a route filter that will match on the specific routes in question.


www.juniper.net


Internal Level 1 Route Summarization Internal Level 1 routes are automatically advertised in a Level 2 LSP into the Level 2 backbone. The Junos OS provides a method for altering this default action with a routing policy. The example on the slide shows that the Level 1 Area 49.0001 contains multiple internal routes within the 10.0.4.0/22 address space. These routes are currently advertised individually to R3, as shown in the following output: user@R3# show route 10.0.4/22 inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.4.12/30 10.0.5.0/24 10.0.6.1/32

*[IS-IS/18] 00:28:50, metric 20 > to 10.0.2.2 via ge-0/2/1.0 *[IS-IS/18] 00:28:50, metric 30 > to 10.0.2.2 via ge-0/2/1.0 *[IS-IS/18] 00:28:50, metric 20 > to 10.0.2.2 via ge-0/2/1.0 Administratively, we want to suppress these specific internal Level 1 routes while advertising a single 10.0.4.0/22 summary in their place. We accomplish this configuration by using a combination of a routing policy and a local aggregate route defined on R2.

www.juniper.net



Level 1 Route Summarization Policy The sample policy shown on the slide meets our administrative requirements of advertising only a single summary route for the internal Level 1 routes. The first term in the policy matches and accepts the locally defined summary route on R2 for advertisement to the Level 2 backbone. The second policy term serves to override the default IS-IS export policy for routes matching the 10.0.4.0/22 route filter. It specifies that these routes will not be advertised to R3 in the Level 2 LSP generated by R2. After applying the internal-L1-summary-route policy as an export policy in R2’s IS-IS instance, we can confirm its success on R3: user@R3# show route 10.0.4/22 inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.4.0/22

*[IS-IS/165] 00:00:20, metric 20 > to 10.0.2.2 via ge-0/2/1.0


www.juniper.net


Apply Export Policy at Global Level of the IS-IS Instance One or more export policies can be applied at the global level of an IS-IS instance, as shown on the slide. Both the external-L1-summary-route and internal-L1-summary-route policies will be used to control the routes advertised by the local router. When wanted, you can apply multiple export policies to the same IS-IS instance. The same effect is normally possible through the use of a single policy containing multiple terms, but in some cases it might be easier to reuse existing policies in such a manner. Note that normal policy processing will proceed from left to right, and that policy processing will terminate once a given route meets with either an accept or reject action.

www.juniper.net




The default operation of a multilevel IS-IS network;

•

IS-IS summarization methods; and

•

The configuration and monitoring a multilevel IS-IS network.


www.juniper.net



www.juniper.net



Lab 6: Configuring a Multilevel IS-IS Network The slide provides the objectives for this lab.


www.juniper.net

Advanced Junos Service Provider Routing Chapter 8: BGP



Chapter 8–2 • BGP

•

Basic BGP operation;

•

Common BGP attributes;

•

The route selection process;

•

The alteration of the route selection process; and

•

The configuration of 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 8–3


What Is BGP? The Border Gateway Protocol (BGP) is a routing protocol between autonomous systems (ASs) and is sometimes referred to as a path-vector routing protocol because it uses an AS path, used as a vector, to prevent interdomain 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 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 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


When Should I Use BGP? 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 are likely to use portable addresses assigned directly by the regional address registry.

www.juniper.net



EBGP and IBGP 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 AS’s topology). 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, an IGP is required 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: 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: 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, searches for a connection initiated by the remote BGP peer, and changes its state to Active.


www.juniper.net



BGP Peering Sessions (contd.)


•

Active: 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: 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: 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: 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: 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: 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: 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.) •

Notification: 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 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



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 determining 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 autonomous systems 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, who 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 Multi-Homed 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, 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 autonomous systems. 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 identifier (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 Message Digest 5 (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.

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 includes multiple keys. Each key contains an identifier and a secret. The key is also configured with a unique start time and an end time. [edit protocols bgp] authentication-key-chain “bgp key chain” group int-65503 { type internal; local-address 192.168.100.1; neighbor 192.168.100.2 } Continued on the next page.

www.juniper.net



Hitless Key Rollover (contd.) [edit security] authentication-key-chains { key-chain “bgp key chain” { key 1 { secret juniper1; start-time 2011-03-01.02:00:00; } key 2 { secret juniper2; start-time 2011-04-01.02:00:00; } } }


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 table exists for each established BGP peer to store all routes received from that peer. The RIB-LOCAL table 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 the local router’s routing table rules. For example, if the router knows about a particular route through both 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.


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. (Whether the two routers are directly connected is irrelevant.) 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. Chapter 8–26 • BGP

www.juniper.net


Hidden Routes You 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. But hidden BGP routes occur for several reasons: •

The route might be a martian route;

•

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

•

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

Unresolvable Next-Hop The most common 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 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 the 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 is 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, which 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 option is not a real world option. With regard to the full IGP adjacency between AS networks, although reachability information can be provided by forming an IGP relationship with the remote EBGP peer, we do not recommend this practice because of the very trusting nature of the IGP protocols. Once this adjacency is formed, the protocol accepts any routing information the remote EBGP peer provides. 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


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

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 routing table, the route preference is evaluated. Remember 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.)

www.juniper.net

4.

If any of the remaining routes are advertised from the same neighboring AS, the router checks the 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 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 of the instance with the lowest Junos OS preference is used, which often means that BGP uses the inet.3 version of the next hop, through an MPLS LSP.

b.

Should the preference values in the inet.0 and the inet.3 routing tables tie, the physical next hop 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 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 RID (usually the loopback IP address). When comparing external routes from two distinct neighboring ASs, if the routes are equal up to the RID 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 RID, 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 IP address.



RID and Peer ID Ignored When you configure multipath on a BGP router, the selection algorithm ignores both the RID 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 OS 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 into this behavior by examining the output of the show bgp summary command. The route information from R2 shows 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/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. The other version of the route is from the R3 router (10.222.29.2), and it is marked inactive.


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 active while the routes from the R3 router are marked 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 OS 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, just the 172.16.20.16/30 route is using the 10.222.29.2 next hop, while the other three routes maintained 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/0. The routes from R2 are active, while the next-hop values from R3 are also used to forward user traffic. 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, altering this default, one-hop, physical peering EBGP behavior is advantageous. 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 time-to-live (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 to 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 destined for the local Routing Engine.


www.juniper.net


Routes with Multiple Next Hops Within the context of a BGP network, both the multihop and multipath tools 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 (PFE). 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.1 and 10.10.2.1. It has currently selected the 10.10.1.1 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 whether 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.1 and the 10.10.2.1 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


Configuration Options The slide highlights the topic we discuss next.

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 setting 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. Before Junos OS release 7.0, advertise-peer-as was the Junos OS default behavior.


www.juniper.net


Graceful Restart Graceful restart (GR) addresses the situation described on the previous slide. GR allows a router undergoing a restart event, including a restart of the routing protocol daemon (rpd), to inform its adjacent neighbors and peers of its condition. The restarting router requests a grace period from the neighbor or peer, which can then cooperate with the restarting router. When a restart event occurs and GR is enabled, the restarting router can still forward traffic during the restart period, and convergence in the network is not disrupted. The neighbors or peers of the restarting router, also known as helper routers, hide the restart event from other devices not directly connected to the restarting router. In other words, the restart is not visible to the rest of the network, and the restarting router is not removed from the network topology. The GR request occurs only if the following conditions are met:

www.juniper.net

•

The network topology is stable;

•

The neighbor or peer cooperates;

•

The restarting router is not already cooperating with another restart already in progress; and

•

The grace period does not expire.



GR Support As shown on the slide, GR is supported by several standards-based protocols. A number of RFCs and drafts exist that document the operational details for GR and each of the protocols for which GR is supported. While these different protocols implement GR slightly differently, the basic concepts and operations are the same from a high availability point of view.

GR Requirements Routers must have GR enabled to support both GR router modes—the restarting router mode and helper router mode. By default, Junos devices can operate as helper routers but not as restarting routers; restarting router mode functionality must be enabled through configuration. We cover GR configuration on subsequent slides. In addition to having the GR functionality enabled, the router must support nonstop forwarding operations, which simply means the router must be able to continue forwarding traffic during times of control plane instability. Nonstop forwarding is an inherent attribute of Junos devices because of the architectural design, which cleanly separates the control and forwarding planes.


www.juniper.net


Configuring GR: Part 1 GR helper mode is enabled by default on all Junos devices. You can disable GR helper mode globally for all supported protocols at the [edit routing-options] hierarchy or on a per-protocol, per-group, or per-neighbor basis, depending on the specific protocol. The slide illustrates the syntax required to disable GR helper mode globally, enable GR helper mode for the BGP protocol, and disable GR for a BGP peer. As with many similar configuration scenarios, the most specific definition is used.

www.juniper.net



Configuring GR: Part 2 GR’s restarting router mode is not enabled by default. You can enable GR restarting router mode through configuration at the [edit routing-options] hierarchy. The slide provides a sample configuration used to enable GR’s restarting router mode globally and for all protocols along with a sample configuration that disables GR for a specific BGP peer. The following are the available GR configuration options for BGP: [edit protocols] user@R1# set bgp graceful-restart ? Possible completions: <[Enter]> Execute this command + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups disable Disable graceful restart restart-time Restart time used when negotiating with a peer (1..600) stale-routes-time Maximum time for which stale routes are kept (1..600) | Pipe through a command


www.juniper.net


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 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 is technically 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, one AS is not 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. On 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 the next page.


www.juniper.net


Eliminating Private AS Numbers (contd.) The remove-private option is enabled on the R1 router in AS 1000. 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. The following 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, nothing is 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. Other options are the following:


•

local-as autonomous-system alias: A BGP peer considers any local AS to which it is assigned as equivalent to the primary AS number configured for the routing device. When you use the alias option, only the AS (global or local) used to establish the BGP session is prepended in the AS path sent to the BGP neighbor.

•

local-as loops number: Specify the maximum number of times that the local AS number can appear in an AS path received from a BGP peer. For number, include a value from 1 through 10. www.juniper.net


Overriding the Default Prepend Action In certain situations, the default mechanics of the AS path prepend mechanism might cause routes to not be received by a peer. One such situation is displayed on the slide. AS 65432 is providing transit service to AS65022, which peers at two different locations. For reasons that we do not discuss in this chapter, the two portions of AS 65022 do not have any other peering links between them. In fact, these two sections of the network rely on AS 65432 for reachability information to the other half of the AS. By default, the router on the right side of AS 65432 only prepends its own AS a single time before advertising the 172.16.10.0/24 route to AS 65022. Unfortunately, this route is never received by the peering router because of an AS path loop. After all, AS 65022 is already in the AS path. The EBGP peer in AS 65432 alters its configuration with its peer in AS 65002 to include the as-override command. This command allows the router in AS 65432 to examine the AS path before advertising the route and look for any instances of AS 65022 already in the path. Should it find any, they are replaced with the peer’s own AS, 65432 in this case. The EBGP peer then performs the default prepend action before advertising the route. The router in AS 65022 now receives the route without an AS path loop and installs it in its local routing table.

www.juniper.net



Allowing AS Paths Loops The Junos OS allows you to configure your router to accept an AS path loop in certain situations. The slide once again shows AS 65432 providing transit service to AS65022. As before, the 172.16.10.0/24 route is not accepted by the router in AS 65022 because of an AS path loop. The configuration option used in this example is performed on the router in AS 65022 itself. The optional keyword loops is appended to the autonomous-system command within the [edit routing-options] configuration hierarchy. This keyword allows the local AS number to appear multiple times in the path. The route can then be received by the router in AS 65022. This scenario also requires the EBGP peer in AS65432 to be configured with the advertise-peer-as command. Otherwise, routes learned from one instance of AS 65022 will not be advertised to the second instance of AS 65022.


www.juniper.net



www.juniper.net

•

Basic BGP operation;

•

Common BGP attributes;

•

The route selection process for BGP;

•

The alteration of the route selection process; and

•

The configuration of some advanced options for BGP peers.



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


www.juniper.net


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

www.juniper.net




www.juniper.net

Advanced Junos Service Provider Routing Chapter 9: BGP Attributes and Policy—Part 1



Various BGP attributes in detail and explains the operation of those attributes; and

•

The manipulation of BGP attributes using routing policy.

Chapter 9–2 • BGP Attributes and Policy—Part 1

www.juniper.net


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

www.juniper.net

BGP Attributes and Policy—Part 1 • Chapter 9–3


BGP and Policy Dependency BGP is a very policy-oriented protocol, in the sense that import and export policies largely determine BGP behavior. 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. 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 based on whether it is an EBGP or 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.

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 for each established BGP peer to store all routes received from that peer. 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. Continued on the next page.


www.juniper.net


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 IS-IS and BGP, the IS-IS route will be active in the local routing table because of the default Junos OS route 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 AS path or cluster-ID sanity checks, as well as 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 or policies (if any are configured and applied) has filtered and manipulated the BGP attributes, the BGP decision process chooses the best route to use and installs that route into the IP routing 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 some 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 (not shown) will contain two entries for the 192.168.14.0/24 prefix, 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 following list summarizes the overall effects of this policy example:

www.juniper.net

•

The 0.0.0.0/0:AS1 route is rejected.

•

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

•

The 192.168.14.0/24 route from AS1 is accepted and preferred.

•

All other AS3 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 OS 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 some 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 summarized as follows:

www.juniper.net

•

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

•

The 192.168.27.0/24:AS3 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/20 aggregate is sent to both AS 2 and AS 4.



Next Hop The slide highlights the topic we discuss next.


www.juniper.net


The Next-Hop BGP Attribute The next-hop concept in IGPs, such as IS-IS and OSPF, is relatively straightforward. IGPs basically exist to give adjacent routers next-hop reachability information, which is then flooded (in one form or another) throughout the AS. However, BGP does not flood BGP peers. And BGP cannot peer unless an underlying IGP route to the peer exists because BGP requires a TCP session for routes to be exchanged. Thus, BGP cannot bootstrap its own next hops as an IGP does. Therefore, a next hop in BGP is more elaborate than in any IGP. The concept of the BGP next-hop attribute is important. Without reachability to the IP address listed in this BGP attribute, a BGP router cannot use the advertised route. This situation is a very common problem to be solved in any ISP network. Continued on the next page.

www.juniper.net



How BGP Gets Its Next-Hop Information The default actions for changing the next-hop attribute are detailed below. Subsequent slides discuss various ways to provide the required reachability. The BGP next-hop attribute value is only changed when a route is advertised across an EBGP link. In this situation, the IP address of the advertising router is placed into the attribute. Should the receiving router choose to advertise this EBGP-learned route to any IBGP peers, it does so without modifying that IP address value. Thus, the EBGP next hop advertised into a local AS is an address from the remote AS. How is the local IGP supposed to know how to reach this external address? When new routing information is injected (or redistributed) into the BGP process, the coding of the next-hop attribute depends on the specifics of the route being injected. When a redistributed route is associated with a forwarding next hop, the BGP next-hop attribute is coded with that forwarding next hop. This behavior accommodates optimal forwarding because it allows a BGP speaker to forward directly to the source of a particular route, even though that source might not speak BGP. This behavior is known as a third-party next hop. When a redistributed route is not associated with a forwarding next hop, such as in the case of a locally defined static route with a reject next hop, the next-hop attribute is set to the local router’s peer ID. For IBGP sessions, the peer ID is typically the local router’s loopback address. For EBGP sessions, the peer ID is usually a peering address associated with a physical link.


www.juniper.net


Next-Hop BGP Example: Part 1 The next few slides graphically show the default BGP behavior with respect to the next-hop attribute. The slide shows the physical interface addresses along with the loopback addresses of each router. The slide shows the details for the R3 router. The R3 router has an EBGP session with the R4 router using 10.10.1.2. The output of the show bgp summary command is listed on the slide. The R3 router is receiving one route from R4 (peer 10.10.1.2) and actively uses that route (last column is 1/1/0). You can verify this activity with the show route terse output, where 172.19.20.0/24 is listed as an active route from protocol BGP and a next hop of 10.10.1.2.

www.juniper.net



Next-Hop BGP Example: Part 2 The slide shows the output from the R1 router. The R1 router has an IBGP session with the R3 router using R3’s loopback address of 192.168.10.1. The output of the show bgp summary command shows that the R1 router is receiving one route from the R3 router (peer 192.168.10.1), but it is not used to forward traffic (last column is 0/1/0). In fact, a look at the show route output does not show 172.19.20.0/24 (the active BGP route on the R3 router) listed at all. If the 172.19.20.0/24 route is received by the R1 router from the R3 router, then the route should appear as the active route (there is no chance of an AS 1 IGP also supplying this AS 2 route). What is the problem?


www.juniper.net


Next-Hop BGP Example: Part 3 You can see the problem with the absent route to 172.19.20.0/24 on the R1 router with the help of the show route hidden extensive command run on the R1 router. The output from this command shows the 172.19.20.0/24 route, but the route is hidden. By examining the output a little more closely, you can determine that the next hop is unusable (Next hop type: Unusable). Why is this route unusable? Obviously, connectivity exists from R1 to R3. Notice, however, that the current BGP next-hop attribute for the 172.19.20.0/24 route is set to 10.10.1.2 (the physical interface IP address of the R4 router). The R3 router does not change the BGP next-hop attribute before the route is advertised to the R1 router, which is the default EBGP-to-IBGP behavior—not to change the advertised next-hop attribute value. The show route terse output on the previous slide did not show a route to 10.10.1.2. Because the R1 router does not have reachability to the IP address listed as the BGP next-hop attribute, it cannot use the received BGP route. On a Juniper Networks router, this type of unusable route is marked as a hidden route.

www.juniper.net



BGP Next-Hop Solutions Numerous approaches exist to solve this BGP next-hop reachability problem, and five examples are listed on the slide. Some of these examples are not best practices in a networking environment but technically solve the reachability issue. Some are in the category of you can use a hammer to swat a fly on a window, but you might want to use something else…. Perhaps 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. You 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 the 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 is 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 option 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, although reachability information can be provided by forming an IGP relationship with the remote EBGP peer, we do not recommend this practice 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



Example Using Next-Hop Self: Part 1 The next few slides show how the use of next-hop-self in a routing policy provides reachability for IBGP peers. The slide details the situation on the R3 router. The R3 router has an EBGP connection to the R4 router using 10.10.1.2 and two IBGP connections to the R2 router and to the R1 router. The R3 router is now configured with the next-hop-self policy shown on the slide as the output of the show policy-options configuration command. The policy matches all routes (no from) and replaces the BGP next-hop attribute (because only BGP has a next-hop attribute) with the value self (a keyword for the local router’s physical interface address on which the route is advertised). This next-hop-self policy is applied as an export policy to the BGP group int, which includes the R1 router.


www.juniper.net


Example Using Next-Hop Self: Part 2 This slide shifts the focus of attention to the R1 router. The output of the show bgp summary command now shows that the R1 router is receiving one route from the R3 router (192.168.10.1) and that this route is actively used to forward traffic (last column is 1/1/0). A look at the show route terse output now shows the 172.19.20.0/24 listed as a BGP route with a next hop of 10.40.4.1. This next-hop address is the self next-hop address advertised for the route to the R1 router by the R3 router because the route was advertised on the 10.40.4.1 interface.

www.juniper.net



Example Using Next-Hop Self: Part 3 How do you know that the BGP next-hop attribute was really changed with the policy? To verify that the policy on the R3 router has indeed changed the BGP next-hop attribute, you can look at the output of the show route extensive command on the R1 router. The output lists the BGP next hop for the 172.19.20.0/24 prefix (which is in AS 2) as 192.168.10.1, the loopback address of the R3 router. Because the R1 router has IGP reachability to the R3 router, the R1 router also has reachability to the BGP next-hop value and can use the BGP route.


www.juniper.net


Next-Hop Equals Peer Address The default action of the BGP protocol is for an EBGP-speaking peer to modify the next-hop attribute prior to advertising a route to peers. The address of the EBGP peering session is the address used for the next hop.

EBGP Peer Can Alter Attribute An EGBP peer can alter this default action through the use of a policy or a BGP configuration statement. The advertised address could be an additional EBGP router on a broadcast network. The address could be an IBGP router in the sending autonomous system (AS). Problems could arise in this situation because the advertised next hop might not be reachable by the local router. This situation would result in the routes being hidden and unusable.

Policy Used to Change Incoming Next Hop The local router can use an import policy to alter the next-hop attribute to be the address of the EBGP peer. This address can guarantee that the local router has connectivity to that next hop. Hence, the advertised routes are usable and active in the inet.0 routing table.

www.juniper.net



Example Using Next-Hop Peer Address: Part 1 The next few slides show how the use of next-hop peer-address in a routing policy corrects the advertisement of improper addresses. The slide details the situation on the R1 router. The R1 router has a multihop EBGP connection to the R2 router using 172.16.20.1. The R2 router advertises routes to the R1 router with a BGP next hop of 172.16.30.1. Because the R1 router does not currently have IP reachability to the advertised next-hop address, the received routes are unusable. The routes then appear as hidden routes within the inet.0 routing table.


www.juniper.net


Example Using Next-Hop Peer Address: Part 2 The slide shows the policy next-hop-to-peer-address on the R1 router. The policy is applied as an import policy within the peer group for the R2 router.

www.juniper.net



Example Using Next-Hop Peer Address: Part 3 After the configuration on the previous slide is committed, the received routes from the R2 router are then usable. On the slide, note that the current Protocol Nexthop is listed as 172.16.20.1, which is the peering address of the R2 router. This address is then recursively associated with 10.10.1.2, which is the physical next hop used to reach the R2 router’s loopback address.


www.juniper.net


Origin and MED The slide highlights the topic we discuss next.

www.juniper.net



Set by Router Originating the Information The first router to inject the route into BGP attaches the origin attribute to a prefix (that is, a route). Other routers can change this value, of course, as the route makes its way through an AS and on to other ASs.

How Believable Is This Information? The intent of the origin code is to provide a measure of believability as to the origin of a particular route. In other words, the intent is to provide a kind of where did you get this from? clue for other routers seeing the route.

Well-Known Mandatory BGP Attribute The origin code is a well-known, mandatory BGP attribute (the Type Code is 1), meaning that each route associated with BGP must have an origin code assigned to it. Continued on the next page.


www.juniper.net


Internal, External, or Unknown The values available for the origin attribute are internal, external, and incomplete. The internal (I) origin is a tag designated for all routes learned through a traditional IGP, such as OSPF, IS-IS, or RIP. These types of routes were typically seen as best sources of information because of their stability at the time BGP was created. The external (E) origin is a tag designated for routes learned through the original Exterior Gateway Protocol (EGP). This protocol was the precursor to BGP but was not as robust, and it was generally less reliable than the IGP routes. The last origin code of incomplete (?) is a tag designated for all routes that did not fall into either the internal or external categories.

Internal Better than External Better than Unknown Each of the origin tags is assigned a value for use in transmitting the attribute to other BGP speakers. The values are 0 for internal origin (I), 1 for external origin (E), and 2 for unknown (incomplete) origin (?). A lower value is better, so routes learned from an IGP are preferred over routes learned from an EGP. EGP routes are better than incomplete routes.

The Junos OS Default Is Internal—IGP Because all routing information eligible to be injected into BGP on a Juniper Networks router resides in inet.0, the Junos OS sees all possible routes as internal routes. These internal routes all receive a BGP origin code of internal when placed into BGP.

www.juniper.net



How Origin Is Used The slide shows the default BGP behavior within the Junos OS with regard to the origin code. Within the AS shown, the static routes of 10.0.0.0/8, 172.16.0.0/16, and 192.168.27.0/24 exist. An export policy placed these routes into BGP. A direct route of 192.168.14.0/24 exists that was exported into BGP. The route to 172.31.0.0/24 was learned from another AS altogether, and this route contains an origin attribute coded to 2, which indicates an unknown origin. Finally, an IGP-learned route of 10.20.0.0/16 exists in the network. The router does not know whether this route is an OSPF route or an IS-IS route, but the route had the appropriate export policy and, therefore, was placed into BGP. To the Juniper Networks router, it does not matter that these routes are advertised to another AS through EBGP; the BGP origin code is not altered as the routes are advertised to an EBGP peer. On the basis of the origin attribute alone, the 172.31.0/24 prefix appears less attractive to the remote AS.


www.juniper.net


Example of Origin Attribute Use: Part 1 In the collection of AS networks on the slide, for all routes originated by AS 1, the BGP origin code is at its default setting of internal. These routes are sent to each of the AS networks on the slide. How will AS 40 send traffic to AS 1? Through AS 30, or AS 20, or AS 10? Assume that the local-preference BGP attribute is the default, and that the AS-path BGP attribute accurately reflects the actual path for the route. Routers in AS 40 see the AS 1 routes advertised from both AS 20 and AS 10. Because the local-preference values and AS-path lengths are the same for both sets of routes, the origin code is examined. For both sets of routes, the origin code is the same as well. Some other method must be used to determine which path the AS 40 routers use. Although that determination is outside the scope of this slide, the important point here is that AS 1 has no way to control how the AS 40 routers reach the AS 1 networks, based on the default value of the origin code alone.

Other AS Networks Note that routers in AS 30 use AS 20 to reach the networks in AS 1, because of a shorter AS-path length through AS 20. Also, routers in AS 20 use AS 2 to reach the networks in AS 1, because of a shorter AS-path length. Finally, routers in AS 10 use AS 3 to reach the networks in AS 1, because of a shorter AS-path length. Why should AS 40 be the only AS confused about the best way to reach AS 1?

www.juniper.net



Example of Origin Attribute Use Part 2 On the previous slide, only AS 40 had multiple path options after examining the AS-path length, because both AS 10 and AS 20 are the same distance away from AS 1. At this point, the value of any other tiebreakers that AS 40 might use to pick one of those two paths through AS 10 or AS 20 is unknown to AS 1. However, perhaps AS 1 now decides that traffic sent to it from AS 40 should use AS 10 rather than AS 20 (for reasons of economics, politics, or something else). By using a routing policy, AS 1 alters the BGP origin code to incomplete (?) on all routes advertised to AS 2. Consider the effect of this policy on AS 40. Routers in AS 40 still see the AS 1 routes advertised from both AS 20 and AS 10. Because the local-preference and AS-path lengths are the same for both sets of routes, the origin code is examined. The routes received by AS 40 from AS 10 have an origin of internal (0) while the routes received from AS 20 have an origin code of incomplete (2). Internal is better (lower) than incomplete, so the routes from AS 10 are used to reach the networks in AS 1. By altering the origin code, AS 1 can now influence the routing decisions in AS 40. Continued on the next page.


www.juniper.net


Other AS Networks Note that, because of shorter AS-path length, the following occur: Routers in AS 30 still use AS 20 to reach the networks in AS 1. Routers in AS 20 still use AS 2 to reach the networks in AS 1. Routers in AS 10 still use AS 3 to reach the networks in AS 1. Notice also that all the other AS networks on the slide (besides AS 40) still use the AS-path length for route selection. The origin code is truly only effective when the AS-path lengths are equal.

www.juniper.net



Modifying Origin with a Policy The slide shows an example of a BGP export policy that changes the origin code. This example finds all BGP routes and changes the origin code from internal (0) to incomplete (2). The match criteria for the policy are all active BGP routes that currently have an origin code of internal. The action for the policy is to change the origin code to incomplete. Once applied as a BGP export policy and committed, this policy starts altering the origin code for all BGP routes advertised to all BGP peers. The Junos OS has specific keywords to represent the different BGP origin codes. They are: •

igp: Internal (value 0);

•

egp: External (value 1); and

•

incomplete: Incomplete (value 2).


www.juniper.net


MED Is Optional, Nontransitive The BGP multiple exit discriminator (MED) attribute is an optional, nontransitive attribute of BGP. Thus, a BGP implementation does not have to understand or use MEDs at all, and a MED is not sent through one AS and on to another AS. In other words, MEDs are only exchanged between pairs of directly connected ASs. So, by default, MED values are transmitted along with BGP routes within the AS where the MED first originated and to all neighboring ASs. The MED travels no further without some intervention from a policy or alternate configuration.

Used with Multiple Inter-AS Links The MED is a type of routing metric assigned to BGP routes. The function of the MED is to assist a neighboring AS to pick which of multiple links connecting the remote AS to the local AS (ingress paths) to use for traffic to a particular route (prefix).

Seeks to Influence Inbound Traffic MEDs are an attempt by the local AS to influence the routing decisions in the remote AS for traffic inbound to the local AS, just like the origin attribute. And just like the origin attribute, MEDs are a negative-bias mechanism to make some paths look worse than others. Continued on the next page.

www.juniper.net



Primitive Load Balancing You can use MED values to perform some form of primitive load balancing between ASs with multiple links between them. However, the use of MEDs for load balancing is neither efficient nor particularly effective, compared to more sophisticated mechanisms available.

Usually Taken from IGP Metric You can set MED values from multiple locations, including administrator configuration or IGP metrics. However, it is very common to take MED values from the metric values in the IGP.

Effects Not Guaranteed Despite the best efforts on the part of a local AS to manipulate MED values to influence inbound traffic flows to the local AS, other ASs can always preempt, or even ignore, the MED. This reaction is not only because the MED is an optional BGP attribute, but also because several other BGP attributes are more important than MED in the BGP route selection process. For example, an altered local-preference attribute always overrides the MED.


www.juniper.net


Simple MED Use The slide shows a very basic example in the use of the BGP MED attribute to influence inter-AS traffic flows. AS 1 assigned its IP address spaces so that it can summarize its network into two major segments. Furthermore, AS 1 is relatively cleanly divided into networks near the left most router (10.10.0.0/16 networks are nearby) and networks near the right most router (10.20.0.0/16 networks are nearby). Perhaps the split is between Eastern and Western operations, but there are many other alternatives. AS 1 has two EBGP sessions to the customer Acme and advertises both the 10.10.0.0/16 and the 10.20.0.0/16 networks to Acme on each EBGP session, as shown on the slide. Naturally, AS 1 would like Acme to return traffic to the closest point in the network so that timely packet delivery and low latency can be achieved. Ordinarily, AS 1 would have no real way to convey this desire to Acme, and Acme would simply send traffic to AS 1 over whichever router Acme decides to use based on its own routing policies. However, the MED attribute offers a method for AS 1 to influence the routing policy on Acme for traffic sent to AS 1. To accomplish this closest point goal, AS 1 alters the MED values on the routes that it advertises to Acme with a BGP export routing policy. Continued on the next page.

www.juniper.net



Simple MED Use (contd.) Both of the networks in AS 1 are advertised across both links for redundancy. All things being equal, the routers in Acme still see multiple network paths to the routes in AS 1 as the AS 1 routes are passed along throughout Acme. The Acme routers, however, use the MED values of 10 and 20 (10 being preferred) to choose the BGP path to install in their local routing tables. Thus, within Acme, traffic to 10.10.0.0/16 networks flows to the left most router and out to AS 1, while traffic to 10.20.0.0/16 networks flows to the right-most router and out to AS 1. AS 1 influenced Acme, and, at the same time, achieved a primitive type of load balancing.


www.juniper.net


Sophisticated MED Use The use of the MED attribute is straightforward when adjacent pairs of ASs are considered. The use of the MED attribute becomes a little more complicated when more than one AS is involved. Consider the AS networks on the slide. Both AS 2 and AS 3 advertise the 192.168.13.0/24 route to AS 1 and want to influence the way AS 1 sends traffic to 192.168.13.0/24. All three of the advertisements have identical local-preference values, AS-path lengths, and BGP origin codes. The other IP addresses on the slide represent the router IDs of the three routers in R1, R3, and R4. The MED value from the AS 2 router is the lowest among the three advertisements. Yet, when the router in AS 1 chooses the BGP path to use in its local routing table, the AS 1 router most likely chooses R1 in AS 3. Why should this be? The problem in this scenario is that the default evaluation of the MED attribute only happens when route advertisements come from the same neighboring AS. In this scenario, only two of the three advertisements come from the same AS: those from R3 and R1. Between those two advertisements, the route from R1 is the best, because of its lower MED value. Continued on the next page.

www.juniper.net



Sophisticated MED Use (contd.) The route from R4 in AS 2 cannot be compared to the two routes from AS 3 because it is from a different AS. At this point, AS 1 is left with the R1 and the R4 routes. The R1 route will most likely be selected as the active path because this router has a lower router ID than R4. However, the routers in AS 1 can compare the MED values for all three of these routes with the use of the always-compare-med configuration statement. With this configuration, the path to 192.168.13.0/24 through R4 should be chosen, based on the lowest MED value.


www.juniper.net


Always Compare MEDs By default, only the MED values from the same neighboring AS are compared to select a BGP path. However, the always-compare-med configuration statement allows you to override the default BGP behavior for MED evaluation. When configured, all routes that have the shortest AS-path length are compared to each other to determine the route with the smallest MED value, not just routes from the same AS. The route with the lowest MED value is then selected as the active BGP path, regardless of the AS the route came from. The lowest MED value is selected as long as other path selection values for the route, such as local preference, are the same. You must be cautious when comparing MED values from different ASs. Some inherent danger exists when using the always-compare-med configuration option to compare MED values from more than one AS because every AS in the Internet can set its own good and bad values for MEDs. One AS might consider a MED of 50 as the best, while 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 (MEDs are optional), which essentially sets the MED value to 0.

www.juniper.net



MED Is Metric Applied to BGP The Junos routing policy framework can use the BGP MED attribute as both a match condition and as an action. The metric statement applied to BGP indicates the MED value. That is, a policy can match on a certain MED value or set the MED value to a certain value as an action.

Value Can Be Manipulated Mathematically Moreover, you can set the MED value not only to a specific value, but you can manipulate it mathematically (add 100 to MED or subtract 50 from MED). The example on the slide shows the MED attribute modified for certain routes. As mentioned, the metric statement represents the MED value. Within a policy, you can set the metric to a value, you can add to its current value, or you can subtract from its current value. The policy shown: •

Sets the MED to 50 for the 172.31.25.0/24 route;

•

Increases the current MED value by 50 for all routes within the 192.168.32.0/20 network; and

•

Decreases the current MED value by 50 for all routes within the 10.124.0.0/16 network with a mask shorter than /24. Should the current value be less than 50, the result of this policy action will be a MED value of 0.


www.juniper.net


Setting the MED Directly The MED value can be set directly using the metric-out statement at the group or neighbor level of [edit protocols bgp]. The following options are available:

www.juniper.net

•

Set to a specific value;

•

Set to the current IGP metric;

•

Set to the minimum IGP metric ever learned;

•

Can add or subtract from the IGP metric; and

•

Can use the statement within a routing policy.



MED and IGP Metrics MED values do not have to be arbitrary. In many cases, the MED values are coordinated with the metric values used by an IGP. Thus, BGP can set the MED value on routes advertised based on the IGP metric leading to the BGP peer from which the route was received.

Use of Metric in a Policy You can set the MED value to match the internal IGP metric to reach the IBGP peer that advertised the route. Use the metric igp command to do this. As the IGP metric to this peer changes, the MED value associated with these routes also changes. You can see this within the term possible-igp-setting in the policy on the slide. The MED value changes every time the IGP metric to the peer changes. If this 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 does not increase the MED value—the metric minimum-igp command alters this value. You can see this setting within the term possible-minimum-igp-setting in the policy on the slide. Lastly, you can use the addition and subtraction functions used with the add or subtract policy functions of the metric command in conjunction with both the igp and minimum-igp options. To alter the MED this way, use the metric igp offset or metric minimum-igp offset command. You can both add to and subtract from the metric.


www.juniper.net


Aggregates Lose MED Information MED values have, by default, a limited scope of operation. For example, by default, MED values are not propagated through one AS and on to another AS (nontransitive). This limiting concept also applies when route aggregation is examined. When a new aggregate route is created, any MED values currently assigned to any contributing route remain only with those routes. The aggregate route has no MED value assigned to it, which is a MED value of 0. While at first this might seem to be a contradiction, because 0 is a MED, the aggregate route has no method for determining which one MED value to choose, so a MED value of 0 is used. No alternative really exists. Because a BGP route can have only one MED value, the aggregate must choose what that value should be. Should the aggregate take the worst MED value from the contributors and be conservative? Should the aggregate take the best MED value to not penalize that contributing route? Should the aggregate average the contributors MED values together? None of these would adequately represent all the contributing information, so the aggregate route takes the ultimate conservative approach: MED equals 0, or no MED at all.

www.juniper.net



Default Aggregate MED Behavior The slide shows the default MED behavior regarding aggregate routes. The router receives the 192.168.17.0/24 route with a MED of 10. You see this from the output of the show route protocol bgp command, as shown on the slide. The router has a locally defined aggregate route, which a policy injects into BGP (the policy is not shown on the slide). By examining the show route advertising-protocol bgp output, you can see that both the aggregate route and the more specific, received BGP route are advertised. The 192.168.17.0/24 route maintains its MED of 10, and the aggregate route of 192.168.16.0/20 has no MED value (MED=0) assigned. Of course, you can always change the MED value on the aggregate with a routing policy, but this lack of an aggregate MED value is the default behavior. Thus, it is ironic that MEDs, which are most useful between AS pairs, are useless by default on aggregates, which are exactly the types of routes you want to send between AS pairs!


www.juniper.net


AS Path The slide highlights the topic we discuss next.

www.juniper.net



The AS-Path Attribute The AS-path attribute describes the path of autonomous systems that the route has been through since it was sourced into BGP. When a BGP router receives routes in an update message, the first action is to examine the current AS path to see if the local AS number (ASN) is in the path. If it is in the path, it indicates that the route has been through the AS already; accepting the route would cause a loop. Therefore, BGP drops the route. The Junos OS performs a verification to ensure that the receiving router’s AS number is not listed in the AS path. If the receiving router’s AS number is listed in the AS path, the router does not advertise the route. By default, the AS-path value is changed as a route transitions between autonomous systems. The AS-path value is null until the associated route is advertised out of the originating AS. As the route leaves an AS, the BGP router adds the local AS number to the front of the path before sending it to a peer. Using routing policy, you can prepend your ASN information to the AS-path attribute. By prepending your ASN information to the AS-path multiple times, you can affect the routing decision made by routers in other autonomous systems and discourage those routes from using that path because of the longer AS-path. The AS-path attribute is mandatory; thus, it must always be present for all BGP routes.


www.juniper.net


16-bit Autonomous System Numbers AS numbers are assigned in blocks by the Internet Assigned Numbers Authority (IANA) to Regional Internet Registries (RIRs). The RIR then assigns AS numbers to entities within its designated area. RFC 1930 defined 65536 ASNs using 16-bit integers. The ASNs 0, 56320–64511, and 65535 are reserved by the IANA and should not be used in any routing environment. IANA designated AS numbers 64512 through 65534 to be used for private networks.

32-bit Autonomous System Numbers RFC 4893 defines 32-bit ASNs. These numbers are written either as simple integers, or in the form x.y, where x and y are 16-bit numbers. Numbers of the form 0.y are exactly the old 16-bit AS numbers, 1.y numbers and 65535.65535 are reserved, and the remainder of the space is available for allocation.

www.juniper.net



Manipulating the AS Path If the AS-path attribute is changed before the route is readvertised to other BGP routers, a route through the local AS can look less attractive to another AS. Note that making the route more attractive by shortening the AS path should not really be possible. However, you can lengthen the path to make the AS-path attribute another type of negative-bias path selection mechanism. In other words, unlengthened paths look more attractive for other AS networks to use than artificially lengthened AS paths.

AS-Path Prepending The only standard approach to alter the AS-path attribute is to add information to it by prepending. You can use a routing policy to extend (by prepending) AS-path information artificially onto an existing AS path. This type of a policy is often an attempt to influence traffic coming into an AS from another AS. Continued on the next page.


www.juniper.net


AS-Path Prepending (contd.) On the slide, AS 1 announces its routes to both AS 2 and AS 3. Using a routing policy, AS 1 prepends its own AS number four times (shown as 1 1 1 1 1 on the slide) onto all route announcements to AS 2. This action causes the following: •

AS 2 will use AS 20 to forward packets to AS 1;

•


•


•

AS 30 will use AS 40 to forward packets to AS 1; and

•

AS 40 will use AS 10 to forward packets to AS 1.

Note that this behavior on the part of AS 2 (using AS 20 instead of sending directly to AS 1) is unexpected and would not occur without the routing policy. This behavior is extended to AS 20 as well, because AS 2 cannot shorten the AS path advertised by AS 1, even if AS 2 would like to shorten it.

www.juniper.net



Policy to Prepend AS Path The slide shows the routing policy AS 1 used in the previous example. A policy named longer-as-path was created on the AS 1 router. Because no from statement exists, all candidate routes match the policy. The action taken on all of the matched routes is to add AS 1 to each route four times. You can use either the as-path-prepend as-number or the as-path-expand last-as count number policy options to add AS numbers to the AS-path attribute in an attempt to make a given route appear less desirable. The latter option automatically locates the most recent AS in the path (the last entry) and prepends it the specified number of times prior to advertising the route to EBGP peers. This particular action is performed with the as-path-prepend statement. This routing policy then is applied for routes exported by BGP to the external BGP peer in AS 2.


www.juniper.net


The Symbol Tells All A symbol can provide information on an object. For example, when looking at the AS path on a Juniper Networks router: •

Brackets ([ ]): Enclose the local AS number associated with the AS path if more than one AS number is configured on the router or if the AS number is being prepended.

•

Braces ({ }): Enclose AS sets—groups of AS numbers in which the order does not matter. A set commonly results from route aggregation. The numbers in each AS set are displayed in ascending order.

•

Parentheses ( ( ) ): Enclose a confederation.

•

Brackets inside parentheses ( ( [ ] ) ): Enclose a confederation set.

In the output on the slide, you can see four routes with different AS paths. The second route represents a bracket output, the third route represents an AS set, and the fourth route represents a confederation.

www.juniper.net



Regular Expressions Often, administrative BGP routing policies require that route announcements or prefixes be found and acted on based on the information contained within the AS-path attribute. This requirement might be to enforce some administrative policy regarding other AS networks. Sometimes, it is just easier to find routes based on their AS path than by looking for many specific prefixes and routes individually.

Other Uses The slide lists some examples of the types of information that must be found in the AS path.

Regular Expressions Can Find Prefixes Through the use of regular expressions, you can quite easily find this type of information in the AS-path attribute.


www.juniper.net


Regular Expressions for Pattern Matching A regular expression (often called regex) is a powerful, pattern-matching tool you can apply in a routing policy to act on AS-path strings. This pattern-matching engine can find specific strings of text or textual patterns.

Different from Wildcards When used in a routing policy, regular expressions work not only on fixed strings, like wildcard operators such as an asterisk (*), but also on variable patterns of text, through the combination of basic text patterns and special operators.

Text Plus Operators Regular expressions are made up of a combination of basic text patterns and special operators.

Context-Sensitive Matching Regular expressions allow information in a string to be found within a specific context, not just in isolated instances. You can use regular expressions in conjunction with the BGP AS-path attribute to match routes within a policy.

www.juniper.net



Configure a Regular Expression Regular expressions have two main components to them—the term and the operator. These expressions take the form term operator.

Terms Are AS Numbers in the AS-Path Attribute The regular expression term is the core matching component to be found by the pattern-matching engine. The term is a mandatory object, and each regular expression must have at least one term. Terms identify the AS number. This AS could be a single number (1024), a complete AS path (1024 2685 3957), or a wildcard character (.) representing any single AS number (1024 . 3957).

Each AS Is an Entity Within the Junos AS-path regular expression syntax, the term is a complete AS value. You can use the wildcard character of the dot ( . ) to represent a single AS number as well. Thus, the Junos OS detects an AS number of 1024 (for example) not as the four character text string of 1, 0, 2, 4, but as the single entity of 1024. To the Junos OS, AS numbers are not sequences of characters.


www.juniper.net


Regular Expression Operators All regular expressions take the form term operator. Use of the term is mandatory.

The Operator Is Optional However, the regular expression operator is an optional component of the pattern-matching engine. You can associate an operator with a single, regular expression term. If used, the operator appears immediately after the term on which it is operating. Two special regular expression operators can appear between regular expression terms. These special characters are the pipe ( | ) and the dash ( - ). You use the pipe ( | ) operator between terms to indicate OR (1024 OR 2685 is 1024 | 2685). You use the dash ( - ) operator between terms to indicate range (1024 through 2685 is 1024-2685).

More Than One An individual regular expression can contain multiple term-operator pairs.

www.juniper.net



Regex Operators for the AS Path The table on the slide shows a subset of the possible regular expression operators you can use with routing policies. Some operators are a shorthand for their longer equivalents. Of special note is the use of the parentheses. Typically, you use the parentheses ( ) operator to group multiple terms together in conjunction with an operator. For example, the regular expression (1|2)? is translated as either AS 1 or AS 2 can be present in the AS path zero times (absent), or at most one time (this is what the ? operator means). The parentheses operator also has another special use. When used with no spaces in between, parentheses represent a null AS-path value. We cover the concept of the null AS path on future slides.


www.juniper.net


AS-Path Regex Examples The table on the slide shows some examples of regular expression pattern matching as applied to AS paths. The first column shows the AS-path string that the routing policy is trying to match. The second column shows the regular expression used to match that pattern. The last column shows examples of values of the BGP AS-path attribute that the regular expression will match. In some cases, the list is not exhaustive, so more AS paths will match the pattern.

www.juniper.net



More AS-Path Regex Examples The table on the slide shows more examples of regular expression pattern matching as applied to AS paths. As before, the first column shows the AS-path string that the routing policy tries to match. The second column shows the regular expression used to match that pattern. The last column shows examples of values of the BGP AS-path attribute that the regular expression will match. In some cases, the list is not exhaustive, so more AS paths will match the pattern.


www.juniper.net


Regular Expressions and Policies You can use AS-path regular expressions as the match criteria within a routing policy. This application of the regular expression is similar in concept to the application of a policy. As such, AS-path regular expressions follow the Junos abstraction concept of first defining the entity and then applying the entity.

Format Both the definition and application of the AS-path regular expressions occurs within the policy-options configuration hierarchy. The regular expression in proper term operator format is given a name with the as-path statement.

AS-Path Name You can reference the regular expression name within a policy.

Spaces Are Allowed The name can be up to 255 characters long and can even include spaces, as long as the name is enclosed in double quotation marks. In practice, however, this practice is not common.

Applied After Definition Once defined, you can apply the AS-path regular expression as a policy match condition. www.juniper.net



AS-Path Regex Policy Example The example on the slide shows an AS-path regular expression used as a policy match condition. The goal is to have a BGP routing policy that accepts only routes with the exact AS path of 1234 56 78 9. We defined an AS path named digits-route within the double quotation marks. The AS path contains only terms (no operators) and defines an exact AS-path match of “1234 56 78 9”. We then used the digits-route path definition within the from-digits-route policy to match routes and accept them. A second term in the policy rejects all other routes. When you apply this policy as an import BGP policy, only routes matching the AS path defined in digits-route are accepted. All other routes seen by BGP are rejected.


www.juniper.net


Another AS-Path Regex Policy Example The example on the slide shows another AS-path regular expression used as a policy match condition. This time, however, the AS path uses both terms and operators. The goal this time is to reject routes that either originate in ASs 123–125, transited through ASs 123–125, or were advertised directly from ASs 123–125. To do this, we defined an AS path named not-a-good-route. The AS path contains both terms and operators. Thus, not-a-good-route defines an AS-path match as follows: •

The AS path starts off with any AS value zero or more times, followed by…

•

Any AS value between 123 and 125, followed by…

•

Any AS value zero or more times.

The not-a-good-route path definition is then used within the from-not-a-good-route policy to match routes and reject them. When you apply this policy as an import BGP policy, only routes matching an AS path defined in not-a-good-route are rejected.

www.juniper.net



Given a Policy Consider the routing policy shown on the slide.

Look at the Results Does this policy, when properly applied, accept a route with the path 1024 44 44 2685, given the as-path statements listed on the slide? Using the different as-path definitions within the testing-as-paths policy gives the following results: •

“.* 1024”: Starts with any AS zero or more times, followed by 1024. The route will not match the term as-paths. This definition does not allow for AS numbers after 1024. Therefore, it is rejected by the final action.

•

“1024 .*”: Starts with 1024, followed by zero or more AS numbers. The route does match the term as-paths. It is accepted.

•

“.* 1024 .*”: Starts with any AS zero or more times, followed by 1024, followed by zero or more AS numbers. The route does match the term as-paths. It is accepted.



www.juniper.net


Look at the Results (contd.)

www.juniper.net

•

“.* 44{1,2} .*”: Starts with any AS zero or more times, followed by 44 once or twice, followed by zero or more AS numbers. The route does match the term as-paths. It is accepted.

•

“2685 44{1,3} 1024”: Start with AS 2685, followed by 44 one to three times, followed by 1024. The route does not match the term as-paths. Therefore, it is rejected by the final action.

•

“1024 44{1,3} 2685”: Start with AS 1024, followed by 44 one to three times, followed by 2685. The route does match the term as-paths. It is accepted.



AS Path Regular Expression Enhancements The AS-path regular expression examples shown thus far are perfectly workable. However, circumstances occur where support for as-path-groups can save you some configuration work and possible mental anguish. AS-path groups allow you to define a list of individual AS-path regular expressions for evaluation as a logical OR within a policy. The example on the slide shows an AS-path group named as-group-1, which comprises three individual AS-path regular expressions. The as-group-1 AS-path group is referenced in the test-as-group policy using a single \ statement. You can specify multiple AS-path groups as part of a single from statement if needed. Achieving the same result without the as-path-group feature requires that you define three separate AS-path regular expressions that are evaluated as a logical OR: [edit policy-options] user@router# show policy-statement not-ideal { from as-path [ path_1 path_2 path_3 ]; } as-path path_1 ".* 1 .*"; as-path path_2 ".* 2 .*"; as-path path_3 ".* 3 .*"; Continued on the next page.


www.juniper.net


AS Path Regular Expression Enhancements (contd.) Or, achieving the same result without the as-path-group feature requires that you define a single, and possibly quite long, AS-path regular expression: [edit policy-options] user@router# show policy-statement not-ideal-either { from as-path customers; } as-path customers ".* 1 .*|.* 2 .*|.* 3 .*"; Using the as-path-group feature alleviates both of these issues. The example on the slide is functionally identical to both of the alternatives shown here.

www.juniper.net



Role of Null AS Path The concept of the null AS path is quite important for the Internet. Routes originating within a particular AS have yet to prepend the BGP AS-path attribute. Therefore, no information is contained in the AS-path attribute for routes originating within the AS, and the AS path is assumed to be null (empty). So, how are routes originating within the AS that were advertised with BGP to be found with a routing policy using an AS-path policy? They are found by creating a match condition based on the null AS path.

Defining the Null AS Path To specify the null AS path using a regular expression, use the parentheses with no space in between them. In the example on the slide, the router receives four routes from IBGP. By examining the routing table, you can see that the AS path column is empty (I is for the origin code). Therefore, these routes were sourced within the router’s own AS. The null AS path finds these routes.


www.juniper.net


Finding Local Routes You can use the null AS path to find routes advertised by BGP that originated within the local AS path. When would this be helpful? Usually, when one AS path does not want to carry transit traffic for another AS path. In the example on the slide, the null AS path is used to halt BGP transit traffic from AS 1 through AS 2. AS 2 does not want to readvertise the routes from AS 1 to AS 4, which could lead to AS 4 routing traffic for AS 1 through AS 2. However, AS 2 still must advertise its own routes to AS 4 so that these prefixes are reachable. AS 2 defines an as-path applied as a BGP export policy towards AS 4 that rejects all routes except those with a null AS path.

www.juniper.net



Use of Null AS Path: Part 1 The slide shows an example of null AS path in action. We applied the not-a-transit policy on the slide as an export policy on R2 towards the EBGP peer on the right side of the diagram. The policy has a term called accept-my-as that matches BGP routes with an as-path regular expression of (). The reject-all-else term rejects all other routes.


www.juniper.net


Use of Null AS Path: Part 2 The slide shows the results of the previously configured and applied policy. The show route protocol bgp output shows that the router R2 receives five BGP routes from its IBGP peer R1. One of these routes is from AS 1, and the other four are sourced from within the AS. The show route advertising-protocol bgp output shows that only the four routes sourced from within the AS are sent to the EBGP peer. The null AS-path regular expression in the routing policy rejects transit routes.

www.juniper.net




Various BGP attributes in detail and explained the operation of those attributes; and

•

How to manipulate BGP attributes using routing policy.


www.juniper.net



www.juniper.net



Lab 8: BGP Attributes: Next-Hop, Origin, MED, and AS Path This slide provides the objectives for this lab.


www.juniper.net

Advanced Junos Service Provider Routing Chapter 10: BGP Attributes and Policy—Part 2



The BGP attributes local preference and communities and explains the operation of those attributes; and

•

The manipulation of those BGP attributes using routing policy.


www.juniper.net


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

www.juniper.net



Local-Preference Power The BGP attribute of local preference is the highest tiebreaker in the BGP path selection process. If a BGP next hop is reachable, and BGP knows multiple routes, BGP always chooses the route with the highest local preference. Thus, local preference is the first BGP attribute that favors one path over another.

Highest Local Preference Wins Because of the position of the BGP local preference, neither the AS-path length, nor the origin code, nor the MED value matters. The route with the highest local-preference value is always chosen as the exit point of the AS—the end.


www.juniper.net


Local-Preference BGP Attribute Do not confuse the BGP attribute of local preference with the Junos OS concept of route preference. The Junos OS route preference is local to an individual router and assists the routing table in choosing the active route among many possible paths. The BGP local-preference attribute is used only within BGP itself. The BGP routers transmit the local preference within an AS. If you do not explicitly configure a value for local preference, the default value used on BGP routes is 100. You can change this value on a per-peer basis using the local-preference command within the [edit protocols bgp] configuration hierarchy directory. In addition, you can alter the value using a policy on a per-route basis. The policy action also uses the local-preference command to alter the attribute value.

Default Local Preference = 100, BGP Preference = 170 The default local preference applied to a BGP route is 100. However, the default route preference applied to BGP itself is 170. The Junos preference applies to the entire routing protocol. Preference is also set in the [edit protocols bgp] configuration hierarchy directory, but as preference, not local-preference (which applies only to BGP).

Pay Attention When it comes to routing policy configurations, make sure to change local preference on the BGP routes, not the preference of the BGP protocol as a whole!

www.juniper.net



IBGP Peers Exchange Local Preference Only IBGP peers exchange the values of the local-preference BGP attribute. EBGP peers never see a local preference set on route information sent between AS networks.

Sets Exit Point You typically use the local preference to set the preferred exit point for a particular route from an AS. This use can be important when several links exist between two ASs.

IBGP Distributes Local-Preference Information Once the local preference for a route is set, IBGP propagates that information throughout the entire AS. Continued on the next page.


www.juniper.net


How to Get to 172.17.2.0/24? The slide shows the concept of how local preference affects traffic leaving an AS. The administrators of the AS on the left know that Router B should always be used to reach the 172.17.2.0/24 network in the AS on the right. Therefore, the administrators of the AS on the left can configure their edge routers to set the local-preference value higher on the copy of the route received on Router B than the copy received on Router A. IBGP makes sure that every router in the AS knows that the preferred exit point for this route is Router B. Note that the AS on the right neither knows nor cares about the value of the local preference assigned to the route by Router A or Router B. The AS on the left still has failover capability because it receives the route from the AS on the right through both routers. Although Router B is the primary exit point for the route, user traffic can use Router A to reach the AS on the right in the event of a failure.

www.juniper.net



Example of Local-Preference Use The slide shows an example of local-preference use within an AS. The network administrators in ISP A decided that the routers in ISP A should use R2 to reach the 192.168.27.0/24 network in ISP C. This decision is because of the greater bandwidth capacity available on that 10 Gigabit Ethernet link. To perform this router assignment, the ISP A network administrators set the local preference to 200 on the route to 192.168.27.0/24 advertised to R1 by ISP B, and set the local preference to 300 on the route to 192.168.27.0/24 advertised to R2 by ISP D. In contrast to almost every other metric associated with routing protocols, the highest local preference is better. Thus, for this route, the exit point of the AS is through R2. IBGP makes these values known to all other routers in ISP A. The link on R1 can still be used for inbound traffic flows from ISP C and for outbound failover traffic if the 10 Gigabit Ethernet link is not useable because of a router or link failure.


www.juniper.net


Local AS Only The slide points out the local nature of local preference. Consider another AS called ISP E linked by two lower-speed, but equal, links to ISP A. Which link should ISP E use to reach 192.168.27.0/24 in ISP B? Because EBGP does not propagate the local-preference values used inside ISP A, the ISP E AS has no knowledge of the local-preference routing decisions made within ISP A with regard to the 192.168.27.0/24 route. ISP A, of course, still wants traffic from ISP E to flow towards R2 to avoid shuttling all this traffic across its backbone.

Another Method Needed However, ISP A cannot accomplish this goal with local preference. ISP A must use other BGP attributes instead of local preference, such as AS path or MED, to influence ISP E’s flow of traffic to ISP A. This is because of the strictly local nature of the local-preference attribute.

www.juniper.net



Changing Local Preference with a Policy In many cases, when it comes to local preference, a routing policy does not consider routes in isolation but considers other BGP attributes, such as the AS path, to select routes for preferred local handling. The example on the slide alters the local-preference value for all received routes that match the AS path of look-for-path. Within the term got-path, we specified an action of local-preference 200. This action changes the local-preference attribute value for those routes to 200. This routing policy does not affect any other received BGP routes.


www.juniper.net


Local Preference and Routing Loops The case study on the slide provides an interesting look at the operation of BGP in general, and how BGP uses local preference specifically. Considering that the local-preference attribute overrides all other BGP attributes in the path selection process, it might be possible to create a routing loop in BGP. Routing loops are especially bad because the destination is technically reachable, but some or even all routers within an AS cannot find the proper path to the destination. In the example on the slide, both R1 and R2 have an export policy in place that sets the local preference to 1000 on EBGP routes before these routes are readvertised to IBGP peers. Note that R1 and R2 have an IBGP peering relationship with each other, which means that both routers also advertise the route to each other. Theoretically, both R1 and R2 could see the preferred value of 1000 in the copy of the route they receive from each other. This information makes each router determine that the IBGP version is better than the local (EBGP) copy of the route! This determination occurs because the local preference on the EBGP version of the route that is stored within the router is still set to 100. As a result, R1 and R2 see each other as the best route to 172.17.0.0/16, and a routing loop occurs as the two routers shuttle traffic back and forth. Note that this situation is easily avoided by setting a route’s local preference at ingress using an import policy. In this case, the local copy of the route as received from an EBGP peer will correctly reflect the local preference modification.

www.juniper.net



Split Horizon for Local Preference It turns out that BGP is smart in this case. The following chain of events assumes that R2 received the EBGP route of 172.17.0.0/16 first and advertises the route with a local preference of 1000 to its IBGP peers. (If R1 accomplishes this first, the roles are easily reversed, but the point is the same.) First, R2 receives the EBGP route of 172.17.0.0/16 from its peer in the other AS. Because R2 detects this route as the current best, R2 installs the route in its routing table. Next, R2 alters the local preference to 1000 and advertises this route to its IBGP peers with this local-preference value. At this point, both R1 and R3 receive the 172.17.0.0/16 route through IBGP. R1 then also receives the EBGP route for 172.17.0.0/16 from the other AS. At this point, R1 determines that it already has a route to 172.17.0.0/16 from R2, with a local preference of 1000. The presence of this route to R2 overrides the EBGP-received route. Because the current version of the route on R1 is from R2, and because IBGP implements split horizon, the routing loop never forms. R1 just sends traffic for 172.17.0.0/16 to R2. And because only active BGP routes are advertised, no confusion develops on R3 with regard to the best path to reach 172.17.0.0/16—R2 is the choice.


www.juniper.net


Communities The slide highlights the topic we discuss next.

www.juniper.net



Optional, but Transitive The BGP community attribute is an optional attribute, so not all implementations of BGP must recognize and use communities. However, if BGP communities are associated with a BGP route, the BGP community attribute must be passed along to all other BGP peers, both within an AS and between AS networks (transitive).

Routes Having Something in Common The BGP community attribute is an administrative tag that you can use to associate routes together that share common properties. The BGP community attribute is not complex. The main role of the BGP community attribute is to make it easy to group routes that should be treated the same by a routing policy. BGP communities are very flexible: a BGP route can belong to many BGP communities.

Make Routing Simpler The attraction of BGP communities is that they can simplify routing policies. BGP communities identify routes based on the logical boundaries you establish and not what the AS number (too broad in most cases) or individual IP prefix (too granular in most cases) establishes.

Use with Other BGP Attributes You can use the community attribute within routing policies to accept or reject routes based on the values of the BGP community tags. In addition, you can use the community attribute values with other BGP attributes to implement routing policies that accept, prefer, or advertise BGP routes. Chapter 10–14 • BGP Attributes and Policy—Part 2

www.juniper.net


Clubs for Routes BGP communities establish various logical categories for routes (prefixes). Think of BGP communities as communities of interest or even clubs for routes. And just as people can belong to more than one club, routes can fit into more than one BGP community.

Can Carry Local-Preference Value Beyond Local AS The BGP community attribute value often implements policies for customer networks, such as altering the local-preference attribute on incoming routes.

Goal: Less Work The community attribute can assist you in the configuration and maintenance of policies. This cuts down on the time needed for manual reconfiguration and the complexity of the overall maintenance task. Continued on the next page.

www.juniper.net



Community Use Example As an example, consider the addition of a new prefix for a new customer within an AS. If you use communities to enforce routing for customer networks, and you can place the new prefix into an existing community, you do not need any changes to overall routing policies. When new customers are brought into the network, you must only assign the new routes the proper community attribute. Without the use of communities, you might need to update each policy in the network to include the new customer information.

Too Many Communities However, you must be careful when establishing communities for the first time. Too many communities defeat the whole purpose. Maintenance of the communities then becomes as tedious as maintaining a whole list of route filters.

Overlapping Communities You should also avoid having too many overlapping communities. Customer routes belonging to multiple communities can also be an issue. When it comes to communities, simplicity is always a worthwhile goal.


www.juniper.net


Well-Known Communities Certain well-known communities have a global meaning and special purposes. They are defined in RFC 1997. All BGP implementations that understand communities (communities are optional, but transitive) must know these communities and respect their functions.

Communities for Local Use BGP communities that are not well-known are for local use. You must define local-use communities locally, but because the BGP community attribute follows the BGP route wherever it goes, even local-use communities are circulated outside the AS. So, you must take care in using BGP community attribute values arriving from other AS networks. BGP communities are best thought of as a category for a group of routes (such as, all customers).

Community Format The BGP community attribute itself is just a list of the individual community attribute values associated with the route (tags). Because no real limit exists on the number of tags in the list, a route can belong to many communities. No predefined, upper limit exists on the number of communities allowed on a route. Continued on the next page.

www.juniper.net



Community Format (contd.) The community attribute values themselves are designed so the values can be uniquely assigned in the global Internet. The BGP community attribute itself is a 32-bit (4-octet) value that has two parts. The two high-order octets (16 bits) form the first part and are set aside for the AS number of the network that assigned the community to the route in the first place. The two low-order octets (16 bits) form the second part and are set aside for use by the specific AS networks. Because the AS value is included in the community, the value is guaranteed to be unique on the whole Internet. When written in bits or hexadecimal format, community values can look very odd. Thus, communities are usually represented in decimal form as AS:number. For example, 200:666 is community 666 in AS 200. One restriction on possible communities values is that the AS values of 0 and 65535 are reserved and cannot be assigned to a route. Therefore, in combination, this restriction covers values 0x00000000 to 0x0000FFFF (AS 0) and 0xFFFF0000 to 0xFFFFFFFF (AS 65535). RFC 4360 provides support for an “extended community attribute”. An extended community attribute consists of eight octets. The BGP extended communities attribute format has three fields: type:administrator:assigned-number.


www.juniper.net


The Three Well-Known Communities Three community attribute values are designated as well-known communities. These well-known communities share the AS value of 65535 (0xFFFFxxxx). The three communities are no-export, no-advertise, and no-export-subconfed. •

No-export (0xFFFFFF01): This value tells routers to distribute routes with this community tag within the confederation or AS, but no farther.

•

No-advertise (0xFFFFFF02): This value tells routers not to advertise these routes to other BGP peers at all. (Despite appearances, this BGP community is quite useful.)

•

No-export-subconfed (0xFFFFFF03): This value tells routers not to distribute routes with this community tag to external BGP peers (thus, they are confined to the sub-AS).

No-Export The no-export community typically makes sure that route aggregation is optimal by suppressing more specific routes. The no-export-subconfed just extends this aggregate concept to the sub-AS.

No-Advertise The no-advertise community has a very narrow scope. Routes go to a BGP peer and no farther, usually because peers know the routes through other means. This community is often used in a LAN-connected router environment or when two BGP peers have multiple links between them.

www.juniper.net



Sample Use of No-Advertise The slide shows an example of the scope of the no-advertise community. The arrow at the lower right shows a BGP route with the no-advertise community injected by R1 into an AS with sub-confederations. The well-known community attribute value of no-advertise is designed such that a route can be sent to a single BGP peer and be advertised no farther. Routes are restricted to the next-hop router R2.


www.juniper.net


Sample Use of No-Export-Subconfed The slide shows an example of the scope of the no-export-subconfed community. The arrow at the lower right shows a BGP route with the no-export-subconfed community injected by R1 into an AS with sub-confederations. The well-known community attribute value of no-export-subconfed is designed such that a route can be sent into a BGP confederation network and have the information remain with a particular sub-AS. The routing information is advertised no farther than the sub-AS routers R3 and R4, as shown on the slide.

www.juniper.net



Sample Use of No-Export The slide shows an example of the scope of the no-export community. The arrow at the lower right shows a BGP route with the no-export community injected by R1 into an AS with sub-confederations. The well-known community attribute value of no-export is designed such that a route can be sent into a neighboring AS and have the information remain within that neighboring AS. Normally, BGP communities are transitive and are passed from each AS to all others, even if the router does not support or use the BGP community option. However, the routing information with the no-export community tag is not advertised beyond the AS routers R5, R6 and R7, as shown on the slide.


www.juniper.net


No-Export Example The slide shows a typical use of the BGP no-export community. AS 1 has multiple BGP sessions to its neighbor, AS 2. AS 1 also uses AS 2 as a transit AS for connectivity to the Internet. AS 1 wants to advertise 172.17.0.0/16 to the Internet because AS 1 owns that entire address space. In addition, AS 1 also wants to advertise more specific route information (shown as 172.17.0/17 and 172.17.128/17) only to its peer, AS 2. Advertising the specifics as well as the aggregate to AS 2 would assist AS 2 to route user traffic into AS 1 more efficiently because load sharing could be used on the more specific routes, as shown on the slide. However, why should the whole Internet know or care about these specifics? To assist AS 2 in finding and rejecting the more specific routes, AS 1 assigns the no-export community to the 172.17.0.0/17 and the 172.17.128.0/17 routes. The BGP edge routers in AS 2 that connect to the Internet automatically suppress and do not readvertise the /17 routes. Only the /16 route is readvertised to the Internet.

www.juniper.net



No-Export and Multihoming The BGP well-known community no-export is also useful when a customer is multihomed to two ISPs. In the example on the slide, the customer wants to receive Internet traffic through one main ISP but be able to receive locally originating traffic from the other ISP (perhaps a major trading partner uses AS 2 as its ISP). One way to do this (among other ways) is with the BGP no-export community. In this example, the customer has AS 1 as its main ISP. Customer AS 20 has address space 172.17.144.0/20, taken from AS 1’s address space of 172.16.0.0/16. The 172.17.144.0/20 route is advertised with BGP to both AS 1 and AS 2. Because AS 2 is not the primary ISP, and only traffic originating in AS 2 should reach AS 20 directly, the route advertised to AS 2 is given the BGP no-export community. This route goes no farther than AS 2. AS 2 advertises 172.31.0.0/16 to AS 1 and the Internet, but does not advertise 172.17.144.0/20. AS 1 covers the 172.17.144/20 address space with aggregate 172.17.0.0/16, as shown on the slide. This is advertised to AS 2 and the Internet. Thus, AS 20 is reachable through AS 1 from the Internet, but AS 20 is only reachable by local AS 2 users. A drawback of this scenario is that if the link from AS 20 to AS 1 fails, the 172.17.144.0/20 route is not reachable from the Internet through AS 2. However, because AS 2 is not the primary ISP for AS 20, this might be acceptable.


www.juniper.net


Transit AS for Backup One of the most common uses of the BGP community attribute addresses one major limitation of the BGP local-preference attribute. Local preference is only distributed within an AS, and no local-preference information is ever sent between two AS networks. Yet, local preference is a valuable way to establish proper exit points for a route within an AS, especially when the AS has multiple links. How can another AS be informed of the local preferences of a route learned from another AS? The most popular way to do this is with BGP communities. In the example on the slide, the customer AS at the bottom agreed to provide backup transit service to both AS 1 and AS 2 in case their links to each other are lost. The slide shows the address spaces used. The customer AS uses 172.17.64.0/18 and 172.20.128.0/18. The customer wants to make the 172.20.0.0/16 route sent to AS 1 to have a lower local preference than the default of 100, and to make the 172.17.0.0/16 route sent to AS 2 to have a lower local preference than the default of 100 there as well. Continued on the next page.

www.juniper.net



Transit AS for Backup (contd.) The key to making this work is with the BGP communities on routes sent to AS 1 and AS 2. Route 172.20.0.0/16 sent to AS 1 is tagged as community 1:60. This says to AS 1, “AS 1, within your AS, this route should have a local preference of 60.” The route 172.17.0.0/16 sent to AS 2 is tagged as community 2:70. This says to AS 2, “AS 2, within your AS, this route should have a local preference of 70.” In this example, AS 1 and AS 2 only advertise aggregate routes to each other and the Internet. If AS 1 and AS 2 set the local preferences on these routes as requested, the exit points through the customer’s AS are only active when there is no normal peering route available (local preference = 100).

Enforcing Communities Of course, setting local preferences in other AS networks with communities requires all the AS administrators to cooperate. Nothing makes an AS respect the community attribute value.


www.juniper.net


Policies and Transit AS The BGP community attribute plays a key role in defining whether an AS is a transit or nontransit network. A transit AS carries traffic that neither originates in that AS nor is destined for hosts within the AS. A nontransit AS only carries traffic that has its own addresses appearing as either the source or the destination. Nontransit AS networks must be careful when advertising BGP routes outside the AS. A nontransit AS can advertise only local routes.

Communities Can Hold Back Routes You can use routing policies in combination with BGP communities to make an AS appear to be a transit AS or a nontransit AS. Communities make it much easier to hold back routes that might be advertised and attract transit traffic. Generally, a small ISP must advertise its own local routes but never be a transit AS for larger ISPs. Such a situation could easily swamp the operation of a small ISP. The slide shows a small ISP linked to two larger, national ISPs: National ISP #1 and National ISP #2. As an example of what could happen, consider that National ISP #1 advertises BGP routes to R1 of the small ISP as shown on the left. R1 advertises not only its own local routes to R2 in the small ISP, but also National ISP #1’s routes, so that all users can reach these routes. Continued on the next page.

www.juniper.net



Communities Can Hold Back Routes (contd.) But R2 should never, ever advertise National ISP #1’s routes to National ISP #2! R1’s and R2’s local routes are okay to send to National ISP #2. However, if R2 ever advertises the National ISP #1 routes to National ISP #2, and the link (or links) between the two national ISPs ever fail, National ISP #2 will think that a good way to reach National ISP #1 is through the small ISP! Hence, the small ISP is now a transit network.


www.juniper.net


Configuring Communities You configure BGP communities in the Junos OS at the [edit policy-options] CLI hierarchy level. You simply give the community a name and a number of members in the form of the community ID. When you define multiple community members, a logical AND is between them. Thus, a given name represents Community1, AND Community2, AND Community3, and so on.

Community ID Format The community ID has an as-number:community-value format, with a colon (:) separating the high-order and low-order octets. You can use the keywords no-export, no-advertise, and no-export-subconfed to specify the well-known community values.

Can Use in Policy When used in a routing policy, you can use the community name as a match condition (that is, find these BGP communities) or as an action. Actions applied to communities include the adding, deleting, or setting of community attribute values.

www.juniper.net



Add to the Community String The slide shows the definition and application of a community in a routing policy. This policy leaves the existing community tags on the route in place but also adds the specified community attribute value to the route. Route 192.168.0.0/24 currently has four community tags on the route: 64512:567, 100:20, 50:70, and 1234:66. Because the policy community-actions has no from statement, all routes are matched. It is not necessary to check for just the BGP routes because only BGP has a community attribute to change. (Including a from protocol bgp statement does not change the action of the routing policy.) All BGP routes have the community tag test-comm value of 65001:1234 added to the existing community tags on the route. The action of then community add test-comm performs this test. After you correctly apply this routing policy, the 192.168.0.0/24 route has five community tags on the route: 64512:567, 100:20, 50:70, 1234:66, and the added 65001:1234.


www.juniper.net


Delete from the Community String This slide also shows a policy that defines and applies a community in a routing policy. This policy removes only the specified values of the existing community tags and leaves other existing community tags in place. Route 192.168.0.0/24 currently has the same four community tags on the route: 64512:567, 100:20, 50:70, and 1234:66. Because the policy community-actions has no from statement, all routes are matched. All BGP routes have the community tag test-comm value of 64512:567 deleted from the existing community tags on the route. The action of then community delete test-comm performs this task. After you correctly apply this routing policy, the 192.168.0.0/24 route has only three community tags on the route: 100:20, 50:70, and 1234:66.

www.juniper.net



Set the Community String The slide also shows a policy that defines and applies a community in a routing policy. This policy removes all the values of the existing community tags and adds (that is, sets) the new community tag (or tags) in place. Route 192.168.0.0/24 currently has the same four community tags on the route: 64512:567, 100:20, 50:70, and 1234:66. Because the policy community-actions has no from statement, all routes are matched. All BGP routes have the community tag test-comm value of 65001:1234 set as the existing community tag on the route. The action of then community set test-comm performs this task. After you correctly apply this routing policy, the 192.168.0.0/24 route has only one community tag on the route: 65001:1234.


www.juniper.net


First Example Using Community The slide shows a realistic application of the BGP community attribute. The goal is to create a community named customers. We define the community as having two members: 56:2379 AND 23:46944. When we use this community in a routing policy to find (that is, match) routes, the community matches routes that have both 56:2379 AND 23:46944 as a community tag value. Once found, these routes are assigned a MED value (the BGP metric) of 20 and a local-preference value of 200 (instead of the default 100).

www.juniper.net



Second Example Using Community The slide shows another realistic example of a BGP community. The goal is to define and attach a community named my-accept to routes that are accepted by the policy. In this example, the policy drops routes that are too specific, based upon the prefix’s address class, while tagging all other routes with the community value of 567:1. The drop-specifics routing policy accepts the desired routes using a series of route filters that are based upon address classes (A, B, and C) and the allowed prefix length. The community add statement attaches the 567:1 community to any existing communities on routes that match the route filters. The final reject action serves to reject all routes that are not matched by the previous route filters. It bears stressing that this reject statement is part of a unnamed term with no match criteria. Operators often forget that the final term in a policy can be unnamed, and it is easy to mistake the reject action in this example as belonging to the drop-specifics term if you do not take careful analysis. Continued on the next page.


www.juniper.net


Second Example Using Community (contd.) An equally workable approach that makes use of a single unnamed term is shown here: [edit policy-options policy-statement drop-specifics] user@router# show from { route-filter 0.0.0.0/1 upto /19 { community add my-accept; next policy; } route-filter 128.0.0.0/2 upto /16 { community add my-accept; next policy; } route-filter 192.0.0.0/3 upto /24 { community add my-accept; next policy; } route-filter 0.0.0.0/1 upto /32; route-filter 128.0.0.0/2 upto /32; route-filter 192.0.0.0/3 upto /32; } then reject; In this approach, a series of class-based route filters are added to match on Class A, B, and C addresses that have prefix lengths longer than 19, 16, and 24 respectively. Note that the final series of route filters do not have any actions specified in the route filter statement. As a result, traffic that matches these statements is subjected to the unnamed term’s reject action. Some might argue that this approach is better because the policy's single term means that the J-tree is only evaluated once. In reality, the performance benefit, if any, is negligible, making both policies equally workable.

www.juniper.net



Routing Policies and Deletions In contrast to other BGP attributes like AS path, BGP allows you to delete some or all the community attribute values on a BGP route. In fact, deleting these values is very useful to do at the boundaries of an AS because there is no guarantee that any other AS understands or respects the values of the communities established in one AS.

Default Is to Send If you do not delete community attribute values, by default, all BGP communities are sent to all peers inside an AS and outside the AS. Why clutter up the routing updates with useless and potentially harmful information?

To Stop, Use Delete To stop the community from being advertised beyond the local AS, you must delete the community. Continued on the next page.


www.juniper.net


Delete All Communities The slide shows a routing policy that deletes all communities from a BGP route. This example uses the wildcard asterisk character (*) to match all communities. The action of community delete wild-match performs this task. Note that you must apply the wildcard to both halves of the community—the AS number as well as the community value. The syntax is therefore “*:*” to match all communities.

www.juniper.net



Simple Community Regular Expressions You can use a regular expression (also called, regex), first introduced in an earlier section on AS paths, also with BGP communities to produce a powerful pattern-matching system for finding communities that match a given regex. Regular expressions used with communities implement the full capabilities of a complete regex implementation, unlike the AS-path regex syntax, which used a subset. Consider two forms of regular expressions used with routing policies concerned with BGP communities. These two forms are simple and complex regular expressions. These are informal terms, defined in this course as follows. Simple community regular expressions contain only the asterisk (*) or dot (.) wildcard characters separately. Complex community regular expressions can use the asterisk and dot in conjunction with each other. Further, the complex regex statements can use additional operator syntax characters. The asterisk matches any single AS number or community value. The dot matches any single digit within the AS number or community value. Note that the combination of these characters (.*) is a complex community regex, which we discuss on a later slide. Continued on the next page.


www.juniper.net


Examples of Simple Community Regular Expressions Some examples of simple community regex matches are:

www.juniper.net

•

*:1000 = Any possible AS number with a value of 1000.

•

65001:* = AS 65001 with any possible community value.

•

65001:100. = AS 65001 with community values of 1000, 1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008, or 1009.

•

11.1:1000 = AS 1101, 1111, 1121,1131, 1141, 1151, 1161, 1171, 1181, or 1191 with a community value of 1000.



Matching the Community: Part 1 You can use standard CLI commands with simple regular expressions to find the routes (if any) associated with any community. The slide shows a few examples. To find all routes having a community value of 20, regardless of AS number, use the command show route community *:20 terse. This command shows the routes but not the complete community attribute values associated with the routes. To see the communities and more detailed information, use show route community *:20 detail.


www.juniper.net


Matching the Community: Part 2 In addition to the standard CLI commands seen previously, you can also locate a route using the name of a community. The example on the slide shows a community called community-1 defined within [edit policy-options]. This community represents the value of 1:20. You can use this community name in the show route community-name community-1 detail command to view all routes having this community assigned.

www.juniper.net



Complex Community Regular Expressions You can use more complex regular expressions (regex) with communities. A community regular expression is character based, unlike the regular expressions used with AS paths, which match entire AS numbers. The format for the community regular expression is still term operator as in AS-path regular expressions, but the application of the term and operator is different. When formulated for use with communities, the regular expression anchors of start (^) and end ($) are not required, but these anchors can be helpful to organize and clearly represent the regular expression. You can use complex regular expressions in both the show route CLI commands and within a policy as a match condition.


www.juniper.net


Community Regular Expression Operators The table on the slide shows a list of the possible regular expression operators you can use with BGP communities. Some operators are shorthand for their longer equivalents. For example, the plus (+) is the same as {1,}. Both match one or more repetition of the term preceding the operator. The square brackets ( [ ] ) match a range ([2-8]) or array ([256]) of numbers. Thus, the first regular expression in the previous sentence matches 2 through 8, and the second one matches 2 or 5 or 6. Of special note is the use of the parentheses. Typically, you use the parentheses ( ) operator to group multiple terms in conjunction with an operator. The parentheses operator also has another special use. When used with no spaces in between, parentheses represent a null value.

www.juniper.net



Examples of Complex Community Regular Expressions The slide shows some examples of quite complex regular expressions you can use to match communities in routing policies. The first column shows the BGP community string that the routing policy is trying to match. The second column shows the community regular expression used to match that pattern. The last column shows examples of values of the BGP community attribute that the regular expression matches. In some cases, the list is not exhaustive, so more possible communities match the pattern. Note the presence of the colon (:) to separate the AS number of community value sections of the community.


www.juniper.net


Complicated Community Regular Expression Example The answer to the question on the slide is yes, the community regular expression on the slide meets the criteria outlined. This complex regular expression uses multiple term-operator pairs in its definition. To understand better how the expression operates, let’s reconstruct it from the ground up. First, we have a basic expression of ^():()$. This part of the expression sets the foundation for the complete expression. Loosely speaking, we search for an exact match of an AS number followed by a colon (:), followed by an exact match of a community value. Next, we assign the AS value. This AS value is actually a regular expression in itself that states the AS is either 105, 207, or 309. The pipe ( | ) operator separates the three AS numbers into logical OR groupings. The extra parentheses are used to set aside each AS number explicitly from the pipe operator. The regular expression now appears as ^((105)|(207)|(309)):()$. Now we can define the community values. As with the AS numbers, the values can be one of three separate entities. Again, we use the pipe operator to separate the values and the parenthesis to define the possible values explicitly. The regular expression is now ^((105)|(207)|(309)):(()|()|())$. Each of the possible community values in this example is an individual expression itself. We’ll examine each one in turn. Continued on the next page.

www.juniper.net



Complicated Community Regular Expression Example (contd.) The first possible value is a 4- or 5-digit number, where the first character is a 1. Because the community expressions are a character-based match, the expression starts simply with a 1. The following characters in the value can be any number, so the wildcard of dot (.) is used to represent that. Because the total value should be 4 or 5 digits, the wildcard can be operated upon with a {3,4}, which means at least three instances of any number can appear, but no more than four instances. Combined with the character of 1 to start the value, the wildcard-operator pair makes the value a 4- or 5-digit number. The regular expression now appears as: ^((105)|(207)|(309)):((1.{3,4})|()|())$. The second possible value can be any length, but it must start with either a 2, 5, or 6. Again, the community expressions are character based, so this value should also start with a character. These are actually three possible characters in this single position, so the brackets are used ([256]) to signify a range of possible values. Following that, there can be more characters in the value, or there could be no characters in the value. To represent this possibility, we once again use the wildcard dot (.). In this case, the wildcard is operated on by the asterisk (*), which results in a .* notation. This represents any possible value present zero or more times. Combined with the [256], this wildcard-operator pair gives any possible value of any length as long as it starts with a 2, 5, or a 6. The regular expression now appears as: ^((105)|(207)|(309)):((1.{3,4})|([256].*)|())$. The final possible value can again be any length. This time, it must end with either a 3, 4, 7, or 9. The logic for this value is exactly the opposite of the logic for the second value, so we can use the same operators. In this case, the value starts with the .*, which again represents any possible value present zero or more times. This is followed by the bracket notation of [3479] to represent a single character in that single position. When combined, the result is any possible value of any possible length, as long as it ends with a 3, 4, 7, or a 9. The regular expression now appears as: ^((105)|(207)|(309)):((1.{3,4})|([256].*)|(.*[3479]))$.


www.juniper.net



www.juniper.net

•

The BGP attributes local preference and communities in detail and explained the operation of those attributes; and

•

How to manipulate those BGP attributes using routing policy.





www.juniper.net


Lab 9: BGP Attributes: Local Preference and Communities The slide provides the objectives for this lab.

www.juniper.net




www.juniper.net

Advanced Junos Service Provider Routing Chapter 11: Route Reflection and Confederations



The operation of BGP route reflection;

•

How to configure a route reflector;

•

The operation of a BGP confederation;

•

How to configure confederations; and

•

Peering relationships in a confederation.

Chapter 11–2 • Route Reflection and Confederations

www.juniper.net


Route Reflection Operation The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.juniper.net

Route Reflection and Confederations • Chapter 11–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 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 autonomous system (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 has to 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 chapter explores the configuration and operation of both mechanisms. Chapter 11–4 • Route Reflection and Confederations

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

Route Reflector 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 was loop prevention, 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 non-clients. The route reflector’s cluster ID is added to all routes that the RR touches, meaning that both clients and non-clients 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:

www.juniper.net

1.

Client sends routes to RR1;

2.

RR1 sends routes to all clients and to RR2 and RR3;

3.

Because route reflection allows IBGP peers to send routes to other IBGP peers, RR2 sends the routes to RR3; and

4.

Because RR3 has no way of knowing the routes received from RR2 came from RR1, RR3 sends them to RR1, forming a loop.



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 non-clients.

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 OS configuration syntax, all clients of an individual route reflector are placed within a single peer group. This placement allows the route reflector to easily determine which peers are clients of a particular cluster. No configuration changes are needed in the client’s configuration.

Route Reflector 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 route reflector. 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 route reflector exists in the cluster, the router ID of the route reflector is often used as the cluster ID. Continued on the next page.


www.juniper.net


Route Reflector 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 route reflectors in that cluster are now stored because the receiving route reflector 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 Route Reflectors The clients in the cluster must peer to the route reflector 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 route reflector for the local cluster. The route reflectors 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 route reflector. 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 non-client IBGP peers of the reflector. This process applies to all other routes the route reflector receives from a client in its cluster. This slide shows how the other route reflectors in the network readvertise all routes received from IBGP peers (the other reflectors in this example) to all of their cluster clients.

www.juniper.net



Dual Route Reflectors in a Cluster The slide shows a cluster containing two route reflectors. This type of cluster design is popular because it avoids a single point of network failure. When a cluster has only a single route reflector, 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 configure two IBGP peers and forward EBGP-learned routes to both route reflectors. The route reflectors 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 route reflectors also establish IBGP peering sessions with the other RRs in the entire AS. As previously mentioned, a debate exists as to whether each route reflector should be assigned the same or 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 route reflectors. 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 route reflectors 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 route reflector 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 route reflector. 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 route reflector. 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 route reflector only forwards to the clients routes which arrive from outside of the cluster.


www.juniper.net


Route Reflector Can Modify Attributes The default operation of a route reflector 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 route reflector readvertises routes from a non-client 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 route reflector, the route reflector itself does not have to be in the forwarding path for packets sent from clients towards the route destination. In fact, often times 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 of sloppy next-hop-self policy 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 route reflector also has EBGP peering sessions established. Most network designs avoid this problem by placing their route reflectors 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 policy-statement selective-nhs] user@router# show term only-EBGP-routes { from { protocol bgp; neighbor 172.16.0.1; } then { next-hop self; } }


www.juniper.net


BGP Confederations The slide highlights the topic we discuss next.

www.juniper.net



Break Up the Global AS A confederation takes a global AS and breaks it into smaller subautonomous systems. These sub-AS networks are connected together to form the unified AS to which all other networks in the Internet peer.

Within a Sub-AS The confederation sub-AS networks act just like a real AS; they require a full mesh of IBGP connectivity within themselves. Should the full mesh of the sub-AS grow too large, route reflection might be used within a sub-AS to scale the network. Each sub-AS must have a unique AS number defined, and most administrators use a private AS number from the 64512 to 65535 range. Continued on the next page.


www.juniper.net


Between Each Sub-AS An EBGP-like connection that is often referred to as confederation BGP (CBGP) is used to interconnect the sub-AS networks. CBGP is a special type of EBGP; certain attributes, such as the BGP next hop, are handled differently across CBGP sessions. CBGP peers modify the AS path attribute to include the sub-AS numbers. This modification is performed to provide loop prevention within only the confederation network. All other BGP attributes, such as local preference and the BGP next hop, remain unchanged when sent across a CBGP link. Because the router views connections between the sub-AS networks as being EBGP, some special configuration might be warranted. The router expects to use the physical address of the CBGP for the BGP session, but many administrators prefer to peer the CBGP routers using loopback addresses. This is accomplished through the use of the multihop command.

www.juniper.net



AS Confederation Sequence As a route is advertised over a CBGP link, BGP modifies the AS path attribute to include the sub-AS number. BGP places this sub-AS number into an AS confederation sequence, as denoted by parentheses, within the AS path attribute. The sequence is a new AS path segment attribute with a type code of 3. The sub-AS values are sequenced in the order in which the route has traversed the network, with the primary purpose being loop prevention within the confederation network. The confederation sequence is not used in the calculation of AS path length for the BGP active route selection algorithm. For routers within a confederation network, the confederation sequence appears as a single, internal BGP AS network.

AS Confederation Set Should some routing aggregation occur within the confederation network, the granularity of the confederation sequence might be lost. This process is very similar to conventional BGP route aggregation. In this situation, the AS confederation sequence becomes an AS confederation set and is denoted by curly braces within the AS path output. The set is also a new AS path segment attribute with a type code of 4. The routers within the confederation view the AS confederation set in the same manner as a sequence. That is, the set is still used for loop prevention even though the ordering of the sub-AS numbers is no longer significant. Chapter 11–22 • Route Reflection and Confederations

www.juniper.net


Global AS Appears Whole The Internet views the confederation as a single autonomous system. The AS path received by other autonomous systems contains only the globally assigned AS number. The AS path contains only this number because all sub-AS numbers are removed from the AS path attribute as the route is advertised to EBGP peers. To operate a confederation network effectively, all BGP routers in the AS must know the globally unique AS number as well as all the configured sub-AS numbers. This information is defined using the confederation command within the routing-options stanza, as shown on the slide.

Confederation Information Removed At the edge of the confederation network, the routers remove all confederation-related AS numbers, both sequences and sets, from the AS path attribute of all routes prior to EBGP advertisement. This removal allows the details of the confederation network to be hidden to all other networks in the Internet. Note that the remove-private command is not required to remove sub-AS numbers when you operate a confederation network. This behavior is the default for a BGP confederation and is controlled by the confederation command.

www.juniper.net



Confederation Peering The slide shows an example of a BGP confederation network. The global AS of 201 is split up into five sub-AS networks—65000, 65001, 65002, 65003, and 65004. The sub-AS networks are connected with EBGP-like connections (sometimes called CBGP). Because the CBGP links behave like EBGP, there is no need for a full-mesh topology between each sub-AS. Therefore, you can provision CBGP connections wherever it is logically, or physically, convenient. Some of the sub-AS networks on the slide are using route reflection within the sub-AS to eliminate the need for a full IBGP mesh. The combination of BGP confederations and route reflection simultaneously allows for great flexibility in scaling your AS to hundreds or thousands of routers.


www.juniper.net


Peering Session Configurations The configuration example on the left side of the slide represents Router 3 in sub-AS 65001. A full mesh of IBGP peering sessions exist within the sub-AS, as seen in peer group sub-AS-65001. The remaining peer groups on that router represent CBGP connections to other sub-AS networks in the confederation. Each group uses a connection type of external, uses the multihop command, and configures both a peer and local AS value. The configuration example on the right side of the slide represents Router 1 in sub-AS 65003. This sub-AS uses route reflection to replace the IBGP full mesh, and Router 1 is the route reflector for the cluster. This configuration is seen in peer group sub-AS-65003 where the cluster command is configured. The other peer group on the router represents the CBGP peering connection to sub-AS 65000.

www.juniper.net




Operation of BGP route reflection;

•

How to configure a route reflector;

•

The operation of a BGP confederation;

•

How to configure BGP confederations; and

•

Peering relationships in a BGP confederations.


www.juniper.net



6.

www.juniper.net



Lab 10: Scaling BGP The slide shows the objectives for the lab.


www.juniper.net

Advanced Junos Service Provider Routing Chapter 12: BGP Route Damping



The causes for route instability;

•

The effect of damping on BGP routing;

•

The default behavior of damping on links;

•

How to control damping using routing policy; and

•

How to view damped routes using command-line interface (CLI) commands.

Chapter 12–2 • BGP Route Damping

www.juniper.net


Route Flap and Damping Overview The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

www.juniper.net

BGP Route Damping • Chapter 12–3


Routing Is Dynamic In any real network, routes can appear and disappear rapidly if a link fails and restores itself repeatedly in a short period of time. This is because any routes (and there could be thousands) that use the failed interface as a next hop must respond to the failure, and the change in next hop must propagate to all other routers on the network. This rapid changing of routing next hops is called route flapping or just flapping as the link flaps up and down.

Update/Withdrawn Pairs Flapping results in a rapid sequence of BGP update or withdrawn messages. Recall that BGP routers must maintain separate memory tables for inbound and outbound traffic on a per-peer basis. In addition, the BGP routing protocol propagates information on an as-needed basis. These two factors make BGP unstable in the face of a flapping link. Every BGP router that receives one of these update or withdrawn messages must send this information on to all its BGP router peers. Much like the link-state IGPs of OSPF and IS-IS, BGP must also recalculate its routing tables and databases every time a new update is received. If the new information alters the path selection process, a new route is chosen for the RIB-LOCAL, and the new route must be sent downstream to all BGP peers. Continued on the next page.


www.juniper.net


Update/Withdrawn Pairs (contd.) The effect of route flapping quickly cascades and affects router performance. One intermittently failing link can adversely affect a whole network. If this type of update or withdrawal occurs on a very frequent basis, valuable resources in the router, such as processing power normally used to forward packets, and bandwidth now needed for routing updates, are consumed.

www.juniper.net



Bad Links Routes in a network can flap for any number of reasons. Quite possibly, the most frequent reason for a link flap is because of faulty circuit that is on the brink of outright failure. Any link that rapidly changes from seemingly operational to failing is a potential source of route flapping.

Unstable IGPs Route flapping is not totally a BGP phenomenon. IGPs that are unstable because of faulty links can affect BGP when IGP routes are injected into BGP for advertising. BGP stability is always desirable and can be enhanced with careful use of static definitions and aggregates instead of injecting raw IGP routes into BGP.

Bad Routing Policy Human error can cause route flaps as well. An incorrectly configured routing policy, causing routes to be first rejected, then accepted because of the change on the route, can cause flapping. Continued on the next page.


www.juniper.net


Congested Links Link congestion can cause route flaps if the overloaded links drop the BGP sessions that keep the BGP routes fresh.

Flapping and History In the past, sometimes the routers themselves contributed to the flapping problem. Older routers were filled with software bugs (mostly after an upgrade to a new release), had insufficient power (a busy CPU in a software-based router would drop BGP sessions), and often had insufficient memory (routing tables must be kept in memory). Sometimes, just adding equipment for routine network upgrades and maintenance caused route flaps.

www.juniper.net



Route Damping Because route flapping can be so harmful to BGP, the protocol was extended to support route damping. RFC 2439, BGP Route Flap Damping (November 1998), defines route damping. Sometimes the term dampening is seen and used.

No Damping for IBGP There is a difference between how damping is applied in BGP for internal and external peers. IBGP sessions ignore damping and flap as they please. There is a very good reason for this IBGP behavior. IBGP sessions usually peer to loopbacks, so IGP routes must be able to come and go so that IBGP sessions always have a way to reach the loopback. Recall that BGP has no reachability information of its own and relies on the IGP to resolve next hops.

EBGP Only Route damping is only applied to routes received from an EBGP peer. EBGP sessions can carry information about thousands of routes. Each EBGP session must update or withdraw these routes as required. Route damping seeks to reward route stabilities while penalizing route flapping. Once damping is enabled, the router begins to maintain a database of instability. If an EBGP-received route experiences enough flaps, the local BGP process ignores information about that route. This reaction results in not including this information in the route selection process and not advertising route changes to downstream BGP peers. Note that some ISPs no longer use damping.


www.juniper.net


Route Damping Use by ISPs The slide shows an example of when BGP route damping is useful. A customer of AS 1 is connected to the AS by a link running EBGP. The customer advertises three routes: 172.31.0.0/20, 172.31.64.0/20, and 172.31.128.0/20. AS 1 provides transit service for this customer to the Internet, so the three routes are readvertised within AS 1 and further to the Internet. However, look what happens when the 172.31.64.0/20 route starts to experience stability problems, causing multiple update and withdraw messages to be sent to AS 1 (up/down/up/down, and so on). Without route damping enabled, this flap action causes the router in AS 1 to send new update messages to other routers in AS 1. These IBGP peers then also send new update messages to their Internet peers. Enabling route damping can halt this wave of instability at the edge of AS 1. Once enabled, the edge router in AS 1 starts maintaining statistics for the routes received from the customer. Once the 172.31.64.0/20 route is deemed unstable, the AS 1 router stops generating new update messages to its IBGP peers. The IBGP peers, in turn, also have no need to send update messages to the Internet. This makes the Internet, as a whole, more stable.

www.juniper.net



Route Damping Parameters The slide highlights the topic we discuss next.


www.juniper.net


Figure of Merit Is a Number The point at which a route is deemed to be too unstable is calculated by the damping figure of merit. It might seem more like a figure of demerit but that is the term the RFC uses. In this context, the term figure means a number, not a picture. The figure of merit is a type of point value given to a route. The value becomes a penalty if the figure of merit exceeds some predetermined value (that is, the route is suppressed). It is often said that damping puts a route into a penalty box for a given period of time.

Default Value = 0 When a previously unknown (that is, new) route arrives at a BGP router that has damping enabled, the new route is assigned a figure of merit value of 0. Continued on the next page.

www.juniper.net



Event Point Values Should the route experience any instability, the figure of merit is incremented according to the following: •

As the EBGP peer withdraws the route, the figure of merit is increased by a value of 1000;

•

As the EBGP peer readvertises the route, the figure of merit is increased by a value of 1000; and

•

As attributes for the route change through new update messages from the EBGP peer, the figure of merit is increased by a value of 500.

Point Reduction The points given to a route decay (that is, reduce in value) at a certain rate, known as the half-life. As long as points decay faster than they accumulate, the route is not suppressed.

The Cutoff Threshold Should the figure of merit value increase beyond a configured cutoff (suppress) threshold, the route is considered unusable, and new information about the route from the EBGP peer is ignored. The suppress value is configurable, but it must be less than or equal to the merit ceiling value explained further on this page.

The Reuse Threshold The route can once again be considered usable after the figure of merit decreases below a configured threshold. The figure of merit is decreased on a time schedule you set. Should the figure of merit not decrease below the bottom threshold in a configured amount of time, the route can automatically be usable again (reuse).

Maximum Suppress Time The configurable max-suppress parameter establishes the maximum time that a route can be suppressed. Also, the figure of merit can only increase to the maximum value, called the merit ceiling. The symbol used for the merit ceiling is c. This maximum value is calculated from a combination of the components listed above and is determined by the following formula: c r e(t/)(ln 2) where r is the figure of merit reuse threshold, t is the maximum suppression (hold-down) time in minutes, and  is the half-life in minutes.


www.juniper.net


Cutoff Threshold The figure-of-merit value interacts with the damping parameters. The slide lists these parameters. The suppress variable is the configured threshold where a BGP route is considered unstable and is not used. This variable represents the value of the penalty that establishes the point at which damping is initiated. When this value is reached, the route is cutoff (suppressed). The default value of suppress is 3000. Possible values range from 1–20000. If changed, this value must be less than or equal to the merit ceiling c, or damping never occurs.

Reuse Threshold The reuse variable is the configured threshold where a BGP route is considered usable once again. This variable is the value to which the penalty must decay before the router considers the route in its path selection. The default value of the reuse is 750. Possible values range from 1–20000.

Decay Half-Life The half-life variable is the rate at which the figure of merit is decreased to half its value once the value is larger than 0. The default value of the half-life is 15 minutes. Possible values range from 1–45 minutes. Continued on the next page.

www.juniper.net



Maximum Hold-Down Time The max-suppress variable is the configured maximum amount of time that a BGP route can be deemed unusable. This variable is the longest time that the route can be suppressed until the route is given another chance to behave. The default value of the max-suppress is 60 minutes. Possible values range from 1–720 minutes. At the end of the max-suppress interval, all is forgiven and the route becomes active again.


www.juniper.net


Sample Figure of Merit in Action The slide shows a graphic representation of the figure of merit in use for a BGP route. The default values for suppress (3000), reuse (750), and half-life (15 minutes) are used. Note that an exponential decay occurs on the figure of merit, and a fixed ceiling exists on the figure-of-merit value (the merit ceiling). After receiving a new BGP route, the figure of merit is 0 for some period of time. As soon as the route is withdrawn (or the link is down), the figure of merit increments to 1000. As long as the route stays down, the figure of merit decays somewhat. As the route is readvertised, the figure of merit is incremented by another 1000. Again, the figure of merit starts to decay. Now the route is withdrawn a second time, and again, the figure of merit is increased. Now, when the route is readvertised, the figure of merit is increased by another 1000. This time, because not enough time has elapsed between these events in this example, the route is over the suppress limit of 3000 and is considered unusable. In short order, the route is withdrawn and readvertised, yet again. Each time, the figure of merit increases 1000 for each action. Notice that the route is still damped and considered unusable, but the figure of merit still increases and decreases, even while the route is suppressed. Continued on the next page.

www.juniper.net



Sample Figure of Merit in Action (contd.) Whenever the figure of merit is greater than 0, the value is constantly and consistently decayed using the configured half-life value. The half-life is always configured in increments of minutes. The purpose of the half-life is to decay exponentially the figure of merit such that the value from any point in time is reduced by half at the end of the configured half-life (this half-life behavior is the essence of an exponential decay). The decay is made an exponential process so that routes can be reused as they gradually cross the reuse threshold and not in large groups as a timer expires. This has the effect of not overloading BGP routers with large amounts of updates at once, causing further route damping.


www.juniper.net


Configuring and Monitoring Route Damping The slide highlights the topic we discuss next.

www.juniper.net



Damping Parameters in a Routing Policy Once damping is enabled within the BGP portion of the Junos OS configuration, the default values introduced on previous slides are used for figure-of-merit calculations. To alter these default values, you can create and define a damping profile within the [edit policy-options] configuration hierarchy.

Applied as Policy Action Much like the AS-path and community attributes, you name and define a damping profile first. Then you can use it within a policy as an action. The slide shows the five damping parameters. The presence of the disable keyword deserves a few words of explanation. You can use the keyword disable within a damping profile to not have the figure of merit be calculated for certain routes. This is often useful to exempt certain routes that should never be damped and made unusable. One good example of these types of routes are the root DNS servers in the Internet. If these servers become unreachable because of damping, the ISP and its customers experience DNS lookup failures. For example, DNS routes could have a damping profile of no-damping defined that contains a single statement: disable.


www.juniper.net


Example of Damping Use: Part 1 The slide shows a fairly sophisticated example of route damping in action. On the slide, AS 1 wants to enable damping for all its EBGP peers, based on the following administrative decisions: •

AS 1 wants to operate the default damping values for routes from AS 100;

•

AS 1 does not want to damp any routes from its customer; and

•

AS 1 wants to damp all routes aggressively from the Internet except for certain prefixes.

The next few slides in this sequence examine how you can implement these damping policies. The next slide outlines the routing policies you can use to accomplish these goals. We detail the application of these routing policies on a later slide.

www.juniper.net



Example of Damping Use: Part 2 This slide shows all the damping profiles and policies to be used in AS 1 in the damping example. The profile do-not-damp has a variable of disable defined. The profile aggressive-damp has defined four variables as follows: •

suppress is 1500;

•

reuse is 200;

•

half-life is 30; and

•

max-suppress is 120.

A policy named customer-inbound is defined with no from statement, so all possible routes match the policy. The policy has an action of damping do-not-damp. This action sets the profile of do-not-damp to all routes. A policy named internet-inbound is defined with two terms. The let-some-through term has several route-filter statements with actions defined of damping do-not-damp. This term further lists an action of then accept. A second term of damp-all-others has no from statement defined, so all routes are subjected to the damping aggressive-damp action. Warning: This version of the internet-inbound policy contains a logic flaw and does not work. Please do not use this policy in your network. A corrected version is presented on a later slide. Can you spot the flaw?


www.juniper.net


Example of Damping Use: Part 3 The routers in AS 1 are next updated to apply the policies we created on the previous slide. Router R1 defines damping in BGP and an import policy of internet-inbound. This configuration enables damping on the router and applies profile parameters as per the policy. As mentioned previously, the currently configured policy contains a logic flaw that causes it not to meet the administrative requirements. Router R2 simply defines damping within its BGP configuration. This configuration both enables damping and operates with the default parameters on routes from AS 100. No policy is needed on this router. Router R3 defines damping within BGP and an import policy of customer-inbound. This configuration enables damping on the router and applies profile parameters as per the policy.

www.juniper.net



Example of Damping Use: Part 4 This slide shows a corrected version of the internet-inbound policy. As mentioned before, previous versions contained a logic flaw. The flaw is a result of the way that we applied immediate actions to a route filter. The issue is the do-not-damp action defined for the route-filter statements. When a candidate route that matches one of the filters appears, the action of damping do-not-damp is taken. Because we defined this action within the route-filter statement itself (it is an immediate action), any further actions on the route specified within a then statement are skipped. In this case, the then accept is skipped within the let-some-through term. But the route-filter statements do not also define a terminating action (accept or reject). Thus, the damping profile is applied, but the route is passed to the next term in the policy for further evaluation. When the route enters the damp-all-others term, the route matches the term because we defined no from statement. The route is then applied the damping profile of aggressive-damp. This causes the specified exempt routes to be damped at the aggressive rate! This violates the administrative policies of the AS. To correct the policy, we must remove the damping do-not-damp actions from the individual route-filter statements and instead place them within the then portion of the term. After making this change, the exempt routes match the let-some-through term, have the correct damping profile applied, and are accepted.


www.juniper.net


Damping History The slide shows the output from the show route damping history command. Any routes displayed by this command were withdrawn from the router. However, the router retains a record of these routes should they be readvertised to the local router. Some notable details in the display include the following:

www.juniper.net

•

The route is currently hidden. We see this in both the State: field as well as the Preference: /-101 field. Notice that no Junos OS protocol preference value is defined.

•

There is a field (Merit) for the current figure-of-merit value. The two values that follow list the value after the last BGP update (or withdrawal), and the current value after experiencing some decay. For this route, the values are Merit: 2777/2454. Thus, the value at the last update/withdrawal was 2777 (note that this value need not necessarily exceed the default suppress threshold of 3000), and the current value is 2454.

•

The default parameters are used (Default damping parameters used). If this route were evaluated by a policy with a damping action, the new damping profile name would appear in the output.



Routes with Non-0 Figures of Merit The slide shows the output from the show route damping decayed command. Any routes displayed by this command were advertised to the router and are currently usable routes, but these routes have a figure of merit greater than 0. Some things to note in the display are: •

The route is currently active. We see this both by the asterisk (*) in the output as well as the State: field.

•

There is a field (Merit) for the current figure-of-merit value. The two values list the value after the last update (or withdrawal) and the current value after experiencing some decay. For this route, the values are Merit: 2000/1954.

•

The default parameters are used (Default damping parameters used). If a policy with a damping action evaluated this route, the new damping profile name would appear in the output.


www.juniper.net


Damped Routes The slide shows the output from the show route damping suppressed command. Any routes displayed by this command were advertised to the router, but these routes have a figure of merit that is currently above the suppress threshold, and the route is unusable.

Manual Clearing The route remains in this state until the figure of merit crosses below the reuse threshold. A route can have the figure of merit reduced to 0 administratively by using the clear bgp damping command. On the slide, the route 200.200.200.0/24 is currently suppressed and hidden. After we issue the clear bgp damping command, the route is no longer hidden.

www.juniper.net




The causes of route instability;

•

The effect that route damping has on BGP routing;

•

The default behavior of damping on links;

•

Controlling damping using the routing policy framework; and

•

Viewing damped routes using CLI commands.


www.juniper.net



www.juniper.net



Lab 11: BGP Route Damping The slide provides the objective for this lab.


www.juniper.net

Appendix A: Acronym List ABR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . area border router ARP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Resolution Protocol AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . autonomous system ASBR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . autonomous system boundary router BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Border Gateway Protocol BGP4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Border Gateway Protocol version 4 CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .command-line interface CLNP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connectionless Network Protocol CLNS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connectionless Network Service CSNP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . complete sequence number PDU DIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . designated intermediate system DR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .designated router EGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . exterior gateway protocol ES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . end system ES-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . End System–to–Intermediate System GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .graphical user interface IAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Advisory Board IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Internet Assigned Numbers Authority IBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . internal BGP ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Control Message Protocol IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . interior gateway protocol IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .IP version 4 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .IP version 6 IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intermediate System ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . International Organization for Standardization ISP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet service provider JNCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Juniper Networks Certification Program LSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . link-state advertisement LSDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . link-state database LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .link-state PDU MD5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Message Digest 5 MED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . multiple exit discriminator MOSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Multicast Open Shortest Path First NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . network entity title NLPID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . network layer protocol identifier NLRI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . network layer reachability information NSSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . not-so-stubby area OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open Systems Interconnection PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .protocol data unit PFE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Packet Forwarding Engine PSNP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . partial sequence number PDU RIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Information Base RID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . router ID rpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . routing protocol daemon SNPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .subnetwork point of attachment SPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .shortest path first TED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . traffic engineering database TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . type/length/value ToS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . type of service TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . time-to-live

www.juniper.net

Acronym List • Appendix A–1

Appendix A–2 • Acronym List

www.juniper.net

Appendix B: 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 affected by the area-range command.

Chapter 4:

OSPF Case Studies and Solutions 1. Although technically you do not need a backbone area, functionally you need one because of the loop prevention mechanisms in OSPF. 2. Virtual links would be deployed if two companies were merging their networks together and physical link connectivity was not an option (for example, because of cost or time constraints). 3. If the source route has a lower preference, usually no issues are present. If a source route has a higher preference, suboptimal routing or loops can occur.

Chapter 5:

IS-IS 1. A PDU is a protocol data unit. It is used to send information about the IS-IS configuration between network devices.

www.juniper.net

Answer Key • Appendix B–1

2. The segments are called type/length/value (TLVs). They describe the originating router. 3. Because IS-IS is deterministic, the added IS will assume the role of the DIS immediately and flood out new PDUs to all other ISs on that segment. 4. Set family iso and net on the physical and loopback interfaces. On the loopback interface, add an IP address and an ISO address. Ensure that the Area Address portion of the NET is the same. Under [protocols isis], disable Level 2.

Chapter 6:

Advanced IS-IS Operations and Configuration Options 1. The maximum default link metric is 63. By default, the Junos OS supports the sending and receiving of wide metrics. To configure IS-IS to generate only the new pair of TLVs and thus to allow the wider range of metric values, include the wide-metrics-only statement. 2. None, simple, and MD5 are the three forms of IS-IS authentication. 3. Import polices are not allowed for IS-IS, because they could lead to inconsistencies in the LSDB. The default export policy for IS-IS is to reject everything. IS-IS floods LSPs to announce local routes and any routes learned by the protocol. Exporting can be used only to announce information from other protocols.

Chapter 7:

Multilevel IS-IS Networks 1. Areas are segmented in an IS-IS L1/L2 network using L1/L2 ABRs. 2. An IS-IS L1/L2 network is similar to an OSPF NSSA with the no-summaries and default-metric options configured. 3. Route leaking is performed on the L1/L2 ABR. A routing policy is written matching the Level 2 routes to be leaked. This policy is then applied at the [edit protocols isis] hierarchy. Summarization is performed on the L1/L2 ABR. An aggregate route encompassing the desired more specific routes must be defined. Then a routing policy is created matching the aggregate with the to level 2 and then accept actions. The policy should include a term to reject more specific routes. The policy is applied at the [edit protocols isis] hierarchy.

Chapter 8:

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.

Appendix B–2 • Answer Key

www.juniper.net

3. With 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. Five approaches can solve the BGP next hop issue: 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 9:

BGP Attributes and Policy—Part 1 1. An import policy operates between the RIB-IN and the RIB-LOCAL. An export policy operates between the RIB-LOCAL and the RIB-OUT. 2. The Junos OS sees all possible routes to be injected into BGP as internal routes and sets the origin code as I=Internal. 3. Different ASs can set the MED values differently. A good MED value from one AS may be a bad value from another AS. The purpose of prepending the AS PATH is to make the route advertisement look undesirable.

Chapter 10: BGP Attributes and Policy—Part 2 1. Local preference is a BGP attribute that influences traffic flow. Route preference is local to an individual router and assists the routing table in choosing the active route. 2. Local preference influences outbound traffic flow. 3. The well-known communities are: No-export; No-advertise; and No-export-subconfed. The add community action adds the specified community string to the existing community attribute. The set community action deletes any existing communities and adds the specified community string.

Chapter 11: Route Reflection and Confederations 1. Cluster ID and Cluster List support route reflection. 2. The cluster statement is configured only on the route reflector. 3. No-client-reflect can be used to stop excess advertisements. An RR readvertises routes received from clients and non-clients, adding the cluster ID and cluster list attributes. Loops are prevented by examining the confederation AS sequence or AS set. 4. Routers in a sub-AS run IBGP. Routers across a confederation boundary run CBGP. Routers external to the confederations run EBGP.

www.juniper.net

Answer Key • Appendix B–3

Chapter 12: BGP Route Damping 1. IBGP sessions usually peer to loopbacks, so IGP routes must be able to come and go so that IBGP sessions always have a way to reach the loopback. 2. The half-life is the rate at which the figure of merit is decreased to half its value once the value is larger than 0. The default value of the half-life is 15 minutes. 3. The max-suppress parameter establishes the maximum time that a route can be suppressed. The default value is 60 minutes. If the suppress threshold is set higher than the merit ceiling no damping will occur. The command shows any routes that were advertised to the router and are currently usable routes, but have a figure of merit greater than 0.

Appendix B–4 • Answer Key

www.juniper.net

Advanced Junos Routing

Recommend Documents