Documente Academic
Documente Profesional
Documente Cultură
11.a
Student Guide
This document is produced by Juniper Networks, Inc. This document or any part thereof may not be reproduced or transmitted in any form under penalty of law, without the prior written permission of Juniper Networks Education Services. Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. Advanced Junos Enterprise Routing Student Guide, Revision 11.a Copyright 2012 Juniper Networks, Inc. All rights reserved. Printed in USA. Revision History: Revision 10.aMarch 2011. Revision 11.aApril 2012. The information in this document is current as of the date listed above. The information in this document has been carefully verified and is believed to be accurate for software Release 11.4R1.6. Juniper Networks assumes no responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary, incidental, or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.
Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. YEAR 2000 NOTICE Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036. SOFTWARE LICENSE The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should consult the software license for further details.
Contents
Chapter 1: Course Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1 Chapter 2: OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1
OSPFv2 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 Link-State Advertisements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-14 Protocol Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-41 OSPF Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-62 OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-68 Lab 1: Configuring and Monitoring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-80
www.juniper.net
Contents iii
iv Contents
www.juniper.net
Course Overview
This three-day course is designed to provide students with the tools required for implementing, monitoring, and troubleshooting Layer 3 components in an enterprise network. Detailed coverage of OSPF, BGP, class of service (CoS), and multicast is strongly emphasized. Through demonstrations and hands-on labs, students will gain experience in configuring and monitoring the Junos operating system and in monitoring device and protocol operations.
Objectives
After successfully completing this course, you should be able to: www.juniper.net Describe the various OSPF link-state advertisement (LSA) types. Explain the flooding of LSAs in an OSPF network. Describe the shortest-path-first (SPF) algorithm. Describe OSPF area types and operations. Configure various OSPF area types. Summarize and restrict routes. Identify scenarios that require routing policy or specific configuration options. Use routing policy and specific configuration options to implement solutions for various scenarios. Describe basic BGP operation and common BGP attributes. Explain the route selection process for BGP. Describe how to alter the route selection process. Configure some advanced options for BGP peers. Describe various BGP attributes in detail and explain the operation of those attributes. Manipulate BGP attributes using routing policy. Describe common routing policies used in the enterprise environment. Explain how attribute modifications affect routing decisions. Implement a routing policy for inbound and outbound traffic using BGP. Identify environments that may require a modified CoS implementation. Describe the various CoS components and their respective functions. Explain the CoS processing along with CoS defaults on SRX Series Services Gateways. Describe situations when some CoS features are used in the enterprise. Implement some CoS features in an enterprise environment. Describe IP multicast traffic flow. Identify the components of IP multicast. Explain how IP multicast addressing works. Describe the need for reverse path forwarding (RPF) in multicast. Explain the role of Internet Group Management Protocol (IGMP) and describe the available IGMP versions. Configure and monitor IGMP. Identify common multicast routing protocols. Describe rendezvous point (RP) discovery options. Configure and monitor Physical Interface Module (PIM) sparse modes. Course Overview v
Configure and monitor RP discovery mechanisms. Describe the basic requirements, benefits, and caveats of source-specific multicast (SSM). List the address ranges used for SSM. Illustrate the role of Internet Group Management Protocol version 3 (IGMPv3) and PIM sparse mode (PIM-SM) in an SSM implementation. Configure and monitor SSM.
Intended Audience
This course benefits individuals responsible for configuring and monitoring devices running the Junos OS.
Course Level
Advanced Junos Enterprise Routing is an advanced-level course.
Prerequisites
Students should have basic networking knowledge and an understanding of the Open Systems Interconnection (OSI) model and the TCP/IP protocol suite. Students should also have working experience with basic routing principles. Students should also attend the Introduction to the Junos Operating System (IJOS), Junos Routing Essentials (JRE), and Junos Intermediate Routing (JIR) courses prior to attending this class.
vi Course Overview
www.juniper.net
Course Agenda
Day 1
Chapter 1: Course Introduction Chapter 2: OSPF Lab 1: Configuring and Monitoring OSPF Chapter 3: OSPF Areas Lab 2: Configuring and Monitoring OSPF Areas and Route Summarization Chapter 4: OSPF Case Studies and Solutions Lab 3: Configuring and Monitoring Routing Policy and Advanced OSPF Options
Day 2
Chapter 5: BGP Lab 4: Implementing BGP Chapter 6: BGP Attributes and Policy Lab 5: BGP Attributes Chapter 7: Enterprise Routing Policies Lab 6: Implementing Enterprise Routing Policies
Day 3
Chapter 8: Introduction to Multicast Chapter 9: Multicast Routing Protocols and SSM Lab 7: Implementing PIM-SM Lab 8: Implementing SSM Chapter 10: Class of Service Lab 9: Implementing CoS Features in the Enterprise Appendix A: BGP Route Reflection Lab 10: BGP Route Reflection (Optional)
www.juniper.net
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 Franklin Gothic Courier New Description Normal text. Console text: Screen captures Noncommand-related syntax commit complete Exiting configuration mode Usage Example Most of what you read in the Lab Guide and Student Guide.
Select File > Open, and then click Configuration.conf in the Filename text box.
GUI Undefined
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/.
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.
www.juniper.net
Additional Information ix
x Additional Information
www.juniper.net
www.juniper.net
Introductions
The slide asks several questions for you to answer during class introductions.
www.juniper.net
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
www.juniper.net
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
Courses
You can access the latest Education Services offerings covering a wide range of platforms at http://www.juniper.net/training/technical_education/.
www.juniper.net
www.juniper.net
Each JNCP track has one to four certification levelsAssociate-level, Specialist-level, Professional-level, and Expert-level. The Associate-level, Specialist-level, and Professional-level exams are computer-based exams composed of multiple choice questions administered at Prometric testing centers worldwide. Expert-level exams are composed of hands-on lab exercises administered at select Juniper Networks testing centers. Please visit the JNCP website at http://www.juniper.net/certification for detailed exam information, exam pricing, and exam registration.
www.juniper.net
www.juniper.net
Find Us Online
The slide lists some online resources to learn and share information about Juniper Networks.
www.juniper.net
Any Questions?
If you have any questions or concerns about the class you are attending, we suggest that you voice them now so that your instructor can best address your needs during class. This chapter contains no review questions.
www.juniper.net
www.juniper.net
Chapter 22 OSPF
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 23
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.
Chapter 24 OSPF
www.juniper.net
Hierarchical Design
OSPF gains scalability as a protocol through the use of a hierarchical design. Portions of the network are designated as separate areas. These remote areas are then connected through a common area called the backbone.
www.juniper.net
OSPF Chapter 25
Chapter 26 OSPF
www.juniper.net
Packet Types
Every OSPF router uses a specific set of packets to perform its functions. The packet types include the following: 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 neighbors 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.
www.juniper.net
OSPF Chapter 27
Hierarchical Design
The slide graphically displays the hierarchical nature of OSPF. A backbone area (0.0.0.0) is the connecting point for all other areas. By specification, each area must attach to the backbone in at least one location. Areas 1, 2, and 3 each contain routers internal to that area as well as a single area border router (ABR). The ABR generates summary LSAs that represent the routes within its area and floods those to the backbone. The ABR is also responsible for generating summary LSAs that represent the backbone routes and injecting these LSAs into its attached area.
Chapter 28 OSPF
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: Area border router (ABR): An OSPF router with links in two areas, the ABR is responsible for connecting OSPF areas to the backbone. It transmits network information between the backbone and other areas. Autonomous system boundary router (ASBR): An OSPF router that injects routing information from outside the OSPF autonomous system (AS), an ASBR is typically located in the backbone. However, the OSPF specification allows an ASBR to be in other areas as well. Backbone router: Defined as any OSPF router with a link to Area 0 (the backbone), this router can be completely internal to Area 0 or an ABR depending on whether it has links to other, nonbackbone areas. Internal router: An internal router is an OSPF router with all its links within an area. If that router is located within the backbone area (Area 0.0.0.0), it is also known as a backbone router.
www.juniper.net
OSPF Chapter 29
OSPF Interfaces
All logical interfaces associated with the area should be listed under the area. Remember the loopback interface, if it should be advertised.
www.juniper.net
What If...?
In the slide, interface lo0.0 has four addresses configured on it. Typically, you would put interface lo0.0 into OSPF using the set area <area-id> interface <interface-name> command. However, doing this will create four LSAs: one for each of the configured addresses on interface lo0.0. You might come across a situation such as this for which you do not want to advertise all of the addresses into OSPF. A solution to this problem is offered on the next page.
www.juniper.net
Then...
The slide shows a solution to our problem. By specifying the specific interface address to advertise, only one LSA is created in the LSDB.
www.juniper.net
OSPF Interfaces
All logical interfaces associated with the particular area should be listed under that area. Remember the loopback interface, if it should be advertised.
www.juniper.net
Link-State Advertisements
The slide highlights the topic we discuss next.
www.juniper.net
www.juniper.net
LSA Types
The following list provides the details of the LSA types: Router LSA: Sent by each router to describe its individual links and their status. Network LSA: Sent by the DR on the broadcast network. Summary LSA: Sent by an ABR to describe routes or other information from one area into another. AS external LSA: Sent by an ASBR to describe routes external to the OSPF domain. Group membership LSA: Used to support Multicast Open Shortest Path First (MOSPF). NSSA LSA: Sent by an ASBR in a not-so-stubby area (NSSA) to describe routes external to the OSPF domain. External attributes LSA: Used to tunnel attributes used by other routing protocols through OSPF. Opaque LSAs: Used to transmit information not currently supported by other LSA types. Examples include graceful restart and traffic engineering information.
www.juniper.net
LSA Functions
Each of the LSA types listed previously has a specific function within the OSPF domain. They each describe a portion of the topology used by the SPF algorithm to supply routing information to a routing table. We discuss each LSA in more detail on future slides. Each LSA has a maximum age of 3600 seconds (1 hour) associated with it. This maximum provides a mechanism for removing stale information from the database. To ensure that its LSAs are up to date, each OSPF router periodically refreshes them prior to reaching the maximum age limit. The Junos operating system performs this refresh every 3000 seconds (50 minutes).
www.juniper.net
LSA Header
The following list details the information contained in the LSA header: Link-state age (2 bytes): Measured in seconds, the LS age is the time from when the LSA was first originated. Each router increments this field prior to reflooding the LSA. Options (1 byte): Indicates support for OSPF options. Within the context of an individual LSA, the E bit (position 7) is set in all external LSAs and the P bit (position 5) is set in all NSSA external LSAs. Link-state type (1 byte): Encodes the specific LSA type. Link-state ID (4 bytes): Describes various portions of the OSPF domain. Each LSA type uses this field in a different manner. Advertising router (4 bytes): The router ID of the router that first originated the LSA. Link-state sequence number (4 bytes): Verifies that each router has the most recent version of an LSA. This field is incremented each time a new version is generated. Values range from 0x80000000 to 0x7FFFFFFF. Link-state checksum (2 bytes): The checksum of the entire LSA contents, minus the LS age field. This field is used to ensure data integrity in the LSDB. Length (2 bytes): The entire length of the individual LSA, including the header.
www.juniper.net
Router LSA
Each OSPF-speaking router generates a Type 1 LSA to describe the status and cost (metric) of all interfaces on the router. This LSA is flooded to each router in the OSPF area. It is defined as having an area scope; therefore, it is not flooded across an area boundary. In addition to the standard LSA header, the router LSA also contains the following fields: V, E, and B bits (1 byte): Following five bits set to a value of 0, the V, E, and B bits represent the characteristics of the originating router. The V bit is set when a virtual link is established. An ASBR sets the E bit. An ABR sets the B bit. Reserved (1 byte): Reserved field. Value is always 0. Number of links (2 bytes): Gives the total number of links represented by the remaining six fields. Link ID (4 bytes): Represents the type of link the far end of the link is connected to. Link data (4 bytes): Represents what the near side of the link is connected to. Link type (1 byte): Describes the type of link. Used with Link ID and Link data fields. Number of type of service (ToS) metrics (1 byte): Lists the number of type of service metrics encoded. Only a value of 0 is supported. Metric (2 bytes): Contains the cost to transmit data out of the interface. Additional ToS data (4 bytes): This field is unused. OSPF Chapter 219
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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: Network mask (4 bytes): This field denotes the IP subnet mask for the interface connected to the broadcast network. Attached router (4 bytes): This field is repeated for each router connected to the broadcast network. The value of each instance is the router ID of the attached routers. You can deduce the total number of routers listed by the length of the LSA.
www.juniper.net
www.juniper.net
www.juniper.net
Summary LSA
Each ABR that transmits information from one OSPF area into another generates a Type 3 LSA to describe that information. This LSA is flooded to each router in the OSPF area. This LSA has an area scope; therefore, it is not reflooded across the area boundary by another ABR. Instead, the receiving ABR generates a new Type 3 LSA describing the link and floods it into the adjacent area. In addition to the standard LSA header, the summary LSA also contains the following fields: Network mask (4 bytes): This field represents the subnet mask associated with the network advertised. It is used in conjunction with the link-state ID field, which encapsulates the network address in a Type 3 LSA. Metric (3 bytes): This field provides the cost of the route to the network destination. When the summary LSA is representing an aggregated route (using the area-range command), this field is set to the largest current metric of the contributing routes. ToS (1 byte): This field describes any optional type of service information encoded within the network described. The Junos OS does not use this field. ToS metric (3 bytes): This field is not used.
www.juniper.net
Note that the command output on the slide is truncated. A fourth summary LSA for the 192.168.20.1/32 network is present, but not shown. This network, however, is shown on the next slide.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
AS External LSA
Each ASBR generates a Type 5 LSA to advertise any networks external to the OSPF domain. This LSA is flooded to each nonstub router in the entire OSPF domain. In addition to the standard LSA header, the AS external LSA also contains the following fields: Network mask (4 bytes): This field represents the subnet mask associated with the network advertised. It is used in conjunction with the link-state ID field, which encapsulates the network address in a Type 5 LSA. E bit (1 byte): The E bit determines the type of external metric represented by the metric field. It is followed by 7 bits, all set to 0 to make up the entire byte. A value of 0, the default value, indicates that this is a Type 2 external metric. Thus, any local router should use the encoded metric as the total cost for the route when performing an SPF calculation. A value of 1 indicates that this is a Type 1 external metric. Therefore, the encoded metric of the route should be added to the cost to reach the advertising ASBR. This additive value then represents the total cost for the route. Metric (3 bytes): This field represents the cost of the network as set by the ASBR. Forwarding address (4 bytes): This field provides the address toward which packets should be sent to reach the network. A value of 0.0.0.0 represents the ASBR itself. External route tag (4 bytes): This 32-bit value field can be assigned to the external route. OSPF does not use this value, but it might be interpreted by other protocols. Optional ToS fields (4 bytes): These fields are unused. OSPF Chapter 233
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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.
Protocol Operations
The slide highlights the topic we discuss next.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Dijkstra Algorithm
After a router receives a new LSA and places it into the LSDB, the router runs the SPF algorithm. This computation uses the database as a data source and results in a loop-free network topology using the best metric from the local router to all nodes in the network. During the course of this calculation, the algorithm uses three databasesthe LSDB, the candidate database, and the tree database. As we have explored, the LSDB is the total compilation of routing knowledge in the network. Conceptually, it consists of multiple tuples in the form of: router ID, neighbor ID, cost. These tuples describe each link in the network. Continued on the next page.
www.juniper.net
As the algorithm operates, the local router moves its own local tuple into the tree database and all tuples for its links into the candidate database. It then performs the following steps until the candidate database is empty: 2. For each new entry in the candidate database, determine the cost from the root to each neighbor ID. Move the tuple with the lowest cost from the candidate database into the tree database. If multiple tuples exist with an equal cost, choose one randomly. 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 entrys neighbor ID into the candidate database.
3.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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.
www.juniper.net
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
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.
Overload Settings
You can turn on the overload setting, turn it off as a permanent value, or have a timer associated with it. If the timer is omitted, the metric values are changed when you commit the configuration. The values will remain until you remove the overload setting from the configuration and commit it again. However, if you assign a timer value, the metrics are not changed automatically. The timer associated with the overload setting only initializes when the routing protocol process initializes. This timer can run from 601800 seconds. When the timer expires, the metrics return to normal in the router LSAs, but the configuration still contains the overload option. www.juniper.net OSPF Chapter 257
Case Study
Enterprise networks are typically built with multiple paths from ingress and egress points for redundancy. During maintenance operations on a router, it can be beneficial to prevent the router from receiving and forwarding transit traffic. The overload feature provides this function. In the graphic on the slide, R2 is scheduled for maintenance. An alternate path exists through R3. Once R2 is put in overload mode the other routers will be notified and transit traffic will traverse R3. Any traffic destined for networks that terminate on R2 will still be forwarded to R2.
www.juniper.net
OSPF Router ID
Each OSPF-speaking router in a network must select a 32-bit value to use as the router ID (RID) of the router. This RID uniquely identifies the router within the OSPF domain. It is transmitted within the LSAs used to populate the LSDB and is used to calculate the shortest-path tree using the method described on a previous slide. It is very important in a link-state network that no two routers share the same RID value. If two routers share the same RID value, the LSDB might not be consistent on all routers. This inconsistency happens because the RID is one method to verify whether an LSA is already present in the database. Therefore, new critical information from one of the routers is never present in all the routers. In addition, because the Dijkstra calculation uses the RID, it is possible that an individual router might not generate a loop-free shortest path topology. This scenario could have a disastrous affect on IP routing.
www.juniper.net
www.juniper.net
www.juniper.net
OSPF Authentication
The slide highlights the topic we discuss next.
www.juniper.net
Authentication
The three different forms of authentication that the Junos OS supports are none, simple, and MD5. As of Junos Release 8.3, IP Security (IPsec) was added.
Authentication Default
The default operation of the OSPF process is the none mode. Thus, no authentication key is configured on any interface.
Plain-Text Passwords
With simple authentication type configured, each OSPF packet includes a plain-text password. This password can be captured easily through a packet analysis system. Therefore, although this password protects against an inadvertent configuration, it does not provide any security.
www.juniper.net
Encrypted Checksum
To provide better security in an OSPF network, we recommend that you use an authentication type of MD5. MD5 includes an encrypted checksum in all OSPF packets instead of a simple-text password. Each OSPF-speaking router uses the same MD5 algorithm to calculate the checksum value, so interoperability and a correct result can be virtually guaranteed.
Authentication Keys
The actual password to verify and authenticate packets is contained within the authentication command. You can configure each individual interface with an authentication value.
Key ID Values
You configure each individual interface with a key value. All interfaces in the area might share the same key value, or each interface might contain a separate value.
www.juniper.net
www.juniper.net
www.juniper.net
Authentication Mismatch
OSPF routers must agree on the authentication method to be neighbors. Use the traceoptions functionality if you suspect there might be an authentication mismatch. The log shows that the local router is ignoring an OSPF packet from 172.20.77.1 because of an authentication mismatch. No authentication method is configured on the local router, so the type is none. The remote router has MD5 authentication configured.
www.juniper.net
OSPFv3
The slide highlights the topic we discuss next.
www.juniper.net
OSPFv3
OSPFv3 is defined in RFC 5340, with some additional features, such as grateful restart and authentication, defined in separate documents (RFC 5781OSPFv3 Graceful Restart and RFC 4552 Authentication/Confidentiality for OSPFv3). OSPFv3 maintains the fundamental mechanisms of OSPF, including LSA flooding scopes, areas, DR election, stub areas, NSSAs, and so on. Though OSPFv3 is often associated with IPv6 addressing, it is also completely compatible with IP version 4 (IPv4) addressing schemes. However, some changes are necessary to account for the differences in IPv4 versus IP version 6 (IPv6) addressing. We address these differences on the following slides. In terms of the Junos OS configuration, all that is required is to substitute ospf3 for ospf in the configuration. [edit] user@router# show protocols ospf? Possible completions: > ospf OSPF configuration > ospf3 OSPFv3 configuration
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
S-bits and flooding scope S2 0 0 1 1 S1 0 1 0 1 Flooding scope Link-local scope. Area scope. AS scope. Reserved.
The function codes are very much like the OSPFv2 type codes. Some exceptions, however, do exist. Most notably, all addressing semantics are removed from the router and network LSAs. The addresses that were advertised in the OSPFv2 versions of the LSAs are now carried in a new intra-area-prefix LSA. Another addition is the presence of the link LSA. The link LSA is used to advertise to directly attached OSPF neighbors the link-local IPv6 address assigned to the interface. As indicated by the LS type, the link LSA is not flooded beyond the physical broadcast domain.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Review Questions
1. 2. 3.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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.
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
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
NSSA Operation
The slide highlights the topic we discuss next.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
NSSA Configuration
The slide highlights the topic we discuss next.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Route Summarization
The slide highlights the topic we discuss next.
www.juniper.net
Route Summarization
To reduce the size of the LSDB in Area 0.0.0.0 (and other remote OSPF areas), you can configure the ABR not to perform its default one-for-one mapping function. This is accomplished using an address range statement on the ABR with the area-range command. All Type 1 and Type 2 LSAs that fall within that address range will no longer be advertised individually into the backbone. Instead, a single Type 3 summary LSA is advertised. The metric associated with this summary route will be equal to the highest metric associated with the individual contributing routes. Because only the ABR performs this mapping function, you configure the area-range command on ABR routers only.
www.juniper.net
Route Summarization
To reduce the size of the LSDB in Area 0.0.0.0 (and other remote OSPF areas), you can configure the ABR not to perform its default one-for-one mapping function. You can configure an address range on the ABR by using the area-range command within the NSSA configuration hierarchy. All Type 7 LSAs that fall within that address range are not advertised individually into the backbone. Instead, a single Type 5 external LSA is advertised. Because only the ABR performs this mapping function, only the ABR is configured with the area-range command. Note that the area-range command referenced here is specific to the NSSA configuration hierarchy and only affects Type 7 LSA routes. The area-range command discussed in the previous slide was within the area hierarchy itself and affected Type 1 and Type 2 LSA routes. The configuration can have these two commands in place at the same time, and they will summarize different aspects of the local area routing domain.
www.juniper.net
Suppressing Routes
The default action of the area-range command causes the generation of a single Type 3 summary LSA into the backbone for all prefixes that fall within the defined range. You can configure the ABR with the restrict keyword to block one or more prefixes from advertisement into the OSPF backbone. Such a configuration prevents routing information from each Type 1 and Type 2 LSA that falls within the address range from being advertised to the backbone, which in turn can block connectivity to those prefixes for routers in other areas. Use the restrict function when you want to prevent interarea routing, or when you want a default route to be used instead of the more preferred summary information that would otherwise be generated. Because only the ABR is responsible for this mapping function, you configure only ABR routers with the area-range restrict command.
www.juniper.net
www.juniper.net
www.juniper.net
Review Questions
1. 2. 3. 4.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Common Elements
The IGP transition strategies contain a few common elements. Every IGP transition strategy requires that you know which IGP provides the active routing information for the network at every point. You control this information in the Junos OS using route preferences. Additionally, most transition strategies require you to export appropriate routing information between the two IGPs so that you can ensure that all routers have access to full routing information.
www.juniper.net
Primary Tiebreaker
The Junos OS uses route preference as the primary criterion for selecting the active route. Preference values cause routes from certain information sources to be ranked more preferably than the same route received from another information source. The table on the slide shows the default preference values for a selected set of routing information sources. Continued on the next page.
www.juniper.net
Lower Is Better
Routing preference values are a 32-bit number that is 0 or higher. The router prefers lower preference values over higher preference values. This command output demonstrates that a direct route with a preference of 0 is preferred over an OSPF internal route with a preference of 10: user@router> show route 10.251.254.130/31 exact inet.0: 18 destinations, 19 routes (17 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 10.251.254.130/31 *[Direct/0] 1d 07:53:39 > via ge-4/0/0.0 [OSPF/10] 1d 07:53:32, metric 65 > via ge-4/0/0.0
www.juniper.net
www.juniper.net
Overlay Transition
In the overlay transition, you configure all routers in the network to run the new IGP while they are still running the old IGP. Once you verify the proper operation of the new IGP, you configure all routers in the network to stop running the old IGP. This transition strategy is appropriate when all routers have the necessary resources (in particular, CPU and memory) to run both protocols simultaneously. Additionally, you must accomplish any network redesign necessary to accommodate the new IGP as part of the transition.
Route Redistribution
If all routers cannot run both protocols simultaneously or if you must make some topology changes as part of the IGP change, you can gradually migrate the network one portion at a time. For example, if you are migrating to OSPF, you might migrate one future OSPF area at a time. As you progress from one portion of the network to another, you must configure routers on the border of the two IGPs to conduct mutual route redistribution, exporting routes between the two IGPs. Continued on the next page.
www.juniper.net
Integrated
If you must significantly redesign your existing topology to make it a well-designed network with the new IGP, the integrated strategy might be the best approach. In this strategy, you create a new network core running the new IGP, connect it to the old network core, and export routes between the new and old IGPs. You then gradually migrate connections from the old core to the new core.
www.juniper.net
www.juniper.net
Sample Topology
This slide shows the topology this chapter uses as an overlay example. We start off with a RIP network and then transition it to an OSPF network.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Multiarea Adjacencies
By default, a single interface can belong to only one OSPF area. However, in some situations, you might want to configure an interface to belong to more than one area. Doing so allows the corresponding link to be considered an intra-area link in multiple areas and to be preferred over other higher-cost intra-area paths. Beginning with Junos Release 9.2, you can configure a logical interface to belong to more than one OSPF area. As defined in RFC 5185, OSPF Multi-Area Adjacency, the area border routers establish multiple adjacencies belonging to different areas over the same logical interface. Each multiarea adjacency is announced as a point-to-point unnumbered link in the configured area by the routers connected to the link. For a given logical interface, it is considered as primary for one single area. To configure that same logical interface in additional areas, you must use the secondary option. In the slide, you can see that interface ge-1/0/0.0 has been configured in two areas, Area 0 and Area 1. Because the Area 1 interface has the secondary option set, the Area 0 occurrence is considered the primary.
www.juniper.net
www.juniper.net
Link Failure
In normal operation, if a link failure occurred between R1 and R3, traffic from R1 to R3 would flow from R4 to R2 and then to R3. This creates three hops to reach a router that was previously one hop away.
www.juniper.net
www.juniper.net
Adjacency Verification
Verify adjacencies with the show ospf neighbor command.
Normal Trace
For the case study, R3 is one hop away from R1.
www.juniper.net
www.juniper.net
Point-to-Point Interface
The output shows that the ge-1/1/0.0 interface now appears in two distinct OSPF areas, Area 0 and Area 100. However, note the secondary link in Area 100 shows up as a point-to-point interface.
www.juniper.net
Adjacency Is Formed
Two adjacencies are now formed over ge-1/1/0.0 for Area 0 and Area 100.
www.juniper.net
External Reachability
The slide highlights the topic we discuss next.
www.juniper.net
www.juniper.net
Route Redistribution
For route distribution to occur, an export policy must be written and applied. Because external routes in OSPF have an interarea flooding scope, the policies are applied globally. This feature allows external routes to be sent into all areas that allow it. When an external route is brought into OSPF, it appears as an external Type 5 LSA of Type 2. If an external LSA Type 1 must be configured, you can modify it with a policy.
www.juniper.net
Mutual Redistribution
Special care must be taken when redistribution is configured in a network. When multiple redistribution points are present sub-optimal routing and loops could occur. Generally, if the source route has a lower preference than the protocol into which it is being redistributed, no issues occur. However, when the source route has a higher preference, issues can occur. Several methods exist to resolve these issues, but the easiest method usually involves modifying route preference values.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
ABR Translation
Because the route was originated from the not-so-stubby area (NSSA), the ABR must convert the Type 7 LSA to a Type 5 for interarea advertisement.
Forwarding Address
When the ABR translates the Type 7 into a Type 5, it places the address of the autonomous system boundary router (ASBR) into the forwarding address. This action supports optimal routing because only one ABR will translate the Type 7 LSAs to Type 5 LSAs in the presence of multiple ABRs. This router might not be in the optimal path for routers in other areas.
ASBR Summary
The ABR also creates a Type 4 LSA to represent the ASBR to other areas.
www.juniper.net
www.juniper.net
The Result
The result of the preference change is now a default that points properly to the ABRs in the NSSA.
www.juniper.net
SPF Review
After a router receives a new LSA and places it into the link-state database (LSDB), the router runs an algorithm known as the Dijkstra algorithm (also called the shortest-path-first [SPF] algorithm). This computation uses the database as a data source and results in a loop-free network topology using the best metric from the local router to all nodes in the network. During the course of this calculation, the algorithm uses three databasesthe LSDB, the candidate database, and the tree database. As we have explored, the LSDB is the total compilation of routing knowledge in the network. Conceptually, it consists of multiple tuples in the form of (router ID, neighbor ID, cost), which describe each link in the network.
www.juniper.net
Import Policy
An import policy can be applied between the tree database and the routing table. This allows filtering of routes from the LSDB to the routing table but it only applies to external routes, as in the case for OSPF export policy. Note that the database stays consistent and the import policy does not block any normal LSA flooding.
www.juniper.net
Flooding Protection
Some OSPF implementations encounter problems when large numbers of external routes are injected into the LSDB. The Junos OS does not behave in this manner, however, and a large number of routes are handled without a problem. Although this protocol stability is a nice feature, a configuration mistake could make a portion of your network unusable as only routers capable of handling such large numbers would be operating effectively. To help you when a configuration mistake occurs, the Junos OS allows a limit to be placed on the number of external routes exported into OSPF. The prefix-export-limit command informs the router how many routes to accept using a routing policy configuration. The command accepts a 32-bit value, which provides a range of routes from 1 to 4,294,967,295. Once the route limit is reached, the router transitions into an overload state where the local links are set to a metric of 65,535 in the router LSA. Additionally, all Type 5 LSAs from the router are purged from the database and the network in general. The local router remains in this state until the number of external routes returns to a level below the configured limit. This situation requires the administrator to manually change the existing configuration; either the number of advertised routes must be reduced or the routing policy must be changed.
www.juniper.net
Modify Policy
To see prefix limits in action, a policy is modified to send all RIP routes into OSPF.
RIP Redistribution
This policy causes all RIP routes to be sent into OSPF.
www.juniper.net
Prefix Limit
To stop the large amount of LSAs that could enter the router, a prefix-limit of six is configured.
The Result
The result is that no RIP routes are distributed. This prefix-limit setting ensures that a configuration error does not affect your network.
www.juniper.net
Virtual Links
The slide highlights the topic we discuss next.
www.juniper.net
www.juniper.net
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
www.juniper.net
www.juniper.net
Technical OSPF
From the OSPF RFC 2328: Area border routers: A router that attaches to multiple areas. Area border routers run multiple copies of the basic algorithm, one copy for each attached area. (Section 3.3) Technically, you can create a multiarea OSPF network with no Area 0. However, we do not recommend this configuration because SPF will process all LSAs in all areas and the ABR loses its OSPF loop detection mechanism.
Functional OSPF
In practice, an ABR should always be connected to Area 0. Because the ABR calculation is similar to a distance vector protocol when processing the Type 3 LSA, a loop avoidance mechanism must be in place. This requirement is met with an Area 0 and a rule that SPF will only process LSAs within that area database.
www.juniper.net
www.juniper.net
Case Study
In this case study, Alpha Corp. has acquired Bravo Corp. Both networks are running multiarea OSPF and the integration team must get both networks communicating with each other.
www.juniper.net
www.juniper.net
www.juniper.net
Connectivity Issues
As soon as the physical connection is created, limited connectivity is achieved. For example, the B6 router can now reach the A1 router in Alpha Corps Area 0. However, Alpha Corps Area 0 routers cannot reach Bravo Corps Area 0 routers. The cause of this limited connectivity is the lack of a contiguous Area 0 backbone.
www.juniper.net
Virtual Link
One solution to the connectivity problem is to create a virtual tunnel between the two backbone areas of the corporations. This feature, known as a virtual link, provides a logical connection between areas. Essentially, OSPF packets are tunneled through a transit area to establish an OSPF adjacency and logically connect the two areas together. This establishes full connectivity between the two corporations. Remember that a virtual link is a control plane feature only. SPF will still calculate the shortest physical path between two points, which might not be the same path as the virtual tunnel. This calculation could create some confusion when troubleshooting, which is one of the primary reasons virtual tunnels are not considered long term solutions.
www.juniper.net
www.juniper.net
www.juniper.net
Contiguous Area 0
Once the neighbor is established over the virtual link, connectivity is restored, all LSAs are processed, and routes to each corporation are installed into the routing table.
www.juniper.net
www.juniper.net
Review Questions
1. 2. 3. 4.
www.juniper.net
Lab 3: Configuring and Monitoring Routing Policy and Advanced OSPF Options
The slide provides the objectives for this lab.
www.juniper.net
Chapter 52 BGP
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 53
BGP Review
BGP is a routing protocol between autonomous systems (ASs). It is sometimes referred to as a path-vector routing protocol because it uses an AS path as a vector to prevent inter-domain routing loops. The term path vector, in relation to BGP, means that BGP routing information includes a series of AS numbers, indicating the path that a route takes through the network. Although BGP is primarily used for inter-AS routing, BGP is also used in large networks for MPLS-based virtual private networks (VPNs) and is used to separate large OSPF domains. BGP is much more scalable and offers a greater amount of control through policy than an interior gateway protocol (IGP). BGP exchanges routing information among ASs. An AS is a set of routers that operate under the same administration. BGP routing information includes the complete route to each destination. BGP uses the routing information to maintain an information base of network layer reachability information (NLRI), which it exchanges with other BGP systems. BGP is a classless routing protocol that supports prefix routing, regardless of the class definitions of IP version 4 (IPv4) addresses. BGP routers exchange routing information between peers. The peers must be connected directly for inter-AS BGP routing (unless certain configuration changes are done). The peers depend on established TCP connections, which we address later in this chapter. BGP version 4 (BGP4) is essentially the only exterior gateway protocol (EGP) currently used in the Internet. It is defined in RFC 4271, which made the former standard of more than 10 years, RFC 1771, obsolete.
Chapter 54 BGP
www.juniper.net
BGP Usage
Networks with a single upstream connection receive little benefit from running a dynamic routing protocol with their Internet service provider (ISP). These customers typically use a static default route to send all external traffic toward the Internet. Their provider also typically uses a static route to direct traffic destined for the customers addresses to the customer. Normally, a single-homed network uses addresses assigned by the provider from the providers 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. BGPs policy controls provide the ability to optimize inbound and outbound traffic flows based on a networks technical and business constraints. Although BGP can detect and route around failures in redundant environments, BGP sessions within the same AS do not typically react as quickly as an IGP, and they often rely on the IGP used in the AS to remain operational when failures occur. Networks that are multihomed to a single ISP likely use nonportable addresses assigned by the provider. Networks that are multihomed to multiple ISPs likely use portable addresses assigned directly by the regional address registry.
www.juniper.net
BGP Chapter 55
BGP Peers
BGP supports two different types of exchanges of routing information. Exchanges between ASs are known as external BGP (or EBGP) sessions and handle inter-AS routing. Exchanges within an AS are known as internal BGP (or IBGP) sessions, and handle intra-AS routing. An EBGP peer connection is between a device in one AS and another device in a different AS. The connection between the two ASs consists of a physical connection and a BGP connection. The physical connection is a shared Data Link Layer subnetwork between the two ASs. On this shared subnetwork, each AS has at least one border gateway belonging to that AS. The BGP connection exists between BGP speakers in each of the ASs. This session can communicate destinations that can be reached through the advertising AS. The EBGP connection typically is established between immediately connected devices located in two different ASs because the time-to-live (TTL) value of the EBGP packets is equal to 1, by default. An IBGP connection is typically established between loopback interfaces of the routers not immediately connected (of course, everything depends on the topology of the AS). BGP uses the loopback interfaces for stability reasonsthese interfaces are always alive, unless the router itself dies. Because the IBGP connection typically exists between remotely connected routers, there is a requirement for an IGP within the AS. BGPs TCP session is established using regular routing tables.
Chapter 56 BGP
www.juniper.net
www.juniper.net
BGP Chapter 57
Chapter 58 BGP
www.juniper.net
www.juniper.net
BGP Chapter 59
Each BGP message uses the same fixed size header, which is 19 bytes. BGP keepalive messages do not include any data portion following the header.
www.juniper.net
BGP Attributes
The primary purpose of BGP is not to find the shortest path to a given destination; rather, its purpose is to find the best path. Each AS determines the best path to a prefix by taking into account its own outbound routing preferences, the inbound routing preferences of the routes 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
www.juniper.net
ISP As Network
The slide highlights a portion of ISP As 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 As 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
www.juniper.net
Customer Bs Aggregate
Customer B is currently a single-homed network but is planning on adding a second connection to another ISP in the near future. Customer B advertises its portable /20 prefix to ISP C with an AS path, indicating that it was originated locally. ISP C sends the advertisement to ISP B, which sends it to ISP A, with each ISP updating the path attributes as it sends the route. ISP A does not have a BGP session to Customer A, so Customer A does not receive any routing information for Customer Bs 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
www.juniper.net
Loopback Peering
You maintain only one IBGP session between each internal peer. The IGP is used to maintain reachability between the loopback addresses regardless of the physical topology, allowing the IBGP sessions to stay up even when the physical topology changes. The physical topology is relevant in one respect: each router along the path between BGP speakers must have enough information to make consistent routing decisions about packet forwarding. In many cases, this requirement means that all routers along all possible physical paths between BGP speakers must run BGP; however, in some networks, this requirement is not necessary.
Interface Peering
Recall that EBGP sessions are simply BGP sessions between two routers in different ASs. When two EBGP peers have a single path between them, EBGP sessions are usually established over the shared subnet between two peers, using the IP addresses assigned to the interfaces on that subnet as the session endpoints. By establishing the EBGP session using the IP address assigned to the interfaces on the shared subnet, you gain many advantages. One of these advantages is that you prevent either AS from needing to maintain any routing information about the other AS (besides what it received through BGP). You also ensure that all traffic flows over this particular shared subnet.
www.juniper.net
Configuring BGP
The slide illustrates the sample configuration. In this configuration example, we see some parameters defined under the [edit routing-options] and [edit protocols bgp] hierarchies. Under the [edit routing-options] hierarchy, we defined the systems router ID (RID) and the local AS number. Optionally, you can configure the systems 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 peers loopback address. The local-address is the local devices 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
www.juniper.net
BGP Authentication
All BGP protocol exchanges can be authenticated to guarantee that only trusted routing devices participate in the ASs routing. By default, authentication is disabled. You can configure MD5 authentication. The MD5 algorithm creates an encoded checksum that is included in the transmitted packet. The receiving routing device uses an authentication key (password) to verify the packets MD5 checksum.
www.juniper.net
www.juniper.net
BGP Operations
The slide highlights the topic we discuss next.
www.juniper.net
www.juniper.net
The purpose of the advertisement rules is to prevent routing loops on a BGP network.
www.juniper.net
Hidden Routes
One might expect all routes received from a BGP peer would be installed in the RIB-LOCAL table and be visible using the show route protocol bgp command. This is not always true. There are several reason why: The route might be a martian route; An import policy might exist that prevents the route from being installed; The routes protocol next-hop might be unresolvable.
Unresolvable Next-Hop
The number one reason for hidden BGP routes is an unresolvable next-hop. The BGP Update message contains a protocol next-hop IP address. If the router cannot resolve this address using its routing table, the route cannot be used and is not installed in the routing table. The number of hidden routes is always shown in the output of the show route command. To view the reason why routes are hidden, issue the show route hidden extensive command.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Configure multipath on R1
The configuration of the R1 router now contains the multipath command within the peer group for AS 2. After committing the configuration, we examine the contents of the local routing table. We still see the four routes advertised from AS 2, and each listing of the prefix still contains two versions of the route. As before, the routes from the R2 router are marked as active while the routes from the R3 router are marked as inactive. The effect of the multipath command on the routes from AS 2 is that the next hop for the routes from R3 (10.222.29.2) are now added to the version of the route from R2. The next-hop information for the inactive route version does not change in this environment. Because each active route now has two next hops in the routing table, the default Junos load-balancing process can be used. Each route has a single next hop selected, and this single next hop is placed into the forwarding table. All traffic for each route uses just that single next hop. The overall benefit of this system is the total amount of traffic sent from AS 1 to AS 2 can now be load-balanced over the two inter-AS links. In our small example, three routes are now using the 10.222.29.2 next hop, whereas just the 172.16.20.4/30 route remains with the 10.222.28.2 next hop. As more routes are announced between the AS networks, the selection of the next hops becomes more evenly distributed. Although not shown on the slide, you can also see the effects of using multipath in the output of the show bgp summary command. The route information from both R2 and R3 now appears as 4/4/4/0. The routes from R2 are active while the next-hop values from R3 are also being used to forward user traffic. Chapter 534 BGP www.juniper.net
www.juniper.net
www.juniper.net
Case Study: Accepting Remote Next Hops over a Single-Hop EBGP Session
In this example, AS 1 is advertising two routes toward AS 2, 2.2.2.0/24 and its own aggregate of 192.168.0.0/20. When you enable a single-hop EBGP peer to accept a remote next hop, you must also configure an import routing policy on the EBGP peer that specifies the remote next-hop address. The R3 router has a BGP import policy in place to set the next-hop of the 2.2.2.0/24 route to 192.168.3.21. By using the accept-remote-nexthop option, along with the import policy, you allow R3 to accept the route and still enjoy the benefits of a multipath setup.
www.juniper.net
Case Study: Accepting Routes with IPv6 Next Hops over an IPv4 EBGP Peer
In this example, we show how you can use the accept-remote-nexthop option, along with a BGP import policy, to accept routes from an IPv4 peer that have IPv6 next-hops. Normally, in this situation, the IPv6 routes would be discarded entirely.
www.juniper.net
www.juniper.net
Load Balancing
You can alter the default behavior of the Junos OS to install a single next hop per route in the forwarding table with a routing policy. The policy should contain the action of then load-balance per-packet and be applied as an export policy to the forwarding table within the [edit routing-options] configuration hierarchy. After committing the configuration, we see the same 172.16.20.4/30 route in the routing table of the local router. The same protocol information is displayed and again, a single next hop has been selected. This selection mechanism is not affected by our load-balancing policy, so we cannot verify if it is working by examining the routing table. Instead, a look at the forwarding table shows the outcome of our policy. Both the 10.10.1.2 and the 10.10.2.2 next hops are listed as valid outbound interfaces for the 172.16.20.4/30 route. Traffic destined for this route is now forwarded across both available next hops using a microflow hashing algorithm. The default inputs to the microflow hash are the incoming router interface, the source IP address, and the destination IP address. You can modify the inputs to the hashing algorithm at the [edit forwarding-options hash-key family inet] configuration hierarchy. Specifying the layer-4 command at this configuration hierarchy incorporates Layer 4 source and destination port information into the hash key.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
5.
6.
b. c.
7.
BGP then uses the route advertised from the peer with the lowest router ID (usually the loopback IP address). When comparing external routes from two distinct neighboring ASs, if the routes are equal up to the router ID comparison step, the currently active route is preferred. This preference helps prevent issues with MED-related route oscillation. The external-router-id command overrides this behavior and prefers the external route with the lowest router ID, regardless of which route is currently active. The router then examines the cluster-list attribute for the shortest length. The cluster list is similar in function to an AS path. The router prefers routes from the router with the lowest peer ID.
8. 9.
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 routers 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
www.juniper.net
www.juniper.net
www.juniper.net
Configuration Options
The graceful restart capability within the Junos OS is controlled under the [edit routing-options] configuration hierarchy. The following configuration enables the restart functionality: routing-options { graceful-restart; } The graceful-restart syntax is also a configuration hierarchy within BGP, which contains three options specific to the operation within the protocol. Those options include the following: disable: This option stops the local router from participating in any graceful restart function. restart-time: This negotiable timer sets the amount of time that can elapse for the peering session to reestablish. The default value for this timer is 120 seconds, and its range is between 1 and 600 seconds. stale-routes-time: This timer specifies the amount of time that routes from the restarting peer can be used before they are withdrawn. The default value for this timer is 300 seconds, and its range is between 1 and 600 seconds.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Paths 1 and 3 were received from the same AS, so their MED values are compared. Path 3 has a better MED value, so path 1 is no longer considered. Path 3 is now compared against path 2. Both paths were received from IBGP peers, so the IGP cost of path 2 makes it the active path for the local router. Continued on next page.
www.juniper.net
The MED values of all three paths are compared against each other. Path 3 has a lower MED value then the other two paths, so the local router installs Path 3 as the active path.
Path 3 was received the most recently, so it is compared against the previously received path, Path 2. The IGP cost of Path 2 is better than Path 3, so Path 3 is no longer considered by the algorithm. Path 2 is then compared against Path 1, which was received first. Path 1 was received from an EBGP peer, whereas Path 2 was received from an IBGP peer. The EBGP-over-IBGP preference rule causes the path selection algorithm to prefer Path 1, which is then installed as the active path for the local router.
www.juniper.net
www.juniper.net
Review Questions
1. 2. 3. 4. 5.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
BGP Attributes
The slide highlights the topic we discuss next.
www.juniper.net
BGP Attributes
A BGP prefix and its set of attributes is defined as network layer reachability information (NLRI). BGP attributes are a group of parameters that characterize a BGP NLRI. Thus a BGP prefix is defined by both its IP address and its set of BGP attributes. Attributes set BGP apart from other protocols. They give a network operator the flexibility to design a robust network and the tools to engineer a scalable routing policy.
www.juniper.net
Well-Known Discretionary
An attribute set as well-known discretionary must be understood by every BGP speaker, but it does not have to be in every update. If an update message contains an attribute in this category and is not understood, the connection is reset and an unrecognized well-known attribute message is sent.
www.juniper.net
Optional Nontransitive
An attribute set as optional nontransitive does not have to be understood by every BGP speaker, and it must not be passed to any peer. If an unrecognized attribute such as MP_REACH_NLRI is received it can safely be ignored, but it MUST NOT be sent to all neighbors.
www.juniper.net
www.juniper.net
www.juniper.net
Originating Router
The router that first inserts the prefix into BGP adds the origin attribute. Origin is supposed to measure the credibility of the source of the route, but it is mostly used by the Junos OS as a way to influence traffic flow.
www.juniper.net
www.juniper.net
www.juniper.net
AS Path Contents
The AS-path attribute contains the AS number of each system advertising the route, prepended to the beginning of the attribute. This behavior can be modified with routing policy.
www.juniper.net
Regex Support
The Junos OS supports regex operators, which allows for flexibility when using matching conditions with routing policy.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Regex Matching
We use a regular expression match for an as-path named REGEX-TEST. AS 1 needs to match an AS beginning with 3 and ending with 15, with anything in between. Using the regex operators available, the matching criteria becomes ^3 .* 15$ . Using a policy named MATCH-AS, term 1 matches an as-path named REGEX-TEST and raises the local preference of the route, making it more desirable. (The local-preference attribute will be covered in subsequent slides.) By using local preference, we force the router to choose the route before it takes AS path into consideration.
www.juniper.net
www.juniper.net
Mandatory Attribute
The next-hop attribute must be understood by all BGP speakers and must be included in every BGP update.
Default Behavior
The BGP next hop is only changed by default when it is sent across EBGP sessions. In this case, the BGP next hop is set to the IP address of the neighbor that sent the route. For IBGP sessions, if the route is originated from an EBGP peer, the BGP next hop remains unchanged.
www.juniper.net
www.juniper.net
www.juniper.net
Optional Nontransitive
Multiple exit discriminator (MED) is an optional nontransitive attribute; thus it does not need to be understood by any BGP speaker. In the case that it is not understood, it is not sent to any peers.
Stays in the AS
MED is never passed across an AS. If a BGP router receives a route from an EBGP peer with a particular MED value, it does not pass this MED value to any EBGP neighbors, but it does pass this MED value to all IBGP neighbors.
Comparison Rules
By default, a Juniper BGP router only compares MED values on routes coming from the same AS. This behavior can be changed by configuring path-selection always-compare-med or path-selection cisco-non-deterministic BGP commands.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Well-Known Discretionary
Local preference is a well-known discretionary attribute. Local preference must be understood by all BGP routers, but is not required to be present on every BGP update.
Restricted to the AS
Local preference is only used within an AS. The value is reset to the default value on an EBGP session, and maintains its value in an IBGP session unless it is manipulated by policy.
First Tiebreaker
Local preference is the first tiebreaker for route selection, so the router looks at local preference before any other attributes when choosing a route. This fact, and the fact that local preference is sent to all IBGP peers, makes it a suitable tool in choosing an exit point.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Well-Known Communities
RFC 1997 defines three community values that are regarded to be well known and should be understood by all BGP speakers. This makes it easier to implement routing policy in multivendor networks. The No-Export well-known community allows routes to be advertised to neighboring ASs, but those ASs are prohibited from sending it further upstream. The No-Advertise well-known community allows routes to be advertised to immediate neighbors, but those neighbors are prohibited from sending the routes to any peers. The No-Export-Subconfed well-known community is used in networks that use BGP confederations. It allows routes to be advertised to sub-confederation ASs but those routers are prohibited it from sending it further.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Review Questions
1. 2. 3. 4. 5.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
BGP Strengths
Routing Policy Control: BGP cannot simply be viewed as just a routing protocol, but as a policy definition device. One of the BGP designers intentions is to give flexibility in designing routing policy. This approach is in contrast to interior gateway protocols (IGPs), where the intent is to provide reachability and fast reconvergence. Diverse Administrative Control: BGP allows the configuration of autonomous systems (ASs) to scope network boundaries. The ability to define network boundaries with ASs allows a more flexible division of administrative duties to network personnel. Handling Large Prefix Counts: The nature of BGP as a distance vector protocol allows it to scale well in environments with large routing tables including the internet routing table. In comparison, most of the IGPs requirements of fast convergence and link state characteristics limit the amount of routes that can be handled.
BGP Weaknesses
Increased Convergence Time: The strengths that BGP has do come with a price. Fast convergence is not one of the things BGP is known for. BGP timers can be tuned or network change notifications can be deferred to a protocol like Bidirectional Forwarding Detection protocol (BFD), but convergence is more efficient with an IGP. Increased Complexity: An important factor to point out is that BGP is not intended to replace an IGP completely. It is rather to act in complimentary fashion with an IGP. With this added layer, an enterprise will need more knowledgeable network personnel. Chapter 74 Enterprise Routing Policies www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
The individual goal solutions are laid out in detail in the next few slides.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Local Preference
Many practices are fairly common among ISPs. Understanding these practices can affect the way we implement routing policies. Among these practices is the use of local preference to prefer certain routes over others. Usually, ISPs assign default local preferences such that customer routes are preferred over routes received from peers (or upstream ISPs). ISPs also usually accept certain communities from customers that cause them to set a different local preference. In general, several options are available between the default customer and peer values, and often, at least one option is available that is less than the default peer value. We can use these communities to further influence inbound traffic flow.
Prefix Length
Most ISPs do not accept routes that are more specific (longer) than a /24 from either customers or peers. Some ISPs accept longer routes from customers, but they do not announce them to other customers or peers. Continued on the next page.
www.juniper.net
www.juniper.net
Path Selection
In this model, the router first tries to determine the best path for traffic to reach its destination. The router first looks at the AS Path length, which should give some indication of the total distance to the destination. If that length is tied between routers from the same next-hop AS, it compares MEDs to determine which path the next AS wants it to use. (Hopefully, the next AS is setting its MEDs to accurately reflect internal metrics.) If the router determines that two or more BGP-received routes are still tied in these values, the router must break the tie between these equally well-preferred routes. Once the router reaches this point in the decision algorithm, it simply tries to choose the closest exit. It does this by preferring EBGP-received paths over IBGP-received paths. If no EBGP-received paths exist, the router next tries to break the tie by choosing the IBGP path with the closest exit, as determined by IGP metrics.
www.juniper.net
www.juniper.net
www.juniper.net
Path Selection
If two paths to a destination have equal AS Path lengths and MED values (if the next AS is the same), the router simply tries to choose the closest exit from the AS. Once it gets to this point, one of the differences between having multiple border routers and a single border router becomes clear. In the case of multiple border routers, each border router prefers one of the EBGP-received announcements over any of the IBGP-received announcements. Thus, traffic bound for Drills, Inc. that reaches R1 is sent through ISP B, and traffic bound for Drills, Inc. that reaches R2 is sent through ISP C. This scenario should result in load sharing, depending on the IGP configuration. In the case of a single border router, the router prefers the oldest EBGP-received announcement, which results in the router preferring the most stable path to a destination. However, in periods of great stability (or immediately following a period of high instability, such as a router reboot), it also generally results in the router preferring a single connection for most routes with an equal AS path. This behavior results in somewhat imbalanced load sharing; however, this behavior should result in better performance over time (because it favors stable paths).
www.juniper.net
Primary/Secondary Variations
A true primary/secondary routing policy has a single preferred ISP, over which all traffic flows while the connection to that ISP is up. Only when that connection is down does traffic flow over the secondary connection. Variations on the primary/secondary routing policy do exist that allow certain traffic to flow over the secondary link, even when the primary link is up. For example, you might want to allow traffic to or from customers of the secondary ISP to use that connection even when the connection to the primary ISP is functioning normally. Continued on the next page.
www.juniper.net
Assured Redundancy
The main benefit to a primary/secondary routing policy is to provide reliability through redundancy. To be assured of true redundancy, you must always have enough bandwidth available to the secondary provider to fully accept the load of the connection(s) to the primary provider. The easiest way to guarantee this availability is to use connections of the same bandwidth to both the primary and secondary providers and to use a strict primary/secondary routing policy. This method ensures that you always have enough bandwidth in place on the secondary link to fully accept the load on the primary link. Implementing a strict primary/secondary model can also allow you to reduce the costs of the secondary connection. It is usually possible to negotiate a lower monthly fixed fee for a secondary circuit in return for accepting a usage-based bill. Provided that there are not extended outages to the primary circuit, this fixed fee will likely result in a lower cost for the secondary circuit than if you purchased two circuits and used them both.
www.juniper.net
Local Preference
The best way to enforce a primary/secondary outbound routing policy is by modifying the local-preference path attribute. The router always selects the route with the highest local preference (regardless of AS path) as its preferred route to a destination. Therefore, setting a higher local preference on the routes using the primary path and a lower local preference on the routes using the secondary path should cause the router to always prefer the routes using the primary path. However, this setting does not necessarily mean that all traffic will flow through the primary path.
www.juniper.net
www.juniper.net
www.juniper.net
Loose Primary/Secondary
In a loose primary/secondary routing policy, you make one ISP your primary ISP and another your secondary ISP, but you want to allow traffic to select prefixes to use your secondary ISP even in normal operations. To implement a loose primary/secondary outbound routing policy, you accept a default route from both providers, but you also accept announcements for some specific prefixes from your secondary ISP. Because you do not receive announcements for those specific prefixes from your primary ISP, your routers use the announcements you receive for these prefixes from your secondary ISP. In the example on the slide, AS 65501 is receiving the specific routes for some of ISP Bs customers. AS 65501 is preferring to send traffic to these prefixes through ISP B.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Review Questions
1. 2. 3.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Overview of Multicast
The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
www.juniper.net
www.juniper.net
Benefits of Multicast
As shown in the previous slide, the use of multicast to deliver content to remote hosts greatly reduces the load on both the server that is generating the content as well as the network bandwidth usage.
Usage of Multicast
Interest in multicast as a content delivery mechanism has increased over the last few years. Because the functionality of multicast is very similar to broadcasts from a radio or television station, it makes sense that many radio and television companies are showing interest in using multicast-enabled IP networks to deliver their content. Multicast is now widely deployed in enterprise networks for such applications as company meetings by video and distance learning.
www.juniper.net
www.juniper.net
www.juniper.net
(S,G) State
The forwarding path built from receiver up to source is stored and maintained in the routers as an (S, G) forwarding state (S comma G). S indicates source address and G indicates group address. Dense Mode protocols always maintain (S,G) state. Sparse Mode protocols only maintain (S,G) state after the receiver router learns about the source.
www.juniper.net
(*,G) State
When the source is not known, a source tree can not be built yet. If a receiver requests to receive traffic for a particular group but does not specify a specific source, the routers will need to build a tree towards an unknown source. PIM Sparse Modes (PIM-SM) solution to this problem is to have a meeting point for sources and receivers in the network. This meeting point is called a rendezvous point (RP). The tree built from the receiver to the RP in the network is called a shared tree (because it is shared by all sources). The forwarding path built from the receiver router to the RP is kept as (*,G) forwarding state (* comma G). The * indicates any source and the G indicates the group address.
www.juniper.net
Multicast Addressing
The slide highlights the topic we discuss next.
www.juniper.net
Multicast Addresses
Multicast group addresses are defined to be the IP addresses whose four high-order bits are 1110, giving an address range from 224.0.0.0 through 239.255.255.255, or simply, 224.0.0.0/4. These addresses also are referred to as Class D addresses.
Registered Groups
The Internet Assigned Numbers Authority (IANA) maintains a list of registered IP multicast groups. The base address 224.0.0.0 is reserved and cannot be assigned to any group. The block of multicast addresses from 224.0.0.1 through 224.0.0.255 is reserved for local wire use. Groups in this range are assigned for various uses, including routing protocols and local discovery mechanisms.
www.juniper.net
Reserved Ranges
The following list comprises the reserved multicast address ranges: Scoped Range: The range 239.0.0.0/8 through 239.255.255.255/8 is reserved for administratively scoped addresses. Because packets addressed to administratively scoped multicast addresses do not cross configured administrative boundaries, and because administratively scoped multicast addresses are locally assigned, these addresses do not need to be unique across administrative boundaries. These addresses are available for private internal use. GLOP addressing: The range of 233.0.0.0/8 is a statically assigned range of multicast addresses based on a networks autonomous system (AS) number. For each AS, 255 unique multicast addresses are available for the global use of that AS. Source-specific multicast (SSM) addressing: The range of 232.0.0.0/8 is dedicated for use with SSM. SSM will be covered in-depth in the next chapter. Session Description Protocol (SDP)/Session Announcement Protocol (SAP) addressing: The range of 224.2.0.0/16 is used to send and receive multimedia session announcements. Session Directory tool (SDR) is a common application that uses SDP/ SAP. These protocols do not scale well and are not recommended for deployment on the Internet because of a potential denial of service (DoS) attack vector that they open.
www.juniper.net
Address Mapping
IANA has been allocated a reserved portion of the IEEE-802 Media Access Control (MAC) layer multicast address space. All of the addresses in IANAs reserved block begin with 01-00-5E (hexidecimal). A simple procedure was developed to map Class D addresses to this reserved address block to allow IP multicasting to take advantage of hardware-level multicasting supported by network interface cards. The use of a MAC-layer broadcast would cause all machines on the subnet to expend cycles for every multicast packet, even though these machines might not want to receive multicast. For example, the mapping between a Class D IP address and an Ethernet multicast address is obtained by placing the low-order 23 bits of the Class D address into the low-order 23 bits of IANAs reserved address block.
www.juniper.net
www.juniper.net
RPF
The slide highlights the topic we discuss next.
www.juniper.net
RPF
But how is this away direction defined? With RPF, multicast-enabled routers use unicast routes to determine the best path back to the source. RPF uses the existing unicast routing table to determine the upstream and downstream neighbors for a particular address. A router only forwards multicast packets received on the upstream interface. These packets, in turn, are only forwarded out interfaces considered downstream from the source. This RPF check helps guarantee that the distribution tree is loop free. If the RPF check is successful, the packet is forwarded. Otherwise, it is dropped. RPF checks can be done using inet.0 and normal unicast routing protocols, or RPF can use MBGP to put unicast routes in inet.2. Continued on the next page.
www.juniper.net
Distribution Trees
Multicast-capable routers create distribution trees, which control the path that IP multicast traffic takes through the network when delivering traffic to all receivers. The two basic types of multicast distribution trees are source trees and shared trees. The simplest form of a multicast distribution tree is a source tree, with its root at the source and branches forming a spanning tree through the network to the receivers. Because this tree uses the shortest path through the network, it also is referred to as a shortest-path tree (SPT). Unlike source trees that have their root at the source, shared trees use a single, common root placed at some chosen point in the network. This root of a shared tree is called a rendezvous point (RP).
www.juniper.net
RPF
The incoming interface of an IP multicast packet is checked, and a decision is made to either forward or drop the packet. When a packet comes in, the router examines the source address to determine whether the packet arrived on an interface that is on the reverse path back to the source. If it is, the packet is forwarded; if not, the packet is discarded. The RPF check ensures that multicast traffic always flows away from its source, which prevents loops and wasted bandwidth. When using Protocol Independent Multicast (PIM), RPF checks are performed against the main routing table (inet.0), by default. Distance Vector Multicast Routing Protocol (DVMRP), on the other hand, requires the presence of interface routes in the inet.2 table for this purpose. Normally, inet.2 is only used in conjunction with PIM when you want unique unicast and multicast topologies; when RPF checks are performed against the main routing instance, you effectively have the same topology for both unicast and multicast.
www.juniper.net
www.juniper.net
www.juniper.net
Dense-Mode Protocols
Common dense-mode protocols include DVMRP, which builds a unique multicast routing table and has a finite hop count of 32. DVMRP was the first multicast routing protocol. As mentioned, PIM dense mode (PIM-DM) uses a flood-and-prune behavior to build a source tree from the source of the multicast.
www.juniper.net
PIM-DM Operation
PIM-DM uses SPTs to deliver multicast traffic and assumes that there is at least one receiver of the multicast traffic on every subnet in the network. Traffic is initially flooded to all points in the network. Each router running PIM-DM creates an (S,G) state entry for each source/group pairing. The slide shows an example of what an (S,G) state entry looks like. Routers without locally attached receivers must prune themselves periodically from the SPT to avoid the reception of unwanted multicast traffic.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
IGMP
The slide highlights the topic we discuss next.
www.juniper.net
IGMP
IGMP manages multicast groups participation between hosts and routers. IP hosts use IGMP to report their multicast group memberships to their neighboring multicast routers. Multicast routers use IGMP to determine whether any hosts on their attached networks are interested in receiving multicast traffic, and if so, in which multicast groups the hosts are participating. IGMP is an integral part of IP and must be enabled on all routers and hosts that want to receive IP multicast. IGMP can also help a Layer 2 switch determine which port it should use for forwarding multicast packets. Normally a Layer 2 switch will forward multicast packets in the same manner as a broadcast packet by sending a copy of received multicast packets out of all interfaces except for the one on which the packet arrived. By enabling IGMP snooping (supported on Junos OS Layer 2 switches), a switch is able to listen in on the IGMP report messages between hosts and attached routers. From what the switch learns from these messages, it can make a better decision on where to send the multicast packets.
Junos OS Support
On Junos OS routers, IGMP is enabled automatically on all multiaccess interfaces configured with a multicast routing protocol such as DVMRP or PIM. You might need to configure the IGMP protocol explicitly if you want to disable IGMP support on a given interface, or if you need to modify various IGMP parameters. The default version of IGMP is version 2; however, the Junos OS also supports versions 1 and 3.
www.juniper.net
www.juniper.net
IGMP Version 1
RFC 1112 defines IGMPv1. IGMPv1 routers periodically transmit host membership query messages to determine which groups have members on their directly attached networks. Query messages are addressed to the all-hosts group address (224.0.0.1) and have IP TTL=1. When a host receives a query message, it responds with a host membership report for each group to which it belongs. Multicast routers periodically transmit queries to update their knowledge of the group members present on each interface. Because queries are normally sent every 60 seconds, multicast traffic can be delivered to a subnet with no interested hosts for several minutes after the last host has left that group.
IGMP Version 2
RFC 2236 specifies IGMPv2. RFC 2236 defines a procedure for the election of a querier for each LAN. The router with the lowest IP address on the LAN becomes the querier. In IGMPv1, the multicast routing protocol determined the querier election. IGMPv2 also defines a group-specific query message and a leave-group message, which improves on IGMPv1s leave latency. Continued on the next page.
www.juniper.net
IGMP Version 3
RFC 3376 defines IGMPv3 and introduces support for group-source report messages. With these messages, a host can elect to receive traffic from specific sources of a multicast group. This capability accommodates SSM. A host identifies the IP addresses of the specific sources from which it wants to receive traffic by generating an inclusion group-source report message. The host generates an exclusion group-source report message to explicitly identify the sources from which it no longer wants to receive traffic. With IGMPv1 and v2, if a host wants to receive traffic from a given group, that host must be prepared to receive traffic from all active sources sending packets to that group. SSM maximizes efficiency by allowing a host to receive group traffic from a selected set of sources. The support for leave-group messages that was introduced in IGMPv2 is enhanced to support group-source leave messages in IGMPv3. Although IGMPv3 adds support for the SSM service model, it still offers backwards compatibility with the any-source multicast (ASM) service model as well.
www.juniper.net
www.juniper.net
Query-Response Model
The primary function of IGMP is to inform multicast routers as to which multicast groups have active listeners on a given segment. In the example on the slide, two hosts are reporting that they want to receive traffic for the group 224.10.1.1, and one host reports a desire to receive traffic for group 224.20.1.1. In this example, Router A is functioning as the querier router. The querier router is responsible for periodically sending query messages to the all-hosts multicast group 224.0.0.1 and is the multicast router with the lowest IP address on a particular subnet. The example begins with the querier router sending a general query to the all-hosts multicast address. A general query does not contain a particular group address, and as such, it applies to all possible groups. Note that IGMPv1 supports only general queries, while IGMPv2 supports both general and group-specific query messages. Group-specific queries are generated as a result of receiving a leave-group message from an IGMPv2 host. Continued on the next page.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Sample Configuration
To configure IGMP, you include statements at the [edit protocols igmp] hierarchy level of the configuration. IGMP is enabled automatically on all non-point-to-point interfaces configured to run DVMRP or PIM in all Junos OS releases. You can manually list the interfaces that should run IGMP or use the all keyword. In all cases, you should ensure that IGMP does not run on the routers out-of-band interface (fxp0) by specifically listing the fxp0 interface as disabled, especially when using the interface all approach. Interfaces enabled for IGMP run version 2, by default. You can manually select version 1 or 3 as needed. IGMP version 3 supports SSM. The syntax on the slide shows how you can configure a static IGMP report under a particular interface for a given group address. This configuration causes the router to act as if it had received an IGMP report on the interface (no IGMP reports are actually sent or received as a result of this configuration). By including a source address, you will cause the router to send an (S,G) PIM Join message while omitting the source address causes the router to send a PIM (*,G) Join message. Static reports are useful when testing multicast in the absence of a multicast receiver. The IGMP querier router periodically sends general host-query messages. These messages solicit group membership information and are sent to the all-hosts multicast group address, 224.0.0.1. By default, the router sends host-query messages every 125 seconds. You might want to change this interval to tune the number of IGMP messages sent on the subnet.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Review Questions
1. . 2. . 3. . 4.
www.juniper.net
www.juniper.net
www.juniper.net
ASM
The ASM delivery model was designed into the original specifications of multicast in RFC 1112. This model supports traffic from one source to many receivers. Internet Protocol Television (IPTV) video is one example that uses this model. ASM also supports traffic between all members of a multicast group. Examples of this many-to-many model are videoconferencing and whiteboard applications. ASM gets its name from a mechanism that allows receivers to join a group without specifying from which source they want to receive traffic. As a result, the receivers accept multicast packets for a particular group from any source.
SSM
In the SSM model, the receiver specifies the sources from which it would like to receive traffic. The receiver can also specify from which sources it does not want to receive traffic. So for SSM to work, the source information must be learned from the receiver. SSM makes deployment of multicast less complex and also makes addressing easier.
www.juniper.net
Dense Mode
When using a dense mode multicast routing protocol, traffic gets forwarded to all parts of the network (flooding). This flooding process allows every router in the network to learn of any active sources in the network and store that information in a state called (S,G) or S comma G. The parts of the network that are not interested in receiving the traffic (no receivers) will send Prune messages to their neighbor routers asking them to stop forwarding traffic to them. In the case where a receiver joins a group after the branch of the forwarding tree has been pruned, the routers along the shortest-path tree (SPT) will send a graft message asking for the traffic to be forwarded again. In a dense mode network, multicast traffic is always forwarded along the SPT between source and receiver. Dense mode multicast routing protocols include Multicast Open Shortest Path First (MOSPF), Distance Vector Multicast Routing Protocol (DVMRP), and PIM dense mode (PIM-DM). The Junos operating system supports DVMRP and PIM-DM, but not MOSPF.
Sparse Mode
When using PIM-SM, multicast traffic only gets forwarded into parts of the network where interested receivers exist. Only routers along the SPT need to maintain (S,G) state. Each router along the forwarding path sends Join messages to indicate its willingness to receive traffic. In the case where the receiver is no longer interested, the router sends Prune messages to the upstream neighbor asking the neighbor to stop forwarding the traffic. In PIM-SM, there are two possible forwarding trees that can be used to deliver traffic to an interested receiver: an SPT or a rendezvous-point tree (RPT). We describe each of these forwarding trees in subsequent slides.
www.juniper.net
SPT
An SPT is a multicast forwarding tree that is rooted at the first-hop router closest to the source. When a dense mode protocol is used in the network, (S,G) state is maintained for every known source and group combination on every router, including those routers not on the SPT. When PIM-SM is used in the network, (S,G) state is maintained for every known source and group combination only on the routers on the SPT, as well as the rendezvous point (RP) (discussed in subsequent pages).
www.juniper.net
RP Tree
An RPT can be found only in a PIM-SM network. The RP is a centralized router that is responsible for knowing all combinations of active sources and groups in the network. The RPT is a multicast forwarding tree that is rooted at the RP in the network and leafs out to the interested receivers. Because all last-hop routers fall on the RPT for a specific multicast group, this tree is sometimes referred to as the shared tree. This tree is generally used temporarily for forwarding until the routers closest to interested receivers learn the source of multicast traffic (learned from the source address of the multicast packets). Once these routers learn the source of the multicast traffic, they build an SPT directly to the source designated router (DR).
www.juniper.net
www.juniper.net
PIM Independence
PIM is indeed as it claimsprotocol independent. Whichever unicast protocol is being used, PIM will use this protocol for its reverse-path forwarding check. PIM does not care if this protocol is OSPF, Intermediate System-to-Intermediate System (IS-IS), RIP, or even BGP!
PIM-SM Trees
The purpose of an RP and a shared tree is to allow receivers to learn of active senders for a given multicast group. Once an active sender is detected, that is, data from sender x is received over a shared tree, PIM sparse-mode routers attempt to optimize the topology by establishing a source-based tree. The resulting SPT removes unnecessary hops, and possibly the RP itself from that particular multicast flow. Subsequent slides provide details of this behavior.
Design Considerations
The placement and selection of a sparse-mode RP can be a critical factor in the networks performance and fault tolerance. Subsequent pages discuss ways of achieving RP redundancy. PIM-SM for IP version 4 (IPv4) requires a pd interface on the RP, and a pe interface on every router that is directly attached to a multicast source. On some Juniper Networks hardware, the pd and pe virtual interfaces require the presence of a specialized services PIC. Consult JTAC or technical documentation to determine whether your hardware model requires specialized hardware. Continued on the next page.
www.juniper.net
Sparse-Dense Mode
The PIM protocol allows the designation of groups to be either sparse or dense. This designation allows some groups to operate in dense mode using SPT, while other groups operate in sparse mode with a shared tree. One example of when to use sparse-dense mode is when using auto-RP.
www.juniper.net
www.juniper.net
Adding a Receiver
Adding a receiver to a PIM-SM network (ASM model) requires that an RPT is built from RP to receiver. The slide shows a new receiver notifying R5 of its interest in receiving traffic destined to 224.7.7.7 by sending an Internet Group Management Protocol version 2 (IGMPv2) report. Not knowing the source of the 224.7.7.7 group, R5 sends a (*,G) Join message in the direction of the RP. R4, after receiving the Join message from R5, also sends its own (*.G) Join message to the RP. This results in the building of the RPT. Because the RP is aware of all active sources in the network (because of the reception of register messages), the RP sends an (S,G) Join message toward the source in an attempt to build an SPT from source to RP. R2, after receiving the Join message from the RP, also sends its own (S,G) Join message to the sources DR which completes the building of the SPT.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Three RP Methods
The Junos OS provides three separate methods for determining which router in the domain is the RP. These methods include static configuration, dynamic announcements using auto-RP, and dynamic announcements using a bootstrap router (BSR).
Precedence Order
In the event that a local router encounters multiple methods of learning the address of the RP, the Junos OS has a default precedence mechanism for making the selection. The RP announced by the BSR is preferred over the RP announced using auto-RP, which is preferred over any local static RP configurations.
Local RP Configuration
Regardless of the method used in the network for determining the RP address, a candidate rendezvous point (candidate RP) itself must be configured to perform that role. In the example on the slide, the local portion of the [edit protocols pim rp] hierarchy accommodates this configuration need. You define the address to be used as the RP address and any applicable group addresses the candidate RP should operate upon. If no group addresses are defined, the candidate RP is used for all possible group addresses (224.0.0.0/4).
www.juniper.net
Static RP
A static RP configuration is very similar to static routes in that no automatic failover exists should the statically defined RP become unreachable. Although this configuration is simple and convenient, you might want to use this method in combination with any-cast RP and Multicast Source Discovery Protocol (MSDP) to provide a fault-tolerant mechanism. Static RP assignment has the benefit of operating in either a PIM version 1 or version 2 network. In the example on the slide, the static portion of the [edit protocols pim rp] hierarchy is used to configure a static RP address. You define the address of the RP, as well as the group addresses for which to use the RP. If no group addresses are defined, the RP is used for all possible group addresses (224.0.0.0/4).
www.juniper.net
Verifying a Static RP
The show pim rps command with the extensive switch displays a wealth of information about how an RP was learned, which groups it handles, and the number of groups actively using the RP. In the example on the slide, the RP at 192.168.50.61 was learned from a static configuration. It can support all groups in the 224.0.0.0/4 range, which is all possible groups. The local router sent PIM control traffic for the 224.7.7.7 group to this particular RP.
www.juniper.net
Dynamic RP Assignment
If you want a dynamic way of assigning RPs in a multicast network, auto-RP is one option. Auto-RP has both positive and negative aspects to its operation. From a positive perspective, it operates in both a version 1 and a version 2 PIM network. Negatively, it is a nonstandard (non-RFC-based) function and requires the use of dense-mode PIM to advertise control traffic.
Failover Capabilities
One advantage that auto-RP maintains over static RP assignment is the ability to maintain a backup RP in the network. This backup allows you to configure multiple routers as RP candidates. Should the elected RP stop operating, one of the other preconfigured routers can take over the RP functions. The auto-RP mapping agent controls this capability. Continued on the next page.
www.juniper.net
Mapping Agents
As multiple candidate RP routers announce their capabilities to support multicast groups, there must be a single router in the networkthe mapping agentto perform the group-to-RP mapping. This functionality is required because only a single RP for each multicast group can exist. The mapping agent sends out Discovery messages to the network informing all routers which RP to use for specific multicast groups.
www.juniper.net
Auto-RP Message
Each local router configured as an RP uses this auto-RP message to advertise its capability into the network. The mapping agent in the network collects these announcements and selects the RP for each group address. This information is then transmitted into the network using this same message format. The message fields include the following: Version and type (1 byte): This octet is split into two 4-bit fields. The first 4 bits represent the current version of auto-RP being used and are set to a constant value of 1. The second 4 bits are used to represent the actual type of auto-RP message encoded. The possible values are the following: 1: RP announcement message; and 2: RP mapping message.
RP count (1 byte): This field displays the number of distinct RP addresses present in the message. For each address present, the RP address field, as well as its associated fields, is repeated. Hold time (2 bytes): This field displays the amount of time, in seconds, for which the RP message is valid.
www.juniper.net
Group count (1 byte): This field displays the number of groups associated with the RP address. Encoded group address (6 bytes): This field contains three separate portions used to describe the group address associated with the RP. The entire 6 bytes are repeated based on the value in the group count field. The field portions include the following: Reserved and N bit (1 byte): This field contains seven bits set to a value of 0, followed by the N bit. The N bit denotes whether group address is positive or negative. A value of 0 represents a positive group address, which should use sparse mode PIM forwarding. A value of 1 represents a negative group address, which should use dense mode PIM forwarding. Mask length (1 byte): This field displays the length of the group prefix to follow. Group address (4 bytes): This field displays the multicast group address that the RP supports.
www.juniper.net
Electing an RP
The slide shows how the mapping agent learns of all of the candidate RPs, performs the RP election, and then informs all of the routers in the network of the elected RP.
www.juniper.net
Configuring Auto-RP
To enable auto-RP successfully in a PIM network, you must complete a few steps. First, each router in the network must enable the sparse-dense mode on all interfaces within the [edit protocols pim] hierarchy. This step allows the router to operate in sparse mode for most groups and dense mode for others. The default action is to operate in sparse mode unless specifically informed of a dense-mode group, which is accomplished with the dense-groups command. Both the 224.0.1.39 and 224.0.1.40 groups must be listed, and you must apply this configuration on all routers in the network. Once you complete the preceding steps, the actual configuration of auto-RP can take place. Each router must have the auto-rp command configured with one of three switches: discovery, announce, or mapping. The discovery option allows a router to receive and process the Discovery messages from the mapping agent. This function is the most basic and limited a router can support. The announce option adds to the same abilities as the discovery option, but also allows a router to send Announce messages into the network stating that it is a candidate RP. Finally, the mapping option adds to the abilities of the announce option, but also allows a router to perform the group-to-RP mapping function as well as to send Discovery messages into the network.
www.juniper.net
Verifying an Auto-RP RP
In the example on the slide, the RP at 192.168.50.61 is learned from auto-RP. It can support all groups in the 224.0.0.0/4 range, which is all possible groups. In addition, the presence of tunnel services in an RP router creates a decapsulation interface to allow the RP to receive multicast traffic from the source. This interface is ppd0.32769 in the example.
www.juniper.net
www.juniper.net
www.juniper.net
Candidate RP Advertisements
After the election of the BSR, each configured RP in the network unicasts a candidate RP advertisement (C-RP-adv) into the domain. This announcement informs the BSR which multicast groups the RP can support, the hold time for the RP, and a priority value. This information allows for a dynamic failover in the event of a failure.
www.juniper.net
4.
www.juniper.net
BSR Message
Each BSR message is encoded in a PIM protocol packet as type code 4. It contains as few as one multicast group address range or multiple ranges. Each advertised address prefix includes a list of RPs capable of servicing that group. The fields of the bootstrap message include the following: Fragment tag (2 bytes): It is possible that an individual bootstrap message might be too large for transmission in the network without fragmentation. This field includes a randomly generated number designed to ensure that all fragmented packets are associated with the same bootstrap message. Each fragment receives the same value in this field. Hash mask length (1 byte): This field displays the length, in bits, that each router should use when calculating the BSR hash algorithm. For IPv4 messages, a value of 30 is recommended. BSR priority (1 byte): This field displays the priority value of the current network BSR. BSR address (6 bytes): The address of the domains BSR is placed in this field using the encoded unicast address format.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Configuring a BSR
As stated on a previous slide, the router in the PIM domain with the highest configured priority becomes the BSR for the network. Set this priority using the bootstrap-priority command within the [edit protocols pim rp] configuration hierarchy. The possible values supported are 0 through 255. A value of 0 means that the local router is ineligible to become the BSR for the network. This value is the default setting within the Junos OS.
www.juniper.net
www.juniper.net
www.juniper.net
PIM Interfaces
The show pim interfaces command lists the configured and operational interfaces for PIM. Each interface contains the following information: Name: The name of the interface; Stat: The current status (Up or Down) of the interface; Mode: Whether the interface is in sparse only, dense only, or sparse-dense mode; IP: Which version of IP is supported on the interface (IPv4 is the default); V: Which version each interface is using (version 2 is the default); State: The current state of the interfaceoptions include P2P for all nonbroadcast-capable interfaces, DR if the interface is responsible for forwarding traffic, or NotDR if the interface is not responsible for forwarding traffic; Count: The number of PIM neighbors seen on the interface; and DR Address: The address on the network link of the current DR.
www.juniper.net
PIM Neighbors
The show pim neighbors command displays information about neighboring routers running PIM.
www.juniper.net
www.juniper.net
www.juniper.net
RPF Table
To determine which table the router is currently using for RPF checks, use the show multicast rpf command. The slide shows that the router is using inet.0 for RPF checks.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Always an SPT
The slide shows the resulting SPT between the source and a particular receiver for a particular channel (S,G) that yields optimal forwarding. Notice that R5 must maintain only (S,G) state for the SPT. It no longer needs to maintain (*,G) state for an RPT. Because any additional receivers will also specify a specific source, there is no need to maintain an RPT.
www.juniper.net
SSM Configuration
Notice that the PIM-SM configuration on the slide is minimal, with no RP configuration necessary. To support the SSM range of addresses, you must configure IGMPv3 on the receiver-facing interface of the receivers DR.
www.juniper.net
www.juniper.net
www.juniper.net
Review Questions
1. 2. 3. 4.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
What Is CoS?
The Junos operating system refers to all facets of quality of service (QoS) as CoS. CoS provides the ability to treat some packets differently as they transit a network. CoS is an end-to-end mechanism; enabling CoS on one router or one node does not provide the entire solution. CoS must be implemented in hops from the source to the destination. Any hop along the transit path of a packet could introduce latency.
www.juniper.net
CoS Components
The slide illustrates the primary components of CoS. When a packet arrives on the ingress interface of a network device performing CoS, the device examines certain IP header fields. CoS is able to use the IP header fields to differentiate various types of traffic into traffic classes. This process is known as classification. Multiple ways exist to classify traffic. Classification can be performed based on the first 6 bits of DiffServ code point (DSCP) values in the IP type of service (ToS) header, the first 3 bits of IP precedence values in the IP ToS header, and other IP header fields such as the source IP address, destination IP address, or port numbers. Classified packets are assigned to a forwarding class. Forwarding classes are assigned to output queues. In general, the device assigns packets to forwarding classes or output queues based on the classification of the packet. The slide depicts different classes of traffic being assigned to different queues. A physical interface contains multiple queues. Classified traffic is subject to policing. If the total traffic received is greater than what the interface can handle or is greater than the bandwidth of the interface, then some packets must be dropped. This bandwidth might not be the complete bandwidth of the interface. For example, assume traffic arrives at a 1 Gigabit Ethernet interface, but somewhere upstream exists a device interface that can handle only 10 Mbps. If the typical traffic load is more than 10 Mbps of traffic, some of that traffic will be dropped at the upstream device. Rather than dropping random voice and data packets, ensuring transmission of the most important 10 Mbps of traffic is better. A policer can provide this type of granular control. Continued on the next page. www.juniper.net Class of Service Chapter 105
www.juniper.net
www.juniper.net
Verify Markings
The engineers in the enterprise know that the VoIP clients are marking the traffic with the expedited forwarding (EF) DSCP value. In this slide, a firewall filter is created to match EF-marked traffic with an action to count. The filter is applied as input filter on the interface facing Site A. The counter increments, which confirms that the packets are coming in properly marked.
www.juniper.net
Default Classifier
When looking at the extensive interface output with the command show interfaces ge-0/0/1 extensive | find Queue counters, the engineers observe that all traffic is classified into the best-effort queue regardless of markings. The engineers also observed that the SRX Series device is dropping packets in this queue. When viewing the default classifier with the command show class-of-service classifier type inet-precedence name ipprec-compatibility, the engineers observed that the EF class is classified into the best-effort queue.
www.juniper.net
www.juniper.net
www.juniper.net
Bandwidth Reservation
The expedited-forwarding forwarding class is configured with a higher priority than the other queues and is reserved the remainder of the bandwidth, which is 12% based on this configuration.
www.juniper.net
Priority Queue
After committing the CoS configuration, the drops in the expedited-forwarding queue disappear and users stop complaining of poor voice quality. The queue counters are running counts; to get a fresh snapshot, clear the statistics with the clear interfaces statistics command. This action clears the statistics for all interfaces; you can optionally specify a particular interface you want to be cleared.
www.juniper.net
Priority Scheduler
In this slide, an ingress policer is created for EF class traffic. The policer reclassifies any traffic in excess of 2 Mbps into the best-effort queue. This is done to keep the EF-class traffic from starving the lower-priority queues. In SRX Series devices, the configured transmit-rate is only honored for queues in the same priority level. On an SRX Series device, a high-priority queue can starve other priorities unless it is rate-limited. The same is true for medium-high and medium, medium low, and so on down the priority chain. We discuss this behavior in subsequent slides.
www.juniper.net
www.juniper.net
2.
3.
4.
2.
3.
4.
www.juniper.net
Default Values
BA classification can be populated by default values. The operational command show class-of-service classifier displays all the default values and configured values.
www.juniper.net
www.juniper.net
Multifield Classifier
A multifield classifier is implemented through a firewall filter. You use this filter to perform multifield classification by associating a set of match criteria to a then forwarding-class action. To activate multifield classification, the filter is applied as an input filter on an ingress interface. Because BA classification is always performed first, you can always apply a multifield classifier in combination with any BA classifier. In case of conflict, the forwarding class associated with the BA match is overwritten by the multifield classifier's choice of forwarding class.
www.juniper.net
Rewrite Marker
One of the most important design goals for Enterprise CoS is to enable classification and marking close to the edge of the network. Doing so simplifies the classification logic and configuration on the rest of the routers in the network.
Default Markings
As with behavior aggregates, a rewrite configuration can be populated with the default values. These values can be viewed with the show class-of-service rewrite-rules operational command.
www.juniper.net
www.juniper.net
Per-Unit Scheduler
By default, when you apply a scheduler to an interface, it takes effect at the port, or interface device (ifd) level. This is fine when the port in question is configured with a single logical interface (ifl), such as would be the case when running Cisco High-Level Data Link Control (HDLC) or the Point-to-Point Protocol (PPP). However, when the interface is partitioned into multiple logical unitsfor example, as the result of adding virtual LAN (VLAN) taggingyou need to use the per-unit-scheduler option. This option provides fine-grained queuing by creating a set of queues and an associated scheduler for each logical interface.
www.juniper.net
Scheduler Configuration
In this slide, a scheduler named test is configured. The scheduler has a high priority, a transmit-rate of 50% of the total interface speed, and a buffer-size of 30% of the total interface buffer. A drop profile named high-drop is referenced for any packets that are marked with a loss-priority (PLP) of low. The scheduler is then mapped to the forwarding-class expedited-forwarding and applied to the ge-0/0/0 physical interface.
www.juniper.net
exact Option
You can, optionally, enforce the exact transmission rate or percentage you configure with the transmit-rate rate or transmit-rate percent statement. Under sustained congestion, a rate-controlled queue that goes into negative credit fills up and eventually drops packets. Note that, in the configuration, you cannot combine the remainder and exact options.
www.juniper.net
drop-profiles Configuration
On a previous slide, the scheduler referenced a drop profile named high-drop for any traffic with a loss-priority of low. Under the [edit class-of-service] hierarchy, a drop profile named high-drop is configured with a fill-level of 40% with a drop-probability of 0%, a fill-level of 50% with a drop-probability of 10%, and a fill-level of 70% with a drop-probability of 20%.
www.juniper.net
www.juniper.net
Default Classification
The Junos OS creates a complete set of BA classifier and rewrite marker tables for each supported protocol family and type, but most of these tables are not used in a default CoS configuration. For example, there is both a default IP precedence (two, actually) and a default DSCP classifier and rewrite table. You can view default and custom tables with the show class-of-service classifier or the show class-of-service rewrite-rule command. The default values in the various BA classifier and rewrite tables are chosen to represent the most common/standardized usage. In many cases, you will be able to simply apply the default tables. Because you cannot alter the default tables, it is suggested that you always create custom tables, even if they end up containing the same values as the default table. This does not involve much work, given that you can copy the contents of the default tables into a custom table and, in the future, you will be able to alter the custom tables as requirements change. In a default configuration, input BA classification is performed by the ipprec-compatibility table and IP rewrite is in effect. As a result, the ToS marking of packets at egress match those at ingress.
www.juniper.net
Policing
The slide highlights the topic we discuss next.
www.juniper.net
Token Based
To rate-limit traffic entering an interface, you can deploy a policer. Implemented policers are token based and use the IP packet to limit based on bandwidth and bursts. Bandwidth is measured as the average number of bits over a one-second interval.
Burst Size
The burst size will set the initial and maximum sizes of a bucket in bytes (tokens) that would be accessed each time data needs to be sent. As a packet is sent, the bucket bytes (tokens) are removed from the bucket. If there are not enough tokens to send the packet, the packet is policed. The bucket is then replenished at the bandwidth rate.
Policer Actions
Once the policer limits have been configured, you must choose the action taken if a packet exceeds the policer limit. Two types of policing are available: soft policing and hard policing. Hard policing specifies that the packet will be dropped if it exceeds the policer's traffic profile. Soft policing simply marks the packet or reclassifies the packet, which could change the probability of the packet being dropped at the egress interface during times of congestion. Soft policing is implemented by either setting the packet loss priority (PLP) setting on the packet or by placing the packet into a different forwarding class.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Virtual Channels
The slide highlights the topic we discuss next.
www.juniper.net
Virtual Channels
Virtual channels are used to ensure that a central site with a high bandwidth connection does not overrun remote sites that access the network at slower rates.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Note that the icmp-ping option is the default probe type on devices running the Junos OS. An RPM measurement can consist of multiple tests, each consisting of a different probe type and exchanged between a particular source-destination IP address pair. The interval between the probes and the tests is user configurable, as is the content of the probes data portion. The user can also control the number of probes that belong to a test. The probe packets are timestamped with the times at which they are sent and received at both the source and destination endpoints. Continued on the next page.
www.juniper.net
Timestamps
Timestamping is needed to account for any latency in packet communications. Timestamps are applied on the client, the server, or both the client and server. All nodes in the network must be synchronized to a common, accurate clock source (preferably a Stratum 3 level) using Network Time Protocol (NTP). The probe types that support timestamping functionality include: icmp-ping; icmp-ping-timestamp; udp-ping; and udp-ping-timestamp.
The timestamping activity consists of the source (client) node applying a timestamp to the RPM packets with the time at which they leave the node. The destination (server) node applies a second timestamp when it receives the probe and a third timestamp when the probe leaves the destination back to the source. The source receives the response and applies a fourth timestamp. Different metrics are calculated based on these timestamps collected from a series of probes.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Review Questions
1. 2. 3.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
RR3 has no way of knowing the routes received from RR2 came from RR1. As a result, RR3 sends them to RR1, forming a loop.
www.juniper.net
Cluster List
The cluster-list attribute is analogous to the AS-path attribute and is used to prevent loops. If an RR receives a route with its own cluster ID in the cluster list, it drops the route. In addition, each router in the network can use this attribute in the BGP path-selection algorithm prior to using the peer IP address attribute. BGP chooses the route with the shortest cluster list length. This process follows the same theory as the AS-path attribute. The cluster ID is very similar to an AS number and should be unique within an individual AS. The cluster ID is added to the cluster-list attribute when a route is sent to clients and nonclients.
Originator ID
The originator-ID attribute provides the router ID of the first router to advertise the route in the AS. It also is used for loop prevention in the rare case where the cluster list does not prevent a loop.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
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 clusters RR (RR1). The slide details how the 10.10.10.0/24 route is readvertised to all other clients in the cluster as well as to all nonclient IBGP peers of the RR. This process applies to all other routes the RR receives from a client in its cluster. This slide shows how the other RRs in the network (RR2 and RR3) readvertise all routes received from IBGP peers (the other reflectors in this example) to all of their cluster clients.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Review Questions
1. 2. 3. 4.
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
www.juniper.net
Chapter 2:
OSPF
1. LSA Type 9 supports graceful restart. 2. The metric or cost of a routers links can be automatically altered with the reference-bandwidth command. 3. The different forms of OSPF authentication include none, simple, and MD5.
Chapter 3:
OSPF Areas
1. The ABR does not forward Type 4 and Type 5 LSAs into a stub area or NSSA. Type 3 LSAs are also not forwarded in an OSPF NSSA with no summaries. 2. You must configure all routers that are in the stub area or NSSA. 3. The ABR of the stub area can optionally inject a 0.0.0.0/0 default route into the stub area or NSSA. 4. The backbone area is directly affected by the area-range command. However, any area that is able to receive summary LSAs also benefits from this command.
Chapter 4:
www.juniper.net
Chapter 5:
BGP
1. Using loopback addresses for peering sessions between IBGP neighbors maintains reachability even when the physical topology changes as long as a viable path exists. 2. EBGP-learned routes are advertised to both EBGP and IBGP peers. IBGP-learned routes are advertised to EBGP peers. However, IBGP-learned routes are not advertised to other IBGP peers to prevent routing loops. 3. With the Junos OS, all new BGP routes have an origin code of I=Internal. When you configure multipath on a BGP router, the route selection algorithm ignores both the router ID and the peer ID selection criteria. The five valid ways to solve the BGP next-hop issue are: Next-hop self; IGP passive interfaces; Export direct routes into IGP; Static routes; and IGP adjacency formed on inter-AS links to EBGP peers.
Chapter 6:
Chapter 7:
www.juniper.net
Chapter 8:
Introduction to Multicast
1. Two benefits of using multicast are that it reduces both the load on the source server and the bandwidth usage in a network. 2. The designated router (DR) is the router closest to the source that is responsible for forwarding multicast traffic. 3. The primary purpose of a multicast routing protocol is to build an SPT between sources and receivers. 4. IGMPv3 can be used by a host to request multicast traffic from a particular source.
Chapter 9:
Appendix A:
www.juniper.net
3. The no-client-reflect command can be used to stop excess advertisements. An RR readvertises routes received from clients and nonclients, adding the cluster-ID attribute and the cluster-list attribute. 4. An RR readvertises routes received from clients and nonclients, adding the cluster-ID attribute and the cluster-list attribute.
www.juniper.net