959 Juniper MX Series ebook Free download


3 months ago
Full text

Table of Contents

  24 Trio Architecture 47 46 Switch and Control Board 44 Network Services 41 Modular Interface Card 32 Packet Walkthrough 31 Modular Port Concentrator 30 Dense Port Concentrator 30 Line Cards and Modules 28 Dense Queuing Block 27 Interfaces Block 26 Lookup Block 25 Buffering Block About the Authors . 235 233 231Chapter Review Answers 230Chapter Review Questions 213Filter Processing in Bridged and Routed Environments 213Monitor and Troubleshoot Filters and Policers 214Bridge Family Filter and Policing Case Study 221Summary Policer Application Restrictions 212Bridge Filtering Case Study Applying Policers200 Filter Application Points195 192Applying Filters and Policers 195 180Cascaded Policers Virtual Switch144 178Basic Policer Example Rate Limiting: Shaping or Policing?

About the Authors

  Prior to joining Juniper, Harry served in the US Navy as an Avionics Technician, worked for equipment manufacturer MicomSystems, and spent much time developing and presenting hands-on technical training curricula targeted to both enterprise and service provider needs. When the testing and writing is done(a rare event, to be sure), Harry can be found in his backyard metal shop trying to make Japanese-style blades.

About the Lead Technical Reviewers

  Stefan Fouant is a Technical Trainer and JNCP Proctor at Juniper Networks with over 15 years of experience in the networking industry. His first exposure to Junos was withJunos 3.4 on the original M40 back in 1998, and it has been a love affair ever since.

About the Technical Reviewers

Proof of Concept Laboratory

  They are, in the authors’ opinion, some of smartest and most capable networking people around. In addition, the authors humbly thank the POC Lab in Sunnyvale, California, where the test bed for this book was cared for and fed by Roberto Hernandez, Ridha Hamidi,and Matt Bianchi.


  The industry is moving to high-speed, high port-density Ethernet- based routers, and the Juniper MX was designed from the ground up to solve thesechallenges. This book is going to show you, step-by-step, how to build a better network using theJuniper MX—it’s such a versatile platform that it can be placed in the core, aggregation, or edge of any type of network and provide instant value.

No Apologies

  There was a conscious decision made between the authors to keep the technical quality of this book very high; this created a constant debate whether or not to include primeror introductory material in the book to help refresh a reader’s memory with certain technologies and networking features. If you want to learn more about spanning Basic Firewall Filters We decided to skip the basic firewall filter introduction and jump right into the advanced filtering and policing that’s available on the Juniper MX.

Book Topology

  Using the same methodology found in the JNCIP-M and JNCIE-M Study Guides, this book will use a master topology and each chapter will use a subset of the devices thatare needed to illustrate features and case studies. For the sake of clarity and readability, the master topology has been broken into five figures, Figure P-1 through Figure P-5 : Interface Names, Aggregate Ethernet Assign-ments, Layer 2, IPv4 Addressing, and IPv6 Addressing.

What’s in This Book?

  Junos is the “secret sauce” that’s common throughout all of the hardware; this chapter will take a deep dive into the control plane and explainsome of the recent important changes to the release cycle and support structure ofJunos. Chapter 5, Trio Class of Service This chapter answers the question, “What is hierarchical class of service and why do I need it?” The land of CoS is filled with mystery and adventure; come join Harry and discover the advantages of hierarchical scheduling.

Conventions Used in This Book

  Constant width Indicates commands, options, switches, variables, attributes, keys, functions, types, classes, namespaces, methods, modules, properties, parameters, values,objects, events, event handlers, XML tags, macros, the contents of files, and the output from commands. Constant width bold Shows commands and other text that should be typed literally by the user, as well as important lines of code.

Using Code Examples

  As with most deep-dive books, the reader will be exposed to a variety of hidden, Junos Shell, and even MPC-level VTY commands performedafter forming an internal connection to a PFE component. The hidden and shell commands that are used in this book were selected because they were the only way to illustrate certain operational charac-teristics or the results of complex configuration parameters.

Safari® Books Online

  Safari Books Online ( www.safaribooksonline.com ) is an on-demand digital library that delivers expert content in both book and video form from theworld’s leading authors in technology and business. Safari Books Online offers a range of product mixes and pricing programs for organizations , government agencies , and individuals .

