|
JUNOS Enterprise Routing
Written by the instructors and creators of the JNTCP-ER
Certification Exams, JUNOS Enterprise Routing is the only
comprehensive book for Juniper enterprise and edge routing
environments. It offers complete coverage of all the
services available to the JUNOS administrator, including
JUNOS Enhanced Services (ES).
This
book is the official study guide for all three Juniper
Enterprise Routing certification exams, and is highly
recommended reading to pass the exams. With its field-guide
emphasis on practical solutions, you can easily take the
book beyond the classroom and into working networks as a
design, maintenance, and troubleshooting reference par
excellence.
JUNOS Enterprise Routing covers all three certification
exams in this track:
Juniper Networks Certified Internet Associate (JNCIA-ER)
Juniper Networks Certified Internet Specialist (JNCIS-ER)
Juniper Networks Certified Internet Expert (JNCIE-ER)
With more services such as voice, conference, and multicast
on the IP router platform, the market for enterprise routers
is growing exponentially, and the need for certified
engineers to keep up with network developments in protocols
and security is paramount. For everyone who works with
Juniper enterprise and edge routing environments, this is a
must-have book.
CONTENTS:
When the founding engineers of Juniper decided to create routers, they took the view of forwarding packets as quickly as possible (line rate) with services enabled, which spawned the marketing decree "Service without Compromise."
All Juniper Networks routers share the same common design philosophy, which is to have a clean separation of the control and forwarding planes. In the M-series, this separation is created in hardware, whereas the J-series maintains this divide in software. The forwarding plane is referred to as the Packet Forwarding Engine (PFE), and the control plane is called the Routing Engine (RE).
The RE's primary functions are to manage the PFE, control the router's software (JUNOS), manage the command-line interface (CLI), provide troubleshooting tools, and maintain the route tables and the master forwarding table. This forwarding table is passed down to the PFE and is used to forward any transit packet to the next hop destination. In this way, the RE never has to be directly involved in packet forwarding (i.e., process switching), which allows more resources for the actual control functions (see ). One example is the ability to issue "debug" commands without degrading the performance of the routeThis chapter describes the interface configurations for a Juniper Networks router. It starts with a description of the types of interfaces, the naming conventions, and the interface properties. It then identifies how to configure a large variety of interface media, such as T1 interfaces, Fast Ethernet, and Serial interfaces. Lastly, we will examine common interface problems, concentrating on the tools available to detect these issues.
Before you begin to design a network's routing topology, you should ensure that all the proper physical connections are in place and are operational. With such a large variance in interface types, this can often be a challenging task, so it is important to understand how an interface is organized within the JUNOS software.
Juniper Networks routers contain two major categories of interfaces: permanent and transient. Users cannot remove permanent interfaces, whereas they can move, change, and remove transient interfaces. Other technical differences exist that are evident when you examine the applications for each interface type.
The interface topics covered in this chapter include:
*
Permanent interfaces
*
Transient interfaces
*
Interface properties
*
Interface configuration examples
*
Interface troubleshooting
This chapter is divided into two main sections. The first section details routing capabilities and features that are not specific to any particular routing protocol, hence the phrase protocol independent. Although termed independent, these features often interact with one or more routing protocols, and in some cases may be required for proper protocol operation! The second half of the chapter investigates JUNOS software routing policy. Routing policy provides a toolbox that facilitates the control of route distribution, including route filtering and route attribute manipulation.
In many cases, you combine the functions of Protocol Independent Properties (PIPs) and routing policy to achieve some goal. For example, a static route is defined using PIP, but this same static route can then be redistributed, perhaps with a modified attribute such as a route tag or Border Gateway Protocol (BGP) community, as a result of routing policy.
This chapter exposes the reader to PIP and routing policy in a manner that is analogous to a mechanic being introduced to each tool comprising a complete toolbox. To continue the analogy, the ways in which tools can be used, either alone or in combinations, are virtually limitless. For example, your hammer can be used as part of the repair of a hole in a boat's hull, or it can be used to make the hole, perhaps in an effort to scuttle the craft. Although the boat may have some opinion, it's safe to say that the tool - the hammer, in this case - is just happy to be used, with no real concern as to the nature of the task.
The routing and service examples covered in subsequent chapters of this book all make use of the PIP and policy tools to solve some requirement specific to the example being discussed in that chapter. Since practical PIP and policy-related applications are provided throughout the remainder of this book, the goal of this chapter is to expose the reader to the general capabilities and configuration of PIP and policy so that subsequent case study examples are fully understood.
The PIP topics include:
This chapter reviews key concepts and characteristics of Interior Gateway Protocols (IGPs) commonly deployed in enterprise networks. It starts with a brief description of the three most common enterprise IGPs and provides examples of IGP configuration and operational analysis in a JUNOS software environment. The chapter also discusses current best practices to minimize network disruption when migrating from one IGP to another, with configuration examples for Routing Information Protocol to Open Shortest Path First (RIP to OSPF) and Enhanced Interior Gateway Routing Protocol to OSPF (EIGRP to OSPF) migration. The topics discussed in this chapter include:
*
IGP overview
*
RIP deployment case study
*
IGP migration
*
RIP to OSPF migration case study
*
EIGRP migration case study
From an IGP perspective, a Juniper Networks router supports RIP, the OSPF protocol, and the Intermediate System-to-Intermediate System (IS-IS) routing protocols. This chapter does not address IS-IS given that it is normally seen in service provider networks and rarely is found in the enterprise.
It should be noted that Juniper Networks routers do not support the Cisco Systems proprietary Interior Gateway Routing Protocol (IGRP), or the updated version known as EIGRP. Technical merits aside, licensing restrictions combined with the closed nature of these protocols prevent Juniper Networks from implementing either of these IGPs. Given that IGRP/EIGRP was commonly deployed in many small to medium-size enterprises, a large portion of this chapter focuses on migration strategies designed to ease such a transition between the two vendors.
As its name would imply, the role of an IGP is to provide routing connectivity within or interior to a given routing domain (RD). An RD is defined as a set of routers under common administrative control that share a common routing protocol. An enterprise network, which can also be considered an autonomous system (AS), may consist of multiple RDs, which may result from the (historic) need for multiple routed protocols, scaling limitations, acquisitions and mergers, or even a simple lack of coordination among organizations making up the enterprise.
This chapter reviews the Border Gateway Protocol (BGP) version 4 operation and key attributes to accommodate a detailed discussion of BGP enterprise applications. BGP is all about the control of routing information between autonomous systems (ASs). Emphasis is placed on the use of routing policy to facilitate load balancing and common enterprise applications of inbound and outbound routing requirements when customers are dual-homed to different service providers. The topics covered include:
*
BGP overview and enterprise applications
*
External BGP (EBGP) peering with asymmetric load balancing
*
BGP policy for the enterprise
*
BGP dual-homing scenario with route reflection and outbound policy
*
Implementation of a dual-homed inbound policy by manipulating BGP attributes
Juniper Networks routers offer extensive feature support for BGP. In fact, the list of supported standards is too long to be valuable here. Consult the BGP overview in the JUNOS documentation to confirm the list of supported RFCs and drafts for your particular JUNOS software release.
BGP is an interdomain routing protocol, which means it operates between networks that are under different administrative control - making BGP an Exterior Gateway Protocol (EGP) that operates between ASs. An AS is defined as a group of IP networks operated by one or more network operators that has a single, clearly defined routing policy.
BGP is a path-vector routing protocol that relies on the uniqueness of AS path numbers for loop prevention. Rather than advertising a simple vector (prefix), as in the case of the Routing Information Protocol (RIP), BGP's reachability information is a prefix with associated attributes that describe the path to that prefix. The rich set of supported attributes in turn allows for an equally rich set of policy actions.
BGP is somewhat unique in that it uses a reliable Transmission Control Protocol (TCP)-based transport for its control and update messages. Reliable transport means there is no need for periodic route updates, which is really, really good, considering that a full BGP table typically comprises more than 220,000 routes! BGP does generate periodic keepalive traffic in the absence of route update activity to ensure that the underlying TCP transport is still functional. *
Static, aggregated, and generated routes
This chapter discusses the techniques of securing the router via different types of access security. Access security is a broad term that includes the creation of users with various authorization levels or allowing access to particular services or networks. Also included in access security is verifying that the router has not been compromised and is performing as you expected. The topics covered include:
*
Security concepts
*
Securing access to the router
*
Firewall filters and policers
*
Spoof prevention
*
Router monitoring
Everybody wants to have a secure network, but providing that security is often a very complex and difficult process due to the multiple levels that need to be examined. For example, it does not do much good if you provide very detailed filters and access privileges on a router, when the physical access is an unlocked door in a wiring closet at a remote location. Security must not be an afterthought; it must be designed literally from the ground up, from physical access to the network to filters that allow only certain types of traffic. When implementing security at any layer, design toward the security concepts that are displayed in : integrity, availability, and confidentiality. These concepts will help to build the network's circle of trust.
Once the routing aspect of a network has been deployed, you'll want additional services to be added to fit your network requirements. In the past, a separate device would have performed these types of services, but in modern networking these tasks have been moved to the router itself. Service is a broad term that can include tasks that are performed at Layer 2 (such as link bonding) or at Layer 3 (such as Network Address Translation [NAT]). We will examine all of these services in this chapter, as well as provide additional detail regarding more specific services throughout the book.
Because many of these services require intensive packet processing on the router, you may have to install additional hardware to avoid any degradation in packet forwarding and throughput. Although this may seem to be a slight nuisance at first, it does solve the problem of increased services causing decreased throughput, as is observed in most other router implementations.
The service topics covered in this chapter include:
*
JUNOS services
*
Layer 2 services
*
Layer 3 services
*
Layer 3 service command-line interface (CLI) configuration
*
Additional service options
The information covered in this chapter, and in , is based on services that are implemented via ASP on the M7i, or on the J-series through its emulation of ASP functionality. Starting with Release 8.5, Juniper Networks has made available its JUNOS software with enhanced services. The reader should be aware that the primary difference between JUNOS and JUNOS software with enhanced services relates to services. In the JUNOS software with enhanced services release, these services are based on ScreenOS functionality. Along with the improved services comes new configuration syntax.
Readers who are not deploying JUNOS software with enhanced services, or who will deploy both JUNOS software and JUNOS software with enhanced services, will need to know the ASP-based service configuration, as covered here and in . Readers who plan to deploy only JUNOS software with enhanced services should focus on the material covered in . Note that at this writing the Juniper Networks Certified Internet Expert (JNCIE-ER) examination is not based on JUNOS software with enhanced services, so readers interested in passing the JNCIE-ER examination will need to be familiar with ASP-based service definitions.We discussed the framework for JUNOS services in . This chapter will dive into more advanced scenarios and configurations. Often, you will need to use many Layer 3 services simultaneously, such as Network Address Translation (NAT), stateful firewall, and IPSec virtual private networks (VPNs), so you must plan properly to create transparent service additions.
The topics we will cover in this chapter include:
*
Route tables and next hop service sets
*
IPSec VPNs
*
NAT
*
Combined Layer 3 services
*
Packet flow
This chapter assumes that the reader grasps the concepts discussed in the preceding chapter; specifically, the types of service sets and command-line interface (CLI) configurations. If these concepts are unfamiliar, please review the preceding chapter.
When using a next hop service set, remember that the packet must go through the "two-legged table" of the inside and outside interfaces. Regardless of which interface the packet enters, two route table lookups will always be performed. To avoid a routing loop, the pre- and post-service lookups must return different next hop values. You can accomplish this in a few ways:
*
Implement virtual routers (VRs)
*
Use filter-based forwarding (FBF)
*
Perform destination NAT to change the destination address
VRs are the most preferred method, followed by FBF and destination NAT. VRs and FBF solve the double next hop issue by using multiple route tables, whereas destination NAT attempts to use a single route table.
With destination NAT, the forward direction can be fairly cut and dried, as demonstrates; simply perform a lookup on the original destination address, which causes the packet to be serviced, and then change the destination address and perform a second lookup on the new destination address to be used for forwarding. Issues arise in the reverse direction, where the destination address would normally stay the same. In this case, you would have to use a method such as FBF to solve this problem.
This chapter details M7i and J-series class of service (CoS) capabilities while also demonstrating typical CoS configuration and verification steps under JUNOS software. A detailed comparison between the ASIC-based M7i and the software-based J-series platform is provided to clarify their operational differences, which is a common source of confusion given that they have so many similarities. The topics covered include:
*
What IP CoS is and why it is needed
*
IP differentiated services primer
*
M7i and J-series CoS capabilities
*
DiffServ-based CoS deployment and verification
*
J-series virtual channels
Juniper Networks routers offer extensive support for IP CoS. As of this writing, the list of supported standards includes:
*
RFC 2474, "Definition of the Differentiated Services Field in the IPv4 and IPv6 Headers"
*
RFC 2597, "Assured Forwarding PHB Group"
*
RFC 2598, "An Expedited Forwarding PHB"
*
RFC 2698, "A Two Rate Three Color Marker"
Simply put, CoS provides a mechanism by which certain packets are afforded preferred treatment in an effort to provide the associated application with a level of performance required for proper operation. Although the preceding sentence seems simple enough, it implies support for several capabilities that must work together within each node - and in a consistent manner network-wide - for an IP CoS deployment to be successful.
IP networks are based on the principal of statistical multiplexing (stat MUX), which is a resource-sharing technique that allocates resources on an as-needed basis. A stat MUX provides efficiency gains by playing the odds that a given application or user will not be active at its peak rate 100% of the time. By allocating bandwidth resources only when needed, a large number of bursty applications can be supported over a network with an aggregate capacity that is significantly less than the potential aggregate rate of its user base.
To make all this work, some degree of buffering is needed to accommodate the occasional synchronized bursts. Because no network has infinite buffers, flow control (typically supported by a virtual circuit [VC] technology) or simple discard in the case of datagram operation (connectionless) is needed during chronic periods of congestion. Throwing more buffers at the problem only changes the symptom from one of discard to one of delay and delay variance, which is known as
This chapter explores typical enterprise deployment scenarios for IPv4 multicast. Focus is placed on the design and configuration of a scalable, fault-tolerant, multicast infrastructure using JUNOS software. Operational analysis and fault isolation are also demonstrated. The topics covered include:
*
Multicast terminology and concepts
*
Multicast protocols: group management and routing
*
Protocol Independent Multicast (PIM) sparse mode using static rendezvous points (RPs)
*
PIM sparse mode with bootstrap-based RP election
*
PIM and Multicast Source Discovery Protocol (MSDP)-based Anycast-RP
Juniper Networks routers offer extensive support for IPv4 multicast. Consult the multicast overview in the JUNOS software documentation to confirm the list of supported RFC and drafts for your software release.
Multicast defines the concept of a one-to-many communications stream. To a casual observer, multicast is similar to broadcast in that a single copy of a packet can be received by multiple nodes - however, multicast is not dependent on an underlying multiaccess medium. It can operate network-wide (unlike broadcast traffic that is not forwarded by routers), and is associated with protocols that attempt to automatically tune the network to eliminate unnecessary transport and delivery of multicast traffic.
Routers use multicast routing protocols to control the forwarding of multicast traffic to prevent loops and avoid inefficiencies associated with having multiple copies of a given packet transmitted over the same link multiple times. Multicast group membership protocols are used by hosts to express interest in one or more multicast groups - multicast traffic is not forwarded over an interface with attached hosts unless at least one host has explicitly requested the receipt of multicast traffic.
When all goes to plan, the presence of multicast traffic is noted only by those nodes that have expressed interest in that particular stream, which is in marked contrast to a link-level broadcast that forces reception of the packet by all nodes on that link. In summary, broadcast is one-to-all with a link-level scope, whereas multicast is one-to-many, network-wide, but only when there is express interest in receiving multicast.The release of JUNOS software with enhanced services represents a significant step forward in solving the needs of enterprise networks. This chapter is not intended to provide complete coverage of the new capabilities associated with JUNOS software with enhanced services. The goal is to prepare the reader for what is coming by providing a high-level overview of what JUNOS software with enhanced services is, detailed information on how to migrate from JUNOS to JUNOS software with enhanced services, and a before-and-after case study showing an Adaptive Services PIC (ASP)-based service set that is migrated to the new enhanced services format, along with the steps needed to validate their operation.
The JUNOS software with enhanced services topics include:
*
An overview of JUNOS software with enhanced services
*
Migrating from JUNOS to JUNOS software with enhanced services
*
An enhanced services case study
Starting with Release 8.5, you have the option of deploying JUNOS software with enhanced services on supported platforms to take advantage of significant security and service enhancements. It's important to note that even when running JUNOS software with enhanced services, JUNOS is JUNOS, and therefore, the majority of the platform concepts, command-line interface (CLI) commands, operational troubleshooting, and so on remain as covered throughout this book. This is especially true of routing protocol configuration and operational verification, which remains as before and is "classic" JUNOS all the way.
This is not a security-focused book, and therefore, comprehensive coverage of the JUNOS enhanced security and services feature set is not possible. This chapter covers migration of a production router from JUNOS to JUNOS software with enhanced services, and gets you familiar with what is different in the new set of enhanced services. It is expected that JUNOS software with enhanced services will continue to evolve, resulting in ongoing updates and additions to the enhanced services portfolio.
|