How to Contact Us

  Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc. 1005 Gravenstein Highway NorthSebastopol, CA 95472800-998-9938 (in the United States or Canada)707-829-0515 (international or local)707-829-0104 (fax) We have a web page for this book, where we list errata, examples, and any additional information.

CHAPTER 1 Juniper MX Architecture Back in 1998, Juniper Networks released its first router, the M40. Leveraging Appli-

  The“M” still refers to the multiple services heritage, while the “X” refers to the new switch- ing capability and focus on 10G interfaces and beyond; it’s also interesting to note thatthe Roman numeral for the number 10 is “X.”It’s no easy task to create a platform that’s able to solve these new challenges. Features that you have come to know and love on the M and T Series are certainly present on the MX Series as it runs on the same image of Junos.


  Junos is a purpose-built networking operating system based on one of the most stable and secure operating systems in the world: FreeBSD. Junos is designed as a monolithickernel architecture that places all of the operating system services in the kernel space.

One Junos

Software Releases

  The last release of Junos in the calendar year is known as the Extended End of Life (EEOL), and this release is sup-ported for 36 months. Junos End of Engineering and End-of-Life scheduleRelease Target End of Engineering End of LifeJunos 12.1 March 24 months + 6 months Junos 12.2 July 24 months + 6 months Release Target End of Engineering End of LifeJunos 12.3 November 36 months + 6 months By extending the engineering support and reducing the number of releases, network operators should be able to reduce the frequency of having to upgrade to a new releaseof code.

Software Architecture

  Junos software architecture At a high level, the control plane is implemented entirely within the routing engine while the forwarding plane is implemented within each PFE using a small, purpose-built kernel that contains only the required functions to route and switch traffic. The benefit of control and forwarding separation is that any traffic that is being routed or switched through the router will always be processed at line-rate on the PFEs andswitch fabric; for example, if a router was processing traffic between web servers and the Internet, all of the processing would be performed by the forwarding plane.


  One feature of Junos is being able toconfigure nonexistent hardware, as the assumption is that the hardware can be added at a later date and “just work.” An example is the expectation that you can configure set interfaces ge-1/0/0.0 family inet address and commit. At a high level, this includes monitoring the health of hardware, managing areal-time database of hardware inventory, and coordinating with the alarm daemon ( alarmd ) and the craft daemon ( craftd ) to manage alarms and LEDs.

Routing Sockets

  {master} dhanks@R1-RE0> start shelldhanks@R1-RE0% rtsockmon -st The author configured the interface in a different terminalge-1/0/0window and committed the change while the rtstockmon command was running.rtsockmon The command is a Junos shell command that gives the user visibility into the messages being passed by the routing socket. The rtsockmon command is only used to demonstrate the functionality of routing sockets and how daemons such as dcd and rpd use routingsockets to communicate routing changes to the Junos kernel.

Juniper MX Chassis

  Juniper MX Series capacity (Based on current hardware)Model DPC Capacity MPC Capacity 80 Gbps MX240 240 Gbps 1.280 TbpsMX480 480 Gbps 3.84 Tbps MX960 960 Gbps 7.68 Tbps MX2020 N/A The MX960 can accept up to 12 DPC line cards; using the 4x10GE DPC in the Ta- ble 1-2 calculations, you can come up with the following calculation: 40 Gbps * 2 (full-duplex) * 12 (maximum number of line cards on the MX960) = 960 Gbps. Using the same calculation for the MPC capacity, the 32x10GE MPC line card can be used with the following calculation:320 Gbps * 2 (full-duplex) * 12 (maximum number of line cards on the MX960) = 7.640 Tbps.


  If the MX80 is still too big of a router, there are a selection of licensing options to restrict the number of ports on the MX80. The benefit is that you get all of the performanceand scaling of the MX80, but at a fraction of the cost.


  Juniper MX240 The MX240 is the first router in the lineup that has a chassis that supports modular routing engines, SCBs, and FPCs. The next slot up is a special slot that supportseither a SCB or FPC, and thus begins the FPC numbering at 0.


  TheMX480 tends to be the most popular in enterprise because six slots is the “sweet spot.”Like its little brother, the MX480 requires two SCBs and routing engines for full re- dundancy. In the case where the chassissupports either an SCB or FPC in the same slot, such as the MX240 or MX960, the keying will allow for both.


  The SCBs and FPCs are installed vertically into the chassis so that it can support 14 slots side to side. If you like living life on the edge and don’t need redundancy, the MX960 requires at least two SCBs to switch the available 12 FPCs.


  The key differentiator is that Trio has the performance of a traditional ASIC, but the flexibility of a field-programmable gate array (FPGA) by allowing the installation of new features via soft- ware. Here is just an example of the inline services available with the Trio chipset: Trio Architecture The Trio chipset comprises of four major building blocks: Buffering, Lookup, Inter- faces, and Dense Queuing.

Buffering Block

Lookup Block

  In the scenario where the number of revenue ports on a single MIC is less than 24x1GE or 2x10GE, it’s possible to move the handling of oversubscription to the InterfacesBlock. Once theLookup Block has finished processing, it sends the modified packet headers back to the Buffering Block to send the packet to its final destination.

Interfaces Block

  Preclassification allows the ability to drop excess packets as close to the source as possible, while allowing critical control plane packetsthrough to the Buffering Block. MICs such as the 4x10GE do not have an Interfaces Block, so the preclassification is performed on the BufferingBlock, or, as listed here, the “MQ_engine.” The author has used hidden commands to illustrate the roles and re- sponsibilities of the Interfaces Block.

Dense Queuing Block

Line Cards and Modules

  For example, the MPC-3D-16x10GE-SFPP line card is a fixed port configura-tion, but only uses the Buffering Block and Lookup Block in the PFE complex. As new line cards are introduced in the future, the number of fundamental Trio building blockswill vary per card as well, thus living up to the “modular” name.

Dense Port Concentrator

  The DPCE-X has the same features and services as the DPCE-R; the main difference is that the route table is limited to 32,000 prefixes and cannot use L3VPNs on this DPC. The DPCE-Q supports all of the same features and services as the DPCE-R and adds additional scaling around H-QoS and number of queues.

Modular Port Concentrator

  Modular port concentrator modelsModel # of Trio chipsets Trio Bandwidth Interface SupportMPC1 1 40 Gbps 1GE and 10GE MPC2 2 80 Gbps 1GE and 10GE MPC3E1 130 Gbps 1GE, 10GE, 40GE, and 100GE The MPC3 is the first of many more MPCs that will use an enhanced Trio chipset that is designed to support 40G and 100G interfaces. It’s important to note that the MPC bandwidth listed previously repre- sents current-generation hardware that’s available as of the writing ofthis book and is subject to change with new software and hardware releases.

Packet Walkthrough

  Now that you have an understanding of the different Trio functional blocks and the layout of each line card, let’s take a look at how a packet is processed through each ofthe major line cards. The packet is sent back to the Buffering Block and is enqueued into the switch fabric where it will be destined to another PFE.

Modular Interface Card

  As described previously, the MICs provide the physical ports and are modules that are to be installed into various MPCs. MICs offer the greatest investment protection as they’re able to be used across all of the MX platformsand various MPCs.

Network Services

  Because there are many different variations of DPC, MPC, Ethernet, and routing options, a chassis controlfeature called network services can be used force the chassis into a particular compat- ibility mode. If the network services aren’t configured, then by default when a MX chassis boots up, the FPC that is powered up first will determine the mode of the chassis.

Switch and Control Board

  At the heart of the MX Series is the Switch and Control Board (SCB). The SCB is a single- slot card and has a carrier for the routing engine on the front.

Ethernet Switch

  The first NIC is connected to the local onboard Ethernet switch, whereas the second NIC is connected to the onboard Ethernet switch on the other SCB. When an ingress PFE re-ceives a packet that needs additional processing—such as a BGP update or SSH traffic destined to the router—the packet needs to be encapsulated and sent to the routingengine.

Switch Fabric

  MX-SCB fabric plane scale and redundancy assuming four PFEs per FPC PFEs 12 24 48 SCBs 2 2 3 Switch Fabrics 4 4 6 Fabric Planes 8 8 6 Spare Planes 4 (1 + 1 SCB redundancy) 4 (1 + 1 SCB redundancy) 2 (2 + 1 SCB redundancy)MX240 and MX480 Fabric Planes Given that the MX240 and MX480 only have to support a fraction of the number ofPFEs as the MX960, we’re able to group together the unused connections on the switch fabric and create a second fabric plane per switch fabric. Typically, each SCB will have the same uptime as the system itself, but it’s possible to hot-swap SCBs during a maintenance; the new SCB wouldthen show a smaller uptime than the others.


  The only drawback when segmenting variable data into a fixed-widthunit is the waste, referred to as “cell tax.” For example, if the router needed to segment a 65-byte packet, it would require two J-cells: the first J-cell would be fully utilized, thesecond J-cell would only carry 1 byte, and the other 63 bytes of the J-cell would go unused. J-Cell Format There are some additional fields in the J-cell to optimize the transmission and process- ing: J-Cell Flow As the packet leaves the ingress PFE, the Trio chipset will segment the packet into J- cells.

MX Switch Control Board The MX SCB is the first-generation switch fabric for the MX240, MX480, and MX960

  First-Generation SCB bandwidthModel SCBs Switch Fabrics Fabric Planes Fabric Bandwidth per SlotMX240 2 4 8 160 Gbps MX480 2 4 8 160 Gbps MX960 3 6 6 120 GbpsMX SCB and MPC Caveats The only caveat is that the first-generation MX SCBs are not able to provide line-rate redundancy with some of the new-generation MPC line cards. When the MX SCB and MPCs are being used on the MX240and MX480, there’s no loss in performance and all MPCs are able to operate at line rate.

Enhanced MX Switch Control Board

  Because the MX SCBE is twice the performance of the previous MX SCB, the MX960 can now go back to the original 2 + 1 SCB for full line-rate performance and redundancy. The big difference is that now four of the planes are Online while the other four are 7 Spare 5 hours, 54 minutes, 30 seconds Much better.



  The bottom inlet plenum supplies cool air from the front of the chassis and the bottom fan trays forcethe cool air through the bottom line cards; the air is then directed out of the back of the chassis by a diagonal airflow divider in the middle card cage. The middle inlet plenum supplies cool air from the front of the chassis and the upper fan trays push the cool air through the upper card cage;the air is then directed out the back of the chassis.


  By distributing these types of features out to the data plane, the control plane doesn’t become a bottleneck and the system is to scale with ease and canrestore service in under 50 ms. The line cards account for the bulk of the investment in the MX family, and a nice investment protection isthat the line cards and MICs can be used in any Juniper MX chassis.

Chapter Review Questions

  What’s the purpose of the Ethernet switch located on the SCB? What J-cell attribute is used by the destination PFE to reassemble packets in the correct order?a.

Chapter Review Answers

  The last major release of Junos of a given calendar year is known as the Extended End of Life (EEOL) release and is supported for three years. Throughout this chapter, you’ll find that features such as bridge domains, learning domains, and VLAN mapping are tightly integrated,and it may be a bit challenging to follow the first time through; however, as you reread the chapter a second time, many features and caveats will become clear.

Isn’t the MX a Router?

  Let’s take the scenario tothe next level and think about adding multiple Layer 3 networks so the requirement is to support multiple Layer 2 and Layer 3 networks on the same physical interface thathas overlapping VLAN IDs, MAC addresses, and IP addresses. Traditional switch compared to the Juniper MX On the left of Figure 2-1 is a traditional switch that simply supports a single Layer 2 network; within this Layer 2 network is support for 4,094 VLAN IDs and some IRBinterfaces.

Layer 2 Networking

  This chapter in- troduces a lot of new topics related to Layer 2 switching in the MX, and it’s critical thatyou have an expert understanding of the underlying protocols. A Layer 2 network, also known as the data link layer in the seven-layer Open Systems Interconnection (OSI) model, is simply a means to transfer data between two adjacent network nodes.

Ethernet II

  The SFD is a single octet of 1010 1011 to signal the end of the preamble, and the next bit is immediately fol-lowed by the destination MAC address. If the checksum calculated by the re-ceiving node is different than the FCS field on the Ethernet frame, this indicates an error occurred in the transmission of the frame and it can be discarded.

IEEE 802.1Q

  Now let’s take a look at how it’s possible for an Ethernet II frame to suggest which VLAN it would like to be in because, as you will see later in this chapter, it’s possible to configure the MX to normalize and change VLAN IDs regardless of the IEEE 802.1Qheader. Notice that both the EtherType in the original Ethernet II frame and the new TPID field in the new IEEE 802.1Q frame begin at the exact same bit position.

IEEE 802.1QinQ

  What you end up with are the following frame formats: Customer Orange S-TAG = 100, C-TAG = 555 Customer Blue S-TAG = 200, C-TAG = 1234 Maximum of 4,094 customers or S-TAGs Because each customer would be mapped to an S-TAG, the maximum number of customers supported would be the 4,094. MAC learning Because the customer destination and source MAC addresses are still present in the IEEE 802.1QinQ frame, all of the equipment in the Service Provider networkmust learn every host on every customer network.

Junos Interfaces Before discussing bridging, a closer look at how Junos handles interfaces is required

  As you move into the finer points of bridging and virtualizationwithin the MX, it’s critical that you have a clear understanding of how interfaces are created and applied within bridge domains, routing instances, and other features. This is the root of the hi- erarchy and all other components are defined and branched off at this point.

Interface Bridge Configuration

  The obvious benefit is that all bridging features are available and can be arranged in any shape and size to provide the perfect Ethernet-based servicesfor customers. Because the re-quirements are so simple and straightforward, the Juniper MX offers a simplified and condensed method to configure Layer 2 interfaces.

Basic Comparison of Service Provider versus Enterprise Style

  Enterprise Style This style is very straightforward and doesn’t require explicit configuration of every feature, which reduces the amount of configuration required, but as you will see laterin this chapter, also limits the number of features this style is capable of. When you commit the configuration, Junos will automatically parse the in-terface structure, identify any interfaces using the Enterprise-style configuration, and place each interface into the appropriate bridge domain based off the vlan-id whenusing IEEE 802.1Q and based-off the inner VLAN IDs when using IEEE 802.1QinQ.

Service Provider Interface Bridge Configuration

  It’s very common for Service Providers to have multiple customers connected to the same physical port on Provider Equipment (PE). For example, a customer may have the following requirements: IEEE 802.1Q and 802.1QinQ VLAN mapping or forcing IFLs into a particular bridge domain without relying on Junos to make bridge domain determinations.


  If the goal is to reduce the size of the configuration, and you do not need any advanced VLAN mapping, you might want to consider using theEnterprise-style interface configuration (covered in detail later in the chapter). Notice that the keyword is applied to the IFD; the other big change is that each IFL is no longer using the vlan-id option, but insteadnow uses the vlan-tags option.


  Let’s take a look at one of those previous example and review the encapsu- lation type: interfaces { ae5 {flexible-vlan-tagging; encapsulation extended-vlan-bridge;unit 100 { When using the extended-vlan-bridge encapsulation type, it can only be applied to the IFD. The only caveatin creating a pure untagged port is that it can only contain a single IFL and the vlan- id must match the native-vlan-id of the IFD:interfaces { ae5 {flexible-vlan-tagging; native-vlan-id 100;encapsulation flexible-ethernet-services; unit 0 {encapsulation vlan-bridge; vlan-id 100;} }} This configuration allows the interface ae5.0 to receive and transmit untagged frames.

Service Provider Bridge Domain Configuration

  It isn’t enough to simply refer to the vlan-id in the IFL configu-ration. Currently, ae5.100 is configured with a vlan-id of 100, so let’smove it into a bridge domain with a vlan-id of 200: bridge-domains { bd-100 {vlan-id 100; interface xe-0/0/0.0;} bd-200 {vlan-id 200; interface ae5.100;interface ae5.200; }bd-300 { vlan-id 300;interface ae5.300; }} This should be interesting.

Enterprise Interface Bridge Configuration

  The icing on the cake is that you no longer have to specify which bridge domain each interface belongs to; this happens automatically on commit, but it doesn’t actuallymodify the configuration. Junos will walk the interface tree and inspect all of the En- terprise-style IFLs, look and see which VLAN IDs have been configured, and automat-ically place the IFLs into the matching bridging domain.

Interface Mode

  And there’s no need to fiddle with VLAN tagging options, as the interface-mode will take care of this automatically:interfaces { xe-0/0/0 {unit 0 { family bridge {interface-mode trunk; vlan-id-list 1-4094;} }} }bridge-domains { VLAN-100 { vlan-id 100;} VLAN-200 { vlan-id 200; } } To define which bridge domains the trunk participates in, you need to use the vlan- id-list option and specify the VLAN IDs. When Junos walks the interface tree and determines which bridge domain to place the IFL with the Enterprise-style interface configuration, all IFLs with dual tags will be placed into a bridge domain based off of their C-TAG(s) or IFL vlan-id .

VLAN Rewrite

  The problem is that the VLAN ID being usedby the downstream device conflicts with an existing VLAN ID being in your network and you’re unable to modify this device. Let’s createa scenario where you need to rewrite VLAN ID 100 to 500 and vice versa: interfaces { ae0 {unit 0 { family bridge {interface-mode trunk; vlan-id-list 500;vlan-rewrite { translate 100 500;} }} }ae1 { unit 0 {family bridge { interface-mode trunk;vlan-id-list 500; }} }} The keyword in the configuration is vlan-rewrite .

Stack Data Structure

  As new tags are applied to the frame, the last tag to be addedwill be at the top of the stack. The last frame to be added will be the first tag to be removed, while the first tag that was added will be the last to be removed.

Stack Operations

  As you walk through each operation, keep in mind that the top of stack is considered the tagand the bottom of the stack is considered the innermost tag in the frame, as noted in Figure 2-14 :Figure 2-14. The first operation is to swap/exchange the outermost tag with a user-specified tag, and the next operation is to push a new user-specified tag to the frame, asshown in Figure 2-21 .

Tag Count

  But the secret here is that when you define a vlan-id or vlan-tags inside of a bridge- domain , it’s actually just a macro for creating automatic VLAN mappings. For example, if you createa bridge-domain called APPLICATION with a vlan-id of 100, and include an interface of ae.200 with a vlan-id of 200, all frames on interface ae.200 will be swapped with VLAN ID 100.

Example: Push and Pop

  When you want to perform IEEE 802.1QinQ and add a S-TAG, it’s very easy to push an S-TAG onto an ingress frame from the customer edge (CE) and pop the S-TAG when sending egress frames destined to the CE, as shown in Figure 2-25 . This frame is destined back to the CE so it will have to egress the interface ae0.0 .

Example: Swap-Push and Pop-Swap

  Remember that at a high level, the only purpose of input-vlan-map and output-vlan-map is to apply a consistent and reversible VLAN map to ingress and egress frames. interfaces { ae5 {flexible-vlan-tagging; encapsulation flexible-ethernet-services;unit 2 { encapsulation vlan-bridge;vlan-id 2; input-vlan-map {swap-push; inner-tag-protocol-id 0x8100;vlan-id 5; inner-vlan-id 4;} Now let’s take a look at how the packet is transformed as it ingresses and egresses interface ae5.2 , as shown in Figure 2-27 .

Bridge Domains

  Learning hierarchy of Juniper MX bridging Because the MX allows for advanced customization of bridging, it was best to start at the bottom and work up through interface hierarchy, configuration styles, and finally VLAN mapping. A bridge domain is simply a set of IFLs that share the same flooding, filtering, and forwarding characteristics.

Learning Domain

  Let’s take a look at how to create a default bridge domain with a single learning domain, using VLAN IDs of 100 and 200 and naming them appropriately: dhanks@R2-RE0> show configuration bridge-domains VLAN100 { vlan-id 100;routing-interface irb.100; } VLAN200 { vlan-id 200;routing-interface irb.200; }bridge-domain The bridge domains are created under the hierarchy, calling our bridge domains VLAN100 and VLAN200 . Now let’s take a look at a couple of show commands and see the bridge domain to learning domain relationship: dhanks@R2-RE0> show bridge domain Routing instance Bridge domain VLAN ID Interfacesdefault-switch VLAN100 100 ae0.0 ae1.0ae2.0 default-switch VLAN200 200 ae0.0ae1.0 ae2.0default-switch As expected, the bridge domains under the routing instance with a VLAN ID of 100 and 200.

Bridge Domain Modes

  Regardless of the VLAN ID and the number of tags on an IFL, the bridge domain mode none only has a single learning domain. When it receives ingress frames, it needs to perform a The automatic In function is using the pop operation to clear the single tag so that the frame becomes untagged as it’s switched through the bridge.

Dokumen baru